[컴퓨터 네트워크] JWT, CORS, REST, URL, 캐시, 프록시

📌 오늘 학습 목표

1️⃣ 쿠키와 세션의 개념을 알고 차이점을 이해한다

2️⃣ JWT 토큰에 대해 이해한다

3️⃣ SOP와 CORS 의 개념을 이해한다

4️⃣ REST 개념을 이해한다

5️⃣ URL, URI, URN 차이에 대해 이해한다

6️⃣ 여러가지 공격에 대해 이해한다

7️⃣ 웹 캐시에 대해 이해한다

8️⃣ 프록시에 대해 이해한다

Chapter 1. 쿠키, 세션, JWT

쿠키

사용자의 인증 정보를 클라이언트가 관리하기 때문에 서버 부하가 적다

1. 클라이언트(사용자)가 쉽게 쿠키에 담긴 인증 정보를 위조할 수 있다.
2. 쿠키의 데이터 크기가 제한적이고, 또 크기가 커진다면 네트워크 부하가 심해진다.

 

세션

세션 인증 방식은 사용자의 인증 정보를 클라이언트가 아닌 서버가 관리하게 됩니다.

 

JWT

기본적으로는 클라이언트가 인증 정보를 관리하기 때문에 쿠키 인증 방식과 Flow가 비슷합니다.

차이가 있는 부분은, 쿠키가 아닌 JWT 토큰을 매개체로 인증한다는 것과 서버에서 '토큰 검증'이 이루어진다는 점입니다.

이를 통해 쿠키보다는 보안적으로 안전하게 관리될 수 있습니다.

 

 

Chapter 2. SOP, CORS

SOP(Same-origin policy, 동일 출처 정책)

동일한 출처에서 온 요청만 처리하는 것이다. 

브라우저 단에서 사용자를 보호하는 것이라고 설명할 수 있겠다. 예를 들면 내가 사이트 A에 내 로그인 정보(인증)를 기억하도록 했다. 악의적인 사이트 B는 외관상으로 사이트 A와 차이점이 없어 보인다. 악의적인 사이트 B에서 사이트 A에 있는 내 인증 정보를 탈취해 나의 인증정보를 이용해 내가 사이트 B에 로그인을 하게 되면 큰 피해로 이어질 수 있다. 따라서 브라우저에서는 서로 다른 출처 간 요청을 주고 받는 것을 기본값으로 막아 둔다.

 

자바스크립트 엔진 표준 스펙의 보안 규칙으로 하나의 출처(Origin)에서 로드된 자원(문서나 스크립트)이 호스트나 프로토콜, 포트번호가 일치하지 않는 자원과 상호작용 하지 못하도록 요청 발생을 제한하고, 동일 출처(Same Origin)에서만 접근이 가능한 정책

두 URL의 Port(명시한 경우), Protocol, Host가 모두 같아야 Same Origin
"scheme/host/port 튜플(tuple)" 혹은 그냥 "tuple"이라고 하기도 한다.

Internet Explorer 예외사항 😠

IE는 동일 출처 정책에 두 가지 중요한 예외가 있고 비표준이며 다른 브라우저에서는 지원하지 않는다.

• 신뢰할 수 있는 사이트
• 양쪽 도메인 모두가 높음 단계의 보안 수준을 가지고 있는 경우 동일 출처 제약을 적용하지 않는다.
• 포트
• Internet Explorer는 동일 출처 정책 검사에 포트를 포함하지 않는다.

CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유)

CORS(Cross-Origin Resource Sharing)는 다른 출처 간에 리소스를 공유할 수 있게 하는 것이다.
사이트 C와 사이트 D가 서로 신뢰할 수 있는 사이트라면, HTTP 정보 요청과 반환이 가능하도록 하는 것이다. 요청에 origin 이라는 header 를 추가해 특정 도메인이나 *(모든 도메인)을 적어 준다. 또 인증정보/토큰 등을 주고 받는 사이트들 간에 CORS 를 허용하려면 credentials 을 true 로 설정해야 한다.

 

웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 한다. 이는 시스템 수준에서 타 도메인 간 자원 호출을 승인하거나 차단하는 것을 결정하는 것이다.

CORS는 웹페이지상에서 자바스크립트를 이용하여 XHR(XMLHttpRequest)을 다른 도메인으로 발생 시킬 수 있도록 해주는 기능을 가지고 있고 XHR 기반 cross-origin HTTP 요청을 이용하여 자원을 공유해야 하는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원한다.

 

 

Chapter 3. REST

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

즉 REST란 

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

REST 구성 요소

REST는 다음과 같은 3가지로 구성이 되어있다. 

 

1. 자원(Resource) : HTTP URI
2. 자원에 대한 행위(Verb) : HTTP Method
3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

REST의 특징

1. Server-Client(서버-클라이언트 구조)
2. Stateless(무상태)
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
5. Uniform Interface(인터페이스 일관성)

REST의 장단점

장점 

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

 

단점 

• 표준이 자체가 존재하지 않아 정의가 필요하다.
• HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

RESPT API란 REST의 원리를 따르는 API를 의미합니다.

RESTFUL이란 REST의 원리를 따르는 시스템을 의미합니다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다.  REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며

모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.

 

Chapter 4. URL, URI, URN

 

URI란?

• URI는 Uniform Resource Identifier, 통합 자원 식별자의 줄임말이다.
• 즉, URI는 인터넷의 자원을 식별할 수 있는 문자열을 의미한다.
• URI의 하위 개념으로 URL과 URN이 있다.
• URI 중 URL이라는, URN이라는 하위 개념을 만들어서 특별히 어떤 표준을 지켜서 자원을 식별하는 것이다.
• 결론은 URI라는 개념은 어떤 형식이 있다기 보다는 특정 자원을 식별하는 문자열을 의미한다. 그래서 URL이 아니고 URN도 아니면 그냥 URI가 되는 것이다.

 

URL이란?

• URL은 Uniform Resource Locator의 줄임말이다.
• URL은 네트워크 상에서 리소스(웹 페이지, 이미지, 동영상 등의 파일) 위치한 정보를 나타낸다.
• URL은 HTTP 프로토콜 뿐만아니라 FTP, SMTP 등 다른 프로토콜에서도 사용할 수 있다.
• URL은 웹 상의 주소를 나타내는 문자열이기 때문에 더 효율적으로 리소스에 접근하기 위해 클린한 URL 작성을 위한 방법론이다.

 

URL구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

1. scheme : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용
2. user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호
3. host와 port : 접근할 대상(서버)의 호스트명과 포트번호
4. path : 접근할 대상(서버)의 경로에 대한 상세 정보
5. query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)
6. fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보

 

URN이란?

• URN은 Uniform Resource Name의 줄임말이다.
• URN은 URI의 표준 포맷 중 하나로, 이름으로 리소스를 특정하는 URI이다.
• http와 같은 프로토콜을 제외하고 리소스의 name을 가리키는데 사용된다.
• URN에는 리소스 접근방법과, 웹 상의 위치가 표기되지 않는다.
• 실제 자원을 찾기 위해서는 URN을 URL로 변환하여 이용한다.

 

URL과 URN의 차이점

• URL은 어떻게 리소스를 얻을 것이고 어디에서 가져와야하는지 명시하는 URI이다.
• URN은 리소스를 어떻게 접근할 것인지 명시하지 않고 경로와 리소스 자체를 특정하는 것을 목표로하는 URI이다.

 

Chapter 5. XSS, CSRF, SQL Injection

XSS(Cross-Site-Scripting)는 웹사이트에서 의도치 않은 스크립트를 넣어서 실행시키는 기법을 말합니다.
보통 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어집니다. 그리고 스크립트가 포함된 글을 열어보게 되면 브라우저에서 원치 않는 스크립트가 실행되는 방식이죠.
이걸 통해 유저의 쿠키 정보를 탈취하거나, 유저 비밀번호를 변경하는 api를 호출하는 행위를 할 수 있습니다.

1. Perpetrator(침입자)는 사이트의 취약점을 찾습니다.
2. 취약점을 찾아서 세션 쿠키를 탈취하는 스크립트를 사이트에 삽입합니다.
3. 사용자가 그 웹사이트에 접근할 때마다 스크립트가 작동합니다
4. 스크립트를 통해 침입자에게 사용자의 세션 쿠키가 전달됩니다.

방지 대책
쿠키에 중요한 정보를 담지 않고 서버에 중요 정보를 저장하는 방식을 사용할 수 있습니다.
그리고 httponly 속성을 다는 방식을 사용할 수 있습니다. (document.cookie를 이용해서 쿠키에 직접 접근하는 것을 막는 옵션입니다!)
마지막으로 보안과 관련된 함수를 사용한 Secure coding을 통해 XSS를 방지할 수 있습니다.

CSRF 

CSRF 공격(Cross-Site-Request-Forgery)은 웹 어플리케이션 취약점 중 하나로 사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 만드는 공격입니다.
XSS가 사용자가 특정 사이트를 신뢰하기 때문에 발생하는 문제라면, CSRF는 특정 사이트가 사용자를 신뢰하기 때문에 발생하는 문제입니다.
즉 XSS는 클라이언트의 브라우저에서 발생하는 문제라면 CSRF는 서버에서 발생하는 문제입니다.
침입자가 XSS를 사용하면 사용자의 쿠키를 탈취할 수 있고, CSRF를 사용하면 서버로부터 권한을 탈취할 수 있습니다.

1. Perpetrator(침입자)는 서버로 넘어가는 자금 전송에 대한 요청을 조작하려고 합니다.
2. 침입자는 하이퍼링크에 자금 전송 요청에 대한 스크립트를 삽입하고 사이트에 로그인할 사람들에게 전송합니다.
3. 사용자는 링크를 누르고, 의도치않게 서버로 요청을 보내게 됩니다.
4. 서버는 로그인 되어있는 사용자의 요청이기 떄문에 정상으로 인식하고 침입자에게 돈을 전송합니다.

방지책

Request header에 있는 요청을 한 페이지의 정보가 담긴 referrer 속성을 검증하여 차단하는 방법을 주로 사용합니다.
같은 도메인상에서 요청이 들어오지 않으면 차단하도록 하는 방법입니다. (엉뚱한 곳에서 해당 URI에 접속하려고 하는 것을 차단하는 것을 의미합니다!)

CSRF Token을 사용할 수 있습니다. 랜덤한 UUID와 같은 임의의 난수를 세션에 저장해두고 해당 난수가 전달되지 않는다면 요청을 거부하는 방법이 있습니다.

SQL Injection

SQL Injection 이란 악의적인 사용자가 보안상의 취약점을 이용하여, 임의의 SQL 문을 주입하고 실행되게 하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위 입니다. 

방지책

1. 입력 값에 대한 검증

2. Prepared Statement 구문사용

3. Error Message 노출 금지

4. 웹 방화벽 사용

 

 

Chapter 6. 웹 캐시

캐시란?

컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가르킵니다.

---

📌 캐싱이란?

캐싱은 애플리케이션의 처리 속도를 높여 줍니다. 이미 가져온 데이터나 계산된 결과값의 복사본을 저장함으로써 처리속도를 향상시키며, 이를 통해 향후 요청을 더 빠르게 처리할 수 있습니다. 대부분의 프로그램이 동일한 데이터나 명령어에 반복해서 액세스하기 때문에 캐싱은 효율적인 아키텍처 패턴입니다.

---

📌 웹 캐시란 무엇인가?

사용자가 웹사이트(client)에 접속할 때, 정적 컨텐츠(JS,이미지, CSS)을 특정 위치에 저장하여, 웹 사이트 서버에 해당 컨텐츠를 매번 요청하여 받는 것이 아닌, 특정 위치에서 불러옴으로서 사이트 응답 시간을 줄이고, 서버 트래픽 감소 효과를 볼 수 있는 것을 말합니다.

❗️ 웹 캐쉬의 종류

웹 캐쉬의 종류는 어디에 적용하느냐에 따라 다음과 같이 나뉠 수 있습니다.

💡 1. Browser Cashes

• 브라우저 또는 HTTP 요청을 하는 Client Appliction에 의해 내부 디스크에 캐쉬
• 캐시된 리소스를 공유하지 않는 한 개인에 한정된 캐시
• 브라우저의 back버튼 또는 이미 방문한 페이지를 재 방문하는 경우 극대화

💡 2. Proxy Caches

• Browser Cashes와 동일한 원리로 동작하며 Client나 Server가 아닌 네트워크 상에서 동작
• 큰 회사나 IPS의 방화벽에 설치 되며 대기시간 & 트래픽 감소, 접근 정책 & 제한 우회, 사용률 기록등을 수행
• 한정된 수의 클라이언트를 위해 무한 대의 웹 서버 컨텐츠를 캐시

💡 3. GateWay Caches

• 서버 앞 단에 설치되어 요청에 대한 캐시 및 효율적인 분배를 통해 가용성, 신뢰성, 성능등을 향상
• Encryption, SSL acceleration, Load balancing, Server/ cache static content, Compression 등을 수행
• 무한 대의 클라이언트들에게 한정된 수의 웹 서버 컨텐츠를 제공

 

Chapter 7. 프록시

프록시 서버란?

Proxy는 대리라는 사전적 의미를 갖고 있다. 

클라이언트와 서버의 관점에서 중간에 대신 요청을 처리한다 하여 클라이언트와 서버의 중계자 역할을 갖는 것을 프록시 서버라고 한다.

 

 

 

 

프록시 서버를 사용하는 이유?

보안

클라이언트에서 서버의 IP 주소를 숨기는 것이 가능하기 때문에 프록시 서버를 통해 한 단계의 보안을 더 유지할 수 있다. 

따라서 보안상의 이유로 외부와 직접 통신할 수 없는 경우에 프록시 서버를 이용한다. 

 

캐시 사용을 통한 속도 향상

프록시 서버는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장한다. 

따라서 캐시를 사용하여 리소스로의 접근을 빠르게 할 수 있다. 특히 웹 프록시는 웹 서버로부터 웹 페이지를 캐시로 저장하는 데 흔히 사용되며 캐싱을 통해 콘텐츠를 빠르게 가져올 수 있다. 

추가로 프록시 서버의 캐시를 이용하면 전송시간도 절약할 수 있음은 물론 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점이 있다. 또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목현상을 방지할 수 있다. 

 

접속 우회

IP를 통해 접속을 감지하는 사이트를 프록시 서버를 통해 우회할 수 있다.

따라서 사용자 IP를 숨기기 위해 여러 프록시 서버를 경유할 수가 있다. 

 

로그 기록 관리

프록시 서버를 통해 클라이언트의 기록을 관리할 수 있으며, 연결된 클라이언트들의 정보를 제어할 수 있다. 

 

방화벽

프록시 서버와 방화벽은 다르지만, 보안을 위해 함께 사용된다. 

프록시 서버는 요청을, 방화벽은 네트워크 패킷을 제어한다.

 

* 프록시 서버의 암호화 문제
프록시 서버가 사용하는 네트워크는 기본적으로 Public Network 이기 때문에, 프록시 서버에서는 데이터를 암호화하지 않는다. 따라서 클라이언트가 보내는 데이터를 탈취당할 수 있다. 
암호화를 위해서는 VPN을 사용해야 하며, 
프록시 서버 + 방화벽 + VPN은 필연적으로 같이 사용된다고 보면 된다. 

* VPN(Virtual Private Netwokr) 가상 사설 네트워크
서버와 클라이언트 간 보안처리된 터널을 만들어 놓고, 이 터널에서 암호화된 데이터를 주고받으며 보안을 유지하는 것.

 

 

 

 

 

프록시 서버 종류

프록시 서버는 네트워크 상 어디에 위치하는가에 따라 포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy)로 나뉜다. 

 

출처: https://research.aimultiple.com/forward-vs-reverse-proxy/

 

Forward Proxy

일반적으로 흔히 말하는 `프록시 서버` 혹은 `웹 프록시`는 포워드 프록시 서버를 의미한다. 

포워드 프록시는 클라이언트들 앞에 위치한다. 내부망에서 클라이언트와 Proxy 서버가 통신하여 인터넷을 통해 외부에서 데이터를 가져온다. 

즉, 클라이언트가 인터넷에 직접 접근하는 것이 아니라, 포워드 프록시 서버가 같은 내부망에 존재하는 클라이언트의 요청을 받아 인터넷을 통해 외부 서버에서 데이터를 가져와 결과를 클라이언트에게 응답해 준다. 

예를 들어, naver.com에 요청하면 포워드 프록시 서버가 naver.com 리소스를 대신 받아 클라이언트에게 내밀어준다(forward)고 생각하면 된다. 

이로서 서버에게 클라이언트가 누구인지 감출 수 있다. 

 

출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

 

 

✨ 포워드 프록시 사용 이점

1. 클라이언트 보안

보통 정부, 학교, 기업 같은 기관에 속한 사람들의 인터넷 사용을 제한하기 위해 방화벽을 사용하는데, 포워드 프록시 서버도 방화벽과 같은 개념으로 제한을 위해 사용된다.

예를 들어, 포워드 프록시 서버에 룰을 추가하여 특정 사이트에 접속하는 것을 막을 수 있다. 

 

2. 캐싱

여러 클라이언트가 동일한 자원을 요청하는 경우, 각각 따로 인터넷을 경유해서 자원을 응답받지 않고, 프록시 내 캐싱된 자원을 불러와 서버의 부하를 줄이고 응답 속도도 높일 수 있다. 

 

3. IP 우회 및 보안

클라이언트에서 프록시 서버를 거쳐 요청을 보내게 되면, 서버 측은 클라이언트 정보가 아닌 포워드 프록시 정보를 받게 된다. 이로써 서버 측에 클라이언트의 정보를 숨길 수 있다.  

 

 

Reverse Proxy

리버스 프록시는 웹 서버/WAS 앞에 위치한다. 내부망에서 Proxy 서버와 내부망 서버가 통신하여 인터넷을 통해 요청이 들어오면 Proxy 서버가 받아 응답해 준다. 

즉, 클라이언트는 웹서비스에 접근 시 웹서버에 요청하는 것이 아닌, 프록시 서버로 요청하게 되고 프록시가 배후(reverse)의 서버로부터 데이터를 가져오는 방식이다.

리버스 프록시는 배후에 있는 서버에 대한 Proxy라고 생각하면 된다. 따라서 본서버의 IP정보를 숨길 수 있는 효과를 얻게 된다. 

 

내부 서버가 직접 서비스를 제공해도 되지만 일반적으로는 보안상의 이유로 아래와 같은 방식으로 구성한다. 

보통 기업의 네트워크 환경에서는 DMZ라고 부르는 내부 네트워크/외부 네트워크 사이에 위치하는 구간이 존재한다. (내부 네트워크/외부 네트워크에 둘 다 접근할 수 있는 공간)

이 구간에는 보통 메일 서버, 웹 서버, FTP 서버 등 외부 서비스를 제공하는 서버가 위치하게 된다. 

WAS를 DMZ에 놓고 서비스해도 되지만, WAS는 DB 서버와 연결되어 있으므로 WAS가 해킹당할 경우 DB 서버까지 해킹당할 수 있는 보안상의 문제가 발생할 수 있기 때문에 그렇게 하지 않고, 리버스 프록시 서버를 DMZ에 두고 실제 서비스 서버는 내부망에 위치시킨 후 서비스한다. 

 

일반적으로 구성하는 WEB(Apache, Nginx) - WAS(Tomcat) 분리 형태를 Reverse 프록시라고 보면 된다. 
여기서 WEB(Apache, Nginx)가 reverse proxy가 된다. 

 

출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

 

 

✨ 리버스 프록시 사용 이점

1. 로드 밸런싱

리버스 프록시 서버를 여러 개의 본 서버들 앞에 두면 특정 서버가 과부하 되지 않도록 대용량 트래픽을 분산시켜 각각 다른 서버로 분배해주는 로드 밸런싱이 가능하다. 

 

2.  서버 보안

서버 측 보안에 좋다. 본래 서버의 IP 주소를 노출시키지 않을 수 있기 때문에 해커들의 DDoS 공격과 같은 공격을 막는데 유용하다. 

 

3. 캐싱

포워드 프록시와 마찬가지로 캐싱 기능 지원된다. 캐싱은 프록시의 본래 기능이라고 보면 된다. 

 

4. 암호화

SSL 암호화에 좋다. 본 내부 서버가 클라이언트들과 통신 시 SSL 또는 TLS로 암, 복호화를 할 경우 비용이 많이 들게 된다. 

그러나 리버스 프록시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할 수 있으며, 본래 서버의 부담을 줄여줄 수 있다.