개념 정리

Server Side vs Client Side

• 서버 사이드 : 서버(제공자) 측에서 즉시 처리하는 것
• 클라이언트 사이드 : 클라이언트(사용자) 측에서 처리하는 것

XSS(Cross Site Scripting)

• Cross Site Scripting : 동적으로 출력하는 페이지에 대해 클라이언트 언어로 작성된 악의적인 스크립트를 삽입해 비정상적 행위를 하는 것
  ⇨ 사용자(클라이언트)를 대상으로 공격함

공격 대상

1. 사용자 입력값을 받아 웹페이지를 구성하는 기능은 잠재적 XSS 위협에 노출되므로 모두의 공격 대상이 됨
2. 공격자가 클라이언트 언어를 이용해서 사용자를 대상으로 공격을 진행함

공격 유형

피싱, 악성코드 유포, XSS Tunnel(사용자 웹 브라우저 권한을 획득), 세션 하이재킹(사용자가 세션을 탈취 후 세션 재사용)

공격 기법

• DOM-BASED XSS
  - DOM : Document Object Model, 문서 객체 모델. html 문서에 접근하기 위한 표준 api
  1. 공격자가 사용자에게 악성 스크립트가 담긴 URL 전달(공격자의 도메일 아니라 쉽게 클릭하게 됨)
  2. 사용자가 사이트에 접속 → 웹 서비스가 정상 응답 전달
  3. 자바스크립트 엔진으로 자바스크립트를 해석하고 URL 참조로 악성 스크립트가 담긴 페이지 구성
  4. 자바스크립트 실행 → 스크립팅 발생
  5. 공격자가 의도한 행위 실행
• REFLECTED XSS
  1. 공격자가 사용자에게 악성 스크립트가 담긴 URL을 전달
  2. 사용자가 사이트에 접속
  3. 어플리케이션에서 악성 스크립트가 담긴 페이지를 구성하여 사용자에게 응답으로 전달해서 스크립트 실행
  4. 공격자가 의도한 행위 실행
• STORED XSS
  ⇨게시물이 삭제되지 않는 한 악성스크립트가 지속되므로 persistent라고도 부름
  1. 공격자가 악성스크립트를 웹 서비스에 저장해둠
  2. DB에 악성스크립트가 그대로 저장
  3. 사용자가 악성 스크립트 담긴 글을 읽음
  4. DB에 저장된 악성 스크립트가 웹페이지로 호출됨
  5. 악성 스크립트가 담긴 페이지가 구성되어 사용자에게 전달
  6. 사용자 웹브라우저에서 스크립팅 발생 → 공격자가 의도한 대로 공격자 서버에 접근함

CSRF(XSRF)

• Cross-Site Request Forgery
  • 사용자는 강제적으로 공격자가 의도한 요청을 서버에 보내고, 이를 통해 사용자 정보 수정, 패스워드 변경, 탈퇴, 게시글 작성 등의 사용자가 의도하지 않은 행위가 무단으로 이루어지게 하는 공격
  • 다른 직접적인 공격 기법과 다르게 사용자가 강제적으로 공격 행위를 하도록 유도하는 간접적인 방식을 취한다.
    ⇨ 대응 방안
  • Referer 값 검증(자신의 사이트에서 온 요청이 아니면 행위가 이루어지이지 않게 함)
  • CSRF TOKEN 사용(폼에 접근할 때마다 달라지는 토큰 값의 성질을 이용해서 토큰 값이 일치 하지 않으면 행위가 이루어지지 않게 함)
  • 인증 로직 사용 / CAPCHA 사용
  • SameSite Cookie

XSS vs CSRF

• XSS
  • 사용자가 악성 스크립트를 읽고 공격자 서버에 요청을 보내면 공격자 서버에서 사용자에게 응답을 보낼 때 공격이 발생
  • 공격 대상 : 사용자(Client)
• CSRF
  • 사용자가 악성 스크립트를 읽으면 취약 웹 서비스 기능에 의도치 않은 요청을 보내게 되는 공격 발생
  • 공격 대상 : 서버

SQL Injection

• DBMS(Database Management System)에서 사용하는 질의 구문인 SQL을 삽입하는 공격

SQL 인젝션 기법

• Terminating Query
• In-line Query

공격 유형

• 인증 우회 공격
  인증기능을 수행하는 어플리케이션 대상으로 SQL 구문을 입력해서 공격
• 데이터 조회 공격
  데이터베이스에 저장된 정보를 조회하는 공격
  1. Error-Based SQL Injection
  2. UNION-Based SQL Injection
  3. Blind SQL Injection
     • Boolean-Based SQL Injection : 참 거짓에 따라 SQL 쿼리의 응답이 다른 경우에 사용
     • Time-Based SQL Injection : SQL 쿼리의 결과가 참 또는 거짓이냐에 따라 서버의 응답 시간을 제어할 수 있을 때 사용
• 시스템 명령어 실행 공격
  SQL 서버에 시스템 명령을 실행하는 공격
  시스템 변경을 실행하기 위한 환경이 매우 까다로워 발생하기 어려움

대응 방안

1. 입력값 검증(특수문자와 명령어 필터링, 데이터 길이 제한)
2. 저장 프로시저 사용(지정된 형식의 데이터가 아니면 쿼리가 실행되지 않도록 함
3. 서버 보안
   • 데이터 베이스 권한을 제한
   • 신뢰 가능한 네트워크와 서버에 대해서만 접근 허용
   • SQL 서버 오류 발생 시, 해당하는 에러 메시지 볼 수 없게 함

COMMAND Injection

• 사용자 입력값에 운영체제 명령어(시스템 명령어)를 주입하여 공격자의 의도대로 서버를 제어하는 공격

SQL Injection vs OS Command Injection

• SQL Injection : 웹 어플리케이션과 데이터베이스가 연결되어 작동하는 특정 기능에 대해, 그 기능이 요구하는 사용자 입력값을 삽입해 공격
• OS Command Injection : 사용자 입력값을 통해 시스템 명령어를 실행하도록 되어있는 특정 기능에 대해 시스템 명령어를 삽입해 공격
  ⇨ OS Command Injection보다 SQL Injection 취약점이 실제 웹 환경에 훨씬 많기 때문에 SQL Injection이 더 주목 받음

대응 방안

• 서버 사이드 스크립트로 기능 구현
• 사용자 입력 값 형식에 따른 정규 표현식 검증
• 악의적인 문자 검증

Burp Suite

• Burp Suite 버프슈트
  - 브라우저와 서버 간의 HTTP/S 트래픽을 가로채고 수정하기 위한 웹 프록시 기능을 포함하는 강력한 웹 애플리케이션 보안 테스트 툴
  • 트래픽의 다양한 측면을 분석, 수정 및 테스트
• 웹 프록시
  - 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템 또는 응용 프로그램
  • 서버와 클라이언트 사이에 중계기로써 대리로 통신을 수행하는 것 → 프록시 (proxy), 그 중계 기능을 하는 것 → 프록시 서버

실습 과제

Fiddler

Fiddler Classic 버전과 Fiddler 인증서 생성 툴을 설치했다.
Fiddler를 실행하고 Trust Root Certification인 인증서를 만들어서 연결했다.
패킷 캡쳐 기능을 키고, 인터넷에 접속하니까 패킷을 모니터링 할 수 있었고, 패킷의 Header로 패킷의 내용을 확인했다.
클라이언트에서 발생한 HTTP/HTTPS의 요청과 상태 코드, 메소드, 응답 크기 등을 확인할 수 있었다.

• 상태 코드
  • 200 → 정상 응답
  • 302 → 리디렉션
  • 404 → 페이지 없음
  • 500 → 서버 오류

Break Point 기능

• 특정 패킷을 서버로 전송하기 전에 수정하거나 서버의 응답을 수정한 후 클라이언트로 전달할 수 있게 하는 기능
• 활성화 방법
  1) 요청 패킷 : Break Point On → F11 단축키 또는 하단 Break Point 아이콘 클릭
  2) 응답 패킷 : Break Point On → Break Point 아이콘 두 번 클릭 또는 오른쪽 클릭
  3) Break Point 해제(Off) → Shift + F11 또는 Break Point 아이콘 클릭
  

SQLMap

blind sql injection advanced
Python과 Sqlmap을 설치하고 cmd에서 sqlmap 위치로 이동한다.

sqlmap을 실행한다.

문제 파일에 있던 'init.sql'에서 admin이라는 user id가 존재함을 확인하고, VM 서버에 접속해서 admin을 입력해 봤다.


파라미터가 있는 url을 선택해야 하므로 ?uid=admin이라는 파라미터가 있는 url을 사용해서 기본 정보를 확인했다.

실행 결과 'the back-end DBMS is MySQL'이라고 나왔으므로 --dbms="MySQL" --dbs라는 명령어를 추가해서 실행했다.

데이터베이스가 'information scheme'와 'user_db' 2개 출력됐고, 'init.sql'파일에서 user의 id, pw가 user_db에 저장되어있다고 했으므로 user_db의 table을 확인했다.

table이 users 하나만 존재해서 users의 column을 찾아봤다.

여기서 실제 원하는 값은 admin의 password이므로 -C uid,upw --dump를 실행했지만 'DH{'까지만 나오고 flag 부분이 나오지 않았다.

문제 설명에서 관리자의 비밀번호는 "아스키코드"와 "한글"로 구성되어 있다고 되어있고, sqlmap은 한글 데이터를 추출하지 못한다고 해서 방법을 찾아보다가 '--hex' 옵션을 사용하면 0xFF의 ASCII 범위 밖의 데이터를 추출할 수 있다는 것을 알게 되었다.
--hex : ASCII가 아닌 데이터를 16진수 함수로 인코딩하고, 원래 형태로 되돌림
In lost of cases retrieval of non-ASCII data requires special needs. One solution for that problem is usage of DBMS hex function(s). Turned on by this switch, data is encoded to it's hexadecimal form before being retrieved and afterwards unencoded to it's original form. - sqlmap(github)

python sqlmap.py -u "http://host3.dreamhack.games:12867/?uid=admin" -dbms="MySQL" -D "user_db" -T "users" -C idx,uid,upw --dump --hex
이 코드를 실행한 결과는 아래와 같다.

⇨ Flag : DH{이것이비밀번호!?}

참고 자료

[Dreamhack] blind sql injection advanced 을 툴을 이용해 케이크처럼 쉽게 풀기
sqlmap README-ko-KR