비SQL 데이터베이스를 사용하면 "SQL 주입"에 대한 보호가 필요하지 않습니까?

Question

이는 당연한(또는 그다지 명확하지 않은) 질문처럼 보일 수 있지만 설명하겠습니다.저는 Google의 데이터베이스 기술인 BigTable을 사용하여 Google App Engine 사이트를 코딩하고 있습니다.모든 App Engine 코더는 Google에 GQL이라는 제한된 쿼리 언어가 있다는 것을 알고 있을 것입니다.결과적으로 Google이 데이터를 가져오기 위해 백엔드 메서드에서 원시 문자열 쿼리를 사용하지 않는다고 가정하기 때문에 내 앱에서 SQL(또는 GQL) 삽입을 확인하지 않으려는 유혹을 받습니다.

또한 CouchDB, MongoDB 및 기타 개체 또는 문서(NoSQL이라고도 함) 데이터베이스와 같은 DB 기술용 라이브러리를 사용하면 악의적인 사용자가 데이터베이스 조작 명령을 주입하는지 확인할 필요가 없는 것 같습니다.데이터베이스의 개체를 선택한 언어의 개체에 직접 매핑하는 라이브러리가 있는 경우가 많습니다.이 작업을 수행하는 SQL 라이브러리도 많이 있다는 것을 알고 있지만 어떤 수준에서는 매개 변수를 결합하여 문자열에 대해 쿼리를 실행한다고 가정하므로 해당 프레임워크에서도 SQL 주입 보호를 계속 사용해야 합니다.

내가 근시안적인가?아니면 차세대 DB 시스템이 자리를 잡고 그 시스템에 주입되는 것을 보게 될 때까지는 시간 문제일까요?

Answer 1

"주입"구멍은 텍스트 컨텍스트 불일치와 관련이 있습니다. 문자열의 다른 문맥에 텍스트 문자열을 넣을 때마다 변경된 컨텍스트에 맞게 인코딩해야합니다. 현악기를 함께 맹목적으로 채우는 것은 유혹적으로 간단 해 보이지만 문자열 처리의 어려움은 기만적입니다.

순수한 객체 기반 인터페이스가있는 데이터베이스는 매개 변수화 된 쿼리가 SQL에있는 것처럼 주입 취약점에 면역됩니다. 공격자가 당신이 그를 넣은 문자열 문자 문맥에서 벗어나기 위해 그의 끈에 넣을 수있는 것은 없습니다.

그러나 GQL은 구체적으로 이들 중 하나가 아닙니다. 문자열 쿼리 언어이며, 신뢰할 수없는 자료를 쿼리로 연결하면 "WHERE title='%s'" % title, 당신은 당신이 풀온 SQL을 사용했던 것만 큼 취약합니다. 어쩌면 GQL의 제한된 기능으로 인해 응용 프로그램을 완전히 타협하는 것을 악용하기가 더 어려워 지지만 일반적으로 불가능하지는 않으며, 최상의 경우에 응용 프로그램이 여전히 잘못되었으며 사람들이 합법적으로 Apostrophes를 사용하려고 할 때 끝날 것입니다.

GQL에는 매개 변수 바인딩 인터페이스가 있습니다. 그걸 써. 문자열 해킹의 매력에 저항하십시오.

Answer 2

GQL과 같은 SQL 서브 세트는 여전히 여전히 그것에 관심이 있지만 CouchDB, Voldemort 등과 같은 순수한 비 SQL 데이터베이스는 SQL 주입 스타일 공격에 대한 우려없이 데이터를 가져와야합니다.

그러나 데이터베이스가 깨지지 않을 수도 있지만 응용 프로그램을 중단하고 XSS (웹 앱인 경우)와 같은 것을 허용 할 수 있기 때문에 컨텐츠 검증을 수행하는 것을 실례하지 않습니다.

Answer 3

사용자 입력에서 나오거나 사용자 입력에 의해 조작되는 데이터가 코드 실행을 제어하는 ​​데 사용될 때마다 정리 작업이 필요합니다.코드에서 사용자 입력을 사용하여 입력을 삭제하지 않고 명령을 실행하는 경우를 보았습니다.악용되지는 않았지만, 만약 악용되었다면 끔찍한 공격 벡터가 되었을 것입니다.

Answer 4

SQL 주입은 통제되지 않은 입력이 평가되는 보안 결함의 유형의 하위 집합 일뿐입니다.

기술적으로, 당신은 무엇보다도 JavaScript를 "주입"할 수 있습니다.