Korean - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookies Hacking

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로부터 영웅까지 AWS 해킹 배우기**!

HackTricks를 지원하는 다른 방법:

Try Hard Security Group

쿠키 속성

쿠키에는 사용자 브라우저에서 동작을 제어하는 여러 속성이 포함되어 있습니다. 다음은 이러한 속성에 대한 설명입니다:

만료 및 Max-Age

쿠키의 만료 날짜는 Expires 속성에 의해 결정됩니다. 반면에 Max-age 속성은 쿠키가 삭제될 때까지의 시간(초)을 정의합니다. 더 현대적인 방식을 반영하는 Max-age를 선택하세요.

도메인

쿠키를 수신할 호스트는 Domain 속성으로 지정됩니다. 기본적으로 이는 쿠키를 발급한 호스트로 설정되며 하위 도메인은 포함되지 않습니다. 그러나 Domain 속성이 명시적으로 설정되면 하위 도메인도 포함됩니다. 이로써 Domain 속성의 지정은 하위 도메인 간 쿠키 공유가 필요한 시나리오에 유용한 덜 제한적인 옵션이 됩니다. 예를 들어 Domain=mozilla.org로 설정하면 developer.mozilla.org와 같은 하위 도메인에서 쿠키에 접근할 수 있습니다.

경로

Path 속성은 Cookie 헤더를 보내기 위해 요청된 URL에 반드시 포함되어야 하는 특정 URL 경로를 나타냅니다. 이 속성은 / 문자를 디렉터리 구분자로 고려하여 하위 디렉토리에서도 일치할 수 있도록 합니다.

순서 규칙

동일한 이름을 가진 두 개의 쿠키가 있을 때, 보내는 쿠키는 다음을 기준으로 선택됩니다:

  • 요청된 URL에서 가장 긴 경로와 일치하는 쿠키.

  • 경로가 동일한 경우 가장 최근에 설정된 쿠키.

SameSite

  • SameSite 속성은 제3자 도메인에서 시작된 요청에 쿠키를 보낼지 여부를 지시합니다. 세 가지 설정을 제공합니다:

  • Strict: 제3자 요청에 쿠키를 보내지 않습니다.

  • Lax: 제3자 웹사이트에서 시작된 GET 요청과 함께 쿠키를 보낼 수 있습니다.

  • None: 어떤 제3자 도메인에서도 쿠키를 보낼 수 있습니다.

쿠키를 구성할 때 이러한 속성을 이해하면 다양한 시나리오에서 예상대로 동작하도록 보장할 수 있습니다.

Invicti에서 가져온 표이며 약간 수정되었습니다. SameSite 속성이 있는 쿠키는 로그인 세션이 필요한 CSRF 공격을 완화합니다.

*Chrome80(2019년 2월)부터 쿠키에 SameSite 속성이 없는 경우의 기본 동작이 Lax로 변경될 것임을 주의하세요 (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). 임시로 이 변경을 적용한 후 Chrome에서는 첫 2분 동안 SameSite 정책이 없는 쿠키가 None으로 처리되고 그 후에는 최상위 교차 사이트 POST 요청에 대해 Lax로 처리됩니다.

쿠키 플래그

HttpOnly

이는 클라이언트가 쿠키에 액세스하지 못하도록합니다(예: document.cookie를 통한 자바스크립트).

우회 방법

  • 페이지가 요청의 응답으로 쿠키를 보내는 경우(예: PHPinfo 페이지), XSS를 악용하여 이 페이지로 요청을 보내고 응답에서 쿠키를 도용할 수 있습니다(예: https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).

  • 이는 서버로부터의 응답으로 쿠키를 보낼 때 TRACE HTTP 요청을 통해 우회할 수 있습니다(이 HTTP 메서드를 사용할 수 있는 경우). 이 기술은 교차 사이트 추적이라고 합니다.

  • 이 기술은 모던 브라우저에서 JS에서 TRACE 요청을 보내지 못하도록 함으로써 회피됩니다. 그러나 특정 소프트웨어에서 \r\nTRACE를 TRACE 대신 IE6.0 SP2로 보내는 등 이에 대한 우회 방법이 발견되었습니다.

  • 다른 방법은 브라우저의 제로/데이 취약점을 악용하는 것입니다.

  • 쿠키 자체를 덮어쓰는 HttpOnly 쿠키 공격을 수행하여 우회할 수 있습니다:

Secure

요청은 **안전한 채널(일반적으로 HTTPS)**을 통해 전송될 때에만 쿠키를 보냅니다.

쿠키 접두사

__Secure-로 접두사가 붙은 쿠키는 HTTPS로 보호된 페이지에서 secure 플래그와 함께 설정해야 합니다.

__Host-로 접두사가 붙은 쿠키는 다음 조건을 충족해야 합니다:

  • secure 플래그로 설정되어야 합니다.

  • HTTPS로 보호된 페이지에서 시작해야 합니다.

  • 도메인을 지정할 수 없으며, 이로 인해 하위 도메인으로의 전송이 금지됩니다.

  • 이러한 쿠키의 경로는 /로 설정되어야 합니다.

__Host-로 접두사가 붙은 쿠키는 슈퍼도메인이나 하위 도메인으로 보내지지 않도록 허용되지 않습니다. 이 제한은 애플리케이션 쿠키를 격리하는 데 도움이 됩니다. 따라서 모든 애플리케이션 쿠키에 __Host- 접두사를 사용하는 것은 보안과 격리를 강화하는 좋은 방법으로 간주될 수 있습니다.

쿠키 덮어쓰기

그래서, __Host- 접두어가 있는 쿠키의 보호 중 하나는 서브도메인에서 덮어쓰기를 방지하는 것입니다. 예를 들어 쿠키 토싱 공격을 방지합니다. 쿠키 붕괴: 웹 세션 무결성 취약점 노출 (논문)에서는 예를 들어, 파서를 속이는 방법으로 서브도메인에서 __HOST- 접두어가 있는 쿠키를 설정할 수 있었다고 소개되었습니다. 예를 들어, "="를 시작이나 시작과 끝에 추가하는 것 등이 가능했습니다...:

또는 PHP에서는 쿠키 이름의 처음에 다른 문자를 추가하여 언더스코어로 대체되도록 할 수 있어 __HOST- 쿠키를 덮어쓸 수 있었습니다:

쿠키 공격

커스텀 쿠키에 민감한 데이터가 포함되어 있는지 확인하십시오 (특히 CTF를 진행 중이라면), 취약할 수 있습니다.

쿠키 디코딩 및 조작

쿠키에 포함된 민감한 데이터는 항상 면밀히 조사되어야 합니다. Base64 또는 유사한 형식으로 인코딩된 쿠키는 종종 디코딩될 수 있습니다. 이 취약점을 통해 공격자는 쿠키의 내용을 변경하고 수정된 데이터를 다시 쿠키로 인코딩하여 다른 사용자를 흉내낼 수 있습니다.

세션 하이재킹

이 공격은 사용자의 쿠키를 도용하여 응용 프로그램 내에서 계정에 무단으로 액세스하는 것을 포함합니다. 도난당한 쿠키를 사용하여 공격자는 합법적인 사용자를 흉내낼 수 있습니다.

세션 픽세이션

이 시나리오에서 공격자는 특정 쿠키를 사용하도록 피해자를 속입니다. 응용 프로그램이 로그인 시 새로운 쿠키를 할당하지 않는 경우, 원래 쿠키를 가진 공격자는 피해자를 흉내낼 수 있습니다. 이 기술은 피해자가 공격자가 제공한 쿠키로 로그인하는 것에 의존합니다.

서브도메인에서 XSS를 발견하거나 서브도메인을 제어하는 경우, 다음을 읽으십시오:

세션 기부

여기서 공격자는 피해자를 공격자의 세션 쿠키를 사용하도록 설득합니다. 자신의 계정에 로그인되어 있는 것으로 믿는 피해자는 실수로 공격자의 계정에서 작업을 수행할 수 있습니다.

서브도메인에서 XSS를 발견하거나 서브도메인을 제어하는 경우, 다음을 읽으십시오:

JWT 쿠키

이전 링크를 클릭하여 JWT의 가능한 결함에 대해 설명하는 페이지에 액세스하십시오.

쿠키에 사용되는 JSON Web Tokens (JWT)은 취약점을 가질 수 있습니다. JWT를 해킹하는 데 사용되는 문서에 액세스하여 잠재적인 결함과 그것을 어떻게 악용하는지에 대한 깊은 정보를 얻을 수 있습니다.

교차 사이트 요청 위조 (CSRF)

이 공격은 현재 인증된 웹 응용 프로그램에서 로그인한 사용자가 원치 않는 작업을 실행하도록 강제합니다. 공격자는 취약한 사이트로의 모든 요청에 자동으로 전송되는 쿠키를 악용할 수 있습니다.

빈 쿠키

(자세한 내용은 원본 연구에서 확인하십시오) 브라우저는 이름이 없는 쿠키를 생성할 수 있으며, 이는 JavaScript를 통해 다음과 같이 시연할 수 있습니다:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

결과는 전송된 쿠키 헤더에 a=v1; test value; b=v2;로 나타납니다. 신기하게도, 빈 이름 쿠키가 설정되면 쿠키를 조작할 수 있어서 빈 쿠키를 특정 값으로 설정하여 다른 쿠키를 제어할 수 있습니다:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

이로 인해 브라우저가 a라는 이름과 값이 b인 쿠키로 해석하는 쿠키 헤더를 보냅니다.

Chrome 버그: 유니코드 서로 대체 코드포인트 문제

Chrome에서 설정된 쿠키에 유니코드 서로 대체 코드포인트가 포함되어 있으면, document.cookie가 손상되어 이후에는 빈 문자열을 반환합니다.

document.cookie = "\ud800=meep";

이로 인해 document.cookie가 빈 문자열을 출력하여 영구적인 손상을 나타냅니다.

구문 분석 문제로 인한 쿠키 스머글링

(자세한 내용은 원본 연구에서 확인하십시오) Java (Jetty, TomCat, Undertow) 및 Python (Zope, cherrypy, web.py, aiohttp, bottle, webob)을 포함한 여러 웹 서버는 오래된 RFC2965 지원으로 인해 쿠키 문자열을 잘못 처리합니다. 이들은 세미콜론을 포함하는 경우에도 이중 따옴표로 묶인 쿠키 값을 키-값 쌍을 분리해야 하는데도 단일 값으로 읽습니다.

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

쿠키 주입 취약점

(자세한 내용은 원본 연구을 확인하십시오) 서버들이 쿠키를 잘못 구문 분석하는 경우, 특히 Undertow, Zope 및 Python의 http.cookie.SimpleCookie 및 http.cookie.BaseCookie를 사용하는 경우, 쿠키 주입 공격 기회가 발생합니다. 이러한 서버들은 새로운 쿠키의 시작을 제대로 구분하지 못하여 공격자가 쿠키를 위조할 수 있게 합니다:

  • Undertow는 세미콜론 없이 따옴표로 묶인 값 바로 뒤에 새로운 쿠키를 기대합니다.

  • Zope는 다음 쿠키를 구문 분석하기 위해 쉼표를 찾습니다.

  • Python의 쿠키 클래스는 공백 문자에서 구문 분석을 시작합니다.

이 취약점은 쿠키 기반 CSRF 보호에 의존하는 웹 애플리케이션에서 특히 위험하며, 공격자가 위조된 CSRF 토큰 쿠키를 삽입하여 보안 조치를 우회할 수 있습니다. 이 문제는 Python이 중복 쿠키 이름을 처리하는 방식에 의해 악화되며, 마지막 발생이 이전 것을 덮어쓸 수 있습니다. 또한 안전하지 않은 컨텍스트에서 __Secure- 및 __Host- 쿠키에 대한 우려가 제기되며, 쿠키가 위조 가능한 백엔드 서버로 전달될 때 권한 우회로 이어질 수 있습니다.

추가 취약한 쿠키 확인

기본 확인 사항

  • 쿠키가 로그인할 때마다 동일합니다.

  • 로그아웃하고 동일한 쿠키를 사용해보세요.

  • 동일한 쿠키를 사용하여 2대의 장치(또는 브라우저)로 동일한 계정에 로그인해보세요.

  • 쿠키에 어떤 정보가 있는지 확인하고 수정해보세요.

  • 거의 동일한 사용자 이름으로 여러 계정을 만들어 유사성을 확인해보세요.

  • "나를 기억" 옵션이 있는지 확인하고 작동 방식을 확인하세요. 존재하고 취약할 경우 항상 나를 기억 쿠키만 사용하세요.

  • 이전 쿠키가 비밀번호를 변경한 후에도 작동하는지 확인하세요.

고급 쿠키 공격

로그인할 때 쿠키가 동일하게 유지되면 (또는 거의 유지되면), 이는 아마도 쿠키가 계정의 어떤 필드와 관련이 있다는 것을 의미합니다(아마도 사용자 이름). 그럼 다음을 시도할 수 있습니다:

  • 매우 유사한 사용자 이름으로 많은 계정을 만들어 알고리즘이 어떻게 작동하는지 추측해보세요.

  • 사용자 이름을 브루트포스해보세요. 쿠키가 사용자 이름의 인증 방법으로만 저장된다면, "Bmin"이라는 사용자 이름으로 계정을 만들고 쿠키의 각 부분을 브루트포스하여 "admin"에 속하는 쿠키 중 하나를 시도할 수 있습니다.

  • 패딩 오라클을 시도하세요(쿠키의 내용을 해독할 수 있습니다). padbuster를 사용하세요.

패딩 오라클 - Padbuster 예제

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster는 여러 번 시도하고 어떤 조건이 오류 조건인지 물어볼 것입니다 (유효하지 않은 조건).

그런 다음 쿠키를 복호화하기 시작할 것입니다 (몇 분이 걸릴 수 있음)

공격이 성공적으로 수행되면 선택한 문자열을 암호화해 볼 수 있습니다. 예를 들어, user=administrator을(를) 암호화하려면

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

이 실행은 문자열 user=administrator을 포함하여 올바르게 암호화 및 인코딩된 쿠키를 제공합니다.

CBC-MAC

쿠키가 일부 값을 가지고 CBC를 사용하여 서명될 수 있습니다. 그럼 값의 무결성은 동일한 값으로 CBC를 사용하여 생성된 서명입니다. IV로 널 벡터를 사용하는 것이 권장되므로 이러한 종류의 무결성 확인은 취약할 수 있습니다.

공격

  1. 사용자 이름 administ의 서명을 가져옵니다 = t

  2. 사용자 이름 rator\x00\x00\x00 XOR t의 서명을 가져옵니다 = t'

  3. 쿠키에 값 **administrator+t'**를 설정합니다 (**t'**는 (rator\x00\x00\x00 XOR t) XOR t의 유효한 서명이 될 것입니다 = rator\x00\x00\x00

ECB

쿠키가 ECB를 사용하여 암호화된 경우 취약할 수 있습니다. 로그인할 때 받는 쿠키는 항상 동일해야 합니다.

탐지 및 공격 방법:

거의 동일한 데이터(사용자 이름, 비밀번호, 이메일 등)를 가진 2명의 사용자를 생성하고 주어진 쿠키 내에서 어떤 패턴을 발견하려고 시도합니다.

예를 들어 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"라는 사용자를 만들고 쿠키에 어떤 패턴이 있는지 확인합니다 (ECB는 동일한 키로 각 블록을 암호화하므로 사용자 이름이 암호화된 경우 동일한 암호화된 바이트가 나타날 수 있습니다).

패턴이 있어야 합니다(사용된 블록의 크기). 그러므로 "a"의 암호화된 패턴을 알고 있다면 "a"*(블록의 크기)+"admin"과 같은 사용자 이름을 만들 수 있습니다. 그런 다음 쿠키에서 "a" 블록의 암호화된 패턴을 삭제할 수 있습니다. 그러면 사용자 이름이 "admin"인 쿠키를 얻을 수 있습니다.

참고 자료

Try Hard Security Group

htARTE (HackTricks AWS Red Team Expert)를 통해 제로부터 AWS 해킹을 배우세요

HackTricks를 지원하는 다른 방법:

PreviousCSP bypass: self + 'unsafe-inline' with IframesNextCookie Tossing

Last updated