SQL 주입 및 SQL 주입 도구란 무엇입니까?

SQL 주입은 일반 WWW 포트에서 액세스되며 일반 웹 페이지 액세스와 별반 다르지 않아 현재 시중에 있는 방화벽은 SQL 에 경고를 주입하지 않습니다. 관리자가 IIS 로그를 보는 습관이 없다면, 알아차리지 않고 오랫동안 침입당할 수 있습니다.

그러나 SQL 주입 방법은 상당히 유연하여 주사 과정에서 예상치 못한 상황이 많이 발생할 수 있습니다. 구체적인 상황에 따라 분석하고, 교묘한 SQL 문을 구성하여 원하는 데이터를 성공적으로 얻을 수 있는지 여부는 전문가와' 초보자' 의 근본적인 차이다.

국정상 국내 웹사이트의 70% 이상이 ASP+Access 또는 SQL 서버를 사용하고, PHP+MySQ 는 L20%, 나머지는 10% 미만이다. 이 문서에서는 ASP 주입의 방법과 기술에 대해 초급부터 고급까지 설명하겠습니다. PHP 주입에 관한 문장 (PHP) 는 NB 연맹의 또 다른 친구인 zwell 이 쓴 것으로, 안전노동자와 프로그래머에게 유용하기를 희망하고 있다. ASP 주사를 아는 친구들도 입문 문장 건너뛰지 마세요. 주사에 대한 기본적인 판단법에 대한 오해가 있기 때문입니다. 모두 준비됐어요? 우리 갑시다 ...

문에 들어서다

이전에 SQL 주입을 시도한 적이 없다면 첫 번째 단계는 IE 메뉴 = & gtTool = & gt인터넷 옵션 => 고급 => 를 친숙한 HTTP 오류 메시지 앞에 있는 확인 표시를 제거하는 것입니다. 그렇지 않으면 서버가 반환한 오류에 관계없이 IE 는 HTTP 500 서버 오류로만 표시되며 추가 프롬프트 정보를 얻을 수 없습니다.

첫 번째 섹션, SQL 주입 원리

먼저 웹 사이트 www. 19cn.com (참고: 이 문서는 발표되기 전에 역장의 승인을 받았으며 대부분 실제 데이터입니다.)

웹 사이트 홈 페이지에는 "IE 가 새 창을 열지 않는 다양한 솔루션" 이라는 링크가 있습니다. Com/showdetail.asp? Id=49, 이 주소 뒤에 작은 따옴표' 를 붙이면 서버는 다음 오류 메시지를 반환합니다.

Microsoft JET 데이터베이스 엔진 오류 "80040e 14"

문자열의 구문 오류가 쿼리 표현식 "ID=49" 에 있습니다.

/showdetail.asp, 행 8

이 오류 프롬프트에서 다음 사항을 볼 수 있습니다.

1. 웹 사이트는 Access 데이터베이스를 사용하여 ODBC 대신 JET 엔진을 통해 데이터베이스에 연결합니다.

2. 프로그램은 클라이언트가 제출한 데이터가 프로그램 요구 사항을 충족하는지 여부를 확인하지 않았습니다.

3. 이 SQL 문이 질의한 테이블에는 ID 라는 필드가 있습니다.

위의 예에서 알 수 있듯이 SQL 주입의 원칙은 클라이언트에서 프로그램 및 서버에 대한 정보를 수집하기 위해 특수 코드를 제출하여 원하는 정보를 얻는 것입니다.

섹션 ii, SQL 주입이 가능한지 확인

첫 번째 섹션을 읽은 후, 어떤 사람들은 생각할 것입니다: 나는 종종 이런 식으로 주사 할 수 있는지 테스트합니다. 매우 간단하지 않습니까?

사실 이것이 최선의 방법은 아니다. 왜요

첫째, 각 서버의 IIS 가 반드시 클라이언트에 특정 오류 프롬프트를 반환하는 것은 아닙니다. Cint (매개 변수) 와 같은 명령문을 프로그램에 추가하면 SQL 주입은 성공하지 못하지만 서버도 오류를 보고합니다. 특정 힌트 정보는 서버가 URL 을 처리하는 동안 발생한 오류입니다. 시스템 관리자에게 문의하십시오.

둘째, SQL 주입에 대해 조금 알고 있는 일부 프로그래머들은 작은 따옴표를 걸러내는 것이 안전하다고 생각하는데, 이는 드문 일이 아니다. 작은 따옴표로 테스트하면 주입 지점이 감지되지 않습니다.

그렇다면 어떤 테스트 방법이 더 정확합니까? 답은 다음과 같습니다.

① .com/showdetail.asp? Id=49

② .com/showdetail.asp? Id=49 및 1= 1

③ .com/showdetail.asp? Id=49 및 1=2

이것이 1= 1 및 1=2 의 고전적인 테스트 방법입니다. 어떻게 판단합니까? 위의 세 웹 사이트에서 반환된 결과를 살펴보십시오.

주입할 수 있는 성능:

① 정상적인 디스플레이 (이것은 불가피합니다. 그렇지 않으면 프로그램에 오류가 있습니다)

② 정상적인 디스플레이, 내용은 ① 기본적으로 동일합니다.

(3) BOF 또는 EOF (프로그램이 아무런 판단도 하지 않은 경우) 또는 레코드를 찾을 수 없다는 프롬프트 (rs.eof 를 판단할 때) 또는 내용이 비어 있음을 표시 (프로그램이 on error resume next 추가) 합니다.

주사를 못 맞으면 판단하기 쉬워요. ① 역시 정상적으로 나타난다. ②, ③ 일반적으로 프로그램 정의 오류 프롬프트 또는 프롬프트 유형 변환 오류가 있습니다.

물론 이것은 들어오는 매개변수가 숫자일 때의 판단 방법일 뿐이다. 실제 응용 프로그램에는 문자 매개 변수와 검색 매개 변수가 있습니다. 중간 장의 "SQL 주입의 일반 단계" 에서 분석합니다.

섹션 iii, 데이터베이스 유형 및 주입 방법 결정

데이터베이스마다 기능과 주입 방식이 다르기 때문에 주입하기 전에 데이터베이스 유형을 판단해야 합니다. 일반적으로 ASP 에서 가장 많이 사용하는 데이터베이스는 Access 와 SQL 서버이며 인터넷상의 웹 사이트의 99% 이상이 그 중 하나입니다.

프로그램이 어떤 데이터베이스를 사용하는지 어떻게 알 수 있습니까? 자, 이제 ：

SQLServer 에는 몇 가지 시스템 변수가 있습니다. 서버 IIS 프롬프트가 닫히지 않고 SQLServer 가 오류 프롬프트를 반환하는 경우 오류 메시지에서 직접 얻을 수 있습니다. 이 방법은 다음과 같습니다.

。 Com/showdetail.asp? Id=49 및 사용자>0

이 말은 간단하지만 SQL 서버의 독특한 주입 방식의 정수를 담고 있다. 나 자신도 의도하지 않은 테스트에서 이 효율적인 추측 방법을 발견했다. 먼저, 앞서 말씀드린 바와 같이, 사용자 > 와 (과) 에 초점을 맞추고 있습니다. 0, 우리는 user 가 SQLServer 에 내장된 변수라는 것을 알고 있습니다. 그 값은 현재 연결된 사용자 이름이고 유형은 nvarchar 입니다. Nvarchar 값을 int 의 숫자 0 과 비교하면 시스템은 먼저 nvarchar 값을 int 유형으로 변환하려고 시도합니다. 물론 변환 과정에서도 오류가 발생할 수 있습니다. SQLServer 의 오류 프롬프트는 nvarchar“ABC "의 값을 데이터 유형이 int 인 열로 변환할 때 구문 오류가 발생한다는 것입니다. 아, ABC 는 변수 user 의 값이므로 데이터베이스의 사용자 이름을 쉽게 얻을 수 있습니다. 다음 몇 페이지에서는 이런 방법을 사용하는 많은 문장을 볼 수 있다.

그나저나, SQL 서버의 사용자 sa 는 관리자 권한과 동등한 역할이라는 것을 잘 알고 있습니다. Sa 권한을 가지고 있으면, 그가 호스트의 관리인을 받을 수 있다는 것을 거의 확신할 수 있다. 위의 방법은 sa 로 로그인했는지 쉽게 테스트할 수 있다. Sa 로 로그인하면' dbo' 를' sa' 가 아닌' int' 로 변환하는 것이 오류라는 점에 유의해야 합니다.

서버 IIS 에서 오류 프롬프트 반환을 허용하지 않는 경우 데이터베이스 유형을 어떻게 결정합니까? 우리는 Access 와 SQLServer 의 차이로 시작할 수 있습니다. Access 와 SQLServer 에는 데이터베이스의 모든 객체를 저장하는 테이블과 같은 고유한 시스템 테이블이 있습니다. Access 는 시스템 테이블 [msy objects] 에 있지만 웹 환경에서 이 테이블을 읽으면 "권한 없음" 이라는 메시지가 표시됩니다. SQLServer 는 테이블 [sysobjects] 에서 웹 환경에서 정상적으로 읽을 수 있습니다.

주사 가능 여부를 확인할 때 다음 명령문을 사용합니다.

。 Com/showdetail.asp? Id=49 및 (select count (*) from sysobjects) > 0

。 Com/showdetail.asp? Id=49 및 (count (*) from msy objects) > 0

데이터베이스가 SQLServer 인 경우 첫 번째 URL 의 페이지는 원본 페이지와 동일합니다. Com/showdetail.asp? Id=49 는 거의 동일합니다. 두 번째 URL 은 msysobjects 테이블을 찾을 수 없기 때문에 오류를 표시합니다. 프로그램에 내결함성이 있더라도 페이지는 원본 페이지와 완전히 다릅니다.

데이터베이스에서 Access 를 사용하는 경우 상황이 달라집니다. 첫 번째 URL 의 페이지는 원본 페이지와 완전히 다릅니다. 두 번째 웹 사이트는 데이터베이스 설정이 시스템 테이블 읽기를 허용하는지 여부에 따라 일반적으로 허용되지 않으므로 원래 웹 사이트와 완전히 다릅니다. 대부분의 경우 첫 번째 URL 을 사용하면 시스템에서 사용하는 데이터베이스 유형을 알 수 있고 두 번째 URL 은 IIS 오류 프롬프트를 열 때만 인증으로 사용됩니다.