SQL 주입을 감지하는 방법은 무엇입니까?
내 대답은: Party A의 보안에 있어서 SQL 주입 감지는 비교적 쉽습니다.
1) 주입 감지 오류.
2) 오탐률이 상대적으로 높으므로 부울 오류 보고서를 삽입하지 마세요.
3) 시간 기반의 시간 주입, 느린 로그 DB 기록을 위한 접촉 운영 및 유지 관리, 수면 모니터링, 벤치마크 키워드 모니터링을 수행합니다. 수면 시간의 소수점에 스캔 작업의 ID 번호를 추가하여 용이하게 할 수 있습니다. 포지셔닝. (p.s. 이 방법으로 SQL 주입을 99% 찾아낼 수 있습니다.)
그래서 시간 기반 시간 주입을 할 때 시간 오류를 매우 가혹하게 제한합니다. 하지만 @chengable은 Party B에서 보안 관련 작업을 수행하고 있으며 일반적으로 시간 기반 시간 주입이 불가능합니다. 그는 주로 주입 지점의 존재를 먼저 필터링한 다음 sqlmapapi.py를 탐지하는 것으로 파악됩니다. 이전에도 sqlmap을 이용해서 테스트했는데 오탐이 많고 스캔 시간이 길다는 문제가 있었는데, sqlmapapi.py를 시도해 보니 스캔 시간이 너무 길고 json 형식 삽입을 지원하지 않는다는 것이 문제였습니다. . 하지만 sqlmap의 시간 주입은 상대적으로 정확합니다. sqlmapapi.py를 사용하고 싶지 않다면 어떻게 될까요? 여기에서는 sqlmap의 시간 기반 주입 논리를 이동하겠습니다.
불평: sqlmap의 코드가 표준화되지 않았고, 보기 흉하고, 큽니다. 누군가 나에게 sqlmap 소스코드를 읽어보고 많이 배우라고 권유했다. 지금 생각해보니 일찍 포기했다.
그래서 게으르고 소스 코드를 보고 싶지 않다면 --technique=T -v 3 을 추가하고 sqlmap 감지 페이로드를 먼저 살펴보세요.
제가 게으르다가 몇 가지 방법을 찾은 것 같습니다. 스크린샷을 보면 알 수 있습니다.
먼저, sqlmap은 sleep의 주입 페이로드를 채웠습니다.
첫 번째로 채워진 sleep(5) , 실행된 것으로 확인된 후 sleep(0)이 삽입되고 마지막으로 sleep(5)이 삽입됩니다.
그런 다음 일반적인 확인 아이디어는 먼저 sleep(5)하고 두 번째 지연이 성공하면 sleep(0)하는 것입니다. 지연이 발견되지 않으면 절전을 계속합니다(5). 지연이 다시 성공하면 주입이 있을 수 있다는 알림이 나타납니다.
마지막으로 매우 영리하게 sqlmap을 사용하여 오탐을 방지합니다. 위 그림을 보면 sqlmap은 식이 참인지 두 번 테스트하고, 2차 지연을 기준으로 식이 성립하지 않는지 두 번 테스트하는 것을 볼 수 있다.
소스 코드로 돌아가서 살펴보기: 이전 키워드 중 일부를 기반으로 코드로 직접 이동하여 살펴보겠습니다. 예를 들어 *appears to be*가 검색 앞에 나타납니다. 첫 번째 단계의 코드를 참조하세요.
sqlmap/lib/controller/checks.py:
여기서 거의 내가 전에 추측했던 것과 똑같다.
페이로드, 특히 if 조건이 있는 페이로드를 찾아보세요. 키워드 쿼리를 사용하여 여기에서 찾으세요.
sqlmap/xml/payloads/time_blind.xml:
각각의 페이로드를 확인할 수 있습니다. 조건은 벡터장에 있습니다.
주입 지점 앞의 문자를 닫는 것이 주입 가능 여부의 관건입니다.
관찰된 tools/sqlmap/xml/boundaries.xml이므로 여기서도 다양한 종료 상황을 참조해야 합니다.
을 참조하세요. 이전 awvs 인젝션을 하면서 좀 더 이해하기 쉬운 탐지 방법을 생각했습니다. 페이로드가 주입되지 않은 6개의 일반 테스트의 소비 시간을 취하여 평균값을 네이티브 요청 시간(ori_time)으로 계산합니다.
주입 시간이 sleep(5)인 경우 현재 시간에서 ori_time을 빼서 sleep_time으로 합니다. sleep_time이 4보다 작으면 지연이 발생하지 않은 것으로 간주됩니다. (여기서 ori_time은 네트워크의 영향을 받아 커지는 점을 고려하여 임계값을 4초로 조정합니다.)
주입 시간이 sleep(0)인 경우 현재 시간에서 ori_time을 빼서 sleep_time으로 합니다. sleep_time이 2보다 크면 지연에 잘못된 경보가 있음을 의미합니다.
sqlmap 코드를 다시 보면 내가 이해할 수 없는 수학적 문제를 사용했습니다(자세히)
Follow up: Request.queryPage --->wasLastResponseDelayed 논리가 다음과 같은 것을 볼 수 있습니다. : 페이로드가 주입되지 않은 일반 테스트 30개의 소비 시간을 취하여 kb.responseTimes에 넣습니다. 표준 편차를 편차로 30회 계산하고 편차를 기준으로 가장 느린 응답 시간을 lowerStdLimit로 계산합니다.
그 값은 30배에 TIME_STDEV_COEFF*표준편차(편차)를 더한 평균값입니다. TIME_STDEV_COEFF는 7로 설정하면 판단 정확도가 99.9999999997440%가 됩니다.
최종적으로 요청의 현재 소비 시간이 lowerStdLimit보다 큰지 확인합니다. 더 크면 지연이 발생했음을 의미하고,보다 작으면 지연이 없음을 의미합니다(또한 lowerStdLimit가 0.5초 미만, lowerStdLimit는 0.5초 소요).
감정은 방법 1을 선택해야 한다고 말하고, 합리성은 방법 2를 선택해야 한다고 말합니다. 나는 여전히 방법 2를 선택하고 주입점(세부 사항)을 측정했습니다. 매우 안정적인 스캐닝으로 주입 취약점이 발견되었습니다.
위 내용은 sqlmap 시간 기반 주입 분석을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
