Hello there, ('ω')ノ
300以上のシステムでクロスサイトスクリプティング（反映）を見つけた方法を。
脆弱性：
反射されたXSS
記事：
いくつかのShodan Dorkingを実行して、いくつかの興味深いターゲットを見つけて。
下記のShodanクエリを使用：
org:target http.html:"Login" port:443 -http.title:"Error,Forbidden,403"
すると、企業に「管理パネル」を提供するサービスがあったので。
ドメインにアクセスすると、ログインページ／管理パネルが読み込まれて。
いくつかの脆弱性をテストしても、何も機能せず。
下記の結果を確認しても何も得られず。
次に、/pleaseworkへアクセスすると404エラーページに反映されてたので。
誰もが考えるであろうXSSを思いついて。
<s></s>の取り消し線でテストするとHTMLインジェクションは正常に機能したので。
次に、基本的なXSSペイロードを試するとWAFは導入されていて。
<script>alert(1)</script>
次に、WAFをバイパスしてXSSを実行するペイロードの構築を開始することに。
下記のタグを持つペイロードはリクエストをブロックされて。
<a>
<script>
<body>
<audio>
<image>
<img>
<style>
<iframe>
“javascript”
<animate>
また、リクエストで送信すると多くのイベントハンドラーがブロックされて。
しかし、<div>タグはXSSの取得にも使用できることを思い出したので。
<div>タグ付きのペイロードを使用するとブロックされず。
ただ、ペイロード内の他の文字がブロックされたためXSSは実行されず。
そのため、<div>タグを使用してペイロードを作成する必要があって。
下記は、非常に便利で。
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
https://portswigger.net/support/xss-beating-html-sanitizing-filters
<div>タグで機能させるために、さまざまなイベントハンドラを試して。
WAFをいじってブロックされた後、実際に機能するペイロードを思いついて。
<div onpointerover=”alert(‘XSS POC by mrsinister15’)”>Please put your mouse on me to see the magic ;)</div>
すると、XSSは機能して。
ただ、このペイロードをはユーザとの対話が必要になる可能性が低くて。
ユーザがテキスト上にマウスを置いてXSSが起動するので。
しばらくして、より良いペイロードのアイデアを思いついたので。
<div>を<html>に置き換えた場合、被害者がページのどこかにマウスを置くと。
XSSが起動するため、ユーザの操作がはるかに少なくて済んで。
さらに下記の２つのペイロードは、ユーザ操作は必要でなく。
これらのペイロードは次のとおりで。
<svg id=x tabindex=1 onload=alert(1)></svg>
このペイロードを使用すると、ページが読み込まれたときにXSSが起動するので。
代替の最良のペイロードは次のとおりで。
<svg/onload=alert(1)>
見つけたXSSはサードパーティのサービスにあり、システムにはなかったので。
「third-party service」を使用しているすべてのWebサイトは。
前述したペイロードを使用したXSSに対して脆弱であることに気付いたので。
Shodanでサービスとそのバージョンを探すと。
300を超える結果が得られ、そのうちのいくつかでペイロードをテストすると。
すべて同じペイロードで同じエンドポイントのXSSに対して脆弱で。
どうやら、それは内部ネットワークへの管理パネルのようで。
自分でXSSを見つけるためのヒントとコツ ：
・XSSをテストするときは、常にまれな単語を使用することから始めて。
例）pleasework123
・オープンソースツールを使用して、リフレクションの検索を自動化して。
・ただし、XSSを見つけて投げるだけのツールはないので。
反射を見つけるのに役立つものの手動で行う必要があって。
・XSSをテストするときに、<>がフィルタリングされていない場合は。
WAFが設定されていたりするので、ほとんどの場合は。
ブロックされていないさまざまなタグとさまざまなイベントハンドラを使用して。
WAFをバイパスできて。
・ペイロードをコピーして貼り付けるだけでは、ほとんど何も見つからず。
・何かが反映されていることがわかった場合は。
「レアな単語」とともにいくつかの特殊文字を入力フィールドに追加して。
ソースコードで応答を確認して。
例）「pleasework123」が反映されている場合は、「pleasework123 ‘ “ ><」を。
試して応答でいずれかがフィルタリングされているかどうかを確認して。
フィルタリングされていない場合は、WAF（存在する場合）を。
バイパスすることで、なんとかしてXSSを取得できる可能性があって。
・<>がフィルタリングされている場合、希望を高く保つことはできず。
入力が引用符または二重引用符で囲まれているタグから脱出することもできて。
ターゲットが入力をURLエンコードする場合は。
入力を二重URLエンコードすることもできて。
ペイロードを二重URLエンコードする場合は、ターゲットがそれらをデコードして。
ペイロードが機能する可能性があって。
・ターゲットが入力（<、>）をエンコードするHTMLで。
ソースコードで「<」が＆lt;として反映されている場合は。
「>」は、「＆gt;」のように反映されて。
次に、これらの反射からペイロードを作成してみることができて。
例）「<」と「>」のHTMLエンコードされた結果を使用して。
次のようなペイロードを形成してみると
「<script>alert(1)</script>」
運が良ければ、デコードされてXSSが機能する可能性があって。
・ XSSは非常に一般的な脆弱性ではありますが、簡単すぎるという意味ではなくて。
・常にすべての入力フィールドをテストし、反射のソースコードを表示して。
・すべての入力フィールドに（XSSHunter）ペイロードを入力して。
ブラインドXSSをテストする必要があって。
特に連絡先情報を求められた場合やフォームへの入力を求められた場合は。
XSSHunterは、ブラインドXSSを見つける傾向にあるので試すように。
Best regards, (^^ゞ
