Lompat ke konten
dokumentasi.id
Commit 0a16c9d
v2
Star6,9 rb

Kamu membaca versi lama. Halaman ini hanya bisa dibaca.

10

Teknik Bypass Kontrol

Folder Bypass/ berisi empat catatan yang membahas satu tema yang sama: sebuah kontrol menolak request, lalu dicari representasi request lain yang masih sampai ke handler yang sama. Kontrol yang dibahas adalah Two-Factor Authentication, filter 403, rate limit 429, dan Captcha. Catatan-catatan itu ditulis sebagai daftar percobaan singkat, tanpa penjelasan panjang, sehingga halaman ini menyusun ulang daftarnya menjadi pohon keputusan berdasarkan respons awal server.

Mekanisme otentikasi dan token tidak diulang di sini; uraiannya ada di Otentikasi, Sesi, dan Token. Varian 403 yang memakai cache juga bersinggungan dengan Web Cache dan Denial of Service.

Pohon keputusan pemilihan teknik

Pemilihan teknik berangkat dari status code dan isi respons pertama, bukan dari daftar alat. Respons 403 mengarah ke manipulasi path atau header, respons 429 ke pemalsuan identitas klien, halaman dengan captcha ke perubahan bentuk request, dan halaman form 2FA ke manipulasi isi respons.

graph TD
  A["Request ditolak kontrol"] --> B{"Apa respons awal?"}
  B -->|"403 Forbidden"| C{"Path masih bisa diubah?"}
  C -->|"ya"| C1["%2e , ; , ..;/ , aDmIN"]
  C -->|"tidak"| C2["Header X-Original-URL"]
  B -->|"429 Too Many Requests"| D["Palsukan identitas klien"]
  D --> D1["X-Forwarded-For : 127.0.0.1"]
  D --> D2["Cookie atau User-Agent baru"]
  B -->|"200 dengan captcha"| E["Ubah bentuk request"]
  E --> E1["POST jadi GET"]
  E --> E2["Kosongkan _RequestVerificationToken"]
  E --> E3["Pakai ulang token lama"]
  B -->|"200 dengan form 2FA"| F["Ubah isi respons"]
  F --> F1["code false jadi code true"]
  F --> F2["404 jadi 200"]
  style A fill:#dc2626,color:#fff
  style B fill:#f59e0b,color:#000
  style D fill:#f59e0b,color:#000
  style E fill:#f59e0b,color:#000
  style F fill:#dc2626,color:#fff
  style C1 fill:#2d7d46,color:#fff
  style C2 fill:#2d7d46,color:#fff
  style D1 fill:#2d7d46,color:#fff
  style D2 fill:#2d7d46,color:#fff
  style E1 fill:#2d7d46,color:#fff
  style E2 fill:#2d7d46,color:#fff
  style E3 fill:#2d7d46,color:#fff
  style F1 fill:#dc2626,color:#fff
  style F2 fill:#dc2626,color:#fff
%% fig: Pohon keputusan bypass berdasarkan respons awal
%% desc: Status code pertama menentukan keluarga teknik, dari manipulasi path untuk 403 sampai manipulasi isi respons untuk form 2FA.
Fig. 1: Pohon keputusan bypass berdasarkan respons awalStatus code pertama menentukan keluarga teknik, dari manipulasi path untuk 403 sampai manipulasi isi respons untuk form 2FA.

Permukaan manipulasi yang dipakai berulang

Keempat catatan tidak menyerang logika kontrolnya, melainkan bentuk request yang dibaca kontrol itu. Ada empat permukaan yang muncul lagi dan lagi, dan sebagian besar teknik di bawah hanya kombinasi dari keempatnya.

graph LR
  S["Permukaan request"] --> P["Path dan URL"]
  S --> H["Header"]
  S --> Bd["Body dan parameter"]
  S --> M["Method"]
  P --> P1["%2e , ; , ..;/"]
  H --> H1["X-Original-URL"]
  H --> H2["X-Forwarded-For , X-Client-IP"]
  Bd --> B1["%00 , spasi di akhir nilai"]
  Bd --> B2["token lama , code=null"]
  M --> M1["POST jadi GET"]
  style S fill:#f59e0b,color:#000
  style P1 fill:#2d7d46,color:#fff
  style H1 fill:#2d7d46,color:#fff
  style H2 fill:#2d7d46,color:#fff
  style B1 fill:#2d7d46,color:#fff
  style B2 fill:#8b5cf6,color:#fff
  style M1 fill:#2d7d46,color:#fff
%% fig: Empat permukaan manipulasi request
%% desc: Path, header, body, dan method adalah empat tempat yang sama-sama dipakai untuk melewati 2FA, 403, 429, dan captcha.
Fig. 2: Empat permukaan manipulasi requestPath, header, body, dan method adalah empat tempat yang sama-sama dipakai untuk melewati 2FA, 403, 429, dan captcha.
PermukaanContoh konkret di catatanCatatan asal
Path dan URL/%2e/admin, /admin..;/, /aDmINBypass/Bypass 403.md:15-22
HeaderX-Original-URL: /adminBypass/Bypass 403.md:3-13
HeaderX-Forwarded-For : 127.0.0.1Bypass/Bypass 429.md:3-20
Body dan parameter[email protected]%00Bypass/Bypass 429.md:22-29
Body dan parameter_RequestVerificationToken=OLD_CAPTCHA_TOKENBypass/Bypass Captcha.md:28-35
MethodPOST / diubah menjadi GET /?...Bypass/Bypass Captcha.md:3-17

Bypass Two-Factor Authentication

Catatan 2FA memuat teknik yang paling ringan sentuhan ke server. Yang pertama adalah manipulasi isi respons: body {"code": false} diganti menjadi {"code": true} sementara status code dibiarkan 404 Not Found Bypass/Bypass 2FA.md:3-16. Varian kedua hanya mengganti status code menjadi 200 OK tanpa menyentuh body Bypass/Bypass 2FA.md:18-31.

Keluarga teknikContoh dari catatanPrasyarat
Manipulasi isi respons{"code": true} menggantikan {"code": false}klien mempercayai body Bypass/Bypass 2FA.md:3-16
Manipulasi status code404 Not Found menjadi 200 OKklien mempercayai status code Bypass/Bypass 2FA.md:18-31
Kebocoran kode di responsbody {"email": "[email protected]", "code": "101010"}POST /req-2fa/ mengembalikan kode Bypass/Bypass 2FA.md:33-47
Validasi integritas hilangkode akun penyerang dipakai untuk akun korbanPOST /2fa/ menerima [email protected]&code=382923 Bypass/Bypass 2FA.md:53-65
Nilai khususcode=00000 dan code=nullpenanganan nilai kosong di server Bypass/Bypass 2FA.md:77-91

Kebocoran kode terjadi karena endpoint POST /req-2fa/ mengirim balik {"email": "[email protected]", "code": "101010"} ke pemanggil Bypass/Bypass 2FA.md:33-47. Pada kasus integritas, kode yang dibuat untuk akun penyerang tetap diterima saat dipasangkan dengan email korban, sehingga tidak ada ikatan antara kode dan akun Bypass/Bypass 2FA.md:53-65.

Sisanya adalah cacat alur, bukan cacat parser: 2FA tidak dicek ulang saat password atau email diubah, 2FA yang baru diaktifkan tidak mengakhiri sesi lama, dan kode yang sama bisa dipakai ulang Bypass/Bypass 2FA.md:67-75. Dua nilai penutup yang dicoba adalah code=00000 dan code=null Bypass/Bypass 2FA.md:77-91.

⚠️ Manipulasi isi respons hanya membuktikan kelemahan di sisi klien. Klaim kerentanan butuh bukti bahwa server menerima request yang seharusnya ditolak, bukan hanya bahwa tampilan aplikasi berubah.

Melewati 403 lewat manipulasi path dan header

Keluarga pertama memindahkan path yang diblokir ke header: request dikirim ke /anything, lalu X-Original-URL: /admin membawa path sebenarnya Bypass/Bypass 403.md:3-13. Keluarga kedua menyisipkan karakter yang membuat proxy dan aplikasi menyimpulkan path berbeda.

Bentuk yang diblokirBentuk bypassYang diubah
/admin/%2e/admin%2e setelah slash pertama Bypass/Bypass 403.md:15-22
/admin/secret/., //secret//, /./secret/..titik dan slash ganda Bypass/Bypass 403.md:24-36
/admin/;/secret, /.;/secret, //;//secretsemicolon sebagai pemisah Bypass/Bypass 403.md:24-36
/admin/admin..;/tambahan ..;/ setelah nama direktori Bypass/Bypass 403.md:38-45
/admin/aDmINkapitalisasi huruf Bypass/Bypass 403.md:48-55

Varian terakhir memakai X-Original-URL lewat Web Cache Poisoning, dengan Host: victim.com Bypass/Bypass 403.md:57-62. Penulis repo juga menyediakan alat terpisah untuk mengulang percobaan ini secara otomatis, yaitu bypass-403 Bypass/Bypass 403.md:64-65.

Mengakali rate limit 429

Rate limit biasanya dihitung dari identitas klien yang ditebak server dari header. Enam header dipalsukan sekaligus dalam satu daftar: X-Forwarded-For, X-Forwarded-Host, X-Client-IP, X-Remote-IP, X-Remote-Addr, dan X-Host, semuanya diset 127.0.0.1 Bypass/Bypass 429.md:3-20.

PermukaanContoh dari catatan
Header identitasX-Forwarded-For : 127.0.0.1 pada POST /ForgotPass.php Bypass/Bypass 429.md:3-20
Nilai parameter[email protected]%00, juga %09, %0d, %0a Bypass/Bypass 429.md:22-29
Cookie dan User-AgentCookie: xxxxxxxxxx diganti Cookie: aaaaaaaaaaaaa Bypass/Bypass 429.md:31-48
PathPOST /ForgotPass.php?random Bypass/Bypass 429.md:50-65
Nilai JSON{"email":"[email protected] "} dengan spasi di akhir Bypass/Bypass 429.md:67-82

⚠️ Contoh di catatan memakai [email protected] sebagai sasaran. Uji rate limit hanya pada akun milik sendiri dan di dalam scope Bypass/Bypass 429.md:3-20.

Menembus Captcha

Catatan captcha menyasar validasi _RequestVerificationToken pada Google reCAPTCHA. Urutan percobaannya berjalan dari perubahan method sampai perubahan karakter token.

PerubahanContoh konkret
MethodPOST / diubah menjadi GET /?_RequestVerificationToken=...&_Username=daffa&_Password=test123 Bypass/Bypass Captcha.md:3-17
Nilai dikosongkan_RequestVerificationToken=&_Username=daffa&_Password=test123 Bypass/Bypass Captcha.md:19-26
Token dipakai ulang_RequestVerificationToken=OLD_CAPTCHA_TOKEN Bypass/Bypass Captcha.md:28-35
Bentuk bodyJSON {"_RequestVerificationToken":"xxxxxxxxxxxxxx",...} diubah menjadi form parameter Bypass/Bypass Captcha.md:37-52
Header IPX-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr diset 127.0.0.1 Bypass/Bypass Captcha.md:54-60
Karakter tokenxxxxxxxxxxxxxx diubah menjadi xxxdxxxaxxcxxx Bypass/Bypass Captcha.md:62-77

Perhatikan bahwa token yang diubah sebagian tetap dikirim bersama _Username dan _Password yang sama, jadi yang diuji adalah apakah server membandingkan token apa adanya atau hanya memeriksa polanya Bypass/Bypass Captcha.md:62-77. Mengubah JSON menjadi form parameter juga menjaga isi tetap sama sambil mengganti jalur parsing Bypass/Bypass Captcha.md:37-52.