> For the complete documentation index, see [llms.txt](https://redryan.gitbook.io/studyjoon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://redryan.gitbook.io/studyjoon/hacking/undefined/undefined-1.md).

# 웹 기술 기초편

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FXCUSaZk1KJJ886HafpRX%2Fimage.png?alt=media&amp;token=a23ce4d4-e99c-4141-810e-f583257d5e83" alt=""><figcaption></figcaption></figure>

목차: 웹 기술 기초

1. 웹의 탄생 그리고 발전
2. 웹을 구성하는 3대 요소
3. 자원을 지정하는 URL
4. 웹의 핵심 기술 HTTP 프로토콜
5. 쿠키와 세션
6. 웹 아키텍쳐 분석

### 추천 도서

* 그림으로 배우는 HTTP & Network Basic
* 성공과 실패를 결정하는 1%의 네트워크 원리

## 0. 웹 기초 지식의 필요성

<div align="center" data-full-width="true"><figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FAPPhVtsCJvNbNBxrBrrT%2Fimage.png?alt=media&amp;token=4a7810d4-4526-4aca-b6c0-8ebe2cecc83d" alt=""><figcaption></figcaption></figure></div>

웹 기초 지식의 필요성 웹은 다수의 사용자가 특정 서비스를 이용하고 서로 정보를 주고 받는 그러한 생태계 구조이다. 이러한 환경 속에서 우리는 취약점 진단하는 것을 수행하는 일원이다.

1. 웹 기초에 대한 이해 - GET, POST 방식 등 → 세션쿠키, 지속 쿠키
2. 웹 어플리케이션에 대한 이해  - php, jsp, asp, .net
3. 웹 어플리케이션 로직에 대한 이해 - 특히 php(게시판, 회원관리(로그인,로그아웃,회원가입)
4. 취약점에 대한 이해
5. 응용 취약점에 대한 이해
6. <mark style="color:red;">**대응책 수립 가능**</mark> - 가장 핵심

## 1.  웹의 탄생 그리고 발전

World Wide Web 이란?

* 다수의 네트워크가 모여 정보를 공유하는 환경
* 웹 서버와 웹 클라이언트로 구성
* 웹 서버는 웹 페이지를 제공하고 웹 클라이언트는 웹 페이지를 요청하는 역할
* 웹 페이지는 HTML 형식으로 작성되어 있으며, 웹 브라우저를 통해 웹 서버에서 제공되는 정보를 확인할 수 있다.

하이퍼텍스트란?

* 웹 페이지를 링크로 연결하는 텍스트

웹1.0 이란?

* 정적인 웹 페이지만 존재
* 일방적으로 정보를 제공 받는 형태

웹2.0 이란?

* 웹 페이지를 쉽게 만들 수 있도록 하는 기술
* 사용자와 웹 페이지 간의 상호작용을 가능하게 하는 기술
* UCC, 블로그, 커뮤니티, 쇼핑몰(전자상거래) 등

웹3.0 -> 웹 4.0 기타 등등

## 2. 웹 브라우저의 탕생과 발전

* HTML, CSS, JavaScript 등의 기술을 사용하여 웹 페이지를 표시하는 프로그램
* 사용자에게 그래픽 인터페이스를 제공(GUI)
* 윈도우 익스플로러, 크롬, 사파리 등&#x20;

## 3. 웹의 기본 구조, 클라이언트/서버 구조

<div align="center" data-full-width="false"><figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Foofqi2uKY0Al9ULcOoY0%2Fimage.png?alt=media&amp;token=0b67d5d2-52ca-471f-a5e2-cbe63ffc8c2c" alt=""><figcaption></figcaption></figure></div>

* **웹 : 클라이언트(사용자, 웹브라우저 사용) / 서버(웹서버, 웹어플리케이션서버) 구조**

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FCf8Wgmr6k0mWP2b8Hxa2%2Fimage.png?alt=media&amp;token=f3014b3d-474b-453b-9a47-69bf80825c7a" alt=""><figcaption></figcaption></figure>

* 웹 서버/웹 애플리케이션 서버(WAS) : 웹 페이지를 제공하는 서버
  * 웹 서버에 따라 PHP, JSP, ASP, .NET 등의 언어를 사용할 수 있다.
* 웹 클라이언트(웹 브라우저) : 웹 페이지를 요청하여 받는 클라이언트
* 웹 프로토콜(HTTP) : 웹 서버와 웹 클라이언트 간의 통신 규약

## 4. 웹 구성 3대 요소&#x20;

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FoYejeCvdA1vmSbJSUoQp%2Fimage.png?alt=media&amp;token=1e7b4069-8ca6-4ae9-9b7a-c671f240beb0" alt=""><figcaption></figcaption></figure>

과정 : HTTP를 이용해 통신하고 URL을 통해 자원을 요청하고 응답 받은 body 값 안에는 HTML이란 코드가 있고 이후 사용자에게 제공되어 출력된다.

* HTML : 웹 페이지를 작성하는 언어
* HTTP : 웹 서버와 웹 클라이언트 간의 통신 규약
* URL : 웹 페이지의 주소

### 웹사이트의 모습을 기술하기 위한 마크업 언어 HTML

* 프로그래밍 언어가 아니라 마크업 정보를 표현하는 마크업 언어로 문서의 내용 이외의 문서의 구조나 서식 같은 것을 포함한다. 보면 알겠지만 애초에 이름 HTML의 ML이 마크업 언어라는 뜻이다. 웹사이트에서 흔히 볼 수 있는 htm이나 html 확장자가 바로 이 언어로 작성된 문서다

#### 클라이언트/서버 통신 원리

1. 클라이언트는 웹 페이지를 요청하고, 서버는 웹 페이지를 제공한다.
2. HTTP 요청 메시지(HTTP Request Message) : 클라이언트는 웹 페이지를 요청할 때 웹 프로토콜을 사용하여 서버에 요청을 보낸다.
3. HTTP 응답 메시지(HTTP Response Message) : 서버는 웹 프로토콜을 사용하여 클라이언트에 응답을 보낸다.

### 자원을 지정하는 URL

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FkWLEeXd9ptuw7cCKXR7d%2Fimage.png?alt=media&amp;token=300e63df-c668-4a71-8d8b-016e2072c837" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fb5fburTFyvQs4dGkTdUH%2Fimage.png?alt=media&amp;token=0ba1d621-0807-4fbb-8b6d-d12bde5eebb4" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FmVNTTHV55J2yfZRVnFIR%2Fimage.png?alt=media&amp;token=8fcc239d-a06b-4355-a14f-93dd5d303fbb" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FApzMG7ezNt7gvHsefEwH%2Fimage.png?alt=media&amp;token=7fb619fb-64e7-48a6-b6a9-9572459a64d6" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FUB397LeA9Sk3Q90m3rWT%2Fimage.png?alt=media&amp;token=cbb9d29e-1c97-4ede-b24f-a2720f3e79e6" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FdvQw19qqUe5qHmG3c82i%2Fimage.png?alt=media&amp;token=c0f899a7-f241-4cb2-be77-5316f7fcfa06" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F3egQMSAEPtuC5p3nEHdk%2Fimage.png?alt=media&amp;token=f51de45f-bd26-4359-9e12-30bd295dec0a" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FOzLDGWkEccAFAxb16wxy%2Fimage.png?alt=media&amp;token=c4b386ef-6fff-429e-b8b4-8e01810c17ad" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FIl4XgWoipRAh7OJYWLM7%2Fimage.png?alt=media&amp;token=94b88afb-e931-4bd9-932a-fa84ff1f48bb" alt=""><figcaption></figcaption></figure>

* 위 사진에서 사용자가 아이디/패스워드 입력하여 전송하면 브라우저가 HTTP Request 메시지를 작성하여 웹서버로 요청한다.

### 웹의 핵심 기술 HTTP Protocol

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FcYE57NcYp7vukPV6MVgb%2Fimage.png?alt=media&amp;token=37335cbf-6179-4464-a4da-6c1be50e82b2" alt=""><figcaption></figcaption></figure>

* OSI 7 Layer 에서 보면 네트워크상에서 HTTP,  HTTPS는 전송계층에있는는 TCP 프로토콜을 사용한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fa693V7oTc4dSm78EAdlX%2Fimage.png?alt=media&amp;token=1b7f223e-beb6-48eb-ba27-6aa1913b6fb3" alt=""><figcaption></figcaption></figure>

* IP : 집주소
* Port : 동호

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F1o2RARc1MgyEY9hkTJmD%2Fimage.png?alt=media&amp;token=f1d94151-b01b-4d86-a0ba-49e14462fb43" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FjV4kaj6pzaQp9yDzG6lr%2Fimage.png?alt=media&amp;token=e8be5707-899e-438b-a1cc-0dce3b638c9b" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FrLI6WwdJchVe16pCnuBw%2Fimage.png?alt=media&amp;token=573893c0-75eb-4b7e-b611-929984dd98a8" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fb4Yx6TkaQEbJQdCu0Jv9%2Fimage.png?alt=media&amp;token=039bc3ea-07dd-4d14-ae27-205928ef5a15" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F9qeoR0BV1gBCCpLySPLq%2Fimage.png?alt=media&amp;token=cfb40a38-e6a5-43b1-8c1b-6ecdbf3df0bb" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FSC4fl9sLVqA0rI5pMHzU%2Fimage.png?alt=media&amp;token=6ddd3b29-2e47-403b-bed0-80ef64c420e6" alt=""><figcaption></figcaption></figure>

* GET/POST 메소드는일반적인 상황에서 제일 많이 쓰이는 방식
* Content-Type 값이 반드시 나와야 POST 메소드를 사용할 수 있음

  * Content-type이없으면 userid 값들이 무용지물이 된다

  <div align="left" data-full-width="false"><figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FqbtO46oKbyXKuKdON4kd%2Fimage.png?alt=media&amp;token=5c9bc1a1-2316-4339-a7a3-00253bd64dce" alt="" width="217"><figcaption></figcaption></figure></div>

GET 메소드: 어떠한 자원을 얻고 싶기만 할때 사용함

POST 메소드 : 어떠한 서버측에 어떤 액션을 하기 위해 사용함

* 삭제, 수정, 작성 등은 Port를 사용함

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F0OsV7OjVailvSvAsw6X0%2Fimage.png?alt=media&amp;token=f8a6bd50-8440-4393-a491-1268a4c2c361" alt=""><figcaption></figcaption></figure>

* 200, 302, 304,400,403, 404, 500 상태 코드는 알아두자.
* 500은 소스코드 에러, WAS(웹 어플리케이션 서버)측 에러

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FI0FO45YpjhcGq7wP4jxE%2Fimage.png?alt=media&amp;token=436b04df-f03c-4f21-915a-124ef9baa434" alt=""><figcaption></figcaption></figure>

* 상태 코드에 따른 에러 페이지를 통해서 어떤 WAS를 쓰는지 알 수 있음.
* WAS(와스) 식별 정보는 중요하다.
* 자체적인 에러 페이지를 만들어두기도 하지만 위의 사진처럼 어떤 WAS를 쓰는지 식별 가능한 디폴트 페이지가 나오기도 한다.
* 저런식으로 페이지가 나오지 않게 해야 보안상 좋다.

## 5. 쿠키와 세션

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fgoqj6V8rBQo9KYJeieTj%2Fimage.png?alt=media&amp;token=6c67e548-759d-439c-a633-b963df93840f" alt=""><figcaption></figcaption></figure>

* 최초 네이버 로그인 - 메일 기능 접속 - 메일 접속했다가 카페 접속 - 해당 다른 카페 접속 - 블로그 - 다른 블로그로  접능 하는 등의 이런 지속적인 연결이 가능하도록 한것을상태 유지 및 관리에 해당
* 저러한모든게  것들이  사용자 인증 수단에 해당한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FAS6AJRb6FlR2V71AK5sv%2Fimage.png?alt=media&amp;token=862740b4-0824-4bad-9c3c-9bfd68a429c4" alt=""><figcaption></figcaption></figure>

### 쿠키 종류

* 쿠키 = 지속 쿠키
* 세션 = 세션 쿠키

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FtsbWa8yR0u2WQQzAEc4p%2Fimage.png?alt=media&amp;token=285fddb2-868a-4501-bc59-50b64e0dba2a" alt=""><figcaption></figcaption></figure>

* 사용자가 A 사이트에 접속하여 정상 로그인 하면, 서버에서 응답값을 줄 때 Set-Cookie를 준다 그러면 클라이언트에서는 cookie 값을 저장한다(세팅)
* 세팅된 이후 A 사이트에 접속할때마다 세팅된 쿠키값이 자동 세팅된다.
* 이를 통해 서버 상태 관리를 하게 됨

### 지속 쿠키(Persistent Cookie)

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FOrbaayz2USFjATjChtJF%2Fimage.png?alt=media&amp;token=17fa3258-96c7-49b5-a5e0-a66028993918" alt=""><figcaption></figcaption></figure>

* 클라이언트 하드 디스크에 텍스트로 저장되는데 요즘에는 이러한 보안적 부분은 보완이 된 상태라서 거의 안 일어난다

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FK8v3JJShkzEhFQ75QYVQ%2Fimage.png?alt=media&amp;token=a36450c0-ede9-4032-ba72-dab354b085af" alt=""><figcaption></figcaption></figure>

* 쿠키는 다양한 기능에서 활용하는데 지금 예시는 로그인 기능으로 설명한다.
* 로그인 하고 서버에 요청한다

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FDAoCwU6oMFbsZSCXcigJ%2Fimage.png?alt=media&amp;token=d9556818-4395-4d1f-a7ba-ea20084ba5b1" alt=""><figcaption></figcaption></figure>

* 만약 아이디/패스워드가 정상이라면 로그인이 이루어지고 위의 쿠키값이 세팅된다.
* 여기서 중요한 것은 id=hong123부분인데 이 부분을 클라이언트로 보내주면 클라이언트는 쿠키값을 세팅(저장)하게 된다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FrG8gpbjrnsRAiowTilzn%2Fimage.png?alt=media&amp;token=8b657d56-7b83-4657-b1a3-a16909905a51" alt=""><figcaption></figcaption></figure>

* 홍길동이 B사이트에 접속하게 되면 웹 브라우저에서 해당 사이트에 대한 쿠키값을 세팅하여 서버에 요청한다
* 그러면 서버측에서는 쿠키라는 헤더를 통해 사용자 식별을 하게 된다. hong123이니까 DB에서 뽑아내서 홍길동이라는 것을 식별하여 홍길동페이지를 보내준다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fy3ID1D8X5gNi570cDgpg%2Fimage.png?alt=media&amp;token=74cc5d76-c482-4408-82c8-77ed7bdba2cd" alt=""><figcaption></figcaption></figure>

* 로그아웃을 눌러 요청하게 되면 WAS 측에서는 셋 - 쿠키값에 삭제시킬 값(deleted)를 세팅하여 보내준다 그러면 클라이언트 측에서는 쿠키값을 삭제한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FghHWNwH2QrSZWnQ7jiwM%2Fimage.png?alt=media&amp;token=90f71f51-db9b-4819-9b68-6ea7be8967fe" alt=""><figcaption></figcaption></figure>

* 쿠키를 제거하여도 클라이언트 측에서만 제거된 것이다, 해당 값을 알고 있으면 재사용이 가능하다.
* 다시 그 값을 웹 프록시로잡아서id:hong123이라고 세팅해서 서버로 보내면 홍길동님으로 식별하여 다시 또 보내주어 재사용 가능해진다.
* 쿠키값이 평문이면 변조의 위험이 있어서 hong을 지우고 admin으로 변조하였는데 관리자계정  값으로 실제로 admin을 쓴다면 관리자 계정으로 접속 가능해지고 이는 관리자 권한 탈취에 해당한다.

  때문에 반드시 암호화 과정을 거쳐야 하고 쿠키의 유효기간 또한 정해두어야 하고 암호화 알고리즘에 대한 적절성 검토도 해야한다.
* 암호화 알고리즘 : 단방향이냐 양방향이냐에 따른 것인데 당연히 양방향을 사용해야한다, 그 이유는 쿠키값을 세팅해줄때 복호화를 통해서 어떤 사용자인지 알아야 하고 어떤 ip인지 알아야한다 이 쿠키를 통해서 이 모든 것을 알수 있어야 해서 양방향 알고리즘 사용해야한다

  여기서 또 중요한 포인트는 key 값도 필요하다 보통 3DES를 많이 사용한다.. 결국 키값도 어떻게 관리해야할지에 대한 보안적인 문제점의 논의가 이루어져야 한다.

### 세션 쿠키(Session Cookie)

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FcGWF0wSJRQYhsw0ftSfj%2Fimage.png?alt=media&amp;token=f8a84b7f-c087-4c4c-a282-f6f3e6aa47a8" alt=""><figcaption></figcaption></figure>

* 임의의 문자가 의미있게 되는 이유 : 서버측에서는 의미없는 문자 abcd가 서버 세션정보 DB에 맵핑 정보로 기록되어 있어서 의미없는 문자를 서버측에 보내게되면 너는 hong 이구나 그런데 이 abcd의미없는 문자를 맞추기가 어렵다 현실적으로.....

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FYxfBhbFkJFLDsrcGelH9%2Fimage.png?alt=media&amp;token=96de4343-54e6-421d-9c25-25db98bbfd7e" alt=""><figcaption></figcaption></figure>

* 로그인 기능을 예시
* 최초 로그인 시 - 정상 계정이면 의미없는 세션값이 + id, perm 이런 필드값들이 개발자가 만들어 놓은 DB 테이블 안의 입력된다. 그러면 홍이라는 계정은 서버 측 DB에 정보가 맵핑되어 진다. - 개발자가 마음대로 필드값을 정할 수 있음

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FJzan8FGCwE3VhnwWsa1p%2Fimage.png?alt=media&amp;token=7012dfd3-473e-4003-a0b9-1f859c71078a" alt=""><figcaption></figcaption></figure>

* 셋-쿠키를 통해서 웹 브라우저에 해당 세션을 위의 셋 쿠키 값을 세팅한다.
* 이제 이 셋 쿠키 값을 가져가면 서버측에서 홍으로 인식한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fya3OhCklM4GXaJrmS2Is%2Fimage.png?alt=media&amp;token=0843c332-7ec7-40ec-a4f1-e1729fd02270" alt=""><figcaption></figcaption></figure>

* 저 세팅된 셋 쿠키값을 서버측으로 요청하여 보내면 홍 계정이라고 인식하여 클라이언트에게 홍길동님의 웹페이지입니다 를 출력해준다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FPzj1Y8QiqqLhtMO3Xyja%2Fimage.png?alt=media&amp;token=5b83ffcc-bc0b-47b4-8697-2e7fea153b01" alt=""><figcaption></figcaption></figure>

* 폐기의 경우에는 로그아웃을 클릭하게되면 이 처리 로직이 지속쿠키와 다르다.
* 지속쿠키 같은 경우에는 클라이언트(사용자 PC의 값) 측의 쿠키값이 삭제되었지만 세션 쿠키는 서버에 있는 이 의미있는 세션이었던 값의 hong, 2 값이 지워진다. 즉 서버측 값이 사라져서 의미있던 값이 의미없는 값으로 된다.
* 훨씬 보안적으로 좋아진다. 폐기 후 재사용에 대한 위협이 세션 쿠키는 없다.

### 지속 쿠키의 필요성

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FzJmRsGtlNhnG6obNXEQP%2Fimage.png?alt=media&amp;token=76909b08-aa12-4246-866a-edaa1ba78f9e" alt=""><figcaption></figcaption></figure>

* 지속쿠키의 문제점이었던 **폐기 후 재사용**에 대한 문제, 유효기간, 암호화 알고리즘 로직에 대한 문제점이 있었는데 이것을 한번에 해결해주는 것이 세션쿠키이다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F2tpXj85XjEnBgtMcE8x4%2Fimage.png?alt=media&amp;token=dac6af82-b4dd-4adc-a28d-c23f7b5622d2" alt=""><figcaption></figcaption></figure>

* 대규모 웹 서비스의 경우에는 많은 사용자가 있고 엄청난 접속이 일어난다.
* 고로 세션을 관리하는 서버에 엄청난 부하를 가져온다.
* 관리 방법은 3가지 메모리, 파일 시스템, DB
  * 메모리는 사용자가 많으니까 불가능
  * 파일시스템은 불가능 파일 용량이 많아져버림
  * DB에 하게 되는데 성능에 좋지 않다. DB에 이미 접속하는 것 자체가 별로다. 그래서 지속 쿠키를 많이 사용한다.
* 지속 쿠키의 경우에는 서버부하가 전혀 없고 단순히 쿠키를 복호화하는 그정도 어플리케이션 속도 측면만 고려하면 돼서 좋다.

즉 접속자가 별로 없으면 세션 쿠키를 사용하고 접속자가 엄청나게 많다면 지속쿠키를 사용하도록 해야한다.

## **6. 웹 아키텍쳐 분석**

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fl1qIsdkricV8MYyLBlvK%2Fimage.png?alt=media&amp;token=10579095-102f-43ae-ad4b-af462af739ab" alt=""><figcaption></figcaption></figure>

* 일반적으로 프론트엔드 개발자는 UI를 담당, HTML, JS, CSS 등을 다룬다
* 백 엔드는 PHP, JSP, ASP, ASPX .. 등을 다룬다
* 모든 것을다루면 풀 스택 개발자 라고 부른다.

### 웹 아키텍처 동작 원리 분석

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FraNKKtE3keBuu73IElMF%2Fimage.png?alt=media&amp;token=d0f051bd-3a84-4f3a-bdbb-fcc4166a7361" alt=""><figcaption></figcaption></figure>

* 클라이언트 측은 최초로 웹 브라우저를 먼저 실행하고 시작페이지 설정되어 있거나 URL 창에[http://www.를](http://www.xn--bx2b) 입력하게 되고 그 다음 이 도메인이 IP로 변환되는 작업을 거치는데 필수적인 작업이다. 도메인으로는 통신이 불가능하기 때문에 실질적으로는 IP가 필요하게 되고 이 IP를 통해서 패킷을 주고 받는다.
* IP는 실제 주소 / 도메인은 사용자를 고려한 도메인 주소(IP주소를 다 기억할 수 없기 때문에 사용한다)
* IP 변환 작업
  * 개인 PC의 로컬 DNS 캐시를 확인한다.
    * ipconfig / displaydns 명령어 실행 예시
  * 예를 들면 [www.naver.com을](http://www.naver.com을) 검색하면 먼저 로컬 DNS캐시를 확인하고 만약 없으면 Hosts 파일을 참조한다. 이 hosts 파일은 IP주소 도메인에 대한 맵핑 정보가 담겨 있는데 그 맵핑 정보를 토대로 해당하는 IP 도메인이 적혀 있는데 일반적으로 이런것을 사용자가 적어두진 않는다.
  * hosts를 일반 사용자 PC에서는 건드릴 일이 거의 없다.
  * 그래서 백신이 이 hosts 파일의 변경 사항을 감지하는 경우가 많다. 혹시나 변조가 되었는지 확인하기 위해서 말이야.
  * 자 다시 만약 그래도 없다면 DNS 서버에 질의 하게 된다.
  * 그래서 해당 도메인에 대한 IP 정보를 획득하기 위해서 DNS 서버들 끼리 서로가 질의를 하게 된다 계속 요청한다 알아낼떄까지 알아냈다면 질의에 대한 응답이 나에게 온다
  * 나에게 오면 로컬 DNS 캐시에 기록이 된다
  * 그래서 나중에 [www.naver.com으로](http://www.naver.com으로) 재접속할때 번거롭게 질의를 할 필요없이 로컬 DNS 캐시에 있는 해당 정보를 토대로 해당 사이트에 접속을 하게 된다.
* 그리고 그 이후  http 요청 메시지를 제작하여 웹 서버에 전송하게 된다.
* 이 과정에서는 웹 브라우저 동작에 대한 예시에 해당한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F6akUlO0RBmTze5uaj0po%2Fimage.png?alt=media&amp;token=e9524424-822a-4fa8-93d3-ba6e7f2d2709" alt=""><figcaption></figcaption></figure>

* http 프로토콜은 TCP/IP 프로토콜에 기반한 통신을 한다. TCP는 신뢰성 있는 정보전송을 제공해야하기 때문에 3-way hand shake을 통해서 연결을 정상적으로 맺은 후 이 때 요청 메시지를 서버에 전송하게 된다.
* 이 때 요청 메시지 뿐만 아니라 실제로 패킷을 보게된다면 wireshark 라는 프로그램으로 보게되면 제일 뒤쪽에

  MAC/IP/TCP/HTTP 역방향으로 인캡슐레이션(캡슐화 과정)을 거쳐서 통신이 된다.
* 이떄 목적지 IP가 나올것이고 이 목적지는 웹서버 IP가 나올 것이다.
* 이 IP는 어디서 얻었냐 웹브라우저(HTTP)가 도메인에 대한 IP 변환 과정을 거쳐서 발견한 IP일것이다.
* TCP에서는 출발지 포트와 목적지 포트가 있는데 이때도 웹 브라우저(HTTP)에서 이미 아래 계층(TCP)에 알려준 상태이다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FmeMdBd2hOWPcOlL4Bkj3%2Fimage.png?alt=media&amp;token=b3052443-5d58-4613-a058-51733b07e1d1" alt=""><figcaption></figcaption></figure>

* 단일 정적 페이지일 경우에는 html기반의 페이지이고 이미지만 있고 정적인 페이지일 경우에는 데이터베이스 질의를 하지 않지만 오늘날의 대부분 웹 사이트는 DB에 질의를 한다.
* 실시간 검색, 최근 게시판 등은 DB정보를 통해 얻는다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FsyVeDWv9be838eVx1AqP%2Fimage.png?alt=media&amp;token=20d9f7d3-fa10-4c9c-800b-50991bb283d0" alt=""><figcaption></figcaption></figure>

* 최종적으로는 응답 메시지를 제작한 뒤 클라이언트에게 응답 메시지를 전송하게 된다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FtxiwIPli5MTHmRrP9pGO%2Fimage.png?alt=media&amp;token=117665e7-10ba-4917-adf5-5c689d6e07c6" alt=""><figcaption></figcaption></figure>

* 웹서버로부터 응답 메시지를 받은 뒤에는 클라이언트 측 웹 브라우저에서 응답 메시지를 해석한다.
  * 응답 메시지가 상태코드에 따라서 바디 값을 해석 후(CSS, JS) 뿌려줄지, 특정 사이트로 리다이렉션 될지 기타 등등의 작업을 한다.

### 클라이언트

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FPYKMgg8ONeoNT8QC2fnt%2Fimage.png?alt=media&amp;token=cd0c8149-7125-4c20-af11-441d7d743d19" alt=""><figcaption></figcaption></figure>

* 웹 클라이언트 프로그램은 웹 브라우저가 존재
  * 인터넷 익스플로러, 크롬, 사파리
* URL을 이용해 서버에 자원을 요청 -> 서버로부터 응답 받아서 해석 후 사용자에게 GUI를 제공

### 웹 사이트 구조 분석

#### 모던 웹 모델

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FuActtnlVXo19QTaPPtvU%2Fimage.png?alt=media&amp;token=faf4c870-a9ba-4b38-a9e6-08ad19f71ff4" alt=""><figcaption></figcaption></figure>

* 동적 인터페이스 구성하기 위해서는 자바스크립트가 사용된다.
* 일반적인 모던 웹은 웹 서버와 통신하기 위해서 폼 데이터 전송을 하게 된다

  * \<form \~ : 로그인 기능 등
  * 동기화 필요없이 비동기화 기술이라고 불린다.
  * 자바스크립트를 통해서 통신하게 되고 실제 웹 페이지는 그대로 인데 어떤 버튼을 클릭하게되면 실제 웹 서버로 요청이 되고 응답을 받아서 자바스크립트 단에서 응답에 대한 처리 - A라는 화면을 띄울지, B라는 화면을 띄울지를, 자바 스크립트 단에서 다 구현을 한다.
  * 즉, 동적인 페이지 구성을 한다. 페이지가 동기화가 되지 않고 새로고침이 되지 않는다. 화면이 그대로있다.
  * 대표적인 예시 게시판 - 예전에는 목록 로고 메뉴 등등이 있는데 이러한 모든 페이지를 다 새로고침을 해야했다 - 예를 들어 페이지 1, 2가 있으면 페이지 2를 누르면 전부 새로고침을 해야했다.
  * 하지만 오늘날은 실제 필요한 부분인 이 목록 부분(요소)만 클릭하게 되면 해당되는 목록만 받아와서 페이지에 해당 하는 게시판 목록만 다시 세팅을 해준다.
  * 실제로는 사용자 측면에서도 전체가 새로고침되지 않고 보다 속도가 빠르게 움직여서 좋다
  * 실제 운영 측면에서는 페이지 2를 클릭하는 순간 이전같은 경우에는 CSS, JAVASCRIPT 이런 파일들도 다시 재요청을 해야해서 비효율적이다.
  * Ajax라는 기술 때문에 필요한 부분만 요청해서 받으면 된다.
  * 이렇게 가능할 수 있는 이유는 오늘날의 PC,데스크탑의 성능이 올라가서 가능해졌다. 사용자에게 맡기게 된 셈이다.

  <figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F6HgCTi1nQASdddAWw1tc%2Fimage.png?alt=media&amp;token=d0d67341-85eb-4436-b124-695ebe88f410" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FqkWTIfcpEXQE8O7nBjBb%2Fimage.png?alt=media&amp;token=e18ce0c6-0113-4829-847b-6239baa6ce96" alt=""><figcaption></figcaption></figure>

* Ajax 기반으로 통신을 하게 될 때 컨텐츠 타입 : xml, json 타입으로 전송이 되는데 대부분 json으로 전송이 된다.
* 그래서 버프 스윗의 웹 프록시 도구로 해당 데이터를 잡게 되면 중간 아래의 내용이 잡히게 된다.
* Ajax 기반 웹 사이트 진단은 별다를게 없다.

  "N"으로 되어 있는 것을 Y로 바꾸면 여기서 페이지 출력이 어떻게 되는지 확인 해보는 것이 다이다.

  <figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FXEls3HbQfmZblDoDYVRX%2Fimage.png?alt=media&amp;token=954a0afd-2d49-4784-9374-b2677a24c1f9" alt=""><figcaption></figcaption></figure>
* 왜냐면 화면 출력되는 구성이 달라질 수 있기 때문이다.

### 웹 서버 그리고 웹 어플리케이션 서버

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FvGxPLQjV0xup9TVTNotw%2Fimage.png?alt=media&amp;token=daeed1e0-eb55-42ab-aa3e-7d894d426b47" alt=""><figcaption></figcaption></figure>

* 웹 서버의 종류 아파치, IIS, Nginx, WetoB, Oracle HTTP Server 등이 존재
* JAVA 웹 어플리케이션을 국내에서는 엄청나게 사용한다.
* 자바 웹 어플리케이션은 자원 처리에 대한 효율성 때문에 많이 사용된다.
* 보통 3-Tier 구조
  * 웹 서버는 정적 자원 담당&#x20;
  * 웹 어플리케이션은 동적 자원 담당
  * 정적 자원 : 이미지, TXT 파일
  * 동적 자원 : jsp, 정적 자원 이외의 나머지 파일들
* 2-Tier 구조
  * &#x20;IIS 에서 많이 사용
* PHP기반

  * 아파치, nginx에서 사용

### 웹 서버 동작 원리 분석

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FoimCvasm0VqFoh3QCR55%2Fimage.png?alt=media&amp;token=aec2ad5a-ff10-4b4c-8053-c40fe0e204ac" alt=""><figcaption></figcaption></figure>

* index.jsp를 클라이언트가 요청했는데 웹서버에서는 어떤 기준으로 이 파일을 찾게 될까?

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FLSOwYWY9Hy6wJ7aYT0gF%2Fimage.png?alt=media&amp;token=a266ba15-8e41-4aeb-83dd-dcf41eb7859d" alt=""><figcaption></figcaption></figure>

* 요청 메시지 -> 요청 메시지 해석 (GET/POST 자원 요청 메소드 사용시) -> 자원 유/무 체크 -> 특정 파일 시스템에 자원 있으면 객체 생성 -> 동적인지 정적인기 구분함 -> 정적이면 스크립트 해석기(서버사이드스크립트)에 대한 해석이 필요없음 -> 반면 동적자원은 서버사이드스크립트에 대한 해석이 필요하다
* 그 뒤 결과를 반환한 뒤에 응답 메시지를 제작하고 클라이언트 쪽으로 전송을 하게 된다.
* 어느 경로의 파일/디렉토리를 찾을까? index.jsp 호출

### 웹에서 호출할 수 있는 자원이 있는, 웹 디렉터리

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FnymYqjUioyZdVmtSrWZ1%2Fimage.png?alt=media&amp;token=7b41d264-f7b7-4fba-a88f-44755c81012e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FG3hPbCf8qEQuQP7QPxWW%2Fimage.png?alt=media&amp;token=bc90a948-6c7c-4a8c-b587-b7874700cd5c" alt=""><figcaption></figcaption></figure>

* 바로 웹 어플리케이션 설정 정보를 보면 웹 디렉토리/더큐먼트 루트가 설정되어 있다.
  * 아파치 설정 파일 - httpd.conf 등의 설정 파일
* 이 설정된 경로를 참조해서 자원을 요청할 경우 웹 루트 안에서 자원을 보게 된다 만약 자원이 없다면 404 상태 코드를 나타낸다.
* 그래서 실제 파일 다운로드/업로드 취약점 공격 시에 웹 서버 설정파일들이 많이 활용되게 된다.
* 이를 통해서 웹쉘 업로드까지 성공한 사례가 너무 많다.

### JAVA Web Application 환경의 3-Tier 구조 동작 원리

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fo4lavQWXGLxuWNdQSPPm%2Fimage.png?alt=media&amp;token=74e8be93-17d7-4d6a-b66d-88dcb3db8199" alt=""><figcaption></figcaption></figure>

* 정적 자원을 요청할 경우 logo.png는 정적 자원에 해당된다
* 웹 서버에서 어플리케이션 서버까지 가지도 않고 웹 서버에서 응답에 대한 처리를 하고 응답메시지를 전송한다
* 동적을 자원을 요청할 경우 [파일명.do](http://xn--v42b30vy3i.do/) ... 이런 것은 웹 서버에서 웹 어플레케이션 서버로 포워딩하게 되고 로직에 따라 데이터베이스에 질의를 하게 되고 그 뒤 응답 메시지를 제작해서 사용자에게 전송한다.

### JAVA Web Application 환경의 WS/WAS 구성

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fbfso6L44769woQONIojn%2Fimage.png?alt=media&amp;token=3ae8c506-d5e8-46b4-bf2e-4b1c967d4f25" alt=""><figcaption></figcaption></figure>

* 물리적으로 분리/논리적으로 분리 둘다 환경에 따라 다르고 많음
* 어떤게 정답이다 할 수 없음.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FH96XIdnerOlRfmek9BoD%2Fimage.png?alt=media&amp;token=5c5299a0-6f25-4732-92fe-370831d58d13" alt=""><figcaption></figcaption></figure>

* 보통 위의 사진처럼 조합하는 경우가 많음.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FpG5JmIwK2FOPdXAxTLYT%2Fimage.png?alt=media&amp;token=d9be3328-d611-4cf2-962c-c523d6253d14" alt=""><figcaption></figcaption></figure>

* Tomcat 설치하고 8080으로 접속해보면 귀여운 토끼가 뜸 - 이미지 - 정적자원인데 출력이 가능하다

### 웹 서버와 웹 어플리케이션 서버를 분리하는 이유

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FG4Ma98IOh5bwYwvFMRYv%2Fimage.png?alt=media&amp;token=14e2d709-b046-4fbc-93b0-ed4eb0d33eb5" alt=""><figcaption></figcaption></figure>

웹 서버는 실제 정적 자원 처리에 굉장히 성능이 뛰어나다

* 실제 웹 어플리케이션 서버와 웹 서버와 정적 자원 처리 속도를 비교하였더니 웹 서버가 통계적으로 더 빨랐다라는 결과가 있음.
* 이 두개를 동시에 하게될 경우 내가 DB에 질의해서 응답을 받아서 응답 페이지 구성을 해야하는데 계속 이미지,자바스크립트파일, CSS파일 달라 정작 중요한 DB질의는 하지 못하고 이러한 작업에 매여있을 수 있음.
* 지금은 업무 분담을 하였다. 자원 처리에 대한 효율성이 극대화 되어 있음.

### 데이터베이스

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F0IS8LMBNCxMuaoXSnHca%2Fimage.png?alt=media&amp;token=d8685bcb-4a2d-4e87-a48f-0207e0409c40" alt=""><figcaption></figcaption></figure>

* 데이터베이스는 동적인 컨텐츠를 제공하기 위해서 데이터를 저장하는 저장소 개념이다
* 우리가 로그인을 하거나 혹은 게시판에 글을 작성하거나 상품을 구매하거나 장바구니에 상품을 담는 등 기타 기능을 이용하게 되는데 이런 작업을 할 수 있는 이유는 데이터베이스 떄문이다.
* 실제 웹의 성장에 엄청나게 큰 역할을 하였다.
* 디비 종류 : 오라클, MS SQL, MYSQL 기타 등등

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FGAI51nlzSj6OixuHaHNJ%2Fimage.png?alt=media&amp;token=3785cf38-b40a-4628-b907-f3ee6ac97ba7" alt=""><figcaption></figcaption></figure>

* <mark style="color:red;">**클라이언트 사이드**</mark>에는 <mark style="color:red;">**웹 클라이언트**</mark> 프로그래밍 웹 프록시가 존재하고 이 웹 프록시는 <mark style="color:blue;">**HTML, CSS, JAVASCRIPT를 이 언어를 해석**</mark>할 수 있음. 이 웹 클라이언트가 해석할 수 있는 언어를 <mark style="color:green;">**클라이언트 사이드 스크립트**</mark>라고 부른다.
* <mark style="color:red;">**서버 사이드**</mark>에는 <mark style="color:red;">**웹 어플리케이션 서버**</mark>가 존재하고 이 서버가 해석할 수 있는 언어는 <mark style="color:blue;">PHP, JSP, ASP, .NET이 존재하고 이 언어를 해석</mark>할 수 있는 언어를 <mark style="color:green;">**서버 사이드 스크립트**</mark>라고 부른다.
  * 이 웹 어플리케이션 서버 같은 경우에는 종류에 따라서 해석할 수 있는 언어가 달라짐.
  * 대표적으로 톰캣일 경우에는 해석 할 수 있는 언어가 PHP는 아니다. jsp를 해석할 수 있음.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FE9RFAAmgU9d4czZ59tLx%2Fimage.png?alt=media&amp;token=10301299-4166-4b21-8017-c1c9d56bc23d" alt=""><figcaption></figcaption></figure>

* 보안 검증 절차가 구현은 자바스크립트로 구현되어 있고 변조하기가 굉장히 쉽다 이유는 웹 프록시 도구와 개발자 도구를 통해서 클라이언트 사이드 측에 값 변조 및 조작이 가능하다.
* 예를 들어서 해당 페이지의 요청 메시지를 전송하고 응답을 받았을 떄 해당 특정 로직에 대한 입력값 검증 로직이 자바 스크립트 안에 담겨 있었고 그런데 웹 프록시 도구로는 이러한 로직을 볼 수 있다.
* 그 해당 로직을 삭제, 강제로 참, 거짓으로 조작
* 결국 변조된 응답값이 웹 브라우저로 전송되어 개발자가 의도한 입력값 검증 로직 절차는 이루어지지 않는다
* <mark style="color:red;">**서버측에도 보안검증 로직을 반드시 구현해야한다.**</mark>
* 클라이언트 측에서 보안 검증 절차라는게 사실상 아무의미가 없다.
* input 태그에 hidden 타입으로 전송하는 경우가 많은데 이떄는 무조건 안좋다가 아니라 기능상 input 태그의 hidden 타입을 사용하는 경우가 있다.
  * 수정 기능 -> 게시물 번호가 굳이 사용자에게 출력될 필요가 없는 경우가 있음.
  * 이럴때는 인풋 태그의 히든 타입으로 인터페이스에는 출력되지 않도록 숨겨서 요청이 될때만 값이 정상적으로 전송되게끔 하는것이 히튼 타입의 기능이다.
  * 그러나 사용자 인증 관련(사용자 체크, 권한 체크) 시 인풋의 히든 타입을 사용하면 문제가 발생한다.
  * 예를 들어 정보조회 페이지 같은 경우에는 인풋 태그의 히든 타입으로 전송하게 되면 웹 프록시로 다 노출이 되기 때문에 변조가 가능하게 된다.
  * <mark style="color:red;">**사용자 인증 관련 부분은 세션과 암호화된 쿠키를 사용해야 한다**</mark>. 이것이 올바른 로직이 될 수 있다.
  * 즉 클라이언트 와 서버 측 둘다 보안 검증 로직이 구현되어 있어야 한다.
  * 인풋 태그의 히든 타입은 기능적으로 중요한 기능 사용자 인증 수단으로 필요한 것이 아닌 <mark style="color:red;">**기능상 필요한 즉, 사용해도 문제가 없는 기능에 대해서는 인풋 태그의 히든 타입을 사용해야 한다.**</mark>

## **7. \[실습] Client-Side Script, Server-Side Script에 대한 이해**

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FRQC55gRT4ggfDz6IpaHE%2Fimage.png?alt=media&amp;token=65f2ab13-99ea-4bb0-8705-fdfbe0714d67" alt=""><figcaption></figcaption></figure>

* test 라는 값이 출력이 된다.
* 클라이언트 사이드 측에서는 이러한 구문을 볼 수가 없다.

즉 서버 사이드 스크립트는 클라이언트 사이드 측에서 볼수가 없다

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fwjg3SVpazg8x2g1x47hO%2Fimage.png?alt=media&amp;token=46c5954c-0baa-4339-80aa-4087960b7de5" alt=""><figcaption></figcaption></figure>

* \<?
* echo "\<b>test\</b>" ;
* ?>
* 진하게 볼드 처리 해보면 클라이언트 사이드 스크립트 이기 때문에 실제 아파치 측에서는 이것을 해석하지 못하여 그대로 반환했다.
* 웹 브라우저 인터페이스 상에서는 클라이언트 사이드 스크립트인 \<b>태그를 해석하여서 다음과 같이 굵게 출력된다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FbCSJnC6oOc9GeN58nH8p%2Fimage.png?alt=media&amp;token=e150991f-5b54-4ed1-82e0-9cb281055ad3" alt=""><figcaption></figcaption></figure>

* 실제 test.php 라는 것이 서버측에서 기동이 되고 결과값을 반환해주기 때문에 위의 것이 먼저 작성되어 있어도 아래의 \<? PHP 스크립트부터 해석한다.

PHP 서버 사이드 스크립트 이기 떄문에 해당 구문부터 해석하여 컴파일러 할 것이다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2F07vXV3wl54tDVARrR8mZ%2Fimage.png?alt=media&amp;token=53fcf7d6-2100-4623-a490-4aedc01d257d" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FjLZlZVnhNMRDLelCSkg0%2Fimage.png?alt=media&amp;token=4b55e0c9-6040-47a8-87ae-ce9e5f0ae273" alt=""><figcaption></figcaption></figure>

* 소스 보기로 보기
* 클라이언트 사이드 스크립트로 작성된것은 그대로 반환된다
* 서버 사이드 스크립트에서 실행된 것은 결과가 다 진행된 상태에서 반환이 된다.
* 이유는 웹서버 측에서는 PHP 구문을 알아서 반환 했는데 클라이언트 사이드 스크립트는 웹 서버에서 모르기 때문에 그대로 반환되었다.

## **8. \[실습] Client-Side Script 기반 보안 검증이 안전하지 않은 이유**

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FkMNET4gMyxyIAuZ7yxav%2Fimage.png?alt=media&amp;token=6d17a661-a1ad-4d97-80ee-04b03c31395a" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FVqW6pEuj9OkOSOESJYhC%2Fimage.png?alt=media&amp;token=a83e8030-328a-4ee5-a0a7-b00a81640d14" alt=""><figcaption></figcaption></figure>

## **9. client-side script 기반 보안 검증이 안전하지 않은 이유**

* 웹 쉘을 업로드 하려고 하면

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2Fiyyvwp5Lh5DDofJcIS64%2Fimage.png?alt=media&amp;token=a1c78aab-609f-4c41-b2db-b2b6a5de0314" alt=""><figcaption></figcaption></figure>

이러한 경고창이 뜬다.

* 이거는 클라이언트 사이드 스크립트 검증이 이루어지고 있구나를 알 수 있음.

버프 스윗으로 프록시를 잡아서 클라이언트 사이드 측에 해당 부분의 검증 로직을 삭제해서 업로드가 가능하다는 것은 서버측에는 검증 로직이 구현되어 있지 않다는 것을 의미한다.

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FCiiZRHViY5LlkCz7QOW1%2Fimage.png?alt=media&amp;token=0e92d257-51b8-4db3-96a9-2cefd38da8fa" alt=""><figcaption></figcaption></figure>

<figure><img src="https://287627346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8ysBTUxkIeOC7SqTEZ2L%2Fuploads%2FwSQu8IQxlkVCqoXmhWdI%2Fimage.png?alt=media&amp;token=b0411dc4-8fa6-43c6-ae13-f25040b48931" alt=""><figcaption></figcaption></figure>

## **10. input 태그의 hidden 타입**

* 화면상으로는 출력이 안되는데 실제로는 서버측에 히든 타입이 적혀 있음.
* 버프 스위트에서 프록시로 잡으면 저 히든 부분도 잡힌다.
* 그 부분을 admin 으로 바꾸면 관리자 페이지로 넘어가진다.