SQL 인젝션을 통해 사이트가 해킹당했습니다.

SQL 인젝션을 통해 사이트가 해킹당했습니다.

최근에 SQL 주입으로 제 사이트가 해킹당했습니다.해커는 내 DB 이름을 얻기 위해 다음 쿼리를 사용했습니다.나는 그들이 쓴 이 질문을 이해할 수 없습니다.

쿼리:

=-999.9%20UNION%20ALL%20SELECT%20concat(0x7e,0x27,Hex(cast(database()%20as%20char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

쿼리를 실행한 후 정수 결과를 표시했습니다. "와 같은 것입니다.74545883".

쿼리가 어떻게 작동하는지 설명해 주시겠습니까?

오버플로 공격 같아요.그들은UNION-ed를 기존 쿼리로 변경합니다. 당신의 모든 쿼리를 대체합니다.%20url-encoded가 다음을 산출하므로 (공백)을 사용합니다.

=-999.9 UNION ALL SELECT CONCAT(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536-

그것을 분해합니다.

1. 그=-999.9현재 쿼리를 종료하는 중입니다.
2. 0x31303235343830303536가NULL- 기존 쿼리의 열 수와 일치할 뿐입니다.가지고 계시다면SELECT * FROM users4개의 기둥이 있었고,UNION또한 4개의 열이 있어야 합니다.결과적으로, 그들은 단지 'NULL 값을 사용하여 그 열들을 채웠습니다.
3. 진짜 혼란은 에 있습니다.CONCAT(). 126, 39, 데이터베이스 이름을 16진수 값, 39, 126으로 조합하고 있습니다.
4. --mysql 주석입니다. 다음에 나머지 쿼리를 무시합니다.

이번 공격으로 미루어 볼 때, 당신이 입력한 내용을 포장하지 않은 것으로 의심됩니다.mysql_real_escape_string(), 당신의 쿼리에서 튀어나와 자신의 쿼리를 실행할 수 있도록 공격을 허용한 것입니다.

자세한 정보는 owasp.org 을 참조하십시오.

이것은 완전한 쿼리가 아닙니다. 실제로 사용자는 웹 앱에 이 문자열을 입력했습니다.

먼저 %20을(를) 유니언 부분의 빈 공간으로 교체하면 다음과 같은 이점을 얻을 수 있습니다.

SELECT concat(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

사용자가 번호를 예상하는 곳에 문자열을 넣은 것 같습니다.따라서 먼저 쿼리의 원래 조건을 완료할 수 있는 숫자(999.9)가 있다는 것을 알 수 있습니다.그런 다음 UNION 파트가 추가됩니다.마지막으로 UNION 부분 뒤에 주석 문자가 추가되어(-- ) 나머지 쿼리(시스템에서 추가될 수 있음)가 바이패스됩니다.

코드를 더 잘 이해할 수 있도록 포맷할 수 있습니다.

SELECT 
    concat
    (
        0x7e,
        0x27,
        Hex(cast(database() as char)),
        0x27,
        0x7e
    ),
    0x31303235343830303536,
    0x31303235343830303536,
    0x31303235343830303536

이제 결과의 첫 번째 열의 하위 문자열이 데이터베이스 이름의 16진수 인코딩 형식을 포함합니다.실제로는 작은 따옴표(0x27)로 둘러싸여 있어야 하고, 다시 ~(0x7e)로 둘러싸여 있어야 합니다.

쿼리는 데이터베이스()를 사용하여 데이터베이스 이름을 반환한 다음 HEx() 함수를 사용하여 16진수 값으로 변환했습니다.

일단 이것을 가지고 나면 UNHEX 기능을 사용할 수 있습니다.

한 번 보세요.UNHEX예

mysql> SELECT UNHEX('4D7953514C');
        -> 'MySQL'
mysql> SELECT 0x4D7953514C;
        -> 'MySQL'
mysql> SELECT UNHEX(HEX('string'));
        -> 'string'
mysql> SELECT HEX(UNHEX('1267'));
        -> '1267'

그들이 어떻게 들어갔는지 아는 것도 좋지만, 대체적으로 SQL 주입을 피하려면 코드를 수정해야 합니다.

-999.9 UNION ALL SELECT 
CONCAT('Hex(cast(database() as char))'),
0x31303235343830303536,
0x31303235343830303536,
0x31303235343830303536

그가 당신이 3개의 열을 가지고 있다는 것을 미리 알았다면, 당신의 로그에 다른 항목들이 있을 것이라고 생각합니다.

Havij를 이용한 주입의 예입니다. 0x7e와 0x27은 id=99999.9와 같은 HTML 디스플레이를 프레임화하는 데 사용될 ~와 '에 해당합니다.+유니온+전부+선택+0x313032353438303536, (선택+콘캣(0x7e,0x27,unhex(주물)_tbl.이름+aschar)),0x27,0x7e+from+test.sample_tbl+Order+by+id+limit+0,1)+-- 이 쿼리는 테이블 테스트의 테이블 sample_tbl에서 열 이름의 필드 값인 ~'Alfred'~를 렌더링합니다.

~r3dm0v3_hvj_injection'~는 http://www.string-functions.com/hex-string.aspx 에 따라 Havij 서명 코드 unhex0x7233646D3076335F68766A5F696E6A656374696F6E입니다.

우선 쿼리는 HTML로 인코딩된 것처럼 보입니다.교체%20공간이 있는 s는 조금 더 가독성이 높아질 것입니다.또한 그들은 쿼리의 일부를 어떤 것의 16진수 표현으로 변환하고 있습니다.문장의 그 부분도 16진수로 해독해 보십시오.

SQL 인젝션 위험은 SQL을 문자열로 동적으로 생성한 후 DBMS로 전송할 때 생성됩니다. 검색 바 등에서 사용하기 위해 시스템에 저장된 이와 같은 문자열을 상상해 보십시오.

SELECT * FROM SOME_TABLE WHERE SOME_COLUMN=

쿼리를 완료하고 공격을 허용하려면 다음과 같이 입력해야 합니다.

'x' or 1=1

이 경우 쿼리는 다음과 같이 됩니다.

SELECT * FROM SOME_TABLE WHERE SOME_COLUMN='x' or 1=1

SOME_COLUMN어떤 변수든 될 수 있어요, 어디서 실패하든 상관없어요, 중요한 건1=1는 항상 참이므로 공격자가 해당 테이블의 모든 행에 액세스할 수 있습니다.

이제 알았으니 코드를 살펴보고 동적으로 생성된 모든 쿼리를 준비된 문으로 대체합니다.OWASP 사이트에는 방어용 코딩을 위한 많은 리소스도 있습니다.

www.owasp.org

네, 그는 당신이 말하는 '74545883' 데이터베이스 이름의 16진수 형식을 가지고 있습니다.그것을 풀면 그는 진짜 데이터베이스 이름을 얻었을 것입니다.

언급URL : https://stackoverflow.com/questions/4600954/site-has-been-hacked-via-sql-injection