SQL 주입은 일반적으로 Spring/Hibernate 설정에서 멈 춥니 다.

정적으로 입력되지 않았기 때문에 Ruby 언어가 싫지만 Spring/Hibernate에서 보내는 시간이 많을수록 Ruby on Rails의 기능이 더 좋아집니다. 특히 액티브 레코드 모델이 SQL 주입을 방해한다는 사실. 이 문제는 대개 Spring/Hibernate 스택에서 어떻게 처리됩니까? 어느 쪽이든 사용자 입력이 안전한지 확인하기 위해 일종의 스크러빙 툴킷이 제공됩니까?SQL 주입은 일반적으로 Spring/Hibernate 설정에서 멈 춥니 다.

DAO를 삽입하는 경우 삽입시 많은 문제가 발생하지 않지만 Select 문을 사용할 때 중요한 문제입니다.

출처

2011-01-27 John Baker

최대 절전 모드를 사용할 때 SQL 삽입은 위험하지 않아야합니다. 정상적으로 사용하는 한.

Hibernate 쿼리는 HQL (Hibernate의 SQL과 유사한 쿼리 언어)로 작성되거나 객체 지향 Criteria API를 사용하여 구현됩니다.

HQL이 가장 일반적이며 가장 권장됩니다. Hibernate는 매개 변수로 문자열에 전달하기 때문에, 당신은 SQL 주입으로부터 보호하는이 양식에서

Subscription sub = (Subscription) sessionFactory.getCurrentSession() 
     .createQuery("from Subscription sub where sub.verification = :verification") 
     .setString("verification", verification) 
     .uniqueResult();

; 일반적으로이 같은 HQL 쿼리를 작성합니다 그것은 SQL의 일부로 해석 될 수 없습니다.

그러나 당신은 쓰기를 심하게

Subscription sub = (Subscription) sessionFactory.getCurrentSession() 
     .createQuery("from Subscription sub where sub.verification = '" + verification + "'") 
     .uniqueResult();

... 다음 SQL 주입으로부터 보호하지 않는이 같은 쿼리를 ... 행동합니다. 그러나 이런 식으로 쿼리를 작성해서는 안됩니다! 문자열을 쿼리에 추가하면 모든 프레임 워크가 보호되지 않을 것이라고 생각합니다.

마지막으로 Hibernate Criteria API를 사용하면 자동으로 SQL 삽입으로부터 보호됩니다. Criteria API를 사용할 때 Hibernate가 기본 쿼리를 빌드하기 때문에 SQL 인젝션을 방해하는 방식으로 Hibernate가이를 수행하기 때문이다.

출처

2011-01-27 02:19:22 gutch

당신이 궁금한 점에 답을 얻은 것 같습니다. HQL 만 최후의 수단으로 사용한다면 잠재 공격 지점의 95 %가 줄어들 것입니다. 그리고 그 까다로운 가장자리 경우에만 사용하기 때문에 실제로하는 일에 더 많은 관심을 기울일 것입니다.

출처

2011-01-27 01:17:02 CurtainDog

SQL 주입은 일반적으로 Spring/Hibernate 설정에서 멈 춥니 다.

답변

관련 문제