web-dev-qa-db-ja.com

XSSを使用するハッキングチャレンジを作成する方法

セキュリティ会議はしばしばハッキングの課題を抱えています。私の同僚と私は number を作成しました。クロスサイトスクリプティングの脆弱性を含む脆弱性はまだ作成していません。

私はこれを行う課題を見てきました。 1つのアプローチは、特定のページ（保存されたXSSに対して脆弱）がブラウザーによって定期的に（10秒ごとに）要求されたことでした。攻撃が成功した後、ペイロードはそのブラウザで実行され、課題はCookieを抽出することでした。

このアプローチの1つの問題は、複数の人が同時に課題に取り組んでいる場合、それらが互いに干渉し、他の人のアイデアを盗むことができることです。別のアイデアは、リフレクティブXSSと、サイトへのリンクを送信できるページを用意することでした。このページは、管理者が公開する前に確認します。

ブラウザーを開いたままにしておく時間は興味深い選択です。しばらく開いたまま（60秒程度）であれば、人々はBeEFのようなツールを使用できるため、少し簡単になります。 2秒間しか開いていない場合は、攻撃をスクリプト化する必要があります。

チャレンジが実際にうまく機能するかどうかに影響を与える多くの詳細があります。私は、XSSハッキングの課題を実行した経験のある人からの回答を望みます。しかし、それに失敗すると、私は情報に基づいた推測に落ち着きます。

それが役に立てば、英国の技術会議に出席する傾向があります。 B-Sidesマンチェスター、SteelCon、SecuriTay。

また、JavaScriptの悪用からブラウザーを防御するためのヒントがあれば歓迎します！

xssctfconference
15
paj28

私が見た最も一般的なアプローチは、送信システムを通じて脆弱なリンクを取得する headless browser ボットを実行することです。次に、これらのリンクのそれぞれに、マジッククッキーを設定して数秒間アクセスします。

例は、記事「 XSS対応ボットをCTFに追加する方法 」にあります。ボットはヘッドレス PhantomJS インスタンスとして実装されています。同様に、 hackxor game は HtmlUnit を使用してブラウジングの犠牲者をシミュレートし、 this XSSチャレンジ は Zombie.js のインスタンスを使用します=。

確かに、保存されたXSSを回避するいくつかの理由があります。プレイヤーが他のメソッドについて学び、最終的にそのペイロードを妨害するだけでなく、リダイレクトや無限ループによって他のユーザーを煩わしくし始め、すべてのクリーンアップで忙しくなってしまう可能性があります。

代わりに、プレーヤーがリンクを提供してボットがアクセスできる単純な送信システムを備えた、反映されたXSSの脆弱性をお勧めします。シナリオに応じて、送信はお問い合わせフォーム、単純なソケットリスナー、 a private IRC message 、または必要に応じて、受信メールからのリンクが抽出されてアクセスされるメールアカウント。

手動による操作が必要なシステムは絶対に避けます。そうしないと、ペイロードがすでに実行されているかどうか、再度アクセスできるかどうかなど、人々は絶えず質問します。プレイヤーの攻撃性に応じて、送信をレート制限する方法も検討する必要があります。 （お問い合わせフォームのCAPTCHAはシナリオによく適合します。）

15
Arminius

個々のコンテナ環境で、競技者間の対立を分離することをお勧めします。

例： https://www.onehourctf.com でSANSの1時間のCTFを確認してください– 1時間のCtFは、DockerとGuacamoleを使用して、迅速な共有学習環境を提供します。ワカモレは、Dockerコンテナーに視覚的な（VNC/RDP/SSH）インターフェイスを提供します。

クロスサイトスクリプティングの脆弱性を教えるための簡単な方法として、カスタムコードを使用した、教育を受けた攻撃のシミュレーションを検討することができます。攻撃者から見ればそれは合法ですが、バックエンドは視覚的な結果をシミュレートします。

3
Kamic

CTFを開発する体系的なアプローチで絞り込むのは明らかに素晴らしいことです。これは、同様の攻撃ベクトルを含むナレッジリポジトリを介して行うことができます。

たとえば、CTFの-code injectionsに焦点を当てるつもりです-code injection攻撃に関連するバリアントは、クライアント側のスクリプトの悪用に完全に関連しています。それを絞り込むには、悪用されている主要成分機能を使用します。この特定のケースでは、主にJavaScriptとJS Enginesが脆弱です。したがって、チームはこの発言に関する情報を照合できるはずです JS Vuln DB CVEを取得できます+開始するPOCです！

さらに別のシナリオを考えてみましょう。たとえば、「ファイルインクルード」ベクター向けのCTFを作成するとします。例は[〜＃〜] lfi [〜＃〜]、[〜＃〜] rfi [〜＃〜]、[〜＃〜] ssi [〜＃〜]など。 cve-search によって提供されるAPIを使用できます。さらに、すべてのCVEをダウンマップして、より簡単にします。

ブルーチームの場合は、安全な環境での実行を一元化し、さらに分離することがアイデアです。第二に、多分、オリジナルをひねった後に微調整またはバッファ追加のコンテキストベースの悪用がうまくいくかもしれないことを提案します。そこから始めます。 Cookieのアイデアが盗まれる最初の問題は、さまざまな並列サンドボックスを使用して簡単に修正できることです。このような設定をしているプロバイダーはあると思います。チェックアウト CTF365 。

1
Shritam Bhowmick

サーバーが特定のURLにアクセスすることだけが必要な場合は、ボットやスレッドをスピンアップするのではなく、最も簡単な解決策は、（URLが送信されたらすぐに）ライブラリを使用してURLにアクセスすることです（リクエストのように） pythonの場合）レスポンスも解析できます。管理者または他のボットが実際に自分のブラウザでアクセスしたかのように。

更新：

次に、（要求に応じて）より詳細な説明を示します。ユーザー入力（この場合はURLなど）を受け取ったらすぐに、次の関数に渡します。

def simulate_admin_visits(url):
try:
    #initialise with empty cookies
    jar = requests.cookies.RequestsCookieJar()
    #visit the page that allows the admin to login 
    #and collect the cookies from the response
    response = requests.post(LOGIN_URL, data={'uname': ADMIN_UNAME, 'password': ADMIN_PASSWORD}, cookies=jar)
    jar.update(response.cookies)
    #visit the user-submitted content using the just-collected cookies
    #here the exploit/ctf_challenge-solution is allowed to work
    <parse the submitted content>
    #have the admin logout
    requests.get(LOGOUT_URL, cookies=jar)
except ConnectionError:
    print 'Could not connect to ' + url
0
iammyr