WebjxCom提示:程序员们写代码的时候讲究TDD(测试驱动开发):在实现一个功能前,会先写一个测试用例,然后再编写代码使之运行通过。其实当黑客SQL Injection时,同样是一个TDD的过程:他们会先尝试着让程序报错,然后一点一点的修正参数内容,当程序再次运行成功之时,注入也就随之 |
프로그래머는 코드를 작성할 때 TDD(테스트 중심 개발)에 주의합니다. 함수를 구현하기 전에 먼저 테스트 사례를 작성한 다음 코드를 작성하여 실행합니다. 실제로 해커가 SQL 주입을 수행하는 것도 TDD 프로세스입니다. 먼저 프로그램이 오류를 보고하도록 시도한 다음 프로그램이 다시 성공적으로 실행되면 매개변수 내용을 조금씩 수정합니다. .
공격:
프로그램에 다음과 유사한 스크립트가 있다고 가정합니다.
$sql = "SELECT id, title, content FROM Article WHERE id = {$_GET[''id'']} " ;
정상 접속 시 URL은 다음과 같습니다.
/articles.php?id=123
해커가 SQL 인젝션 취약점이 있는지 확인하려는 경우 가장 일반적인 방법은 정수 ID 뒤의 작은따옴표:
/articles.php?id=123''
$_GET[''id''] 매개변수를 필터링하지 않았으므로 필연적으로 오류가 보고될 수 있습니다. 다음과 유사합니다.
제공된 인수는 유효한 MySQL 결과 리소스가 아닙니다...
이 정보는 스크립트가 취약하다는 것을 보여주기에 충분합니다.
/articles.php? id=0 Union select 1,2,3
1,2,3을 선택한 이유는 Union에서 양쪽 필드의 개수가 동일해야 하기 때문입니다. id, title, content 세 가지 필드가 있습니다. 앞에는 1, 2, 3이라는 세 개의 필드도 있으므로 구문 오류가 보고되지 않습니다. 또한 id=0으로 설정하면 존재하지 않는 레코드이므로 쿼리 결과는 1, 2, 3. 웹페이지에 반영되면 원래 아이디가 표시된 곳에 1, 제목이 표시된 곳에 2, 내용이 표시된 곳에 2가 표시됩니다.
계속 사용하는 방법은 Magic_quotes_gpc 설정에 따라 다릅니다:
magic_quotes_gpc가 꺼진 경우:
/articles.php?id=0 Union Select 1,2, load_file(' '/etc/passwd'')
이렇게 하면 /etc/passwd 파일의 내용이 원래 표시되었던 위치에 표시됩니다.
magic_quotes_gpc가 켜져 있는 경우:
이 때 load_file(''/etc/passwd'')를 직접 사용하면 작은따옴표가 이스케이프 처리되어 무효가 되지만 여전히 :
/articles.php?id=0 Union select 1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100))
숫자는 /etc/passwd 문자열의 ASCII입니다: 각 문자열 이외에도 문자열의 16진수 형식을 사용할 수도 있습니다. 문자열의 각 문자는 주기적으로 출력됩니다. dechex(ord(...))
/articles.php?id=0 Union Select 1, 2,load_file(0x2f6574632f706173737764)
숫자 매개변수에 대한 몇 가지 공격 방법은 빙산의 일각에 불과하며 문자열 매개변수와 같은 공격 방법은 아래 문서 링크를 참조하세요.
방어:
GreenSQL과 같이 인터넷에서 사용할 수 있는 SQL 주입 방화벽과 유사한 일부 소프트웨어가 있습니다. 웹 사이트가 SQL 주입 공격을 받기 시작한 경우 이러한 바로 가기 도구를 사용하면 생명을 구할 수 있는 경우가 많습니다. 이렇게 하면 소프트웨어가 아키텍처에서 Proxy 역할을 하므로 웹 사이트의 동시 성능에 영향을 미칠 수 있으므로 선택할 때 객관적인 조건을 바탕으로 신중하게 결정하는 것이 가장 좋습니다. 많은 경우 전문 소프트웨어가 필요하지 않으며 가벼운 솔루션이 많이 있습니다. 다음은 awk를 사용하여 가능한 취약점을 탐지하는 방법을 보여줍니다.
다음 내용으로 discover_sql_injection.awk 스크립트를 생성하십시오(내용을 복사하려면 줄 번호를 포함하지 마십시오).
01 #!/bin/gawk -f
02
03 /$_(GET |POST|COOKIE|REQUEST)s*[/ {
04 IGNORECASE = 1
05 if (match($0, /$.*(sql|query)/)) {
06 IGNORECASE = 0
07 출력()
08 다음
09 }
10 }
11
12 함수 출력()
13 {
14 $1 = $1
15 print "CRUD: " $0 "nFILE: " FILENAME "nLINE: " FNR "n"
16 }
이 스크립트는 다음과 유사한 문제 코드를 일치시킬 수 있습니다. 일치 모드를 확장하는 것은 쉽습니다. . if match 문을 작성하세요.
1: $sql = "SELECT * FROM users WHERE 사용자 이름 = ''{$_POST[''username'']}''";
2: $res = mysql_query("SELECT * FROM users WHERE 사용자 이름 = ''{$_POST[''username'']}''");
사용하기 전에 chmod x discover_sql_injection.awk를 잊지 마세요. 두 가지 호출 방법이 있습니다:
1: ./Detect_sql_injection .awk /path/to/php/script/file
2: find /path/to/php/script/directory -name "*.php" | xargs ./Detect_sql_injection.awk
는 문제가 있는 코드 정보를 생성합니다. 다음과 같이 표시됩니다:
CRUD: $sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
FILE: /path/to/file .php
LINE: 123
CRON을 통해 프로그램 소스 파일을 정기적으로 스캔하거나 SVN에 제출할 때 후크 방식을 통해 자동으로 일치시키는 등 실제 환경에서 이 스크립트를 적용하는 방법은 다양합니다.
전문 도구를 사용하든 스크립트를 탐지하든 문제의 근본 원인은 항상 프로그래머가 명심해야 할 몇 가지 지침이 있는지 여부에 달려 있습니다.
1: intval 및 floatval과 같은 방법을 사용하여 숫자 매개변수를 필터링하도록 합니다.
2: mysql_real_escape_string과 같은 메소드를 사용하여 간단한 추가 래시 대신 필터 문자열 매개변수를 강제 적용합니다.
3: mysql_query와 같은 splicing SQL 쿼리 방식은 가급적 버리고 PDO의 prepare 바인딩 방식을 최대한 활용하는 것이 가장 좋습니다.
4: 재작성 기술을 사용하여 실제 스크립트 및 매개변수 정보를 숨기고 일반 규칙 재작성을 통해 의심스러운 매개변수를 필터링합니다.
5: 오류 메시지를 끄고 공격자에게 민감한 정보를 제공하지 마세요: display_errors=off.
6: 로그 형식으로 오류 정보를 기록합니다. log_errors= />7: MySQL에 연결하기 위해 FILE 권한(예: 루트)이 있는 계정을 사용하지 마세요. 이렇게 하면 load_file과 같은 위험한 기능이 차단됩니다.
8:...
웹사이트 보안은 사실 복잡하지 않습니다. 필터 입력과 이스케이프 출력이라는 한 문장으로 요약할 수 있습니다. 그 중 위에서 논의한 SQL 인젝션 문제는 입력 필터링 문제에 속하며, 출력 이스케이프 문제는 대표적으로 Cross-site scripting이 있지만 이 글의 범위에 속하지 않으므로 나는 다음과 같이 설명한다. 그것에 대해 더 말하지 않을 것입니다.
문서:
addslashes() 대 mysql_real_escape_string()
MySQL을 사용한 SQL 주입
MySQL을 사용한 고급 SQL 주입
MySQL 주입에서 내보낸 필드 콘텐츠에 대한 연구 - 주입을 통한 WebShell 내보내기
재인쇄 출처: http://www.aspnetjia.com/Cont-328.html
위 내용은 HP MYSQL 홈페이지의 SQL 인젝션 공격과 방어에 대한 내용을 포함하여 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되었으면 좋겠습니다.