' 문자가 삭제되어도 SQL을 주입할 수 있는 방법이 있나요?

https://stackoverflow.com/questions/71756

09-06-2019
|

문제

SQL 쿼리에서 ' 문자를 모두 제거한 경우 데이터베이스에 SQL 주입 공격을 수행할 수 있는 다른 방법이 있습니까?

어떻게 할 수 있나요?누구든지 나에게 예를 들어 줄 수 있습니까?

해결책

예, 그렇습니다.에서 발췌 위키피디아

"SELECT * FROM data WHERE id = " + a_variable + ";"

이 진술을 보면 작성자가 a_variable을 "id" 필드와 관련된 숫자로 의도했음이 분명합니다.그러나 실제로 문자열인 경우 최종 사용자는 원하는 대로 명령문을 조작할 수 있으므로 이스케이프 문자가 필요하지 않습니다.예를 들어, a_variable을 다음으로 설정합니다.

1;DROP TABLE users

SQL은 다음과 같이 렌더링되므로 데이터베이스에서 "users" 테이블을 삭제(삭제)합니다.

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

SQL 인젝션은 ~ 아니다 간단한 공격으로 싸울 수 있습니다.내가 당신이라면 매우 신중하게 조사를 할 것입니다.

다른 팁

예, 사용 중인 문에 따라 다릅니다.저장 프로시저를 사용하거나 최소한 매개변수화된 쿼리를 사용하여 자신을 보호하는 것이 더 좋습니다.

보다 위키피디아 예방 샘플용.

네, 확실히 가능합니다.

다음 SELECT 문을 만들기 위해 정수가 필요한 양식이 있는 경우 비슷한 내용을 입력할 수 있습니다.

선택 *에서 thingy WHERE 속성ID=

5(좋은 답변, 문제 없음)
5;드롭 테이블 users;(나쁘다, 나쁘다, 나쁘다...)

다음 웹사이트에서는 전통적인 SQL 주입 기술에 대해 자세히 설명합니다. SQL 주입 치트 시트.

매개변수화된 쿼리나 저장 프로시저를 사용하는 것은 더 이상 좋지 않습니다.이는 전달된 매개변수를 사용하여 미리 만들어진 쿼리일 뿐이며 주입 소스가 될 수도 있습니다.이 페이지에도 설명되어 있습니다. SQL의 저장 프로시저 공격.

이제 간단한 인용문을 억제하면 특정 공격 세트만 방지하게 됩니다.하지만 전부는 아닙니다.

언제나 그렇듯이 외부에서 들어오는 데이터를 신뢰하지 마십시오.다음 3가지 수준으로 필터링하세요.

명확한 내용에 대한 인터페이스 수준(드롭다운 선택 목록이 자유 텍스트 필드보다 낫습니다)
데이터 특성(정수, 문자열, 길이), 권한(이 페이지에서 이 사용자가 이 유형의 데이터를 사용할 수 있는지)과 관련된 검사를 위한 논리적 수준...
데이터베이스 액세스 수준(간단한 인용문을 이스케이프 처리...)

재미있게 즐기시고 확인하는 것을 잊지 마세요 위키피디아 답변을 위해.

/베이

변수를 매개변수로 전달하고 자신만의 SQL을 구축하지 않는 것이 좋습니다.그렇지 않으면 현재 우리가 인식하지 못하는 방식으로 SQL 주입을 수행할 수 있는 방법이 항상 있을 것입니다.

생성한 코드는 다음과 같습니다.

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

나와 같은 이름에 ''가 들어간 이름이 있다면.모든 '-문자가 제거되거나 유효하지 않은 것으로 표시되는 것은 매우 짜증나는 일입니다.

당신은 또한 이것을보고 싶을 수도 있습니다 SQL 주입에 대한 Stackoverflow 질문.

매개변수화된 인라인 SQL 또는 매개변수화된 저장 프로시저가 자신을 보호하는 가장 좋은 방법입니다.다른 사람들이 지적했듯이 단순히 작은따옴표 문자를 제거/이스케이프 처리하는 것만으로는 충분하지 않습니다.

내가 구체적으로 "매개변수화된" 저장 프로시저에 대해 이야기한다는 것을 알 수 있을 것입니다.단순히 저장 프로시저를 사용하는 것만으로는 프로시저의 전달된 매개변수를 함께 연결하는 것으로 되돌아가는 경우 충분하지 않습니다.즉, 정확히 동일한 취약한 SQL 문을 저장 프로시저에 래핑한다고 해서 더 안전해지는 것은 아닙니다.인라인 SQL에서와 마찬가지로 저장 프로시저에서 매개변수를 사용해야 합니다.

또한 아포스트로피만 찾더라도 제거하고 싶지는 않을 것입니다.당신은 원한다 탈출하다 그것.모든 아포스트로피를 두 개의 아포스트로피로 바꾸면 됩니다.

그러나 매개변수화된 쿼리/저장 프로시저가 훨씬 더 좋습니다.

이 질문은 상대적으로 오래된 질문이므로 완전하고 포괄적인 답변을 작성하지 않겠습니다. 답변의 대부분이 여기 포스터에서 언급되었기 때문입니다.
그러나 여기서는 누구도 다루지 않은 또 다른 문제인 SQL Smuggling을 언급하는 것이 필요하다고 생각합니다.특정 상황에서는 따옴표 문자 '를 쿼리에 "밀입출"하는 것이 가능합니다. 그걸 없애려고 노력했어도.실제로 이는 적절한 명령, 매개변수, 저장 프로시저 등을 사용한 경우에도 가능할 수 있습니다.

전체 연구 논문을 확인하세요. http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (공개, 나는 이것에 대한 주요 연구원이었습니다) 또는 단지 Google "SQL Smuggling"입니다.

...어 다른 방법으로는 약 50000000개 정도

어쩌면 다음과 같은 것 5; drop table employees; --

결과 SQL은 다음과 같을 수 있습니다.select * from somewhere where number = 5; drop table employees; -- and sadfsf

(-- 코멘트를 시작합니다)

네 그럼요:SQL 언어 등에 따라 아포스트로피를 사용하지 않고 주입을 수행하는 방법이 많이 있습니다.

SQL 주입 공격에 대한 유일하고 안정적인 방어 방법은 데이터베이스 인터페이스에서 제공하는 매개변수화된 SQL 문 지원을 사용하는 것입니다.

필터링할 문자를 파악하는 대신 매개변수화된 쿼리를 사용하여 문제를 완전히 제거했습니다.

쿼리를 어떻게 구성하느냐에 따라 다르지만 본질적으로 그렇습니다.

예를 들어, Java에서 다음을 수행하려는 경우(의도적으로 터무니없는 예):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

그러면 주입 공격에 노출될 가능성이 높습니다.

Java에는 이러한 문제를 방지할 수 있는 몇 가지 유용한 도구가 있습니다. 예를 들어 ReadyStatements("SELECT name_ from Customer WHERE ID = ?"와 같은 문자열을 전달하고 JDBC 계층이 ?를 대체하는 동안 이스케이프를 처리함)와 같습니다.토큰)이지만 일부 다른 언어는 이에 그다지 도움이 되지 않습니다.

문제는 아포스트로피가 실제 입력일 수 있으며 코드에서 인라인 SQL을 사용할 때 아포스트로피를 두 배로 늘려 이스케이프해야 합니다.당신이 찾고있는 것은 다음과 같은 정규식 패턴입니다.

\;.*--\

실제 명령문을 조기에 종료하는 데 사용되는 세미콜론, 일부 삽입된 SQL, 원래 실제 명령문의 후행 SQL을 주석 처리하기 위한 이중 하이픈이 뒤따릅니다.공격시 하이픈은 생략될 수 있습니다.

따라서 대답은 다음과 같습니다.아니요, 단순히 아포스트로피를 제거한다고 해서 SQL 주입으로부터 안전이 보장되는 것은 아닙니다.

나는 다른 사람들이 말한 것을 반복할 수 있을 뿐입니다.매개변수화된 SQL이 좋은 방법입니다.물론, 코딩하는 데는 약간의 고통이 따릅니다. 하지만 일단 코딩을 하고 나면 해당 코드를 잘라내어 붙여넣고 필요한 수정 작업을 수행하는 것이 어렵지 않습니다.우리는 웹 사이트 방문자가 전체 범위의 검색 기준을 지정할 수 있도록 하는 많은 .Net 애플리케이션을 보유하고 있으며 코드는 SQL Select 문을 즉석에서 작성하지만 사용자가 입력할 수 있는 모든 항목은 매개 변수에 들어갑니다.

숫자 매개변수를 기대하는 경우 항상 입력의 유효성을 검사하여 숫자인지 확인해야 합니다.주입으로부터 보호하는 데 도움을 주는 것 외에도 유효성 검사 단계를 통해 앱이 더욱 사용자 친화적으로 만들어집니다.

id = 1044를 예상했는데 id = "hello"를 받은 경우 데이터베이스가 오류를 반환하도록 하는 대신 사용자에게 유용한 오류를 반환하는 것이 항상 더 좋습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow