[컴퓨터 네트워크 스터디 5주] 쿠키 , 세션 , 토큰 , REST

쿠키와  세션

 

정보 유지가 필요한 상황에서 HTTP 특징인 Stateless한 방식을 대처하기 위해 쿠키와 세션을 사용한다.
큰 차이점은 상태정보의 저장 위치이다. 쿠키와 세션 모두 클라이언트가 가지고 있지만 세션은 서버도 저장한다.

 

쿠키

 

클라이언트의 상태 정보를 클라이언트의 PC에 저장 후 필요시 정보를 참조하거나 재사용을 가능하게 한다.

 

• Key-Value 쌍의 작은 데이터 파일
• 이름 , 값 , 만료일(저장 기간 설정) , 경로 정보 등으로 구성되어 있다.
• 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
• 하나의 도메인 당 20개의 쿠키를 가질 수 있다.

동작방식

1. 클라이언트가 서버에 로그인 요청
2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고 응답헤더에 set-cookie: user=홍길동을 추가하여 응답
3. 클라이언트는 이후 서버에 요청할 때 전달받은 cookie: user=홍길동 쿠키를 자동으로 요청헤더가 추가하여 요청한다.(브라우저에서 자동으로 추가)

 

세션

 

클라이언트별로 세션ID를 부여하고 서버에 저장하여 클라이언트의 상태정보를 유지하는 기술이다.

 

• 웹 서버에 상태를 유지하기 위한 정보를 저장한다.
• 웹 서버에 저장되는 쿠키(=세션 쿠기라고도 불림)
• 브라우저를 닫거나 , 서버에서 세션을 삭제했을때만 삭제가 되므로 쿠키보다 비교적 보안이 좋다.
• 각 클라이언트에 고유 Session ID를 부여한다.

동작방식

 

1. 클라이언트가 서버에 로그인 요청
2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고 unique한 id를 sessionId라는 이름으로 저장
3. 서버가 응답할 때 응답헤더에 set-cookie:sessionId:abcdefg를 추가하여 응답.
4. 클라이언트는 이후 서버에 요청할 때 전달받은 sessionid:abcdefg 쿠키를 자동으로 요청 헤더에 추가하여 요청
5. 서버에서는 요청 헤더의 sessionId 값을 저장된 세션 저장소에 찾아보고 유효한지 확인 후 요청을 처리하고 응답
   * 세션의 내용은 서버에 저장되기 때문에 계속하여 늘어날 경우 서버에 부하가 발생

쿠키와 세션의  차이점

 

• 저장위치
  • 쿠키는 클라이언트(로컬), 세션은 클라이언트와 서버에 저장
• 보안
  
  • 쿠키는 탈취와 변조가 가능하지만 , 세션은 ID값만 가지고 있고 서버에도 저장되어 있기 때문에 상대적으로 안전하다. 
• Lifecycle
  • 쿠키는 브라우저를 종료해도 파일로 남아있지만 , 세션은 브라우저 종료시 세션을 삭제
• 속도
  
  • 쿠키는 파일에서 읽기 때문에 상대적으로 빠르고 , 세션은 요청마다 서버에서 처리를 해야하기 때문에 비교적 느리다.
• 접근성
  
  • 쿠키는 js를 이용하여 접근할 수 있다.(httponly 속성이 활성화 되어 있을 경우 JS 엑세스 불가능)
  • 세션은 접근 할 수 없다.
• 용량
  
  • 쿠키는 하나당 최대 4KB
  • 션은 서버측 용량에 따라 다름

 

 SOP와  CORS

 

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

 

다른 출처의 리소스를 사용하는 것을 제한하고 동일 출처에서만 접근이 가능하게 하는 방식.

출처(origin)는 protocol , Host , Port 를 통해 같은 출처 인지 다른 출처인지 판단할 수 있다.

 

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

 

다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 방식

 

종류

1. 예비요청(Preflight Request)
2. 단순 요청(Simple Request)
3. 인증정보 포함 요청 (Credentialed Request)

• Preflight Request(예비 요청)
  • OPTIONS 메서드를 통해 다른 도메인의 리소스에 요청이 가능한 지 확인 작업
  • 요청이 가능하다면 실제 요청을(Actual Request) 보낸다.
  • Access-Control-Max-Age
    • 하나의 요청마다 매번 Preflight 요청을 날릴 수 없으니 응답값을 캐싱, 그럼 캐싱시간동안 바로 요청을 보낼 수 있다.
• Simple Request(단순 요청)
  
  • Preflight 요청 없이 바로 요청을 날린다.
  • 서버가 이에대한 응답 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식
• Credentialed Request(인증정보 포함 요청)
  • 인증 관련 헤더를 포함할 때 사용하는 요청이다.

 

 REST API

 

REST 아키텍처를 기반으로 URL은 어떤 자원에 접근할 것인지 , 메소드로 어떤 행위를 할 것인지등을 표현하여 설계한 API를 말한다.

여기서 API는 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 하여 서로 정보를 교환가능 하도록 하는 것을 말한다.

 

* REST라는 것은 웹 서비스에서 많이 사용되는데 Application 사이에 결합도를 낮추게끔 설계하는 아키텍처 스타일이다.      결합도를 낮춰 서버 / 클라이언트가 별도로 구축되고 결합될 수 있게 하는것이다.

 

REST   API   제약조건  6가지

 

 

 1 . Client-Server  구조

 

 

클라이언트는 요청을 발생 시키고, 서버는 요청에 대해 반응하는 구조 
관심사의 분리를 통해 클라이언트는 UI의 이식성에만 집중 , 서버는 확장성에만 집중 가능.

 

 2 . Stateless(무상태성)

 

 

요청은 상태를 가지지 않는다는 제약조건 , 각각의 요청은 독립적이고 필요한 모든 정보를 제공해야 한다.

서버는 클라이언트가 이전에 무슨 요청을 보냈는지 모른다.

 

 3 .  캐시

 

서버는 자원이 캐시 가능한 지 명시해야 한다.

 

 

 4.  계층형 시스템

 

계층형 시스템을 적용해야 한다는 제약 조건이다.
각자의 책임에 맞게 서버에서 이를 구현하여 단순성과 확장성이 향상된다.

 

 5.  주문형 코드(Optional)

 

클라이언트가 '필요에 의해' 기능을 확장할 수 있도록 해야한다는 제약조건이다.

시스템 전체적으로 적용되었을 때 오히려 성능엥 안 좋은 영향을 끼칠수도 있어서 Optional이다.

 

 6. Uniform Interface

 

개발을 할 때 클라이언트와 맞닿아 있는 부분을 쉽고 일반적으로 설계하라는 제약조건이다.

 

1. 자원의 식별
   • 클라이언트와 서버 사이의 상호작용에서 고유하게 자원을 식별할 수 있어야 한다.

     

2. 표현을 통한 자원의 조작
   
   • 표현이란? 메타데이터 + 데이터이면서 자원의 특정 상태를 의미한다.이러한 표현을 통해서 자원을 조작해야 한다.

     

3. 자기 서술적인 메시지

 

4. HATEOAS(hypermedia as the engine of application state)

 

클라이언트는 서버와 상호작용하면서 하이퍼링크를 통해 동적으로 모든 리소스에 접근할 수 있어야 한다는 제약조건이다.

 

 

REST의 핵심

클라이언트와 서버간의 결합도를 낮춰 독립적인 진화를 할 수 있게 하는것

※ 독립적인 진화는 서버와 클라이언트 간의 상호작용에서 변경의 영향을 최소화하고 유연성을 제공하기 위한 노력을 의미한다.

 

 

 토큰

 

토큰은 서버에서 해당 클라이언트에게 인증되었다는 의미로 유니크하고 암호화된 데이터이다.

• 세션과 달리 서버가 아닌 클라이언트에 저장된다. 그래서 확장성이 좋다.
• 토큰 자체에 데이터가 들어있어 서버에서는 토큰을 받아서 클라이언트에서 위조되었는지 판별하고 내부 데이터를 꺼내서 사용할 수도있다.
• 토큰은 앱과 서버가 통신 및 인증할 때 가장 많이 사용된다. 왜냐하면 웹에는 쿠키와 세션이 있지만 앱에서는 없기 때문이다.
• 대표적인 방식으로 JWT 방식(인증에 필요한 정보들을 암호화 시킨 JSON 토큰)이 있다.

단점

• 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어 , 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있다.
• Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
• 토큰을 탈취당하면 대처하기 어렵다. (따라서 사용 가간 제한을 설정하는 식으로 극복한다.

 

XSS  공격 , SQL Injection

 

 

XSS(Cross-site-Scripting)

가장 널리 알려진 웹 보안 취약점 중 하나이며 악의적인 사용자가 공격하려는 사이트에 악성 스크립트를 삽입할 수 있는 보안 취약점이다.

C&C 로 리다이렉트 하거나 사용자의 쿠키를 탈취하여 세션 하이재킹 공격을 할 수 있다.

 

대표적인 공격방식

•  Stored XSS
  • 해커는 XSS 취약점이 있는 곳을 파악하고 , 악성 스크립트를 삽입합니다. 삽입된 스크립트는 데이터베이스에 저장이 되고 저장된 악성스크립트가 작동하면서 사용자의 쿠키를 탈취한다던가 , 혹은 다른 사이트로 리다이렉션 되는 공격등을 한다.
•  Reflected XSS
  • Reflected XSS 공격은 사용자에게 입력 받은 값을 서버에서 되돌려 주는 곳에서 발생합니다. 서버가 사용자의 입력 값을 포함해 응답해 줄 때 스크립트가 실행됩니다.  보통 Reflected XSS 는 공격자가 악의적인 스크립트와 함께 URL을 사용자에게 누르도록 유도하고 , URL을 누른 사용자는 악의적인 스크립트가 실행되면서 공격을 당하게 됩니다.
•  DOM based
  • 악의적인 스크립트가 포함 된 URL을 사용자가 요청하게 되어 브라우저를 해석하는 단계에 발생하는 공격이다.
  • 다른 XSS 공격과는 다르게 서버 측에서 탐지가 어렵다는 점이 있다.

 

XSS 예방법

 

• XSS 취약점이 있는 innerHTML 사용을 자제한다.
  • textContent , innerText를 사용하면 스크립트가 주입되지 않는다.
• 쿠키에 HTTPOnly 옵션을 활성화 한다.
  • 악의적인 클라이언트가 쿠키에 저장된 정보(세션Id , 토근)에 접근하는 것을 차단한다.
  • 활성화 하지 않으면 스크립트를 통해 쿠키에 접근할 수 있어 Session 하이재킹 취약점 발생할 수 있다.
  • LocalStorage에 세션 ID같은 민감한 정보를 저장하지 않는다.
• XSS 특수문자를 치환한다.

SQL Injection

 

데이터베이스와 연동된 웹 어플리케이션에서 공격자가 입력이 가능한 폼에 조작된 질의문을 삽입하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위를 말한다.

 

예방법

1. Parameter Binding 방식을 지원하는 PrepareStatement 객체를 사용한다.

    - Prepared Statement란 미리 쿼리에 대한 컴파일을 수행하고 , 입력값을 나중에 넣는 방식이다.

2. 사용자의 입력을 받을 때 검증 로직을 추가하여 값이 유효한지 검증합니다.

3. DB 보안

 

 

 URL , URI , URN

 

• URI(Uniform Resource Identifier)
  
  • 특정 리소스를 식별하는 통합 자원 식별자
  • 추창석 / 물리적 리소스를 식별하기 위한 식별자(identifier)
• URL(Uniform Resource Locator)
  • 리소스의 위치
  • 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약
• URN(Uniform Resource Name)
  • 리소스에 이름을 부여
  • 한 리소스에 대해 위치와 상관없이 유일하게 해당 리소스를 식별하는 이름 역할을 한다.
  • URN은 아직 실험중이고 , 널리 채택되어 사용되고 있지 않다.

 

 웹 캐시

 

캐시란?

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

 

캐싱?

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

 

웹 캐시?

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

 

 프록시 

 

프록시는 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 말합니다. 그 중계 기능을 하는 것을 프록시 서버라고 한다. 프록시 서버는 요청된 내용들을 캐시를 이용하여 저장한다.

 

 

 포워드   프록시

 

클라이언트가 인터넷에 직접 접근하는 게 아니라 포워드 프록시가 요청을 받고 인터넷에 연결하여 서버 응답을 클라이언트에게 전달. 캐시를 자주 사용하는 데이터라면 서버에 요청을 보내지 않고 캐시에서 가져와 응답하기 때문에 성능 향상이 가능하다.

 

리버스   프록시

 

클라이언트가 인터넷에 데이터를 요청하면 리버스 프록시 서버가 해당 요청을 받아 내부 서버에서 데이터를 받은 후 클라이언트에게 응답한다.

웹 서비스에 접근할 때 웹 서버에 요청하는 것이 아닌, 프록시 서버로 요청하게 되고, 프록시 서버가 배후의 서버로부터 데이터를 가져오는 방식