sql injection testing tutorial example
SQL 주입 예 및 웹 애플리케이션에 대한 SQL 주입 공격을 방지하는 방법
웹 사이트 나 시스템을 테스트하는 동안 테스터의 목표는 테스트 된 제품이 최대한 보호되는지 확인하는 것입니다.
보안 테스트는 일반적으로 이러한 목적으로 수행됩니다. 이러한 유형의 테스트를 수행하려면 먼저 어떤 공격이 발생할 가능성이 가장 높은지 고려해야합니다. SQL Injection은 이러한 공격 중 하나입니다.
SQL 주입은 시스템과 민감한 데이터에 심각하고 해로운 결과를 초래할 수 있으므로 가장 일반적인 공격 중 하나로 간주됩니다.
학습 내용 :
- SQL 주입이란?
- SQL 주입의 위험
- 이 공격의 본질
- 권장 도구
- SQL 주입에 대한 웹 애플리케이션의 보안 테스트
- 이 공격의 취약한 부분
- SQL 주입 테스트 자동화
- 다른 공격과의 비교
- 결론
- 추천 도서
SQL 주입이란?
일부 사용자 입력은 프레이밍에 사용될 수 있습니다. SQL 문 그런 다음 데이터베이스의 응용 프로그램에 의해 실행됩니다. 응용 프로그램이 사용자가 제공 한 입력을 제대로 처리하지 못할 수 있습니다.
만일이 경우라면, 악의적 인 사용자는 데이터베이스에서 SQL 문을 구성하고 실행하는 데 사용되는 예기치 않은 입력을 응용 프로그램에 제공 할 수 있습니다. 이를 SQL 주입이라고합니다. 그러한 행동의 결과는 놀라 울 수 있습니다.
이름 자체에서 알 수 있듯이 SQL Injection 공격의 목적은 악성 SQL 코드를 삽입하는 것입니다.
웹 사이트의 모든 분야는 데이터베이스로가는 관문과 같습니다. 로그인 양식에서 사용자는 로그인 데이터를 입력하고, 검색 필드에는 검색 텍스트를 입력하고, 데이터 저장 양식에서는 사용자가 저장할 데이터를 입력합니다. 표시된 모든 데이터는 데이터베이스로 이동합니다.
올바른 데이터 대신 악성 코드가 입력되면 데이터베이스와 전체 시스템에 심각한 손상이 발생할 가능성이 있습니다.
SQL 주입은 SQL 프로그래밍 언어로 수행됩니다. SQL (Structured Query Language)은 데이터베이스에 보관 된 데이터를 관리하는 데 사용됩니다. 따라서이 공격 중에이 프로그래밍 언어 코드는 악의적 인 주입으로 사용됩니다.
이것은 데이터베이스가 거의 모든 기술에 사용되기 때문에 가장 널리 사용되는 공격 중 하나입니다.
많은 애플리케이션이 특정 유형의 데이터베이스를 사용합니다. 테스트중인 애플리케이션에는 다음 태스크를 수행하는 데 사용되는 사용자 입력을 허용하는 사용자 인터페이스가있을 수 있습니다.
#1) 사용자에게 저장된 관련 데이터를 보여줍니다. 애플리케이션은 사용자가 입력 한 로그인 정보를 사용하여 사용자의 자격 증명을 확인하고 관련 기능과 데이터 만 사용자에게 노출합니다.
#두) 사용자가 입력 한 데이터를 데이터베이스에 저장합니다. 사용자가 양식을 작성하고 제출하면 애플리케이션은 데이터를 데이터베이스에 저장합니다. 이 데이터는 동일한 세션 및 후속 세션에서 사용자에게 제공됩니다.
SQL 주입의 위험
요즘에는 데이터가 어딘가에 저장되어야하므로 거의 모든 시스템과 웹 사이트에서 데이터베이스가 사용되고 있습니다.
민감한 데이터가 데이터베이스에 저장됨에 따라 시스템 보안과 관련된 더 많은 위험이 있습니다. 개인 웹 사이트 나 블로그의 데이터가 도난 당하더라도 은행 시스템에서 도난 당할 데이터와 비교할 때 큰 피해는 없을 것입니다.
이 공격의 주요 목적은 시스템의 데이터베이스를 해킹하는 것이므로이 공격의 결과는 실제로 해로울 수 있습니다.
SQL 주입으로 인해 다음과 같은 결과가 발생할 수 있습니다.
- 다른 사람의 계정을 해킹합니다.
- 웹 사이트 또는 시스템의 민감한 데이터를 훔치고 복사합니다.
- 시스템의 민감한 데이터 변경.
- 시스템의 민감한 데이터를 삭제합니다.
- 사용자는 관리자로도 다른 사용자로 응용 프로그램에 로그인 할 수 있습니다.
- 사용자는 다른 사용자의 개인 정보를 볼 수 있습니다. 다른 사용자의 프로필, 거래 세부 정보 등의 세부 정보
- 사용자는 응용 프로그램 구성 정보와 다른 사용자의 데이터를 변경할 수 있습니다.
- 사용자는 데이터베이스의 구조를 수정할 수 있습니다. 애플리케이션 데이터베이스의 테이블도 삭제합니다.
- 사용자는 데이터베이스 서버를 제어하고 마음대로 명령을 실행할 수 있습니다.
위에 나열된 위험은 데이터베이스 또는 데이터를 복원하는 데 많은 비용이들 수 있으므로 실제로 심각한 것으로 간주 될 수 있습니다. 손실 된 데이터와 시스템을 복원하는 데 회사의 명성과 비용이들 수 있습니다. 따라서 이러한 유형의 공격으로부터 시스템을 보호하고 보안 테스트를 제품 및 회사의 명성에 대한 좋은 투자로 고려하는 것이 좋습니다.
테스터로서 가능한 공격에 대한 테스트는 다음과 같은 경우에도 좋은 습관이라고 말하고 싶습니다. 보안 테스트 계획되지 않았습니다. 이렇게하면 예기치 않은 사례 및 악의적 인 사용자로부터 제품을 보호하고 테스트 할 수 있습니다.
이 공격의 본질
앞서 언급했듯이이 공격의 본질은 악의적 인 목적으로 데이터베이스를 해킹하는 것입니다.
이 보안 테스트를 수행하려면 먼저 취약한 시스템 부분을 찾은 다음이를 통해 악성 SQL 코드를 데이터베이스로 보내야합니다. 시스템에이 공격이 가능하면 적절한 악성 SQL 코드가 전송되고 데이터베이스에서 유해한 작업이 수행 될 수 있습니다.
웹 사이트의 모든 분야는 데이터베이스로가는 관문과 같습니다. 우리가 일반적으로 시스템 또는 웹 사이트의 모든 필드에 입력하는 모든 데이터 또는 입력은 데이터베이스 쿼리로 이동합니다. 따라서 올바른 데이터 대신 악성 코드를 입력하면 데이터베이스 쿼리에서 실행되어 유해한 결과를 초래할 수 있습니다.
권장 도구
# 1) Kiuwan
SDLC의 모든 단계에서 코드에서 SQL 삽입과 같은 취약성을 쉽게 찾고 수정합니다. Kiuwan은 OWASP, CWE, SANS 25, HIPPA 등을 포함한 가장 엄격한 보안 표준을 준수합니다.
개발 중 즉각적인 피드백을 위해 Kiuwan을 IDE에 통합하십시오. Kiuwan은 모든 주요 프로그래밍 언어를 지원하고 주요 DevOps 도구와 통합됩니다.
=> 무료로 코드 스캔
이 공격을 수행하려면 적절한 데이터베이스 쿼리의 행위와 목적을 변경해야합니다. 이를 수행 할 수있는 방법 중 하나는 쿼리를 항상 참으로 만들고 그 후에 악성 코드를 삽입하는 것입니다. 데이터베이스 쿼리를 항상 true로 변경하는 것은‘또는 1 = 1; –과 같은 간단한 코드로 수행 할 수 있습니다.
테스터는 쿼리를 항상 참으로 변경할 수 있는지 여부를 확인하는 동안 작은 따옴표와 큰 따옴표를 시도해야합니다. 따라서‘또는 1 = 1; –과 같은 코드를 시도한 경우 큰 따옴표 '또는 1 = 1; –을 사용하여 코드를 시도해야합니다.
예를 들어, 데이터베이스 테이블에 입력 된 단어를 검색하는 쿼리가 있다고 가정 해 보겠습니다.
노트에서 *를 선택하십시오. 여기서 nt.subject =‘search_word‘;
따라서 검색어 대신 SQL 주입 쿼리 '또는 1 = 1; –을 입력하면 쿼리가 항상 참이됩니다.
nt.subject =‘‘또는 1 = 1; –
이 경우 'subject'매개 변수는 따옴표로 닫히고 코드 또는 1 = 1이 있으므로 쿼리가 항상 참이됩니다. '–'기호로 실행되지 않을 나머지 쿼리 코드에 대해 설명합니다. 쿼리 제어를 시작하는 가장 인기 있고 가장 쉬운 방법 중 하나입니다.
다음과 같이 쿼리를 항상 true로 만드는 데 사용할 수있는 다른 코드는 거의 없습니다.
- ‘또는‘abc‘=‘abc‘; –
- ‘또는‘‘=‘‘; –
여기서 가장 중요한 부분은 쉼표 기호 뒤에 실행하려는 악성 코드를 입력 할 수 있다는 것입니다.
예를 들어, ‘또는 1 = 1 일 수 있습니다. 드롭 테이블 노트; —
이 주입이 가능하면 다른 악성 코드가 작성 될 수 있습니다. 이 경우 악의적 인 사용자의 지식과 의도에만 의존합니다. SQL 주입을 확인하는 방법?
이 취약점에 대한 검사는 매우 쉽게 수행 할 수 있습니다. 때로는 테스트 된 필드에‘또는 '기호를 입력하는 것으로 충분합니다. 예상치 못한 또는 비정상적인 메시지를 반환하면 해당 필드에 대해 SQL 주입이 가능하다는 것을 확신 할 수 있습니다.
예를 들어 , 검색 결과로 '내부 서버 오류'와 같은 오류 메시지가 표시되면 시스템의 해당 부분에서이 공격이 가능한 것입니다.
가능한 공격을 알릴 수있는 다른 결과는 다음과 같습니다.
- 빈 페이지가로드되었습니다.
- 오류 또는 성공 메시지 없음 – 기능 및 페이지가 입력에 반응하지 않습니다.
- 악성 코드에 대한 성공 메시지입니다.
이것이 실제로 어떻게 작동하는지 살펴 보겠습니다.
예를 들어, 적절한 로그인 창이 SQL Injection에 취약한 지 테스트 해 보겠습니다. 이를 위해 이메일 주소 또는 비밀번호 필드에 아래와 같이 sign을 입력합니다.
이러한 입력이 '내부 서버 오류'오류 메시지 또는 기타 나열된 부적절한 결과와 같은 결과를 반환하는 경우 해당 필드에 대해이 공격이 가능하다는 것을 거의 확신 할 수 있습니다.
매우 까다로운 SQL 주입 코드 시도 될 수도 있습니다. 제 경력에서 부호로 인해 '내부 서버 오류'메시지가 표시되는 경우는 없었지만 때때로 필드가 더 복잡한 SQL 코드에 대해 반응하지 않는 경우를 언급하고 싶습니다.
따라서 작은 따옴표‘로 SQL Injection을 확인하는 것은이 공격이 가능한지 여부를 확인할 수있는 매우 신뢰할 수있는 방법입니다.
작은 따옴표가 부적절한 결과를 반환하지 않으면 큰 따옴표를 입력하고 결과를 확인할 수 있습니다.
또한 쿼리를 항상 참으로 변경하는 SQL 코드는 이러한 공격이 가능한지 확인하는 방법으로 고려할 수 있습니다. 매개 변수를 닫고 쿼리를‘true‘로 변경합니다. 따라서 유효성이 확인되지 않으면 이러한 입력은 예상치 못한 결과를 반환하고이 경우에이 공격이 가능함을 알릴 수도 있습니다.
웹 사이트 링크에서 SQL 공격 가능성을 확인할 수도 있습니다. 웹 사이트의 링크가 http://www.testing.com/books=1 . 이 경우‘books‘는 매개 변수이고‘1‘은 해당 값입니다. 제공된 링크에 1 대신 '기호를 쓰면 가능한 주입이 있는지 확인합니다.
따라서 링크 http://www.testing.com/books= 웹 사이트에서 SQL 공격이 가능한지 테스트하는 것과 같습니다. http://www.testing.com 또는 아닙니다.
이 경우 링크가 http://www.testing.com/books= '내부 서버 오류'와 같은 오류 메시지 또는 빈 페이지 또는 기타 예상치 못한 오류 메시지를 반환합니다. 그러면 해당 웹 사이트에 대해 SQL 삽입이 가능함을 확인할 수 있습니다. 나중에 웹 사이트의 링크를 통해 좀 더 까다로운 SQL 코드를 보낼 수 있습니다.
웹 사이트 링크를 통해이 공격이 가능한지 확인하기 위해‘또는 1 = 1; –과 같은 코드를 보낼 수도 있습니다.
경험 많은 소프트웨어 테스터로서 예상치 못한 오류 메시지 만이 SQL 주입 취약점으로 간주 될 수 있다는 점을 상기시키고 싶습니다. 많은 테스터가 오류 메시지에 따라서 만 가능한 공격을 확인합니다.
그러나 악성 코드에 대한 유효성 검사 오류 메시지 나 성공 메시지도이 공격이 가능하다는 신호가 될 수 없다는 점을 기억해야합니다.
SQL 주입에 대한 웹 애플리케이션의 보안 테스트
간단한 예제로 설명 된 웹 애플리케이션의 보안 테스트 :
이 취약점 기술을 허용하면 결과가 심각 할 수 있으므로 응용 프로그램의 보안 테스트 중에이 공격을 테스트해야합니다. 이제이 기술에 대한 개요를 통해 SQL 주입의 몇 가지 실용적인 예를 이해하겠습니다.
중요 :이 SQL 주입 테스트는 테스트 환경에서만 테스트해야합니다.
응용 프로그램에 로그인 페이지가있는 경우 응용 프로그램에서 아래 명령문과 같은 동적 SQL을 사용할 수 있습니다. 이 문은 SQL 문에 입력 된 사용자 이름과 암호가있는 행이있을 때 결과 집합으로 Users 테이블의 사용자 세부 정보가있는 하나 이상의 행을 반환 할 것으로 예상됩니다.
SELECT * FROM Users WHERE User_Name =‘”& strUserName &“‘AND Password =‘”& strPassword & ' ';'
테스터가 strUserName (사용자 이름 텍스트 상자에)으로 John을 입력하고 strPassword (암호 텍스트 상자에)로 Smith를 입력하면 위의 SQL 문은 다음과 같습니다.
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;테스터가 John'–을 strUserName으로 입력하고 strPassword는 입력하지 않으면 SQL 문은 다음과 같습니다.
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;John 뒤의 SQL 문의 부분이 주석으로 바뀝니다. 사용자 테이블에 사용자 이름이 John 인 사용자가있는 경우 애플리케이션은 테스터가 사용자 John으로 로그인하도록 허용 할 수 있습니다. 테스터는 이제 사용자 John의 개인 정보를 볼 수 있습니다.
테스터가 애플리케이션의 기존 사용자 이름을 모르면 어떻게합니까? 이러한 경우 테스터는 admin, administrator 및 sysadmin과 같은 일반적인 사용자 이름을 시도 할 수 있습니다. 이러한 사용자가 데이터베이스에없는 경우 테스터는 strUserName으로 John '또는'x '='x를 입력하고 strPassword로 Smith '또는'x '='x를 입력 할 수 있습니다. 그러면 SQL 문이 아래와 같이됩니다.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;'x'= 'x'조건은 항상 true이므로 결과 집합은 Users 테이블의 모든 행으로 구성됩니다. 애플리케이션은 테스터가 사용자 테이블의 첫 번째 사용자로 로그인하도록 허용 할 수 있습니다.
중요 : 테스터는 다음 공격을 시도하기 전에 데이터베이스 관리자 또는 개발자에게 문제의 테이블을 복사하도록 요청해야합니다.
테스터가 John을 입력하면 '; DROP table users_details; '— strUserName 및 strPassword와 같은 모든 SQL 문은 아래와 같이됩니다.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';이 문으로 인해 'users_details'테이블이 데이터베이스에서 영구적으로 삭제 될 수 있습니다.
위의 예에서는 로그인 페이지 만 SQL 삽입 기술을 사용하는 것을 다루지 만 테스터는 텍스트 형식으로 사용자 입력을 허용하는 애플리케이션의 모든 페이지에서이 기술을 테스트해야합니다. 검색 페이지, 피드백 페이지 등
SSL을 사용하는 애플리케이션에서 SQL 삽입이 가능할 수 있습니다. 방화벽조차도이 기술로부터 응용 프로그램을 보호하지 못할 수 있습니다.
이 공격 기법을 간단한 형식으로 설명하려고했습니다. 이 공격은 개발 환경, 프로덕션 환경 또는 기타 환경이 아닌 테스트 환경에서만 테스트되어야 함을 다시 한 번 말씀 드리고 싶습니다.
fig_cropper.swf 여는 방법
응용 프로그램이 SQL 공격에 취약한 지 여부를 수동으로 테스트하는 대신 웹 취약성 스캐너 이 취약점을 확인합니다.
관련 자료 : 웹 애플리케이션의 보안 테스트 . 다양한 웹 취약성에 대한 자세한 내용은 여기를 확인하세요.
이 공격의 취약한 부분
테스트 프로세스를 시작하기 전에 모든 성실한 테스터는이 공격에 가장 취약한 부분을 어느 정도 알고 있어야합니다.
시스템의 어떤 필드를 정확히 어떤 순서로 테스트할지 계획하는 것도 좋은 방법입니다. 테스트 경력에서 저는 일부 필드를 놓칠 수 있으므로 SQL 공격에 대해 필드를 무작위로 테스트하는 것은 좋지 않다는 것을 배웠습니다.
이 공격이 데이터베이스에서 수행됨에 따라 모든 데이터 입력 시스템 부분, 입력 필드 및 웹 사이트 링크가 취약합니다.
취약한 부분은 다음과 같습니다.
- 로그인 필드
- 검색 필드
- 댓글 필드
- 기타 데이터 입력 및 저장 필드
- 웹 사이트의 링크
이 공격에 대해 테스트하는 동안 하나 또는 몇 개의 필드 만 확인하는 것으로는 충분하지 않습니다. 한 필드가 SQL 주입으로부터 보호 될 수 있지만 다른 필드는 그렇지 않은 것은 매우 일반적입니다. 따라서 웹 사이트의 모든 필드를 테스트하는 것을 잊지 않는 것이 중요합니다.
SQL 주입 테스트 자동화
일부 테스트 된 시스템 또는 웹 사이트는 매우 복잡하고 민감한 데이터를 포함 할 수 있으므로 수동 테스트가 정말 어려울 수 있으며 시간도 많이 걸립니다. 따라서 특수 도구를 사용하여이 공격에 대해 테스트하는 것이 때때로 정말 도움이 될 수 있습니다.
이러한 SQL 주입 도구 중 하나는 SOAP UI . API 수준에서 자동화 된 회귀 테스트가있는 경우이 도구를 사용하여이 공격에 대한 검사를 전환 할 수도 있습니다. SOAP UI 도구에는이 공격을 확인하기 위해 이미 준비된 코드 템플릿이 있습니다. 이러한 템플릿은 사용자가 작성한 코드로 보완 할 수도 있습니다.
매우 신뢰할 수있는 도구입니다.
그러나 테스트는 API 수준에서 이미 자동화되어 있어야하므로 쉽지 않습니다. 자동으로 테스트 할 수있는 또 다른 방법은 다양한 브라우저 플러그인을 사용하는 것입니다.
자동화 된 도구가 시간을 절약하더라도 항상 매우 신뢰할 수있는 것으로 간주되는 것은 아닙니다. 매우 민감한 데이터가있는 은행 시스템이나 웹 사이트를 테스트하는 경우 수동으로 테스트하는 것이 좋습니다. 정확한 결과를보고 분석 할 수있는 곳. 또한이 경우 건너 뛴 내용이 없음을 확인할 수 있습니다.
다른 공격과의 비교
SQL 주입은 데이터베이스에 영향을 미치고 데이터와 전체 시스템에 심각한 손상을 줄 수 있으므로 가장 심각한 공격 중 하나로 간주 될 수 있습니다.
확실히 자바 스크립트 주입이나 HTML 주입보다 더 심각한 결과를 초래할 수 있습니다. 두 가지 모두 클라이언트 측에서 수행되기 때문입니다. 비교를 위해이 공격을 사용하면 전체 데이터베이스에 액세스 할 수 있습니다.
이 공격에 대해 테스트하려면 SQL 프로그래밍 언어에 대한 충분한 지식이 있어야하며 일반적으로 데이터베이스 쿼리가 작동하는 방식을 알아야합니다. 또한이 인젝션 공격을 수행하는 동안 부정확성이 SQL 취약성으로 남을 수 있으므로 더욱주의하고 관찰해야합니다.
결론
SQL 인젝션이 무엇인지, 그리고 이러한 공격을 어떻게 방지해야하는지 명확하게 이해 하셨기를 바랍니다.
그러나 데이터베이스가있는 시스템 또는 웹 사이트를 테스트 할 때마다 이러한 유형의 공격에 대해 테스트하는 것이 좋습니다. 남아있는 데이터베이스 또는 시스템 취약성은 회사의 평판과 전체 시스템을 복원하는 데 많은 리소스를 소모 할 수 있습니다.
이 주입에 대한 테스트는 가장 중요한 보안 취약점 , 또한 지식 및 테스트 도구에 투자하는 것이 좋습니다.
보안 테스트가 계획된 경우 첫 번째 테스트 부분 중 하나로 SQL 주입에 대한 테스트를 계획해야합니다.
일반적인 SQL 인젝션을 보셨습니까? 아래 댓글 섹션에서 경험을 자유롭게 공유하십시오.