shikata ga nai

Private? There is no such things.

How I found Cross-Site-Scripting (Reflected) on more than 300 systems!を訳してみた

Hello there, ('ω')ノ

 

300以上のシステムでクロスサイトスクリプティング(反映)を見つけた方法を。

 

脆弱性:

 反映されたXSS

 

記事:

 https://mrsinister1501.medium.com/how-i-found-cross-site-scripting-reflected-on-more-than-300-systems-81d8118d9de5

 

Shodan Dorkingを実行して、いくつかの興味深いターゲットを見つけだして。

下記のShodanクエリを使用:

 org:target http.html:"Login" port:443 -http.title:"Error,Forbidden,403"

 

結果には、企業に「管理パネル」を提供するサービスで。

ドメインにアクセスすると、下記の管理パネルのログインページが読み込まれて。

 

f:id:ThisIsOne:20210809161108p:plain

 

それから、いくつかの脆弱性をテストしたものの何も機能せず。

下記のツールでの結果を確認しても何も得られず。

 https://github.com/ffuf/ffuf

 

f:id:ThisIsOne:20210809160922p:plain

 

ただ、/pleaseworkに入ると404エラーページが。

そこで、誰もが考えるであろうXSSを考えて。

 

f:id:ThisIsOne:20210809161253p:plain

 

下記をテストしたところ、HTMLインジェクションは正常に機能して。

 <s>strikethrough?</s>

 

次に、基本的な下記のXSSペイロードを試したもののWAFは導入されていて。

 <script>alert(1)</script>

f:id:ThisIsOne:20210809161324p:plain

 

なので、WAFをバイパスしてXSSを実行するペイロードの構築を開始すると。

多くのヒットと試行の結果、下記のタグが付いたペイロードは。

リクエストをブロックすると結論付けて。

 <a>
 <script>
 <body>
 <audio>
 <image>
 <img>
 <style>
 <iframe>
 “javascript”
 <animate>

 

リクエストで送信された場合に多くのイベントハンドラがブロックされて。

しかし、<div>タグはXSSの取得にも使用できることを思い出して。

<div>タグ付きのペイロードを使用すると、ブロックされず。

ただ、ペイロード内の他の文字がブロックされたため、XSSは実行されず。

そのため、<div>タグを使用してペイロードを作成する必要があって。

そこで、下記のPortSwiggerは非常に便利で。

 

XSSチートシート

 https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

 

f:id:ThisIsOne:20210809161928p:plain

 

XSS:HTMLサニタイズフィルタを打ち負かす

 https://portswigger.net/support/xss-beating-html-sanitizing-filters

 

f:id:ThisIsOne:20210809162011p:plain

 

<div>タグで機能させるために、さまざまなイベントハンドラを試して。

ついに下記のペイロードで、XSSが機能して。

 <div onpointerover=”alert(‘XSS POC by mrsinister15’)”>Please put your mouse on me to see the magic ;)</div>

 

ただし、このペイロードはユーザとの対話が必要になる可能性が低くなって。

ユーザがテキストにマウスを合わせると、XSSが起動するももの。

 

<div>を<html>に置き換えた場合は。

被害者がページのどこかにマウスを置くとXSSが起動するため。

ユーザの操作がはるかに少なくて。

 

さらに下記の2つのペイロードは、ユーザの操作は必要なくて。

 <svg id=x tabindex=1 onload=alert(1)></svg>

 

下記のペイロードを使用すると、ページが読み込まれたときにXSSが起動して。

下記が最良のペイロードで。

 <svg/onload=alert(1)>

 

#自分でXSSを見つけるためのヒントとコツ :

・XSSをテストするときは、常にまれな単語を使用することから始めて。

  例-pleasework123(ソースコードでそれの反映を見つけるのは簡単で)

 

・いくつかのオープンソースツールを使用して、反射の検索を自動化できて。

 ただし、反射を見つけるのに役立つものの別途手動で行う必要があって。

 例-https://github.com/mikey96/reflection-public

 

f:id:ThisIsOne:20210809170839p:plain


・XSSをテストするときに、<>がフィルタリングされていない場合は。

 WAFが設定されている必要があって。

 ブロックされていないさまざまなタグとイベントハンドラを使用して。

 WAFはバイパスでて。

 

・ペイロードをコピーして貼り付けるだけでは、ほとんど何も見つからず。

 

・何かが反映されていることがわかった場合は、「レアワード」で。

 いくつかの特殊文字を入力フィールドに追加してソースコードで応答を確認して。

 例-「pleasework123」が反映されている場合は。

 「pleasework123」「> <」を試して。

 応答でそれらのいずれかがフィルタリングされているかどうかを確認して。

 フィルタリングされていない場合は。

 WAF(存在する場合)をバイパスすることで、XSSを取得できる可能性があって。

 

・<>がフィルタリングされている場合は、希望を高く保つことはできず。

 入力が引用符または二重引用符で囲まれているタグから脱出することもできて。

 ターゲットが入力をURLエンコードする場合は。

 入力を二重URLエンコードすることもできて。

 ペイロードを二重URLエンコードする場合は。

 ターゲットがそれらをデコードして、ペイロードが機能する可能性があって。

 

・ターゲットが入力(<、>)をエンコードするHTMLで。

 ソースコードで「<」が&lt;として反映されている場合は。

 「>」は、&gt;のように反映されるので。

 下記のようなペイロードをだとXSSが機能する可能性があって。

  &lt;script&gt;alert(1)&lt;/script&gt;

 

・常にすべての入力フィールドをテストして、反射のソースコードを表示して。

 また、すべての入力フィールドに(XSSHunter)ペイロードを入力して。

 ブラインドXSSをテストする必要があって。

 特に、連絡先情報を求められた場合やフォームへの入力を求められた場合は。

 XSSHunterはブラインドXSSを見つける傾向にあるので、試してみてください。

  https://xsshunter.com/

 

f:id:ThisIsOne:20210809171638p:plain

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain