[Web Hacking]Background - Web 정리

Background: Web

웹(Web) : HTTP를 이용하여 정보를 공유하는 서비스
웹 서버 (Web Server) : 정보를 제공하는 주체

웹 클라이언트 (Web Client) : 정보를 받는 이용자


이전의 웹 서비스가 이용자가 요청하는 정보를 제공하기만 하는 수동적인 형태의 서비스였다면,  현재는 이용자의 요청을 해석하고 가공하여 필요한 정보와 기능을 제공하는 능동형 서비스에 가깝다.

• 프론트엔드(Front-end) : 이용자의 요청을 받는 부분/이용자에게 직접 보여지는 부분으로, 웹 리소스(Web Resource)로 구성
• 백엔드 (Back-end) : 요청을 처리하는 부분

 

웹 리소스(Web Resource) : 웹에 갖춰진 정보 자산
모든 웹 리소스는 고유의 Uniform Resource Identifier(URI)를 가지며, 이를 이용하여 식별된다.

 

웹의 프론트엔드를 구성하는 대표적인 웹 리소스

• Hyper Text Markup Language (HTML) :
  웹 문서의 뼈와 살을 담당. 태그와 속성을 통한 구조화된 문서 작성을 지원
• Cascading Style Sheets (CSS) :
  웹 문서의 생김새를 지정. 웹 리소스들의 시각화 방법을 기재한 스타일 시트. 글자의 색깔이나 모양, 배경 색상, 이미지의 크기나 위치 등을 CSS로 지정하고 브라우저는 이를 참고하여 웹 문서를 시각화한다.
• JavaScript (JS) :
  웹 문서의 동작을 정의. 이용자가 버튼을 클릭했을 때, 어떻게 반응할지, 이용자가 데이터를 입력하면 어디로 전송할지 등을 JS로 구현. JS는 클라이언트가 실행하는 코드라고 하여 Client-Side Script라고도 부른다.
• 그 외 :
  문서, 이미지, 동영상, 폰트 등

 

웹 서비스의 통신 과정을 간략화하면 다음과 같다.

1. (클라이언트) 이용자가 브라우저를 이용하여 웹 서버에 접속한다.
2. (클라이언트) 브라우저는 이용자의 요청을 해석하여 HTTP 형식으로 웹 서버에 리소스를 요청한다.
3. (서버) HTTP로 전달된 이용자의 요청을 해석한다.
4. (서버) 해석한 이용자의 요청에 따라 적절한 동작을 한다다. 리소스를 요청하는 것이라면, 이를 탐색한다. 계좌 송금, 입금과 같은 복잡한 동작을 요구할 경우 내부적으로 필요한 연산을 처리한다.
5. (서버) 이용자에게 전달할 리소스를 HTTP 형식으로 이용자에게 전달한다.
6. (클라이언트) 브라우저는 서버에게 응답받은 HTML, CSS, JS 등의 웹 리소스를 시각화하여 이용자에게 보여준다.

---

 

요약

통신: 정보를 전하는 것
웹: 인터넷이라는 통신망을 활용하여 구현된 전 지구적 정보 공간
웹 클라이언트: 웹에서 정보를 요구하는 주체
웹 서버: 웹에서 정보를 제공하는 주체
웹 리소스: 웹 서버가 제공하는 정보 자원(e.g. HTML, Javascript, CSS 등)
웹 서비스: 웹 상에서 제공되는 서비스 (e.g. SNS, 온라인 쇼핑몰 등)

---

Background: HTTP/HTTPS

인코딩
컴퓨터의 모든 데이터는 0과 1로 구성된다. 0과 1로 우리의 문자를 표현하는 것도 일종의 약속 덕분인데, 이런 약속들을 특별히 인코딩(Encoding) 표준이라고 부른다.

*대표적 예시 : 아스키(Ascii), 유니코드(Unicode)

통신 프로토콜

요청(Request) : 웹에게 특정 리소스를 지정하여 제공해달라고 하는 클라이언트의 행위

응답(Response) : 해당 요청을 이해하고, 대응되는 동작을 통해 클라이언트에게 리소스를 반환하는 서버의 행위

프로토콜(Protocol)은 규격화된 상호작용에 적용되는 약속을 이른다.
컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터를 명확히 해석할 수 있도록 문법(syntax)을 포함한다. 일반적으로 이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시된다.
표준 통신 프로토콜 : 네트워크 통신의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP 등이 있다.

HTTP(Hyper Text Transfer Protocol) : 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜
HTTP의 기본 메커니즘 : 클라이언트가 서버에게 요청하면, 서버가 응답하는 것. 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서비스 포트에 HTTP 요청을 전송하면 이를 해석하여 적절한 응답을 반환한다.

네트워크 포트(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 헤더(Headers) : 각 줄은 CRLF로 구분, 첫 줄은 시작 줄(Start line), 나머지 줄은 헤더(Header)라고 부른다. 헤더의 끝은 빈 줄로 나타낸다. 영문 표기에서는 Headers와 Header이지만, 한국어에서는 모두 헤더로 부른다.

헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타낸다. 하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있다.
HTTP 바디(Body) : 헤드의 끝을 나타내는 CRLF 뒤의 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 바디에 담긴다.
*CRLF : Carriage Return(CR)와 Line Feed(LF)의 조합을 나타낸다. Carriage Return은 커서를 현재 줄의 맨 앞으로 이동시키는 문자이고, Line Feed는 커서를 다음 줄로 이동시키는 문자이다.

 

 

<HTTP 요청>
HTTP 요청은 서버에게 특정 동작을 요구하는 메시지이다. 서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고, 적절할 때만 이를 처리한다.

시작 줄
HTTP 요청의 시작 줄은 메소드(Method), 요청 대상(Request target), 그리고 HTTP 버전으로 구성된다.
*메소드 : 요청 대상에 대해 서버가 수행하길 바라는 동작을 나타낸다. HTTP 표준에 정의된 메소드는 8개가 있다.

• GET : 리소스를 가져와달라 요청하는 메소드이다.
  이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아온다.
• POST : 요청 대상에게 데이터를 보내는 메소드이다.
  전송할 데이터는 보통 HTTP 바디에 포함된다. 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내진다.

요청 URI는 메소드의 대상을, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타낸다.

헤더와 바디
시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같다.


<HTTP 응답>
HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지이다. 요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함된다.

시작 줄
HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성된다.
*HTTP 버전 : 서버에서 사용하는 HTTP 프로토콜의 버전을 나타낸다.
*상태 코드 : 요청에 대한 처리 결과를 세 자릿수로 나타낸다. HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데, 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류된다. 각 클래스에 대한 설명은 아래의 표 참조.

상태 코드	설명	대표 예시
1xx	요청을 받았고 처리 중임
2xx	요청이 제대로 처리됨	200(OK) : 성공
3xx	요청을 처리하려면 클라이언트가 추가 동작을 취해야 함	302(Found) : 다른 URL로 갈 것
4xx	클라이언트가 잘못된 요청을 보내 처리에 실패함	-400(Bad Request) : 요청이 문법에 맞지 않음 -401(Unauthorized) : 클라이언트가 요청한 리소스에 대한 인증이 실패함 -403(Forbidden) : 클라이언트가 리소스에 요청할 권한이 없음 -404(Not Found) : 리소스가 없음
5xx	클라이언트의 요청은 유효, 서버에 에러가 나서 처리에 실패함	-500(Internal Server Error) : 서버가 요청을 처리하다 에러가 발생함 -503(Service Unavailable) : 서버가 과부하로 인해 요청을 처리할 수 없음

*처리 사유 : 상태 코드가 발생한 이유를 짧게 기술한 것이다.



HTTPS
HTTP의 응답과 요청은 평문으로 전달된다. 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있다.

HTTPS(HTTP over Secure socket layer) : TLS(Transport Layer Security) 프로토콜을 도입하여 이런 문제점을 보완한다. *TLS : 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화한다.

---

 

요약

HTTP(HyperText Transfer Protocol): 웹 서버와 클라이언트가 리소스를 교환하기 위해 사용하는 프로토콜. 클라이언트가 요청하면, 서버가 응답하는 방식.

HTTP 메시지: HTTP 서버와 클라이언트가 교환하는 데이터. 헤드와 바디로 구성되며, 각 줄은 CRLF로 구분됨.
헤드: 메시지에 대한 정보. 헤드의 끝에는 CRLF가 한 줄 있음.

바디: 클라이언트가 서버에게, 또는 서버가 클라이언트에게 전달할 데이터

 

HTTP 요청(Request): 클라이언트가 서버에게 특정 동작을 요청하는 메시지

메소드(Method): 요청 URI가 가리키는 리소스에 대해, 서버가 수행했으면 하는 동작을 지정

요청 URI(Request-URI): 메소드의 대상이 되는 리소스를 지정

HTTP 응답(Response): 요청을 처리한 결과 및 이유, 그리고 클라이언트에 전송할 웹 리소스를 포함하는 메시지

상태 코드(Status code): 요청을 처리한 결과

처리 사유(Reason phrase): 상태 코드가 발생한 이유

HTTPS(HTTP on Secure socket layer): TLS를 이용하여 HTTP의 약점을 보완한 프로토콜

---

Background: Web Browser

도구로서의 소프트웨어는 반복적인 작업을 자동화하여 일의 능률을 높이고, 복잡한 기능을 쉽게 사용할 수 있도록 단순하고 직관적인 인터페이스를 제공한다.
*대표적인 소프트웨어 : 웹 브라우저(Web Browser)

웹 브라우저
웹은 인터넷이라는 글로벌 네트워크 위에 구현되어 있으며, 정해진 프로토콜을 기반으로 통신한다. 20세기에 등장한 웹 브라우저는 서버와 HTTP 통신을 대신해주고, 수신한 리소스를 시각화하였다.

해당 그림은 이용자가 주소창에 dreamhack.io를 입력했을 때 웹 브라우저가 하게 되는 기본적인 동작을 나열한 것이다.

1. 웹 브라우저의 주소창에 입력된 주소를 해석 (URL 분석)
2. dreamhack.io에 해당하는 주소 탐색 (DNS 요청)
3. HTTP를 통해 dreamhack.io에 요청
4. dreamhack.io의 HTTP 응답 수신
5. 리소스 다운로드 및 웹 렌더링 (HTML, CSS, Javascript)

 

URL : Uniform Resource Locator의 약자로, 웹에 있는 리소스의 위치를 표현하는 문자열이다.

URL은 Scheme, Authority (Userinfo, Host, Port), Path, Query, Fragment 등으로 구성된다.

자주 사용되는 요소
Scheme : 웹 서버와 어떤 프로토콜로 통신할지 나타낸다.
Host : Authority의 일부로, 접속할 웹 서버의 주소에 대한 정보를 가지고 있다.
Port : Authority의 일부로, 접속할 웹 서버의 포트에 대한 정보를 가지고 있다.
Path : 접근할 웹 서버의 리소스 경로로 '/'로 구분된다.
Query : 웹 서버에 전달하는 파라미터이며 URL에서 '?' 뒤에 위치한다.
Fragment : 메인 리소스에 존재하는 서브 리소스를 접근할 때 이를 식별하기 위한 정보를 담고 있다. '#' 문자 뒤에 위치한다.


Host는 웹 브라우저가 접속할 웹 서버의 주소를 나타낸다. Host는 Domain name, IP address의 값을 가질 수 있다.

 IP address는 네트워크상에서 통신이 이루어질 때 장치를 식별하기 위해 사용되는 주소로, 일반적으로는 도메인의 특성을 담은 이름을 정의하여 IP 대신 사용한다. 
Domain name을 Host 값으로 이용할 때, 브라우저는 Domain Name Server(DNS)에 Domain name을 질의하고, DNS가 응답한 IP address를 사용한다.

Domain name에 대한 정보는 MacOS/Linux/Windows에서 nslookup 명령어를 사용해 확인할 수 있다.


웹 렌더링(Web rendering) : 서버로부터 받은 리소스를 이용자에게 시각화하는 행위를 말한다. 서버의 응답을 받은 웹 브라우저는 리소스의 타입을 확인하고, 적절한 방식으로 이용자에게 전달한다.

---

 

요약

웹 브라우저(Web browser): 웹 브라우저는 HTTP/S로 이용자와 웹 서버의 통신을 중개하며, 서버로부터 전달받은 다양한 웹 리소스들을 가공해 이용자에게 효과적으로 전달한다. 이용자가 다양한 프로토콜들을 알지 못해도 쉽게 웹을 사용할 수 있도록 도와준다.

URL(Uniform Resource Locator): URL은 리소스의 위치를 나타내는 문자열로, 브라우저는 이를 사용하여 서버에 특정 리소스를 요청할 수 있다.

DNS(Domain Name Server): Host의 도메인 이름을 IP로 변환하거나 IP를 도메인 이름으로 변환한다.
웹 렌더링(Web rendering): 서버로부터 받은 리소스를 이용자에게 시각화하는 것을 말한다.

---

Tools: Browser DevTools

브라우저 개발자 도구(Devtools)는 HTML과 CSS 코드를 브라우저에서 수정하고 결과를 바로 확인할 수 있으며, 자바스크립트 코드를 대상으로 디버거도 제공한다.

개발자 도구 : F12

• Elements: 페이지를 구성하는 HTML 검사
• Console: 자바 스크립트를 실행하고 결과를 확인할 수 있음
• Sources: HTML, CSS, JS 등 페이지를 구성하는 리소스를 확인하고 디버깅할 수 있음
• Network: 서버와 오가는 데이터를 확인할 수 있음
• Performance
• Memory
• Application: 쿠키를 포함하여 웹 어플리케이션과 관련된 데이터를 확인할 수 있음
• Security
• Lighthouse

시크릿 모드 : 해당 모드를 사용하면 브라우저를 종료했을 때, 방문 기록/쿠키 및 사이트 데이터/양식에 입력한 정보/웹사이트에 부여된 권한이 저장되지 않는다.

시크릿 모드 단축키
Windows/Linux : Ctrl + Shift + J
macOS : Option(⌥) +Cmd(⌘) + J