Hello there, ('ω')ノ
これまで、実例をもとに学んだ脆弱性診断につかえる実践的なテクニックは以下のとおりで。
・サブドメインの1つに403を返すエンドポイントがある場合は、通常のバイパスは機能しないので、Refererヘッダを変更すると200 OKが取得できる場合があります。
・エンドポイントのディレクトリとリクエストボディを削除して、メソッドを「PUT」から「GET」に変更すると隠されたエンドポイントに関する情報を取得できる場合があります。
・見つけたエンドポイントに通常アカウントで403エラーが発生した際、管理者アカウントのjsonリクエストの本文と比較して差分のパラメータを追加するとアクセスできる場合があります。
・Linux環境でコマンドを実行する際、スペース文字をバイパスするためのペイロードは以下のとおりです。
cat</etc/passwd
{cat,/etc/passwd}
cat$IFS/etc/passwd
cat${IFS}/etc/passwd
・WEBアプリケーションでSQLインジェクションを見つけるには、下記のペイロードを全てのパラメータに挿入します。
0"XOR(if(now()=sysdate(),sleep(12),0))XOR”Z
・パスワードリセットなどで、csrfの保護が実装されてなくて、認証トークンとリセットのキーとなる電子メール等がリンクされていないときは、アカウントを乗っ取れる場合があります。
・X-Frame-Optionsが欠落しているときは、サブドメインがクリックジャッキングに対して脆弱であることを意味しているので、iframeを使用して任意のサイトに埋め込むことができる場合があります。
・null値のインジェクションを試すポイントは以下のとおりです。
１．csrfトークンが渡されてそれをバイパスする場合
２．ログインにワンタイムパスワードが必要な場合
３．2FAが必要な場合
・tokenのパラメータ値をnullに変更するだけで、ログインに成功する場合があります。
・SSRF攻撃を軽減する良い方法は、アプリケーションがアクセスする必要のあるIPアドレスやDNS名をホワイトリストに登録します。
・データベースクエリを実行していると思われるすべてのリクエストを確認して、手動テストとファジングを使用してSQLインジェクションを確認します。
・機密情報のあるエンドポイントにアクセスしてリダイレクトされる際は、Cookieヘッダの情報を使用すると閲覧できる場合があります。
・SetCookiesヘッダにトークンが含まれている際には、2つのアカウントで変化を比較すると一部分を変えることでなりすますことができる場合があります。
・ディレクトリトラバーサルがブロックされる際、Base64でエンコードされたペイロードだと機能する場合があります。
・XSSは、すべての入力フィールドでテストして、結果のソースコードを表示して確認します。
・ターゲットが入力（<、>）をエンコードするHTMLでソースコードで「<」が＆lt;として反映されている場合は、下記のようなペイロードをだとXSSが機能する場合があります。
<script>alert(1)</script>
・ターゲットが入力をURLエンコードする場合は、入力をダブルURLエンコードすることもできるので、ペイロードを二重URLエンコードするとターゲットがそれらをデコードして、ペイロードが機能する場合があります。
・XSSをテストするときに、<>がフィルタリングされていない場合は、さまざまなタグとイベントハンドラを使用してWAFはバイパスできる場合がありますが、単にペイロードをコピーして貼り付けるだけでは、ほとんど何も見つかりません。
・<div>タグはXSSの取得にも使用できるので、WAFをバイパスできる場合があります。
・ディレクトリにブルートフォース攻撃して、応答403 Forbiddenを受け取った際は、表示やアクセスを望まない非表示のコンテンツ/セクションが確実に存在します。
・応答に404 Not Foundが表示されている場合は、そのWebサイトに何かが隠されている可能性があることを意味しているので、ディレクトリをブルートフォースして列挙します。
・ステータスコード403 Foriddenエラーが発生するときは、URLの末尾に「.css」を追加すると403をバイパスしてアクセスできる場合があります。
・アップロード時に画像のexifタグをサニタイズしていなかったらXSSが発生する場合があります。
・アプリケーションが、alert, promptをブロックしている際、それらの大文字だと許可してXSSのペイロードを実行する場合があります。
・パスワード変更ページのCSRFトークンをnull指定するとパスワードを変更できる場合があります。
・パスワード変更機能で、適当に現在のパスワードを入力してから新しいパスワードを入力して、リクエストで現在のパスワードパラメータを削除してもユーザのパスワードを変更できる場合があります。
・一般的なXSSペイロードを試すとXML形式を壊すので、XML構造を壊さないように特殊文字<を＆lt;にエンコードして挿入すると機能する場合があります。
・リクエストのバラメータの最後に下記のようなパラメータを追加するとペイロードが機能する場合があります。
&Set-Cookie: <script>alert(1)</script>
・ワンタイムパスワードは、適当な数字を入れてリクエストして、HTTP応答コードと応答本文を成功したものに変更すると認証機能をバイパスする場合があります。
・メールアドレスとワンタイムパスワードの関係がゆるいことがありますので、自分の受け取ったワンタイムパスワードを他人のメールアドレスと組み合わせてログインできる場合があります。
・リクエストでヘッダを削除してサーバにリクエストを送信して、レスポンスがエラーなしの200 OKが得られたらサーバは、このヘッダを検証してない場合があります。
・16進数でエンコードされているメールアドレスのパラメータ値にXSSペイロードを挿入する際は、ペイロードも16進数にエンコードする必要がある場合があります。
・「email」のパラメータ値をbase64、md5、その他の一般的な暗号化方法でデコードしても何も見つからず、値にAからFと0から9桁しかないときには16進数でデコードすると確認できる場合があります。
・WAFが「javascript」や「alert」の機密性の高いキーワードをMarkdownで解析していてる際は、Unicodeエンコーディングを使用するとペイロードを実行できる場合があります。
・管理者がアカウントを削除してログインできないときは、ログインのリクエストに対してのエラーレスポンスの中身を正常時の内容に置き換えるとログインできる場合があります。
・ファイルのアップロードでファイル拡張子をクライアント側とサーバ側で確認している際は、リクエストでファイルの中身をプログラムに書き換えてアップロードした後に、そのファイルの拡張子の変更ができればペイロードを実行できる場合があります。
・readonly=というパラメータを見つけたら削除することでデータを更新できる場合があります。
・APIで自分のメールアドレス以外に他のメールアドレスが見つかった際、そのメールアドレスをつかってAPIをリクエストすると機密情報を得られる場合があります。
・Burp SuiteのParam Minerで隠されたパラメータを見つけて、インジェクションを試すと機能する場合があります。
・セッションキャッシュによるレート制限は、Accept-Languageのq=の重みをIntruderで変化させれば、バイパスできる場合があります。
・大量のメールが発生する可能性があれば、ユーザへの電子メール爆撃はビジネスへに悪影響を及ぼすことになる場合があります。
・レート制限のアルゴリズムは、セッションキャッシュ内の情報に基づいてユーザセッション（またはIPアドレス）を制限する必要があるかどうかを確認したりしています。
・「X-Forward-For: 127.0.0.1」ヘッダが設定されている場合は、応答サーバは、内部IPによってアクセスされていると見なして、ユーザが制限されたコンテンツにアクセスできるようにしていたりします。
・レート制限は、IPベースで実装されていることもありますので、クライアントIP、またはアップストリームサーバに提示されるIPを変更すると、OTPブルートフォースのレート制限をバイパスできる場合があります。
・非表示フィールドを表示させてデータを確認すると重要なデータを発見できる場合があります。
・Burp Suiteは、Optionタブの[Response Modification]セクションで、非表示のフォームフィールドを再表示したり、入力フィールドの制限を削除したり、JavaScriptフォームの検証を削除したりできます。
・OPTIONSメソッドをGETに変更すると予想外の情報を得ることができる場合があります。
・WEBアプリケーションでデータの変更時にPOSTリクエストを確認して、変更したデータ以外で、メールアドレス等のパラメータがあれば、それを書き換えると乗っ取れる場合があります。
・XSSの検証でブロックされているようであれば、
alert,prompt ⇨ 403 Forbidden
ale rt, pro mpt ⇨ 200 OK
aler<<h1>>rt ⇨ 200 OK
のような流れで、さらに応答を確認します。
・XSSを検証するには、
“,’,<,>
を入力したり
alert、prompt、<script>
などを入力してウェブサイトの応答を確認してから次のアクションを考えます。
・パラメータをBase64等でデコードしてXMLだったらXXEのペイロードを挿入した後にエンコードして送信します。
・URLの一部に数値のID値がある際には、そのパスのみをBurp SuiteのIntruderでブルートフォースして200の応答が得られると他人の情報閲覧できる場合があります。
・IDORを見つける簡単な方法は、Burp SuiteのHTTP履歴を使用して、ユーザIDを持つすべてのリクエストを検索してオプションから[Match and Replace]を使用して、最初のアカウントのユーザIDを２番目のアカウントのユーザIDに変更して、200 OKの応答が返されるかどうかを確認します。
・２つのJWTの違いを比較するとIDのみが異なる際、ユーザのアカウント番号だったりしますので、IDを変更すると他人になりすますことができる場合があります。
・XSSで括弧を使用しない手段としてthrowメソッドがあって、onerrorイベントハンドラを悪用するテクニックがあります。
javascript:window.onerror=alert;throw 1
・XSSで、alert(1)の括弧に問題があるときは、「alert`1`」で括弧をバイパスできる場合があります。
・コマンドインジェクションのテストで、パイプ演算子を使用してうまくいかないときは、ヌルバイト文字を使用してバイパスできる場合があります。
・コマンドインジェクションをテストするための一般的なパラメータです。
/?query=
/?email=
/?id=
/?username=
/?user=
/?to=
/?from=
/?search=
/?query=
/?q=
/?s=
/?shopId=
/?blogId=
/?phone=
/?mode=
/?next=
/?firstname=
/?lastname=
/?locale=
/?cmd=
/?sys=
/?system=
・リクエストのJSON本文にある各オブジェクトに対してSQLインジェクションのペイロードを挿入すると機能する場合があります。
・パスワードリセットリンクのエンドポイントがランダムな10桁のコードで構成されているように見えても実際には3桁のみが異なるだけのときもあってブルートフォースで有効なコードを見つけ出せる場合があります。
・Originヘッダが許可しているサブドメインでXSSの脆弱性を見つけることができたらCORSの設定ミスを悪用できる場合があります。
・CORSの設定は、HTTPリクエストのOriginヘッダを操作してサーバのレスポンスを調べてドメインのホワイトリストチェックをします。
・Bcryptで暗号化された値を復号化することでパスワードを取得できる場合があります。
・エンドポイントがユーザID等の検索キーワードに使われるパラメータと同じようであれば一重引用符（ ‘）などのSQLインジェクションのペイロードを追加してリロードすると機能する場合があります。
・WEBアプリケーションで、AuthorizationヘッダがBase64を使用していたら復号化するとIDやメールアドレスが含まれていることがあり他人になりすませる場合があります。
・パスワードリセットをリクエストする際のトークンを使って、他人のパスワードを変更できる場合があります。
・脆弱なエンドポイントとパラメータが見つかってもメールID、またはUUID主キーがわからなければ大丈夫と思われている方もおられますが、Google Dorksで取得できる場合があります。
・WEBアプリケーションが、HTTPSプロトコルをフィルタリングしたり、ホストとIPアドレスをフィルタリングしてリダイレクトをブロックしているときは、IPを整数IPに変換するとバイパスできる場合があります。
・リダイレクトパラメータには、
?return=
?returnURI=
?forwardedTo=
?redirect=
?redirectURI=
?url=
?forward=
のようなものが使われている場合があります。
・有料と無料のコンテンツがある際には両方のエンドポイントを比較して異なる箇所を変更すると有料のコンテンツが見れる場合があります。
・レート制限があるときにX-Forwarded-For: 127.0.0.1と変更するとローカルホストからのテストとみなされ
X-RateLimit-Limit:が増加する設定になっている場合があります。
・管理者パネルのサブドメインにアクセスして403エラーがでたらプロトコルをhttpからhttpsに変更するとアクセスできる場合があります。
・jwtトークンをデコードして、ユーザIDを変更すると不正アクセスできる場合があります。
・adminというエンドポイントにリクエストして403エラーの際には、Hostヘッダを変更してリクエストを送信するとサーバがその要求を検証せずに管理パネルのログインページを開く場合があります。
・WEBアプリケーションで、通貨パラメータを変更してリクエストを送信すると表示上は変更されなくても価格は変更されている場合があります。
・アプリケーションの入力フィールドに😯を入力するとSQLコードのエラーが発生する場合があります。
・WEBアプリケーションの中には、トークンと別のパラメータの長さのみを検証していて完全なトークンを検証していないものもあります。
・同形異義語の作成に使用される類似文字のhomogliyphを使って「Tommy」を「Tömmy」で上書き登録して乗っ取ることができる場合があります。
・apiが、乱数に基づいてユーザの詳細を表示している際には、乱数を変更すると他のユーザの詳細が表示される場合があります。
・間違ったOTPを入力して、そのレスポンスに200 OKのレスポンスをコピーして、貼り付けて転送するとバイパスできる場合があります。
・メールアドレスの変更などで、リクエストパラメータのuserIdを変更するとなりすますことができたりしますが、このパラメータは高いエントロピーで推測できないようであれば、Google Dorksで検索すると発見できる場合があります。
・データを追加して表示されるページは、サーバがページ全体をロードするのに時間がかかるのでBurp SuiteでIntruderを使って連続して追加するリクエストを送信するとサーバに遅延が発生する場合があります。
・パスワードが自動的にリセットされてメールを送信するページでレート制限がなければ、Burp SuiteのIntruderで頻繁にリクエストを送信するとパスワードが毎秒変更されて、ユーザはまったくログインできなくなる場合があります。
・支払いページにて、HTMLソースコードで数量の（-）ボタンの「無効（disabled）」属性を削除して（-）ボタンで、追加したものを削除してリクエストを送信すると前ページで追加したものの料金をバイパスできる場合があります。
・WEBアプリケーションで製品を購入する際にリクエストパラメータの価格設定を変更するとそのままペイメントゲートウェイに送られて、この金額で購入できる場合があります。
・WEBアプリケーションで割り当てるリクエストパラメータのIDですが、プロファイルのソースコードで確認できる場合があります。
・tokenパラメータを列挙すると使われている英数字が数個に限られている場合がありますので、レート制限がなければブルートフォースできることがあります。
・アカウント作成やパスワードリセット等でIDNホモグラフ攻撃を使って、例えばメールアドレス@gmailを@gmáilに置き換えるとアカウントを乗っ取ることができる場合があります。
・トークンを生成するAPIエンドポイントを見つけて、トークンを別のユーザのものと入れ替えるとなりすますことができる場合があります。
・リクエストパラメータが、サブドメインを作成しているようであれば、バラメータの後ろに「?」を追加するとリダイレクトされる場合があります。
・apiキーをBase64でデコードすると機密情報を確認できる場合があります。
・掲示板で投稿するリクエストパラメータにユーザIDらしきものがあれば、それを別のユーザのものに置き換えるとなりすまして投稿できる場合があります。
・メールフィールドは、@が必要だったりもしますので、下記のようにペイロードを送信するとXSSが機能する場合があります。
“<svg/onload=alert(1)>”@x.y
・パスワード再作成するリンクをメールで受け取る際、リンク先でパスワードを入力したリクエストの中にメールアドレスのパラメータがあれば、それを変更してすると他のユーザのパスワードを変更できる場合があります。
・WEBアプリケーションで何らか追加数の制限があるときは、Burp SuiteのIntruderでスレッドの数を増やしてサーバへのリクエスト送信を高速化すると制限数を超えて登録できる場合があります。
・ワンタイムパスワードは、レート制限がない場合はブルートフォースで検証します。
・CSRF保護をバイパスするには、anti_csrfパラメータを削除して、GETメソッドに変更してリクエストすると成功する場合があります。
・XSSで、<img src=x>が機能するもののブロックされるときは、xをURLに置き換えてスクリプトを指定すると実行できる場合があります。
・XSSで、javascript:alert('XSS')がブロックされているときは、全てを16進エンコードすると、フィルタをバイパスできる場合があります。
・XSSで、alert()がブロックされているときは、代わりにprompt()を使用してフィルタをバイパスできる場合があります。
・ファイルアップロードで拡張子jpg以外をブロックされているときは、ファイル名のあとに％00.jpgを追加するとパスできる場合があります。
・php等のファイルをアップロードする際にサーバサイドの検証をエスケープするためにWebシェルのコードの先頭にに「GIF98」を追加すると成功する場合があります。
・リダイレクトパラメータが解読できないときは、パラメータ値な=を追加してBase64でデコードすると読めてフォーマットが理解できる場合があります。
・任意のワンタイムパスワード送信してレスポンスの結果を200に変更して、エラーに関するメッセージを削除するとログインできる場合があります。
・自分に関係ない識別子IDを変更してリクエストを送信すると404エラーを返すべきですが、200が表示されて認証なしでパスすることがあります。
・パスワードリセット機能でメールにパスワードリセットリンクを送るリクエストで、別のHostヘッダを追加すると悪意のあるドメインにトークン付きのリンクが送られる場合があります。
・WEBアプリケーションでリクエスト内のすべてのパラメータを微調整しているとトークンがクライアント側で生成される場合がありますので、解読することができたりします。
・パスワードをテストするときは、メールアドレスの@の前に+1と+2を追加すると追加していない実際のメールアドレスに届くので、この追加した２つのエイリアスを使用して、リセットトークンのどのビットが異なるかを確認します。
・Originヘッダにサブドメインを指定して、Access-Control-Allow-Originがレスポンスで確認できたらサブドメインに悪用できるXSS等の脆弱性がないかを確認します。
・２要素認証のあるWEBアプリケーションで、ワンタイムパスワードを送るリクエストパラメータ内の認証コードに関連するパラメータを削除するとワンタイムパスワードなしで認証が通る場合があります。
・WEBアプリケーションで、ブロックされたアカウントのパスワードリセットトークンを有効なアカウントのパスワードリクエストでアカウントトークンを置き換えると、ブロックされたアカウントのパスワードのリセットが成功する場合があります。
・ワンタイムパスワードで正しいものと不正なもののレスポンスコードを比較して、不正なもののレスポンスコードを正しいものに変更するとワンタイムパスワードをバイパスできる場合があります。
・WEBアプリケーションでワンタイムパスワードを入力して送信するページのソースコードを確認すると数値を確認できるようなコーティングがされていたりします。
・XSSの可能性は、ペイロードに使用する<script>、<frame、<input、<form、<img、<svg>等のタグがブロックされないかを試してスタートします。
・XSSペイロードをBase64にエンコードするとWAFをバイパスてきる場合があります。
・WAFがSQLのキーワードを含むクエリをブロックするようであればエンコードして一部を16進にすればバイパスできる場合があります。
・WEBアプリケーションのリクエストパラメータをクエリ文字列からJSONに変更して送信するとWAFをバイパスできる場合があります。
・WEBアプリケーションで入力した文字がリクエスト後にページに反映される場合はHTMLインジェクションできる可能性があります。
・WEBアプリケーションでパスワードを忘れた際に自分にリンクの通知がくる機能をもっていたらリクエストのX-Forwarded-HostとReferrerを追加して両方に同じ悪意のあるサイトを指定するとそちらへ通知が行く場合があります。
・WEBアプリケーションの登録機能で、例えばトルコ語の文字「ı」（ドットのない「i」）を使用して既存のメールアドレスやIDを登録すると違うものとみなされますが、その後ラテン語の「i」に変換されて乗っ取ることができたりします。
・ペイロードを挿入する際にスペースをスラッシュ（/）に変更するとフィルタリングされなかったりしますので機能したりします。
・Wordpressのサイトでwp-configバックアップファイルを見つけて確認するとIDとパスワードが書かれている場合があります。
・WEBアプリケーションのパスワード変更のリクエストのパラメータにメールアドレスと現在のパスワードと新しいパスワードが含まれているとメールアドレスを変更してアカウントを乗っ取れる場合があります。
・WEBアプリケーションの情報更新ページで変更が無効となっている項目はブラウザの開発ツールでHTML内の値を変更して更新すると変更できる場合があります。
・WEBアプリケーションのパスワードリセットでメールに送られてくるリンク先に付加されているトークンが誰もが共通の場合がありますので、トークン情報さえわかればなりすまして他人のパスワードを変更できたりします。
・WEBアプリケーションでユーザの削除機能がある場合、パラメータにuser_idのようなものがあるとパラメータ値を変更すると一般ユーザが管理者まで削除できる場合があります。
・WEBアプリケーションのパスワードリセットページでメールアドレスを入力してリクエストする際にHostヘッダを変更すると変更したサイトへトークンを付加して漏らす場合があります。
・WEBアプリケーションのパスワードリセットで新しいパスワード入力ページにtwitter、facebook、linkedinなどのサードパーティへのリンクが含まれていると、それらのリンク先にもトークンが漏れている場合があります。
・WEBアプリケーションのトークンにはタイムスタンプが使われているかを確認します。もし使われていたらそれ以外の情報がユーザごとに何が違うかを確認すると仕組みがわかることがあります。ユーザ情報は全てにおいて一文字だけが異なるようにすると見つけやすいです。
・WEBアプリケーションが自分の送信元を確認するような動きをしている場合は、リクエストヘッダX-Forwarded-Forを追加してレスポンスを確認します。
・WEBアプリケーションのリクエストパラメータでidやroleという名前があったら役割別にユーザを作成して違いを確認してパラメータ値を変更しています。
・WEBアプリケーションのリクエストで送信される各パラメータを削除してレスポンスを確認すると予期せぬ動作を起こす可能性があります。例えばトークン関係なくアクセスできないページが表示されたり、認証が通ったりと。
・WEBアプリケーションのリクエストでBase64でエンコードされているパラメータを見つけたら必ずデコードします。重要なパラメータが存在していたりします。
Best regards, (^^ゞ