웹
웹으로 연결된 사람들 사이에 형성되는 정보의 흐름이 마치 거미줄 같다고 하여 붙여진 이음
웹은 인터넷을 기반으로 구현된 서비스 중 HTTP를 이용하여 정보를 공유하는 서비스이다
정보를 제공하는 주체를 웹 서버(Web Server), 정보를 받는 이용자를 웹 클라이언트(Web Client)의 역할이 있으며
이전의 웹 서비스가 이용자가 요청하는 정보를 제공하기만 하는 수동적인 형태의 서비스였다면 현재는 이용자의 요청을 해석하고 가공하여 필요한 정보와 기능을 제공하는 능동형 서비스에 가깝다
이용자의 요청을 받는 부분을 프론트엔드(Front-end), 요청을 처리하는 부분을 백엔드(Back-end)라고 한다
프론트엔드는 이용자에게 직접 보여지는 부분으로 웹 리소스(Web Resource)로 구성되어있다
웹 리소스
웹에 갖춰진 정보 자산
웹 브라우저의 주소창에 http://dreamhack.io/index.html 주소를 입력하면 dreamhack.io에 존재하는 /index.html 경로의 리소스를 가져오라는 의미
모든 웹 리소스는 고유의 Uniform Resource Identifier (URI)를 가지며 이를 이용하여 식별됨
Hyper Text Markup Language (HTML)
웹 문서의 뼈와 살을 담당
태그와 속성을 통한 구조화된 문서 작성을 지원
Cascading Style Sheets (CSS)
웹 문서의 생김새를 지정
웹 리소스들의 시각화 방법을 기재한 스타일 시트
글자의 색깔이나 모양, 배경 색상, 이미지의 크기나 위치 등을 CSS로 지정 브라우저는 css를 참고하여 웹 문서를 시각화
JavaScript (JS)
웹 문서의 동작을 정의
이용자가 버튼을 클릭했을 때 어떻게 반응할지, 이용자가 데이터를 입력하면 어디로 전송할지 등을 JS로 구현
JS는 이용자의 브라우저에서 실행됨
클라이언트가 실행하는 코드라고 하여 Client-Side Script라고도 부름
그 외
문서, 이미지, 동영상, 폰트 등
클라이언트와 서버의 응답 요청 ->
(클라이언트) 이용자가 브라우저를 이용하여 웹 서버에 접속합니다.
(클라이언트) 브라우저는 이용자의 요청을 해석하여 HTTP 형식으로 웹 서버에 리소스를 요청합니다.
(서버) HTTP로 전달된 이용자의 요청을 해석합니다.
(서버) 해석한 이용자의 요청에 따라 적절한 동작을 합니다. 리소스를 요청하는 것이라면, 이를 탐색합니다. 계좌 송금, 입금과 같은 복잡한 동작을 요구할 경우 내부적으로 필요한 연산을 처리합니다.
(서버) 이용자에게 전달할 리소스를 HTTP 형식으로 이용자에게 전달합니다.
(클라이언트) 브라우저는 서버에게 응답받은 HTML, CSS, JS 등의 웹 리소스를 시각화하여 이용자에게 보여줍니다.
HTTP/ HTTPS
인코딩(Encoding) 표준이라고 부르는데 대표적으로 아스키(Ascii)와 유니코드(Unicode)
통신 프로토콜📃
클라이언트의 행위를 요청(Request), 서버의 행위를 응답(Response)
규격화된 상호작용에 적용되는 약속
많은 컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터(이하 메시지)를 명확히 해석할 수 있도록 문법(syntax)을 포함
이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시
현재까지 제정된 표준 통신 프로토콜에는 네트워크 통신의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP
HTTP (Hyper Text Transfer Protocol)
서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜
HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면 서버가 응답하는 것
웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킴
이 포트는 일반적으로 TCP/80 또는 TCP/8080임
네트워크 포트(Network Port)
란 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소
포트에는 항구라는 의미가 있는데, 클라이언트가 서버의 포트에 접근하여 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보내는 장면을 연상시킴
편의상 네트워크를 설명하는 맥락에서는 네트워크를 생략하여 “포트” 라고 부르기도 함
서비스 포트(Service Port)
는 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트
예를 들, HTTP가 80번 포트를 점유하고 있다면 HTTP의 서비스 포트는 80번 포트가 됨
포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따름 대표적으로는 TCP와 UDP
TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 않음
포트의 개수는 운영체제에서 정의하기 나름
그러나 현대의 윈도우나 리눅스, 맥 운영체제는 0번 부터 65535번까지, 총 65536개의 같은 수의 네트워크 포트를 사용
포트 중 0번부터 1023번 포트는 잘 알려진 포트(Well-known port) 또는 특권 포트(Privileged port)
각 포트 번호에 유명한 서비스가 등록되어 있음 대표적으로 22번 포트에는 SSH, 80에는 HTTP, 443에는 HTTPS가 할당
잘 알려진 포트에 서비스를 실행하려면 관리자 권한이 필요
따라서 클라이언트는 이 대역에서 실행 중인 서비스들은 관리자의 것이라고 신뢰할 수 있음
HTTP 메시지
HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있음
기능과 세부 구조에서는 차이가 있지만 크게 보면 이들은 HTTP 헤드와 바디로 구성된다는 공통점이 있음
HTTP 헤드
HTTP 헤드의 각 줄은 CRLF로 구분되며 첫 줄은 시작 줄(Start-line), 나머지 줄은 헤더(Header)라고 부름
헤드의 끝은 CRLF 한 줄로 나타냄
시작 줄의 역할은 요청과 응답에서 큰 차이가 있음
헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타냄
하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있음
HTTP 바디
HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말함 클라이언트나 서버에게 전송하려는 데이터가 바디에 담김
HTTP 요청
HTTP 요청은 서버에게 특정 동작을 요구하는 메시지
서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고 적절할 때만 이를 처리함
시작 줄
HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성
각각은 띄어쓰기로 구분함
메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타냄
HTTP 표준에 정의된 메소드는 8개가 있으나 비교적 자주 사용되는 GET과 POST 메소드
GET은 리소스를 가져오라는 메소드
이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요
이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아옴
반대로, POST는 리소스로 데이터를 보내라는 메소드
전송할 데이터는 보통 HTTP 바디에 포함됨
로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내짐
이 외에 요청 URI는 메소드의 대상을, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타냄
헤더와 바디
시작 줄을 제외한 헤더와 바디는 HTTP 메시지의 것과 같음
GET요청과 POST 요청의 구조 ->
HTTP 응답
HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지
요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함됨
시작 줄
HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성
각각은 띄어쓰기로 구분함
HTTP 버전은 서버에서 사용하는 HTTP 프로토콜의 버전을 나타냄
상태 코드는 요청에 대한 처리 결과를 세 자릿수로 나타냄
HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데,각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류됨 처리 사유는 상태 코드가 발생한 이유를 짧게 기술한 것
헤더와 바디
시작 줄을 제외한 헤더와 바디는 HTTP 메시지의 것과 같음
200 상태 코드를 갖는 응답 ->
HTTPS (HTTP over Secure socket layer)
HTTP의 응답과 요청은 평문으로 전달됨 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있음
예를 들어 로그인할 때 전송한 POST 요청에는 대개 이용자의 ID와 비밀번호가 포함되는데 공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있음
HTTPS는 TLS(Transport Layer Security) 프로토콜을 도입하여 이런 문제점을 보완함
TLS (Transport Layer Security)
는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화함
공격자가 중간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능하며결과적으로 HTTP 통신이 도청과 변조로부터 보호됨
Wireshark로 확인한 HTTP 및 HTTPS의 웹 서버와 오가는 메시지
빨강(request), 파랑(response)
HTTP 메시지는 쉽게 읽을 수 있지만 HTTPS의 것은 해석할 수 없음
HTTPS가 제정된 초기에는 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들 위주로 HTTPS가 사용되었다 그러나 현재 개발되는 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세이다
TLS의 기반이 되는 공개 키 암호 시스템(Public Key Crypto Standard, PKCS) 및 대칭 키 암호(Symmetric Key Cryptography)
웹 브라우저
웹 브라우저는 서버와 HTTP 통신을 대신해주고, 수신한 리소스를 시각화
웹 브라우저는 뛰어난 이용자 경험(User eXperience, UX)을 제공하는 소프트웨어
URL (Uniform Resource Locator)
웹에 있는 리소스의 위치를 표현하는 문자열
브라우저로 특정 웹 리소스에 접근할 때는, URL을 사용하여 이를 서버에게 요청
URL은 Scheme, Authority (Userinfo, Host, Port), Path, Query, Fragment 등으로 구성됨
Domain Name
URL 구성 요소 중 Host는 웹 브라우저가 접속할 웹 서버의 주소를 나타냄
Host는 Domain Name, IP Address의 값을 가질 수 있음
IP Address는 네트워크상에서 통신이 이루어질 때 장치를 식별하기 위해 사용되는 주소
불규칙한 숫자로 이루어진 IP Address는 사람이 외우기 어려우므로 일반적으로는 도메인의 특성을 담은 이름을 정의하여 IP 대신 사용
Domain Name을 Host 값으로 이용할 때, 브라우저는 Domain Name Server(DNS) 에 Domain Name을 질의하고, DNS가 응답한 IP Address를 사용함
예를 들어 웹 브라우저에서 http://example.com에 접속할 경우, DNS에 질의해 얻은 example.com의 IP와 통신함
Domain Name에 대한 정보는 MacOS/Linux/Windows에서 nslookup 명령어를 사용해 확인
웹 렌더링(Web Rendering)
서버로부터 받은 리소스를 이용자에게 시각화하는 행위
서버로부터 HTML과 CSS를 받으면 브라우저는 HTML을 파싱하고 CSS를 적용하여 이용자에게 보여줌
웹 렌더링 엔진에 의해서 이뤄지는데, 브라우저별로 서로 다른 엔진을 사용함
사파리는 웹킷(Webkit), 크롬은 블링크(Blink), 파이어폭스는 개코(Gecko) 엔진을 사용
HTML-injecton reflected (POST)
low
버프스위트의 intercept를 on으로 하고
firstname과 lastname에 아무거나 입력을 한 뒤 버프스위트를 확인하면 버프스위트가 낚은
페이지 소스가 뜬다
이 소스에 GET 요청과 같이
<h1>SUCCESS</h1> <img src="http://[ip]/bWAPP/images/bee_1.png>를 입력해 forward를 클릭해 응답을 준다
medium
ASCII 인코딩을 사용해 %3C %3E %2F로 대치시켜 입력
-> 실패
더블 인코딩
인코딩에 사용하는 % 문자도 인코딩이 되었다 % 문자를 인코딩한 %25을 적용해 더블인코딩된 값을 입력한다
<의 더블인코딩한 결과는 %253C
high
htmi_post.php를 확인하니
high 레벨의 경우 받은 데이터를 xss_check_3으로 처리한다
xss_check_3은 htmlspecialchars의 우회 방식을 쓰기 때문에 이전의 GET과 동일한 이유로 조작이 불가능하다
