정보보안 2차시: 웹 - 기본적인 웹 취약점

경희대학교 중앙동아리 쿠러그의 정보보안 강의를 기반으로 정리한 글입니다.

웹 해킹

해킹이란 개발자가 의도하지 않은 동작을 입력 혹은 행위를 통해 악의적인 결과를 만들어내는 것을 말하며,

웹 해킹은 클라이언트와 웹 서버 간의 요청과 응답 흐름에서 발생한다.

클라이언트 / 서버

▶ 클라이언트 / 서버

 

클라이언트

브라우저

• 서버라는 다른 컴퓨터에 접속할 수 있는 응용프로그램이나 서비스
• 웹페이지에서 하는 요청은 대부분 웹브라우저가 함 (웹에서 클라이언트는 브라우저)

HTML, JS, CSS 등

• 웹페이지를 요청해서 CSS와 같은 요소에 연결해서 홈페이지가 그려짐
• 브라우저의 위치도 내 컴퓨터이기에, 코드들의 실행 위치도 내 컴퓨터 안에 있음
• 페이지를 전송받으면 인터프리터를 통해 페이지를 화면에 뿌림

서버 사이드

웹서버, 데이터베이스

• 클라이언트에게 요청을 받아서 처리를 하고, 처리 결과를 송신하고 응답하는 역할

PHP, JSP, ASP, Python Flask, Spring 등

• 찾는 데이터를 전달해 줌

서버와 클라이언트 사이의 중간 다리가 인터넷

 

데이터 처리 방법

클라이언트 사이드에서 처리

• 장점: 서버의 비용 부담 감소, 암호화 소요 줄어듦(내가 바로 처리하니 암호화 안 해도 됨)
• 단점: 개별 컴퓨터의 처리 부담 증가, 공공 컴퓨터의 데이터 위조 가능성

서버 사이드에서 처리

• 장점: 위조하면 안 되는 데이터의 위조 어려움, 클라이언트 부담 감소
• 단점: 서버가 할 일이 많아져서 서버 유지 비용 증가

웹 서버와 웹 사이트

웹 서버는 HTTP/HTTPS 프로토콜을 이용해서 서비스 제공

• HTTP, HTTPS: 웹 서버와 브라우저 사이에 정보를 주고받기 위한 프로토콜

웹 사이트의 종류

• 정적인 페이지: 미리 저장되어 있는 정보들을 보여줌
• 동적인 페이지: 사용자의 요청에 맞는 페이지를 생성해서 보여줌

웹 서버 구조

클라이언트가 request를 보내면 서버가 response를 한다.

기본적인 처리 과정: 클라이언트 -> 웹서버 -> WAS(동적 데이터 처리) -> 외부 프로그램(DB 등)

• 웹 서버는 정적인 데이터를 처리함 = 단순 HTML 문서, 이미지, 파일 등 즉시 응답 가능한 것 처리
• WAS는 데이터베이스 조회 등 다양한 로직 처리가 필요한 동적 컨텐츠 제공

대표적인 프로토콜

▶ TCP/IP Protocol

• IP: Internet Protocol의 약자로, 네트워크에서 정보를 주고받는데 사용하는 아주 중요한 규약
• RARP: Reverse Address Resolution Protocol의 약자로, IP를 확인하는 프로토콜
• FTP: 파일을 전송하는 프로토콜
• DNS: 주소창에 문자를 입력하면 해당하는 IP 주소로 매핑을 시켜주는 기능
• HTTP: Hyper Text Transport Protocol의 약자로, 기능이 통상적인 텍스트 문서 주고받는 수준
• HTTPS: Hyper Text Transfer Protocol over Secure Socket Layer
  • HTTP의 보안 향상 버전으로, 암호화해서 통신함
  • 위험한 데이터(카드번호, 주민번호, 전화번호 등)를 http로 전송하면 데이터를 바로 볼 수 있음
  • 민감한 정보는 반드시 https로 보내야 함

요청과 응답

웹 != 인터넷

1. 인터넷

Local Area Network (LAN)

• 근거리 통신망, 구내 정보 통신망은 네트워크 매체를 이용하여 집, 사무실, 학교 등의 건물과 같은 가까운 지역을 한데 묶는 컴퓨터 네트워크

LAN 이외에도 MAN(Metropolitan Area Nework), WAN(Wide Area Network)와 같은 다양한 네트워크 존재

 

Internet은 이러한 컴퓨터 네트워크들을 서로 연결 지어주는 범지구적 네트워크이다.

(= Inter-Network = 컴퓨터 네트워크들의 네트워크)

 

이렇게 구축된 인터넷이라는 거대한 네트워크 위에서 오늘날 우리가 사용하는 다양한 서비스들이 동작하는데,

웹도 인터넷 위에서 동작하는 서비스들 중 하나이다.

 

2. 웹(World Wide Web)

웹의 존재 이유는 정보(자원)의 공유이다.

-> 웹은 수많은 요청과 응답 사이클의 연속으로 이루어진다.

서버 & 클라이언트

• 서버 (Server): 정보, 자원, 서비스를 제공하는 측. 요청을 받고 응답하는 측. (Response) - 웹서버
• 클라이언트 (Client): 정보, 자원, 서비스를 사용하는 측. 요청을 보내는 측. (Request) - 웹브라우저

HTTP (HyperText Transfer Protocol)

• 웹 요청과 응답에 관한 클라이언트와 서버 사이의 규약 (약속)
• HTTPS는 HTTP에서 보안이 더욱 강화된 버전

HTTP의 대표적인 특성

(1) 비연결성(Connectionless)

 

클라이언트의 요청에 대해 서버가 응답을 마치면 연결을 끊어버리며,

다음 요청은 새로운 연결을 통해 이루어진다

• 단점: 매번 모든 요청에 대해 새로운 연결/해제 과정을 거치므로 네트워크 비용 측면에서 비효율적
• 보완책: HTTP/1.1 Keep-Alive 서버와 클라이언트 사이에서 통신이 없어도 지정된 시간 동안 연결을 유지하는 기능

(2) 무상태(Stateless)

서버와 클라이언트는 하나의 요청이 진행되는 동안만 서로를 인지한다.

• 단점: 클라이언트 인증(로그인)이 필요한 서비스에서 불편함
• 보완책: 쿠키, 세션, 토큰(OAuth - 인증 프로토콜, JWT - JSON 형태의 토큰) - 상태를 기억하기 위한 기능들
  • 쿠키: 웹 브라우저에 저장되는 작은 데이터 파일로, 사용자의 정보를 서버와 주고받을 때 사용됨
  • 세션: 서버 측에서 사용자 정보를 저장하여 클라이언트와의 연결을 유지하는 방식
  • 토큰: 인증을 위해 사용자 정보를 포함하는 문자열로, 서버와 클라이언트 간 안전한 정보 전달을 위해 사용됨

HTTP Status Code (응답 패킷)

클라이언트의 요청에 대해서 서버는 요청에 대한 처리 상태를 숫자 코드로 반환한다.

e.g. 200 (서버가 요청을 제대로 처리했을 때), 404 (요청한 페이지 찾을 수 없음)

• 1xx: (정보) 요청을 받았으며 프로세스를 계속한다.
• 2xx: (성공) 요청을 성공적으로 받았으며 인식해서 처리했다.
• 3xx: (리다이렉션) 요청 완료를 위해 추가 작업 조치가 필요하다.
• 4xx: (클라이언트 에러) 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
• 5xx: (서버 에러) 서버가 명백히 유효한 요청에 대해 충족을 실패했다. -> 취약점을 일으킬 부분을 찾았다는 의미일 수도 있음

HTTP Method (Verbs) - 의도 / 방법

클라이언트가 요청을 보낼 때 해당 요청의 목적이 뭔지 HTTP Method를 통해 명시한다.

• GET - 서버의 리소스를 조회하고자 할 때 URL 쿼리를 통해 파라미터를 담아 요청 (READ)
• POST - 서버에 리소스를 생성하고자 할 때 HTTP Body를 통해 파라미터를 담아 요청 (CREATE)
• PUT - 서버의 리소스를 생성하거나 수정할 때 (UPDATE)
• DELETE - 서버의 리소스를 삭제할 때 (DELETE)
• HEAD - GET과 동일하나, 서버에서 Body(Content)를 빼고 HEAD로만 응답 (리소스 확인의 용도)
• PATCH - 리소스의 일부를 수정할 때
• OPTIONS - 지원 가능한 메서드 종류를 알아볼 때
• TRACE - 리소스의 경로를 따라 메시지 look-back 테스트를 실행
• CONNECT - 리소스로 식별되는 서버로의 터널을 맺을 때

임의의 메소드를 만들어서 정의도 가능하다.

 

RestAPI: GET, POST, PUT&PATCH, DELETE

웹 요청과 응답 과정

▶ Example) 티스토리 홈페이지에 대한 요청과 응답

 

1. URL: Uniform Resource Locator. 네트워크상 자원의 위치(주소)

2. 홈 페이지에 대한 요청을 서버로 전송 (HTTP Request)

• URL을 치고 ENTER를 치면 브라우저가 행위를 해석해 HTTP Request를 서버로 보냄 (GET - 읽기 요청)

3. 서버가 클라이언트로부터 요청을 받고 처리

• Request Headers 확인 = 요청에 대한 정보 (URL, Method ..) + 클라이언트에 대한 정보
• 요청에 상응하는 로직 수행
• 홈페이지에 해당하는 html 파일을 찾은 후 요청에 대한 응답 생성

4. 서버가 클라이언트에게 응답 (HTTP Response)

5. 클라이언트(웹 브라우저)가 응답을 받은 후 필요한 리소스들을 추가 요청 & 응답 받기

6. 클라이언트(웹브라우저)가 모든 리소스 요청에 대한 응답을 받음

• 렌더링: 클라이언트가 서버로부터 받은 리소스를 처리하여 사용자에게 화면에 표시하는 과정

※ Example

• 티스토리 블로그 글 임시저장 요청과 응답: POST - payload(POST, PUT같은 요청 보낼 때 포함되는 데이터)
• 티스토리 임시 저장된 글 삭제 요청과 응답: DELETE

▶ 전반적으로 요청과 응답은 비슷한 구조

요청 내용

URL

▶ 인터넷에 있는 자원의 정보(위치)

• 프로토콜: 서버 리소스에 접근하기 위함 https:// http://
• Host: ehapdls.ip:pw@www.link.com:port 형태
• Path: 파일의 위치 /, .../ 등
• Query String: 파라미터 전달
• Fragment: 북마크 위치

HTTP Version

1.0, 1.1, 2, 3 -> 1.1이 여전히 가장 많이 쓰인다.

 

Request Header

▶ Request Header

• Host: 요청하는 host
• Content-Type: 이 형식으로 받아들여 달라는 의미
• Content-Length: Post Body 데이터의 길이
• User-Agent: 요청하는 클라이언트 정보
• Referer: 요청 패킷이 어디서부터 흘러왔는지 알려주는 정보
• Cookie: 사용자 세션 정보와 같이 어디서부터 흘러왔는지 알려주는 정보

쿠키 vs 세션

쿠키 (Cookie)

요청과 응답은 독립적인 통신으로, 여러 번 주고받더라도 서로 연동되지 않는다.

따라서 서로 같은 연결임을 알려주어야 한다.

 

쿠키는 브라우저에 임시로 저장되는 txt 파일로, key - value 형태로 되어 있다.

이 값을 함께 전달해 주어 같은 요청임을 표시할 수 있다.

 

세션 (session)

클라이언트로부터 오는 일련의 요청을 하나의 상태로 보고 일정하게 유지하는 기술로,

클라이언트가 웹 서버에 접속해 있는 상태가 하나의 단위이다.

 

세션 동작 순서

• 클라이언트 요청
• Request-Header 필드의 Cookie에서 Session ID를 보냈는지 확인
• Session ID가 없을 경우, 서버에서 생성해서 클라이언트에게 전송
• 쿠키를 사용해 세션 ID 저장
• 클라이언트 재접속 시, 쿠키를 이용해 세선 ID 값을 서버에 전달

브라우저는 세션 ID를 쿠키에 저장하고, 이를 서버에서 받아 매칭한다.

▶ 쿠키 vs 세션

프록시 실습

요청과 응답을 중간에 가로채서 볼 수 있다.

이때 서버 단은 컨트롤할 수 없으나, 중간에 주고받는 것은 변조가 가능하다.

즉, 바깥으로 나가기 전에 중간에 끼어들어 통신을 제어한다.

ex) Burp Suite, Fiddler

 

 

 

프록시 vs VPN

 

IP주소라는 것은 인터넷에 들어갈 때 가지고 들어가는 신분증으로서,

이를 이용해 광고 회사들은 IP라는 신분증을 보고 어떻게 효율적으로 광고할지,

인터넷 회사들은 어떻게 IP를 효율적으로 관리할지,

사이버 경찰은 IP주소를 이용해 어떻게 수사에 이용할지 고민하며 사용한다.

 

인터넷 사생활 침해 아닌가? 

이러한 의문점을 바탕으로 나온 것이 프록시와 VPN이다.

 

프록시

유저와 인터넷 사이에 위치하여, 마치 유저가 요청을 보낸 것이 아닌 프록시의 서버가 요청한 것처럼 만든다.

▶ 해킹 방지, 정부의 규제 우회

 

VPN(Virtual Private Network)

가상 사설 네트워크이다.

▶ 정부의 규제 우회, 해킹 방지

 

프록시는 중간에서 IP만 바꾸어 내용을 전달한다.

 

VPN은 암호화된 상태로 VPN 서버로 전달된 후, 암호화된 데이터를 복호화하여 인터넷에 전달,

그리고 인터넷에서 응답이 오면 VPN에서 다시 암호화하여 유저에 전달한 후, 유저의 컴퓨터에서 복호화한다.

이때, VPN은 정보가 암호화되니 IP도 자연스레 가려지게 된다.

Fiddler 사용법

HTTPS 보기

HTTPS는 원래 클라이언트와 서버만이 해독할 수 있는 방식으로 암호화되어 중간에 가로채도 볼 수 없다.

때문에 HTTPS를 보려면 Fiddler를 사용자의 컴퓨터에서 신뢰받는 프록시 역할을 하도록 설정하여야 한다.

이 방식은 Fiddler가 가짜 인증서를 사용해 트래픽을 가로채고 복호화한 뒤 다시 암호화하여 서버로 전달하는 방식이다.

▶ Fiddler -> Tools -> Option -> HTTPS -> Decrypt HTTPS CONNECTs, Decrypt HTTPS traffic 선택

▶ 실시간으로 주고받는 내용을 볼 수 있다.

 

주요 기능

• Capturing:  단축키 F2, 이 기능을 통해 브라우저를 띄우게 되면 그 브라우저를 모니터링할 수 있음
• 브레이크 포인트: 단축키 F11, 클라이언트가 서버에 요청하는 패킷 잡아두거나 서버가 클라이언트에 응답하는 패킷 변조 가능
  • Break Point 한 번 클릭 시: Request 패킷 활성화 -> 클라이언트가 서버에 요청하는 패킷을 잡아 둠
  • Break Point 두 번 클릭 시: Response 패킷 활성화 -> 서버가 클라이언트에게 응답하는 패킷 변조 가능
  • Break Point 세 번 클릭 시: Break Point를 Off

브레이크 포인트 기능은 주로 Request 패킷을 활성화하여 중간에 클라이언트가 서버에 전송하는 패킷을 변조하여 사용할 수 있다.

 

기타 기능

• 패킷 재전송: 해당 패킷을 선택한 뒤 단축키 R
• 패킷 수정: 이미 보낸 패킷을 고치려면 단축키 E (브라우저에는 반영 안 됨, Fiddler에만 조작 가능)
• 패킷 검색: ctrl + F
• 문자열을 특정 형식으로 변환(해싱, 인코딩, 디코딩 등): ctrl + E

 

 

문제별 해결방법

1. Fiddler HTTPS 인증서 오류

▶ 개인 정보 보호 오류

 

Fiddler를 키면 google 혹은 youtube 등이 접속이 안 되는 오류가 발생했다.

 

Fiddler는 웹사이트와 브라우저 사이에서 프록시 역할을 하면서 트래픽을 중간에서 확인한다.

이때 HTTPS 트래픽을 복호화하려면 Fiddler의 자체 인증서가 필요한데,

google과 youtube는 HSTS(HTTP Strict Transport Security) 정책을 사용해서 중간자 인증서를 거부한다.

그래서 브라우저가 Fiddler의 인증서를 신뢰하지 않으면 위와 같은 오류가 발생할 수 있다.

 

오류가 발생한 이유는 Fiddler의 인증서가 손상되었거나 브라우저에서 신뢰하지 않아서 HTTPS 연결이 차단된  것일 가능성이 크다. 때문에 새로운 인증서를 등록하여 오류를 해결할 수 있었다.

 

해결방법: Fiddler 인증서 초기화

• Tools - Options - HTTPS - Actions 버튼 - Reset All Certificate

2. Fiddler Breakpoint 설정 시 패킷이 안 뜨는 문제

 

chrome은 특정 요청이 너무 오래 걸리면 자동으로 취소하고 재시도하지 않는다.

특히 google 검색 자동완성 요청은 짧은 시간 내 응답을 받지 못하면 다시 보내지 않는다.

그래서 Breakpoint에서 중단된 요청이 chrome 쪽에서 사라져버릴 수 있다.

 

즉, 'Before Request'에서 멈추면 google이 요청을 취소해서 패킷이 사라지고, 

'Disabled'이면 Breakpoint 자체가 비활성화 되어 있는 것이다.

 

해결방법: 'After Response'로 변경

• Rules - Automatic Breakpoints - After Response

이렇게 하면 요청은 정상적으로 보내지고 응답만 멈추기에 패킷이 안 뜨는 문제를 해결할 수 있다.

 

하지만, 서버에서 Response를 보낸 후에는 Request를 다시 수정해서 보낼 방법이 없기 때문에 'After Response'로 설정하면 Request의 변수값들을 수정할 수 없다. 

 

즉, Request 수정하려면 'Before Request'로 설정해야 한다.

• 변조 방법: 패킷 클릭 -> Inspectors의 WebForms 항목의 변수 값 수정 후 'Run to Completion' 버튼 클릭

 

몇 가지 Mitigation

SOP (Same Origin Policy)

프로토콜, 호슽, 포트가 같은 서버로만 리소스를 주고받을 수 있게 한다.

▶ 예시

CORS (Cross Origin Resource Sharing)

SOP에 의해 다른 출처의 리소스를 사용할 수 없게 되었다.

이때 CORS를 사용하면 특정 출처의 선택한 자원에 접근할 수 있는 권한을 부여할 수 있다.

 

이는 서버에서 Access-Control-Allow-Origin 헤더를 추가함으로써 동일 출처로 이동시킨다.

CSP (Content Security Policy)

서버에서 허용한 동작만 브라우저가 수행하도록 설정하는 방식이다.

이는 원천적으로 잘못된 요청 자체가 나가지 않도록 한다.

몇 가지 취약점

세션 / 쿠키 변조

쿠키는 클라이언트(사용자의 브라우저)에 저장되는 데이터로, 서버와 클라이언트 간에 상태 정보를 저장하거나 세션을 관리하는 데 사용된다. 쿠키는 기본적으로 사용자의 컴퓨터에 저장되기 때문에, 사용자가 이를 임의로 수정할 수 있다.

 

쿠키 변조

쿠키에 저장된 세션 토큰이나 사용자 정보(id 등)을 사용자가 임의로 수정할 수 있다.

 

예를 들어, id: user 1로 저장된 쿠키를 id: admin으로 변경하면,

시스템이 이를 인정하여 관리자(admin) 권한으로 접근할 수 있게 된다.

 

이렇게 서버가 단순히 쿠키의 값을 확인해서 인증을 처리한다면, 쿠키 변조만으로 인증을 우회할 수 있다.

 

세션 토큰 훔치기

세션 토큰은 사용자가 로그인 후 세션을 식별하기 위해 서버에서 발급한 값으로, 보통 쿠키에 저장된다.

 

악성 사이트를 방문하거나, 쿠키의 값을 유출시키는 방법으로 다른 사용자의 세션 토큰을 탈취할 수 있다.

세션 토큰을 훔친 후, 이를 내 브라우저의 쿠키에 삽입하면,

서버가 이를 유효한 토큰으로 인식하여 다른 사용자의 계정에 로그인될 수 있다.

 

이러한 취약점은 강력한 인증 및 세션 관리와 ID/PW 등의 암호화를 통해 방지할 수 있다.

SQL Injection

Injection

신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로 전달될 때 발생한다.

공격자의 악의적인 데이터로 인해 예기치 않은 명령이 실행되거나 올바른 권한 없이 데이터에 접근할 수 있다.

 

SQL Injection

서버의 구문상의 문제를 이용하는 방법으로, SQL 삽입, SQL 주입이라고도 하며, 코드 인젝션의 기법 중 하나이다.

이 방식은 클라이언트의 입력값 조작을 통해 서버의 Database를 공격하는 방식이다.

▶ SQL Injection

▶ 예시) 로그인 성공

• 1 = 1: 항상 True
• #: 뒤 구문 생략

XSS (Cross Site Scripting)

악성 스크립트를 웹사이트에 주입하는 코드 인젝션의 기법 중 하나이다.

이는 공격자가 웹 어플리케이션에 보낸 악성 코드가 다른 사용자에게 전달될 때 발생한다.

 

주로 게시판, 댓글창 등에 <script>와 같은 태그를 끼워넣는 방식으로 작동한다.

또한, 이메일의 내용도 사용자가 입력한 내용을 포함할 수 있기 때문에, 수상한 이메일을 열어보면 안 된다.

 

공격자는 <script>, <button>, href, src 등 HTML 태그를 이용해 사용자 데이터를 훔치거나, 악성 행동을 유도할 수 있다.

예를 들어, 로그인 정보를 훔치거나, 사용자가 의도하지 않은 요청을 서버로 보내는 CSRF 변조 요청 기법으로 이어질 수 있다.

 

이러한 XSS는 스크립트 문장에 존재할 수 있는 <, >, (, ), #, & 등의 메타 문자를 다른 문자로 변환하거나 글 게재 시점에서 스크립트가 있는 경우에는 게재를 차단하여 해결 가능하다.

 

 

Reflected XSS

공격자가 사용자에게 악성 스크립트를 메일이나 웹 사이트를 통해 전달하고 사용자가 실행하도록 하는 공격 기법이다.

▶ Reflected XSS

• 해커가 공격 스크립트가 포함된 URL을 사용자에게 클릭하도록 유도
• URL을 클릭하면 취약점이 있는 서버에 요청을 보냄
• 웹 서버가 스크립트를 포함한 것에 대해 응답을 보내고 브라우저는 서버에서 온 응답을 실행
• 해커가 사용자의 민감한 데이터를 얻게 됨

Stored XSS

공격자가 취약점이 있는 Web Application에 악성 스크립트를 영구적으로 저장하여 다른 사용자에게 전달하는 방식이다.

▶ Stored XSS

• 악성 스크립트를 포함한 글을 게시판에 업로드
• 게시글을 사용자에게 노출시키고 사용자가 글을 클릭
• 사용자는 스크립트에 대한 요청을 서버에 전송
• 웹 서버에서 스크립트를 포함한 응답을 전송하여 공격에 성공

DOM Based XSS

Document Object Model은 HTML 및 XML 문서에 접근하는 방법을 표준으로 정의하는 문서 객체 모델이다.

DOM Based XSS는 이러한 DOM 환경을 사용자의 브라우저에서 수정하여 코드가 예상치 못한 방식으로 실행되는 공격이다.

 

DOM Based XSS

• 해커에 의해 공격 스크립트가 전송
• 사용자가 링크를 클릭하면 브라우저가 요청
• 서버에서 스크립트가 포함된 페이지로 응답하고 브라우저는 페이지에 대한 DOM 객체를 생성
• 브라우저에서 해커의 악성 스크립트가 실행됨

과제: XSS game 문제 해결하기

모든 문제는 alert 창 하나를 띄우면 성공이다.

<script>alert()</script>

▶ Level 1

<button onclick="alert()">button</button> // 첫 번째 solution
<img src=# onerror=alert()> // 두 번째 solution

▶ Level 2

• 첫 번째 solution: 버튼을 클릭할 때 alert() 함수가 실행되도록 설정
• 두 번째 solution: 이미지 소스를 잘못된 값으로 지정하여 이미지 로드를 실패하게 만들고, 이미지 로드 실패 시 onerror 이벤트를 트리거하여 alert()가 실행되도록 설정

---

참고자료

https://www.youtube.com/watch?v=0jV7xOUcKog

https://www.youtube.com/watch?v=hjRQzHeirw8

https://new82.tistory.com/222

Fiddler HTTPS 인증서 오류 시 해결방법

https://mu-sa.tistory.com/97

Fiddler의 간단한 기능과 패킷 변조

https://www.youtube.com/watch?v=laQAQeuuJF4

https://blog.naver.com/oriisme/223332700003

[웹해킹] XSS game 문제 해결하기

https://com-on-bappool.tistory.com/59

xss-game / Level2 : Persistence is Key [write-up]