DOM XSS in document.write sink using source location.search inside a select elementの考え方について詳しく書いてみて

Hello there, ('ω')ノ

PortSwiggerのWEBアカデミーにはソリューションがあるのですが

それだけでは、なかなか理解できないところもあるかと。

脆弱性を見つけ出すにはWEBの仕組みを理解することろからはじまって。

一つのアクションについて丁寧にリクエストを確認したりと。

まずは、View detailsを。

該当するリクエストとパラメータを確認しておいて。

次にCheck stockを。

ここでもエンドポイントとパラメータを。

ページを再描画するリクエストは送信されていないようなので。

在庫数は、JavaScriptで処理されていると考えて。

ソースコードを確認して、該当箇所を読んでいると。

下記の処理のところでstoreIdパラメータを渡すと受け取って処理してくれそうで。

　var store = (new URLSearchParams(window.location.search)).get('storeId');

GETメソッドなので、URLに下記のパラメータを追加してみると。

　&storeId=test

狙い通りにプルダウンメニューに反映され。

そこで、コントールできるパラメータがアウトプットできることがわかったので。

XSSの検証に入ることに。

該当するリクエストを確認して、このリクエストのStoreIdパラメータに

XSSのペイロードを入れて検証していくわけで。

Best regards, (^^ゞ

オリジナルGPTsをつくってみた

Hello there, ('ω')ノ

オリジナルGPTsをGPT Storeへ。

https://gptstore.ai/gpts/3krj5K3r_7-advanced-web-app-defense-practical-test-strategies

GPT Plusの有料会員の方は、使えるようになっていて。

このGPTでは、ペネトレーションテスト方法や脆弱性についての解説が含まれていて。

他にKali LinuxやMetasploit、Androidについても。

今後は、他のAIと差別化するためにファインチューニングをしていく予定で。

Best regards, (^^ゞ

Android HTML Injection in Email Abused for $$$を訳してみた

Hello there, ('ω')ノ

電子メールへの Android HTML インジェクションが $$$ のために悪用されるを。

脆弱性：

　HTML インジェクション

記事：

　https://cyberweapons.medium.com/android-html-injection-in-email-7db6b1ba7df1

Androidアプリケーションを探しているときにこのバグを発見し。

単純に、メール内で実行される任意のユーザ入力フィールドに

HTML タグを挿入してみることができて。 

今回は電子メールへの Android HTML インジェクションについて。

これは、攻撃者が他のユーザが閲覧する Web ページに HTML コードを

挿入することを可能にするセキュリティ上の脆弱性で。

個人的には、Web アプリよりも Android アプリで狩りをするのが好きで。

なぜなら、ほとんどの場合、Android、特に Bug-Crowd や Hacker-One で

小さなバグを見つけた場合、多額の報奨金が得られるからで。

また、小さなバグの重大度は Web アプリよりも大きな影響を及ぼし。

さらに、追加のスキルセットと理解を必要とするため、

業界では Android テスターの数も非常に少なくなり。

サインアップ後にアプリにログインし、プロフィールページに行き。

そこで名前を更新するオプションがあり。

ここで SSTI ペイロードを入力しようとしましたが、うまくいかず。

SSTI ペイロードが注入され

次に、ハイパーリンクの挿入を試し、忘れたページに戻ってメールを送信しました。うまくいきました。素晴らしいです。!

ハイパーリンクインジェクション

しかし、その影響は低く、ユーザを騙すにはユーザとの対話や

ソーシャル エンジニアリングが必要となるため、企業はほとんどの場合

ハイパーリンク インジェクションを考慮しておらず。

次に、ハイパーリンクの代わりに、HTML の下線タグ ( <u>Hacker</u>) を挿入し、

パスワードを忘れた場合に電子メールを送信するとインジェクションに成功して。

メールに挿入される下線タグ

ほとんどの場合、テスターはここで停止し。

ただし、影響を示すためにさらにタグを挿入しようとし。

次に、ボタンタグを挿入して。

これも成功して。

Best regards, (^^ゞ

Finally received first bounty from Starbucks for subdomain takeoverを訳してみた

Hello there, ('ω')ノ

ついにスターバックスからサブドメイン乗っ取りで初の報奨金を受け取りましたを。

脆弱性：

　サブドメイン乗っ取り

記事：

　https://medium.com/@jeetpal2007/finally-received-first-bounty-from-starbucks-for-subdomain-takeover-5dbb46d56180

どうやって見つけたか。

それを見つけるには何らかのツールが必要で。

ツール：

　Subfinder

　https://github.com/projectdiscovery/subfinder

　Subzy

　https://github.com/PentestPad/subzy/

実行コマンドを使用するには

手順:

　Subfinder

　subfinder -d example.com -v -o example_subdomain.txt

     -d : ドメイン名を定義
     -v : 詳細な結果
     -o : 出力ファイル

　Subzy

　Subzy run --targets example_subdomain.txt --hide_fails

    --targets : サブドメインのファイルを定義
    --hide_fails : 脆弱なサブドメインのみを表示

スキャンが完了すると、結果が得られ、

サブドメインは acquia 乗っ取りに対して脆弱で。

サブドメインが Acquia を指していることがわかるので、

Acquia アカウントが必要ですが、最初に Via がサブドメインを

調べていることを確認し。

Web サイトが見つからず脆弱で。

nslookupでも確認できて。

$ nslookup example.subdomain.com
http://example.subdomain.com [404 Not Found] Country[UNITED STATES][US],
 HTML-Comments[ Acquia sсripts look for the following keyword to confirm the initial site install: ACQUIA_DEFAULT_HTML_INSTALLED ],
 HTTPServer[nginx], IP[xx.xxx.xxx.xxx], Title[Web Site Not Found], UncommonHeaders[x-cache-hits], Via-Proxy[varnish], nginx

それで、Acquia でデモアカウントを作成してみて。

https://www.acquia.com/products/acquia-cloud-platform

Acquia でサブドメインのドキュメントを使用してサブドメインを作成した後、

サブドメインの乗っ取りに成功して。

https://docs.acquia.com/site-factory/manage/preferences/site-owner/

Best regards, (^^ゞ

Server Side Template Injection-Something Distinct!を訳してみた

Hello there, ('ω')ノ

サーバサイドテンプレートインジェクション - 何か違う!を。

脆弱性：

　SSTI

記事：

　https://sagarsajeev.medium.com/server-side-template-injection-something-distinct-f0ac234e379

これは、SSTI (サーバー サイド テンプレート インジェクション) に関する最近の

発見の 1 つについての記事で。

Portswiggerによると、サーバサイド テンプレート インジェクションとは、

攻撃者がネイティブ テンプレート構文を使用して悪意のあるペイロードを

テンプレートに挿入し、サーバサイドで実行できることを指し。

テンプレート エンジンを使用すると、アプリケーションで

静的テンプレート ファイルを使用できて。

つまり、基本的には、テンプレート エンジンに何か (ペイロード) を挿入し、

それがサーバ側で実行される方法で。

これは場合によっては RCE につながる可能性があり。

SSTI のバグはどうやって見つけたか？

１．target.com には簡単なサインアップ/登録アカウント ページがあり。

２． [名前]フィールドに「{{7*7}}」と入力し。

３．ページの残りの部分を適宜埋めていき。

　ペイロードは「名前」フィールドにのみ入力する必要があることに注意して。

４．新しいユーザにメールで挨拶し、メールの確認を求めるのは、

　Web アプリケーションの通常の意図された動作で。

５．主な内容は次のとおりです。メールの件名は次のとおりで。

参考サンプル画像

では、どうやって49 という名前になったのか?

・これは、ペイロード {{7*7}} がテンプレート エンジンによって実行され、

　バックエンド サーバに渡されたためで。

・ほとんどの場合、成功した SSTI は RCE にエスカレーションでき。

　ただし、各ペイロードはそのケースに固有であるため、

　特定のペイロードを一般化することはできず。

・{{system(‘whoami’)}} ⇨ これは RCE を証明できるペイロードの 1 つで。

　ただし、このペイロードが実行される可能性は非常に低くて。

試してみたいペイロードをさらにいくつか紹介を。

１．{{7*'7'}}

２．#{ 5* 8 }

３． ,@(5+5)

４．さらに多くの SSTI ペイロードをオンラインで見つけることができ。

　ただし、そのペイロードを自分で変更して調整してみて。

　そうすることで実行される可能性が高まるはずで。

Best regards, (^^ゞ