From 8d8a1bcd53c34846ad8062143983a663a834f844 Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 18 May 2025 03:21:47 +0000 Subject: [PATCH] Translated ['src/pentesting-web/hacking-with-cookies/README.md'] to ko --- .../hacking-with-cookies/README.md | 72 +++++++++---------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/src/pentesting-web/hacking-with-cookies/README.md b/src/pentesting-web/hacking-with-cookies/README.md index afd06e6f9..789016cce 100644 --- a/src/pentesting-web/hacking-with-cookies/README.md +++ b/src/pentesting-web/hacking-with-cookies/README.md @@ -35,20 +35,20 @@ 쿠키를 구성할 때 이러한 속성을 이해하면 다양한 시나리오에서 예상대로 동작하도록 보장할 수 있습니다. | **요청 유형** | **예제 코드** | **쿠키 전송 시** | -| -------------- | ------------------------------- | ----------------- | -| 링크 | \\ | NotSet\*, Lax, None | -| 프리렌더링 | \ | NotSet\*, Lax, None | -| 폼 GET | \
| NotSet\*, Lax, None | -| 폼 POST | \ | NotSet\*, None | -| iframe | \ | NotSet\*, None | -| AJAX | $.get("...") | NotSet\*, None | -| 이미지 | \ | NetSet\*, None | +| ---------------- | ---------------------------------- | --------------------- | +| 링크 | \\ | NotSet\*, Lax, None | +| 프리렌더 | \ | NotSet\*, Lax, None | +| 폼 GET | \ | NotSet\*, Lax, None | +| 폼 POST | \ | NotSet\*, None | +| iframe | \ | NotSet\*, None | +| AJAX | $.get("...") | NotSet\*, None | +| 이미지 | \ | NetSet\*, None | 표는 [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/)에서 가져왔으며 약간 수정되었습니다.\ _**SameSite**_ 속성이 있는 쿠키는 **CSRF 공격을 완화**합니다. **\*Chrome80(2019년 2월)부터 쿠키에 SameSite 속성이 없는 경우 기본 동작은 lax**입니다 ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ -이 변경을 적용한 후, Chrome에서 **SameSite 정책이 없는 쿠키는** **처음 2분 동안 None으로 처리되고, 이후 최상위 교차 사이트 POST 요청에 대해 Lax로 처리됩니다.** +이 변경을 적용한 후, Chrome에서 **SameSite 정책이 없는 쿠키는** **처음 2분 동안은 None으로 처리되고, 이후에는 최상위 교차 사이트 POST 요청에 대해 Lax로 처리됩니다.** ## 쿠키 플래그 @@ -72,16 +72,16 @@ cookie-jar-overflow.md ### Secure -요청은 **HTTPS**와 같은 보안 채널을 통해 전송될 경우에만 HTTP 요청에서 쿠키를 **전송합니다**. +요청은 **보안 채널**(일반적으로 **HTTPS**)을 통해 전송되는 경우에만 HTTP 요청에서 쿠키를 **전송**합니다. ## 쿠키 접두사 -`__Secure-`로 접두사가 붙은 쿠키는 HTTPS로 보호된 페이지에서 `secure` 플래그와 함께 설정되어야 합니다. +`__Secure-`로 접두사가 붙은 쿠키는 HTTPS로 보호되는 페이지에서 `secure` 플래그와 함께 설정되어야 합니다. `__Host-`로 접두사가 붙은 쿠키는 여러 조건을 충족해야 합니다: - `secure` 플래그와 함께 설정되어야 합니다. -- HTTPS로 보호된 페이지에서 유래해야 합니다. +- HTTPS로 보호되는 페이지에서 유래해야 합니다. - 도메인을 지정하는 것이 금지되어 하위 도메인으로의 전송을 방지합니다. - 이러한 쿠키의 경로는 `/`로 설정되어야 합니다. @@ -89,11 +89,11 @@ cookie-jar-overflow.md ### 쿠키 덮어쓰기 -따라서 `__Host-` 접두사가 붙은 쿠키의 보호 중 하나는 하위 도메인에서 덮어쓰는 것을 방지하는 것입니다. 예를 들어 [**쿠키 토스 공격**](cookie-tossing.md)을 방지합니다. [**쿠키 크럼블: 웹 세션 무결성 취약점 공개**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**논문**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))에서 하위 도메인에서 \_\_HOST- 접두사가 붙은 쿠키를 설정할 수 있는 방법이 제시되었습니다. 예를 들어, 시작이나 끝에 "="를 추가하여 파서를 속이는 방법입니다: +따라서 `__Host-` 접두사가 붙은 쿠키의 보호 중 하나는 하위 도메인에서 덮어쓰는 것을 방지하는 것입니다. 예를 들어 [**쿠키 토스 공격**](cookie-tossing.md)을 방지합니다. [**쿠키 크럼블: 웹 세션 무결성 취약점 공개**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**논문**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))에서 하위 도메인에서 \_\_HOST- 접두사가 붙은 쿠키를 설정할 수 있는 방법이 제시되었습니다. 예를 들어, 시작 부분이나 끝 부분에 "="를 추가하여 파서를 속이는 방법입니다:
-또는 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가하여** 이를 **밑줄 문자**로 대체하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다: +또한 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가하여** 이를 **밑줄 문자**로 대체하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다:
@@ -137,17 +137,17 @@ cookie-tossing.md ### 교차 사이트 요청 위조 (CSRF) -이 공격은 로그인된 사용자가 현재 인증된 웹 애플리케이션에서 원치 않는 작업을 수행하도록 강요합니다. 공격자는 취약한 사이트에 대한 모든 요청과 함께 자동으로 전송되는 쿠키를 악용할 수 있습니다. +이 공격은 로그인된 사용자가 현재 인증된 웹 애플리케이션에서 원하지 않는 작업을 수행하도록 강요합니다. 공격자는 취약한 사이트에 대한 모든 요청과 함께 자동으로 전송되는 쿠키를 악용할 수 있습니다. ### 빈 쿠키 -(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) 브라우저는 이름이 없는 쿠키 생성을 허용하며, 이는 JavaScript를 통해 다음과 같이 시연할 수 있습니다: +(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) 브라우저는 이름이 없는 쿠키를 생성하는 것을 허용하며, 이는 JavaScript를 통해 다음과 같이 시연할 수 있습니다: ```js document.cookie = "a=v1" document.cookie = "=test value;" // Setting an empty named cookie document.cookie = "b=v2" ``` -전송된 쿠키 헤더의 결과는 `a=v1; test value; b=v2;`입니다. 흥미롭게도, 이는 빈 이름 쿠키가 설정되면 쿠키를 조작할 수 있게 하며, 빈 쿠키를 특정 값으로 설정함으로써 다른 쿠키를 제어할 수 있습니다: +전송된 쿠키 헤더의 결과는 `a=v1; test value; b=v2;`입니다. 흥미롭게도, 이는 빈 이름 쿠키가 설정될 경우 쿠키를 조작할 수 있게 하며, 빈 쿠키를 특정 값으로 설정함으로써 다른 쿠키를 제어할 수 있습니다: ```js function setCookie(name, value) { document.cookie = `${name}=${value}` @@ -155,11 +155,11 @@ document.cookie = `${name}=${value}` setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value ``` -이로 인해 브라우저는 모든 웹 서버에서 `a`라는 이름과 `b`라는 값의 쿠키로 해석되는 쿠키 헤더를 전송하게 됩니다. +이로 인해 브라우저는 모든 웹 서버에서 `a`라는 이름과 `b`라는 값으로 해석되는 쿠키 헤더를 전송하게 됩니다. -#### Chrome 버그: 유니코드 대리 코드 포인트 문제 +#### Chrome 버그: 유니코드 서러게이트 코드포인트 문제 -Chrome에서 유니코드 대리 코드 포인트가 설정된 쿠키의 일부인 경우, `document.cookie`가 손상되어 이후에 빈 문자열을 반환합니다: +Chrome에서는 유니코드 서러게이트 코드포인트가 설정된 쿠키의 일부인 경우, `document.cookie`가 손상되어 이후에 빈 문자열을 반환합니다: ```js document.cookie = "\ud800=meep" ``` @@ -167,13 +167,13 @@ document.cookie = "\ud800=meep" #### 파싱 문제로 인한 쿠키 스머글링 -(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 확인하세요) Java(Jetty, TomCat, Undertow) 및 Python(Zope, cherrypy, web.py, aiohttp, bottle, webob)에서 제공하는 여러 웹 서버는 구식 RFC2965 지원으로 인해 쿠키 문자열을 잘못 처리합니다. 이들은 세미콜론이 포함되어 있어도 더블 인용된 쿠키 값을 단일 값으로 읽으며, 이는 일반적으로 키-값 쌍을 구분해야 합니다: +(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) Java(Jetty, TomCat, Undertow) 및 Python(Zope, cherrypy, web.py, aiohttp, bottle, webob)에서 제공하는 여러 웹 서버는 구식 RFC2965 지원으로 인해 쿠키 문자열을 잘못 처리합니다. 이들은 세미콜론이 포함되어 있어도 이중 인용된 쿠키 값을 단일 값으로 읽으며, 세미콜론은 일반적으로 키-값 쌍을 구분해야 합니다: ``` RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` #### 쿠키 주입 취약점 -(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) 서버가 쿠키를 잘못 파싱하는 경우, 특히 Undertow, Zope 및 Python의 `http.cookie.SimpleCookie`와 `http.cookie.BaseCookie`를 사용하는 경우 쿠키 주입 공격의 기회를 제공합니다. 이러한 서버는 새로운 쿠키의 시작을 적절히 구분하지 못하여 공격자가 쿠키를 스푸핑할 수 있게 합니다: +(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) 서버가 쿠키를 잘못 파싱하는 경우, 특히 Undertow, Zope 및 Python의 `http.cookie.SimpleCookie`와 `http.cookie.BaseCookie`를 사용하는 경우 쿠키 주입 공격의 기회를 제공합니다. 이러한 서버는 새로운 쿠키의 시작을 제대로 구분하지 못해 공격자가 쿠키를 스푸핑할 수 있게 합니다: - Undertow는 세미콜론 없이 인용된 값 바로 뒤에 새로운 쿠키가 올 것으로 기대합니다. - Zope는 다음 쿠키를 파싱하기 위해 쉼표를 찾습니다. @@ -185,7 +185,7 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; #### WAF 우회 -[**이 블로그 포스트**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)에 따르면, **`$Version=1`** 쿠키 속성을 사용하여 백엔드가 **RFC2109**로 인해 쿠키를 파싱하는 오래된 로직을 사용할 수 있을 가능성이 있습니다. 또한 **`$Domain`** 및 **`$Path`**와 같은 다른 값을 사용하여 쿠키와 함께 백엔드의 동작을 수정할 수 있습니다. +[**이 블로그 포스트**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)에 따르면, **`$Version=1`** 쿠키 속성을 사용하여 백엔드가 **RFC2109**로 인해 쿠키를 파싱하는 오래된 로직을 사용할 수 있을 가능성이 있습니다. 또한 **`$Domain`** 및 **`$Path`**와 같은 다른 값들도 쿠키와 함께 백엔드의 동작을 수정하는 데 사용될 수 있습니다. #### 쿠키 샌드위치 공격 @@ -193,7 +193,7 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; - 응답에 명백히 쓸모없는 **쿠키가 반영되는 위치를 찾습니다.** - **값이 `1`인 `$Version`이라는 쿠키를 생성합니다** (JS에서 XSS 공격을 통해 이 작업을 수행할 수 있습니다) 더 구체적인 경로를 설정하여 초기 위치를 차지하게 합니다 (Python과 같은 일부 프레임워크는 이 단계를 필요로 하지 않습니다). -- **반영되는 쿠키를 생성**하고 **열린 큰따옴표**를 남기는 값을 설정하며, 이전 쿠키(`$Version`) 뒤에 위치하도록 특정 경로를 설정합니다. +- **반영되는 쿠키를 생성**하고, **열린 큰따옴표**를 남기는 값을 설정하며, 이전 쿠키(`$Version`) 뒤에 위치하도록 특정 경로를 설정합니다. - 그러면 정당한 쿠키가 순서상 다음에 오게 됩니다. - **큰따옴표를 닫는 더미 쿠키를 생성**하여 그 값 안에 포함시킵니다. @@ -219,11 +219,11 @@ document.cookie = `param2=end";`; #### 쿠키 이름 차단 목록 우회 -RFC2109에서는 **쉼표가 쿠키 값 사이의 구분자로 사용될 수 있다고 명시되어 있습니다**. 또한 **등호 앞뒤에 공백과 탭을 추가하는 것이 가능합니다**. 따라서 `$Version=1; foo=bar, abc = qux`와 같은 쿠키는 `"foo":"bar, admin = qux"`라는 쿠키를 생성하지 않고, `foo":"bar"`와 `"admin":"qux"`라는 쿠키를 생성합니다. 두 개의 쿠키가 생성되고 admin의 등호 앞뒤 공백이 제거된 것을 주목하세요. +RFC2109에서는 **쉼표가 쿠키 값 사이의 구분자로 사용될 수 있다고 명시되어 있습니다**. 또한 **등호 앞뒤에 공백과 탭을 추가하는 것이 가능합니다**. 따라서 `$Version=1; foo=bar, abc = qux`와 같은 쿠키는 `"foo":"bar, admin = qux"`라는 쿠키를 생성하지 않고, `foo":"bar"`와 `"admin":"qux"`라는 쿠키를 생성합니다. 두 개의 쿠키가 생성되는 방식과 admin이 등호 앞뒤의 공백을 제거한 방식을 주목하세요. #### 쿠키 분할을 통한 값 분석 우회 -마지막으로, 서로 다른 백도어는 서로 다른 쿠키 헤더에서 전달된 서로 다른 쿠키를 문자열로 결합할 수 있습니다: +마지막으로, 서로 다른 쿠키 헤더에서 전달된 서로 다른 쿠키를 문자열로 결합하는 다양한 백도어가 있을 수 있습니다: ``` GET / HTTP/1.1 Host: example.com @@ -237,19 +237,19 @@ Cookie: comment') Resulting cookie: name=eval('test//, comment') => allowed ``` -### Extra Vulnerable Cookies Checks +### 추가 취약한 쿠키 검사 -#### **Basic checks** +#### **기본 검사** -- **쿠키**는 매번 **로그인**할 때 **같습니다**. -- 로그아웃하고 같은 쿠키를 사용해 보세요. -- 두 개의 장치(또는 브라우저)로 같은 계정에 같은 쿠키로 로그인해 보세요. +- **로그인**할 때마다 **쿠키**가 **같은**지 확인합니다. +- 로그아웃하고 동일한 쿠키를 사용해 보세요. +- 두 개의 장치(또는 브라우저)로 동일한 계정에 동일한 쿠키로 로그인해 보세요. - 쿠키에 정보가 있는지 확인하고 수정해 보세요. -- 거의 같은 사용자 이름으로 여러 계정을 생성해 보고 유사성을 확인하세요. +- 거의 동일한 사용자 이름으로 여러 계정을 생성하고 유사성을 확인해 보세요. - "**기억하기**" 옵션이 존재하는지 확인하고 어떻게 작동하는지 살펴보세요. 존재하고 취약할 수 있다면, 다른 쿠키 없이 항상 **기억하기** 쿠키를 사용하세요. - 비밀번호를 변경한 후에도 이전 쿠키가 작동하는지 확인하세요. -#### **Advanced cookies attacks** +#### **고급 쿠키 공격** 로그인할 때 쿠키가 동일하게 유지되거나 거의 동일하다면, 이는 쿠키가 귀하의 계정의 일부 필드(아마도 사용자 이름)와 관련이 있음을 의미합니다. 그러면 다음을 시도할 수 있습니다: @@ -257,7 +257,7 @@ Resulting cookie: name=eval('test//, comment') => allowed - **사용자 이름을 브루트포스**해 보세요. 쿠키가 사용자 이름에 대한 인증 방법으로만 저장된다면, 사용자 이름 "**Bmin**"으로 계정을 생성하고 쿠키의 모든 **비트**를 **브루트포스**할 수 있습니다. 왜냐하면 시도할 쿠키 중 하나는 "**admin**"에 속하는 쿠키일 것이기 때문입니다. - **패딩** **오라클**을 시도해 보세요(쿠키의 내용을 복호화할 수 있습니다). **패드버스터**를 사용하세요. -**Padding Oracle - Padbuster examples** +**패딩 오라클 - 패드버스터 예제** ```bash padbuster # When cookies and regular Base64 @@ -275,7 +275,7 @@ Padbuster는 여러 번 시도하며 어떤 조건이 오류 조건인지(유효 ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` -이 실행은 문자열 **user=administrator**가 포함된 쿠키를 올바르게 암호화하고 인코딩합니다. +이 실행은 **user=administrator** 문자열이 포함된 쿠키를 올바르게 암호화하고 인코딩하여 제공합니다. **CBC-MAC** @@ -298,7 +298,7 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB 예를 들어 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"라는 사용자를 생성하고 쿠키에서 패턴이 있는지 확인합니다(ECB는 동일한 키로 모든 블록을 암호화하므로 사용자 이름이 암호화되면 동일한 암호화된 바이트가 나타날 수 있습니다). -사용된 블록의 크기로 패턴이 있어야 합니다. 따라서 "a"의 암호화된 묶음이 어떻게 되는지 알면 사용자 이름을 생성할 수 있습니다: "a"\*(블록 크기)+"admin". 그런 다음 쿠키에서 "a" 블록의 암호화된 패턴을 삭제할 수 있습니다. 그러면 사용자 이름 "admin"의 쿠키를 얻게 됩니다. +사용된 블록의 크기로 패턴이 있어야 합니다. 따라서 "a"의 암호화된 묶음을 알고 있으면 사용자 이름을 "a"*(블록 크기)+"admin"으로 만들 수 있습니다. 그런 다음 쿠키에서 "a" 블록의 암호화된 패턴을 삭제할 수 있습니다. 그러면 사용자 이름 "admin"의 쿠키를 얻게 됩니다. ## References