Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator 4903c8dbf5 Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat
2024-03-17 16:41:54 +00:00
..
cookie-bomb.md Translated to Korean 2024-02-10 21:30:13 +00:00
cookie-jar-overflow.md Translated to Korean 2024-02-10 21:30:13 +00:00
cookie-tossing.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-17 16:41:54 +00:00
README.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-17 16:41:54 +00:00

README.md

쿠키 해킹

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로**부터 **히어로**까지 **AWS 해킹**을 배우세요!

HackTricks를 지원하는 다른 방법:

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

쿠키 속성

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

만료 및 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자 도메인에서도 쿠키를 보낼 수 있습니다.

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

요청 유형 예제 코드 쿠키 전송 시
링크 <a href="..."></a> NotSet*, Lax, None
프리렌더 <link rel="prerender" href=".."/> NotSet*, Lax, None
폼 GET <form method="GET" action="..."> NotSet*, Lax, None
폼 POST <form method="POST" action="..."> NotSet*, None
아이프레임 <iframe src="..."></iframe> NotSet*, None
AJAX $.get("...") NotSet*, None
이미지 <img src="..."> NetSet*, None

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

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

쿠키 플래그

HttpOnly

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

우회 방법

  • 페이지가 요청의 응답으로 쿠키를 보내는 경우 (예: PHPinfo 페이지에서), XSS를 악용하여 이 페이지로 요청을 보내고 응답에서 쿠키를 도용할 수 있습니다 (https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
  • 이는 서버로부터의 응답으로 TRACE HTTP 요청을 보내는 경우 우회할 수 있습니다 (이 HTTP 메서드를 사용할 수 있는 경우). 이 기술은 Cross-Site Tracking이라고 합니다.
  • 이 기술은 모던 브라우저에서 JS에서 TRACE 요청을 보내지 못하도록 하여 회피됩니다. 그러나 특정 소프트웨어에서 \r\nTRACE를 TRACE 대신 IE6.0 SP2로 보내는 등 이에 대한 우회 방법이 발견되었습니다.
  • 다른 방법은 브라우저의 제로/데이 취약점을 악용하는 것입니다.
  • 쿠키 자 저장소 오버플로 공격을 수행하여 HttpOnly 쿠키를 덮어쓸 수 있습니다:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Secure

요청은 일반적으로 HTTPS를 통해 전송되는 경우에만 HTTP 요청에서 쿠키를 보냅니다.

쿠키 접두사

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

__Host-로 접두사가 있는 쿠키의 경우 다음 조건을 충족해야 합니다:

  • secure 플래그로 설정되어야 합니다.
  • HTTPS로 보호된 페이지에서 발생해야 합니다.
  • 도메인을 지정하지 않아야 하며, 이는 하위 도메인으로의 전송을 방지합니다.
  • 이러한 쿠키의 경로는 /로 설정되어야 합니다.

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

쿠키 덮어쓰기

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

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

쿠키 공격

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

쿠키 디코딩 및 조작

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

세션 하이재킹

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

세션 픽세이션

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

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

세션 기부

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

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

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

{% embed url="https://discord.gg/tryhardsecurity" %}

htARTE (HackTricks AWS Red Team Expert)와 함께 제로부터 영웅까지 AWS 해킹을 배우세요!

HackTricks를 지원하는 다른 방법: