実験2CSFRの脆弱性、安全でないCAPTCHAの脆弱性、ファイルインクルード

1.実験の目的

1.csrfの脆弱性の定義と原則を理解します
。2。生徒にcsrfの脆弱性と防御方法の使用を習得させます。
3.安全でないCAPTCHA脆弱性の定義と原則を理解します。
4.学生が安全でないCAPTCHAエクスプロイトと防御方法を習得できるようにする。
5.ファイルに抜け穴の定義と原則が含まれていることを理解します。6。
ファイルに抜け穴の悪用と防御方法が含まれていることを生徒に習得させます。

2.実験環境DVWA実験プラットフォーム、phpエディターなど。

3.実験の内容と手順：

1. XSSストレージの脆弱性、低、中、高レベルのコード分析。
2.抜け穴を悪用して、ポップアップを表示します。
3.安全でないCAPTCHAの脆弱性、低、中、高レベルのコード分析。
4.抜け穴を悪用して、ポップアップを表示します。
5.ファイルには、脆弱性の低、中、高レベルのコード分析が含まれています。
6.サーバー情報を取得します。

4.実験プロセス：

（1）CSFRの脆弱性

1.1。保存されているCSRFとは何ですか？CSRFのフルネームはクロスサイトリクエストフォージェリです。これはクロスサイトリクエストフォージェリとして中国語に翻訳されています。まだ有効期限が切れていない被害者のID認証情報（Cookie、セッションなど）を使用して、悪意のあるリンクをクリックしたり、攻撃コードを含むページにアクセスしたりします。被害者の知らないうちに、被害者のIDを使用して（ ID認証情報）対応）サーバーは不正な操作を完了するための要求を送信します。エンドユーザーは、現在のWebアプリケーションで、少量のソーシャルエンジニアリング（電子メールチャットを介したリンクの送信など）による認証を支援する不要なアクションを実行する必要があります。攻撃者は、Webアプリケーションのユーザーに、攻撃者が選択したアクションを実行するように強制する可能性があります。ターゲットエンドユーザーが管理者アカウントである場合、CSRF攻撃が成功すると、エンドユーザーのデータと操作が危険にさらされ、Webアプリケーション全体が危険にさらされる可能性があります。Webアプリケーションは、ユーザーがアカウントパスワードの変更、アカウントの追加、送金などの機密操作を実行するときに、httpリクエストヘッダーのフォームトークンとリファラー値をチェックするなどの防御手段を講じないため、悪意のある攻撃者が悪用される可能性があります。機密性の高い操作を実行する人のID。

CSRF攻撃プロセスは次のとおりです。攻撃者はCSRFの脆弱性を発見します-悪意のあるコードを構築します-被害者に送信します-被害者は開きます-被害者はコードを実行します-攻撃を完了します

2.この実験で使用したツール：Firefox、Firefox用のハックバープラグイン。

3.実験の難易度は低いです。DVWAプラットフォームにログインし、低レベルおよびCSRFモジュールを選択します。このページは非常に一般的なパスワード変更ページであり、元のパスワードを確認するために必要なのは新しいパスワードのみです。コードでは、 $pass_newと$ 二つの変数の後に $E$ $W$ $と$ pass_conf、それらはmysql_real_escape_stringの（）関数を用いてフィルタリングされる。SQLインジェクションを防止することができるが、それはCSRF攻撃を防ぐことはできない。次に、これらの2つの変数が直接データベース更新動作を実行するためのUPDATEステートメントに置換されています。。次に、最初に通常のユーザーの方法でパスワードを変更します。たとえば、ここではパスワードを123に変更します。以下に示すパスワード変更は、パスワードが正常に変更されたことを示しています。同時に、この時点でHackBarを使用してURLを分析したところ、このURLに入力したパラメーターがすべてURLに含まれていることがわかりました。直接変更できるかどうかを推測しますURLのパラメータでパスワードを変更できるので、新しいURLを作成します：http：//127.0.0.1/DVWA-1.9/vulnerabilities/csrf/？password_new = 12345＆password_conf = 12345＆Change = Change＃とブラウザでこのURLを新しいインターフェイスで開くと、パスワードも変更されていることがわかります。ここでは、CSRF脆弱性攻撃を実装しました。もちろん、ここで作成したURLはあまりにも明白なので、まとめることができます。たとえば、ここではCSRF.phpファイルを作成しますが、内容はより単純で類似している可能性があります。<img src="http://127.0.0.1/DVWA-1.9/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#"/>次に、それをPhpStudyのWWWディレクトリに配置し、同じブラウザで127.0.0.1 / CSRF.htmlを開いたところ、この画像が表示されましたが、DVWAに再ログインすると、パスワードは実際に変更されました。次に、低レベルのコードを見てみましょう。<？php if（isset（$ _GET ['Change']））{//入力を取得$ pass_new = $ _GET ['password_new']; $ pass_conf = $ _GET ['password_conf' ]; //パスワードは一致しますか？if（$ pass_new == $ pass_conf）{//一致します！$ pass_new = mysql_real_escape_string（$ pass_new）; $ pass_new = md5（$ pass_new）; //データベースを更新します$ insert = "UPDATE` users` SET password = '$ pass_new' WHERE user = '"。DvwaCurrentUser（）。 "';"; $ result = mysql_query（$ insert）またはdie（ '

'。mysql_error（）。'

'）; //ユーザーへのフィードバックecho "

パスワード変更済み。

";} else {// echoに一致するパスワードの問題"

パスワードが間違っています。

";} mysql_close（）;}？>ここでは、入力された2つのパスワードが同じであるかどうかのみを判断し、防御は行いません。したがって、Cookieがまだ有効である間に、ユーザーが同じブラウザで特定のブラウザにアクセスするだけで済みます。 URLが攻撃される可能性があります。

3.3。難易度中レベル。最初にパスワードを以前のパスワードパスワードに戻し、次にブラウザを開く前に構築したWebサイト127.0.0.1 / CSRF.htmlを開いてから、DVWAに再ログインすると、パスワードが123456に変更されていることがわかりました。明らかに、私たちの攻撃は成功しました。中レベルのコード分析を見て、低レベルと比較してどのように改善されているかを見てみましょう。

<？php if（isset（$ _GET ['Change']））{//リクエストの送信元を確認if（eregi（$ _SERVER ['SERVER_NAME']、$ _SERVER ['HTTP_REFERER']））{/ /入力を取得$ pass_new = $ _GET ['password_new']; $ pass_conf = $ _GET ['password_conf']; //パスワードは一致していますか？if（$ pass_new == $ pass_conf）{//そうです！$ pass_new = mysql_real_escape_string（$ pass_new）; $ pass_new = md5（$ pass_new）; //データベースを更新します$ insert = "UPDATE` users` SET password = '$ pass_new' WHERE user = '"。dvwaCurrentUser（）。"';"; $ result = mysql_query（$ insert）またはdie（ '

'。mysql_error（）。'

'）; //ユーザーへのフィードバックecho "

パスワード変更済み。

";} else {// echoに一致するパスワードの問題"

パスワードが間違っています。

";}} else {//信頼できるソースからのものではありませんecho"

そのリクエストは正しく見えませんでした。

";} mysql_close（）;}？>

$passnewとpass_new$ を取得するには、ここを参照してください。 $p a s s_{n個} 電子ワット和$ これら2つの変数をpass_confする前に、まずifステートメントを使用して、「$ _ SERVER ['HTTP_REFERER']」の値が127.0.0.1であるかどうかを判別します。これは、CSRF攻撃から防御するための基本的な方法です。HTTPリファラーフィールドを確認します。ここでは、eregi（）関数を使用してHTTPリファラーを判断していることがわかりました。作成したWebサイトはこのマシン上にあるため、リファラーにはDVWAプラットフォームのホスト番号が含まれています。また、Webサイトをバイパスします。たとえば、構築されたファイルの名前を相手のホスト名に変更できます。たとえば、XXXXhtmlは、以前の方法を再度使用してCSRF攻撃を実装できますが、それがなくなっていることがわかります。動作します。この防御方法の原理を以下に説明します。HTTPプロトコルによると、HTTPヘッダーにはRefererというフィールドがあり、HTTPリクエストの送信元アドレスを記録します。たとえば、Burpsuiteによってインターセプトされた次のデータパケットでは、データの送信先のページはupfile_Other.aspであり、リファラーフィールドの後にあるページhttp://192.168.80.131/upload_Other.aspからリクエストを開始しました。通常の状況では、安全な制限付きページへのアクセス要求は同じWebサイトから行う必要があります。たとえば、http：//bank.example/withdraw？account = bob＆amount = 1000000＆for = Mallorにアクセスするには、ユーザーは最初に銀行にログインする必要があります。 .exampleをクリックし、ページのボタンをクリックして転送イベントをトリガーします。このとき、転送リクエストのリファラー値は、転送ボタンが配置されているページのURLになります。通常は、bank.exampleドメイン名で始まるアドレスです。***が銀行のWebサイトにCSRF攻撃を実装したい場合、彼は自分のWebサイトでのみリクエストを作成できます。ユーザーが攻撃者のWebサイトを介して銀行にリクエストを送信すると、リクエストのリファラーは攻撃者自身を指します。ウェブサイト。したがって、CSRF攻撃から防御するために、銀行のWebサイトは、銀行の場合、各転送要求のリファラー値を確認するだけで済みます。例の冒頭のドメイン名は、リクエストが銀行のWebサイト自体からのものであり、正当であることを示しています。リファラーが別のWebサイトである場合、攻撃者によるCSRF攻撃である可能性があり、リクエストを拒否します。DVWAでは、管理者はローカルアドレス127.0.0.1を介してパスワード変更ページにアクセスします。したがって、パスワード変更要求では、リファラーが127.0.0.1でない場合、CSRF攻撃と判断され、拒否されます。ただし、この方法は絶対確実ではありません。リファラー値はブラウザーによって提供されるため、一部のブラウザーでは、一部の方法を使用してリファラー値を改ざんすることができます。したがって、攻撃者はユーザーのブラウザのリファラー値を必要なアドレスに完全に変更して、検証に合格し、CSRF攻撃を実行することができます。さらに、攻撃者がリファラー値を改ざんできない場合でも、この方法は