Shikata Ga Nai

Private? There is no such things.

How I was able to takeover any users account on a major telecoms websiteを訳してみた

Hello there, ('ω')ノ

 

主要なテレコムのWebサイトでユーザーアカウントを乗っ取ることができた方法を。

 

脆弱性:

 XSS

 

記事:

 https://medium.com/@tobydavenn/how-i-was-able-to-takeover-any-users-account-on-a-major-telecoms-website-2cd5aa43e3d6

 

今回は、アフリカの主要な通信プロバイダのWebサイトで見つけた。

同じ脆弱性の複数のインスタンスに関するもので。

 

このドメインを探しているときに、テレコムプロバイダの顧客が。

顧客として獲得したバウチャー/ポイント、および追加の有料製品を含む。

アイテムを購入できるサブドメインを見つけて。

 

テスト中に、ユーザ入力の大部分がページに反映されていることに気付いて。

これは、潜在的に反映されたXSSを示しているため興味深いもので。

送信されたすべてのリクエストは、GETリクエストで。

XSSペイロードを挿入すると、これらはブロックされ、ページに反映されず。

URLエンコードなど、いくつかのWAFバイパスペイロードが試行されましたが。

うまくいかず。

 

POSTリクエストで同じリクエストを送信するとどうなりますか。

入力したものは、はまだ反映されているので。

最初の攻撃ベクトルであるCookieに。

POSTリクエストに変更しXSSをリクエストすると。

ウェブページは、URLエンコードを使用することに対して脆弱で。

 

%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert%28document.domain%29%3E

"><img src=x onerror=alert(document.domain)>

 

 

 

Cookieを削除し、これをPOSTパラメータとして本文に配置するとどうなるか。

それでも反映されたので、これはもはやXSSではなく。

これはPOSTベースのリクエストであるため。

これを被害者に送信するにはどうすればよいか。

 

サイトは同じオリジンを使用しておらず。

XSS攻撃をCSRFペイロードに組み込み、この自動送信を行い。

被害者をページに送信し、XSS攻撃を使用してCookieを盗むことができて。

(既に認証されている場合)

 

HTTP Onlyが設定されていないため、Cookieを盗むことは可能で。

 

 

さらに調べてみると、投稿ベースのURLエンコードされたXSSに対しても。

脆弱な追加の4つのパラメータが明らかになって。

 

 

 

 

Best regards, (^^ゞ