DVWA Security Level 을 Low로 설정하고 XSS (Reflected) 페이지로 들어간다. 페이지에 접속하면 이름을 물어보는 폼이 있다. 여기에 alice라고 입력해보자. 입력한 값이 다시 그대로 리턴 되는 것을 알 수 있다. XSS 취약점을 찾기 위한 가장 간단한 방법은 script 태그를 위와 같은 폼에 입력해 보는 것이다. 구문을 넣어보자. 위 그림과 같이 XSS 취약점이 있으면 이렇게 script가 실행된다. alert라는 함수에 의해서 1이라는 값이 출력 되었는데 이 말은 script가 웹 브라우저에서 실행 되었다는 뜻이고 XSS 공격이 가능하다는 뜻이다. 이와 같이 script 코드가 요청에 실어 보내질 때 바로 script가 리턴이 되어 실행되는 것을 reflected XSS ..
XSS 공격은 자바스크립트와 밀접한 관련이 있다. 자바스크립트에 대해 잠깐 살펴보자. 자바스크립트 · 웹 애플리케이션에서 사용되는 언어 - HTML : 텍스트, 이미지 등 정적인 내용을 표시 - 자바스크립트 : 동적인 기능 구현(마우스를 가져가면 메뉴의 색깔이 변함) · 와 같이 구현 - => 이 코드는 쿠키를 빼내는 데 사용 할 수 있다. 쿠키에는 세션 정보가 포함되어 있는데 document.cookie를 실행하면 그 값을 읽을 수 있다. document.location 을 이용하면 외부의 사이트로 전달 할 수 있다. - => 자바 스크립트는 파일 인클루전 공격과 유사하게 src 소스 키워드를 이용하여 외부의 자바 스크립트를 페이지 내에 삽입시켜 실행 할 수 있다. 이를 이용해 외부 해커 사이트에 올려..
DVWA Security Level을 High로 설정하고 SQL Injection 페이지로 간다. High 단계의 SQL Injection 페이지에는 링크가 있는데 이 링크를 눌러보자. 다음과 같은 창이 뜨고 여기에 ID 1을 입력하면 그 결과가 원래 페이지에 표시되는 구조이다. Low 단계와 비교했을 때 폼을 새로운 창에서 입력 받는 차이가 있다. 하지만 만약 이것 뿐이라면 Medium 단계에서 보았듯이 GUI의 변화는 SQL 인젝션 공격을 전혀 막을 수 없다. 소스 코드를 한 번 보도록 하자. 소스 코드를 보면 LIMIT 이라는 키워드를 이용하여 출력되는 레코드의 수를 조절하고 있다. 무조건 하나만 출력 되도록 막고 있는 것이다. 하지만 이것 역시 SQL 인젝션 공격을 방어하는 용도로는 아무런 의미가..
DVWA Security Level 을 Medium으로 설정하고 SQL Injection 페이지로 간다. 이번에는 ID를 폼에다가 입력하는 것이 아니라 정해진 값을 선택하도록 되어 있다. 이 경우 비록 GUI에서 값을 선택하도록 만들어놨지만 Intercept 기능을 이용해서 값을 바꾸는 것을 시도해 볼 수 있다. Burp Suite의 Proxy -> Intercept로 가서 Intercept를 켠다. User ID를 1로 선택하고 submit을 눌러 본다. Burp Suite에서 위와 같은 화면이 나오는데 여기서 id=1 부분을 id=1' or '1'='1 로 수정하여 Forward를 한다. Forward를 했더니 그림과 같이 구문 에러가 난다. id값이 1, 2, 3, 4, 5 로 숫자로 되어 있었는데..
지금까지 우리는 SQL 인젝션 공격을 손수 시도하여 각종 정보를 알아내는 실습을 하였다. 이번 시간에는 SQL 인젝션 공격 프로그램 중 가장 대중적이라고 할 수 있는 SQLMAP 이라는 프로그램을 이용하여 자동으로 공격하는 방법을 배워 보자. Applications 메뉴로 가서 Web Application Analysis -> sqlmap 클릭 sqlmap은 파이썬으로 개발된 프로그램으로 터미널에서 명령을 실행 할 수 있다. sqlmap 화면을 보면 sqlmap과 관련된 각종 옵션들을 참고 할 수 있다. 이 중 필수 옵션은 -u 이다. -u 뒤에다가 공격할 URL주소를 입력하면 sqlmap 프로그램이 그 url을 대상으로 자동으로 공격을 수행한다. DVWA처럼 로그인 된 상태에서 공격을 수행할 때는 쿠키..
이번에는 블라인드 SQL 인젝션에 대해서 알아보자. DVWA의 블라인드 SQL 인젝션 페이지에 들어가서 1이라는 id를 입력해보자. 사용자 1에 대한 정보가 나오는 대신에 이 페이지에는 ID 1인 사용자가 존재한다는 것만 알려준다. 이번에는 지난번에 SQL 인젝션 공격을 할 때 했던 것 처럼 한 번 작은 따옴표를 입력해본다. 특별한 에러가 발생하는 대신 사용자가 존재하지 않는다는 메시지를 보여준다. 에러가 발생하지 않기 때문에 이 폼 뒤에 SQL 쿼리문이 사용되고 있는지, 또 우리가 조작할 수 있는지 쉽게 알기 어렵다. 만약 조작한다고 하더라도 데이터의 내용을 출력하지 않기 때문에 쉽게 정보를 빼내기도 어렵다. 이번에는 1'AND 1=1# 을 입력해본다. ID가 존재한다고 나온다. 1' AND 1=2# ..
데이터베이스 정보를 알아내보자. 깃허브에 올려져 있는 SQL 구문을 보면 데이터베이스 명 조회에 관련된 구문이 있다. 이 구문을 사용한다. information_schema라는 데이터베이스의 schemata라는 테이블에서 정보를 가져오는데 mysql에서는 information_schema라는 데이터베이스에서 데이터베이스 정보나 테이블, 칼럼 정보를 관리하고 있다. schema_name을 가져오면 데이터베이스 명을 조회할 수 있다. user ID에 위의 구문을 넣고 실행한다. 모든 데이터베이스의 이름들이 출력되었다. dvwa, information_schema, mysql 등의 데이터베이스 명이 있음을 알 수 있다. dvwa 데이터베이스가 우리가 관심을 가질만한 DB이다. select로 schema_nam..
이번에는 UNION 키워드를 이용한 공격을 실습 해보자. UNION을 이용하면 데이터베이스의 모든 정보를 알아낼 수 있다. UNION은 합집합 이라고 했었는데 UNION을 사용하기 위해서는 원래 쿼리문이 조회하는 select문에 칼럼 개수와 union 뒤의 select문에서 요청하는 칼럼 개수가 같아야 한다. 그렇지 않으면 에러가 발생하기 때문에 먼저 원래의 쿼리문이 몇 개의 칼럼을 리턴하는지 알아내야 한다. DVWA의 SQL Injection 페이지에 가서 UserID에 1'union select 1# 을 입력해보자. 이 select 뒤에 1이라는 상수 값을 주게 되면 그것을 그대로 출력 할 수 있다. 꼭 1 뿐만 아니라 2, 3 혹은 null 이라는 값을 줄 수 있다. submit을 누른다. 실행을 ..
DVWA Security Level을 Low로 설정한 후 SQL Injection 페이지로 간다. user ID를 입력하는 폼이 있다. 여기에 1이라는 값을 넣으면 ID가 1인 사용자에 대한 정보가 출력된다. 위와 같은 페이지가 있을 때 SQL Injection 공격에 취약한지 알아보는 가장 기본적인 방법은 작은 따옴표를 입력해 보는 것이다. 작은 따옴표를 입력해보자. 취약한 페이지의 경우 위 페이지 처럼 sql 관련 에러가 발생한다. 그 이유는 소스 코드를 보면 알 수 있다. user_id 부분을 보면 사용자가 입력한 값은 $id라는 변수로 들어가게 되는데 이 $id라는 변수는 이미 작은 따옴표로 둘러싸여 있다. 만약 여기에 작은 따옴표가 하나 더 들어오게 되면 작은 따옴표가 총 세 개가 되면서 에러가..
SQL 인젝션 공격 SQL 인젝션 공격 이란 데이터베이스에 전송되는 SQL 쿼리문을 사용자 입력으로 조작하여, 데이터베이스 내의 데이터를 변조하거나 허가되지 않은 정보에 접근 할 수 있는 공격이다. 웹사이트의 회원정보 등 개인정보를 빼낼 때 최근까지도 자주 쓰이는 웹 공격이다. 실제 사례 · 2011년 소니 해킹 2011년에 소니 데이터베이스가 SQL 인젝션 공격을 당해 100만 명의 회원정보와 350만 개의 디지털 쿠폰 등이 탈취 · 2015년 뿜뿌 해킹 뿜뿌 사이트가 해킹 되어 190만의 회원정보가 유출 · 2015년 어나니머스 WTO 해킹 유명한 해킹그룹인 어나니머스가 WTO 세계무역기구의 한 사이트를 SQL 인젝션 공격으로 해킹하여 수천 명의 각국 재직자 정보를 유출 두 가지의 기본적인 SQL 인..
이번에는 High 단계에서 실습해보자. DVWA Security Level을 High로 설정한다. 이번에도 프록시 history 기능을 통해서 어떻게 전달 되는지 확인한다.CAPTCHA 메뉴로 가서 password는 normal을 입력하고, captcha 값을 입력해준다. change 버튼을 누른다. 이번에는 두 단계에 걸치지 않고 바로 패스워드가 변경된다. 이제 Low, Medium 단계의 방식으로는 공격을 할 수 없게 되었다. 소스 코드를 한 번 살펴보자. 이 부분은 captcha가 실패했을 때 처리하는 부분이다. if문의 조건을 자세히 살펴보면 응답이 vaild 하지 않으면(!$resp->is_valid 부분) 뒤에 추가로 조건을 검사하고 있다. 그 조건은 'recaptcha response fie..
DVWA Security Level을 medium으로 설정하고 Insecure CAPTCHA로 들어간다. Low 단계에서 작업했던 것 처럼 password는 'normal'로 입력하고 captcha부분을 작성한다. change 버튼을 두 번 누른다. HTTP history를 확인해보면 이번에도 Law 단계와 마찬가지로 두 단계에 걸쳐서 패스워드를 변경하고 있음을 알 수 있다. 두 번째 요청의 내용을 보면 이전 Law 단계의 두번 째 요청과 같이 step 파라미터의 값이 2이고 password 역시 같이 전송한다. 한 가지 추가된 것은 passed_captcha 파라미터인데 아마도 이 파라미터를 추가로 넣어서 captcha를 제대로 입력했는지 확인하려고 한 것일 것이다. 이 요청을 Repeater로 보내서..