모든 사람은 SQL 주입에 익숙합니다. 일반적인 공격 방법입니다. 공격자는 "또는 '1'= '1'"문과 같은 인터페이스의 양식 정보 또는 URL에 이상한 SQL 조각을 입력하며, 이는 매개 변수 검증 불충분 한 응용 프로그램을 침범 할 수 있습니다. 따라서 이러한 공격 방법을 방지하기 위해 응용 프로그램에서 작업을 수행해야합니다. 뱅킹 소프트웨어와 같은 보안이 높은 일부 응용 프로그램에서는 종종 SQL 주입을 방지하기 위해 모든 SQL 문을 저장 절차로 바꾸는 방법을 사용합니다. 이것은 물론 매우 안전한 방법이지만, 우리는 일상적인 개발 에이 엄격한 방법이 필요하지 않을 수 있습니다.
반자동 지속성 층 프레임 워크로서, mybatis 프레임 워크는 스스로 수동으로 작성해야합니다. 물론 현재 SQL 주입을 방지해야합니다. 실제로 Mybatis의 SQL은 다음과 같이 함수와 유사한 "입력 + 출력"함수가있는 구조입니다.
<select id = "getBlogById"resultType = "blog"parameterType = "int"> <br> id, 제목, 저자, 블로그에서 id =#{id} </select>를 선택하십시오. 여기서는 ParameterType가 입력 매개 변수 유형을 나타내고 resultType는 출력 매개 변수 유형을 나타냅니다. 위의 응답으로 SQL 주입을 방지하려면 자연스럽게 매개 변수를 입력하는 데 열심히 노력해야합니다. 위 코드의 강조 표시된 부분은 입력 매개 변수가 SQL에 스 플라이 싱되는 부분입니다. 매개 변수를 전달한 후 실행 된 SQL 문을 인쇄하면 SQL이 다음과 같습니다.
ID, 제목, 저자, 블로그에서 id =?
어떤 매개 변수를 입력하든 인쇄 된 SQL은 다음과 같습니다. MyBatis가 사전 컴파일 함수를 활성화하기 때문입니다. SQL이 실행되기 전에 위의 SQL은 컴파일을 위해 데이터베이스로 전송됩니다. 실행 중에 컴파일 된 SQL을 직접 사용하여 자리 표시 자 "?"를 교체 할 수 있습니다. SQL 주입은 컴파일 프로세스에서만 작동 할 수 있으므로이 방법은 SQL 주입 문제를 피할 수 있습니다.
Mybatis는 SQL의 사전 컴파일을 어떻게 달성합니까? 실제로, 프레임 워크의 맨 아래에서 JDBC의 준비 상태 클래스가 작동 중입니다. ProadingStatement는 우리가 매우 익숙한 진술의 서브 클래스입니다. 객체에는 컴파일 된 SQL 문이 포함되어 있습니다. 이 "준비된"접근 방식은 SQL이 컴파일되었고 다시 실행할 때 컴파일 할 필요가 없기 때문에 보안을 향상시킬뿐만 아니라 하나의 SQL을 여러 번 실행할 때 효율성을 향상시킵니다.
Mybatis를 사용하여 SQL 주입을 방지 할 수 있습니까? 물론 다음 코드를 참조하십시오.
<select id = "orderBlog"resulttype = "blog"parametertype = "map"> id, 제목, 저자, 블로그의 내용 $ {OrderParam} </select> 주의 깊은 관찰 후 인라인 매개 변수의 형식은 "#{xxx}"에서 $ {xxx}로 변경되었습니다. 매개 변수 "OrderParam"을 "ID"에 할당하고 SQL을 인쇄하면 다음과 같습니다.
ID, 제목, 저자, ID의 블로그 주문에서 컨텐츠를 선택하십시오
분명히 이것은 SQL 주입을 방지 할 수 없습니다. Mybatis에서 "$ {xxx}"형식의 매개 변수는 SQL 컴파일에 직접 참여하여 주입 공격을 방지합니다. 그러나 동적 테이블 이름과 열 이름과 관련하여 "$ {xxx}"와 같은 매개 변수 형식 만 사용할 수 있으므로 주입을 방지하기 위해 코드에서 이러한 매개 변수를 수동으로 처리해야합니다.
결론 : mybatis 매핑 명령문을 작성할 때 "#{xxx}"형식을 사용하십시오. "$ {xxx}"와 같은 매개 변수를 사용해야하는 경우 SQL 주입 공격을 방지하기 위해 수동으로 필터링을 잘 수행해야합니다.
위는 Java Persistence Layer 프레임 워크 Mybatis의 전체 내용이 편집자가 귀하에게 가져 오는 SQL 주입을 방지합니다. 모두가 wulin.com을 더 지원하기를 바랍니다