01脆弱性の説明
HTTPはステートレスで、Webアプリケーションをリードすると、ユーザーを識別するために、セッション・メカニズムを使用する必要があります。Webサイトへの接続（アクセスログ）と、ユーザは、通常、クッキーに割り当てられます、後続の要求は、クッキーを持って来るので、ユーザデータが変更され、ユーザーが要求しているから、Webサイトを、区別することは容易です。あなたが第三者から現在のサイトのための要求を開始した場合、要求はクッキー現在のサイトをもたらすでしょう。これは、CSRFの創出につながっこの欠陥は、ユーザーが非意図する動作を行う乗っ取る可能性があり、この脆弱性を利用して、まさにです。
02脆弱性検出
CSRFの使用シナリオでは、ユーザが駅の外から偽造要求を開始したい、多くの場合、ユーザがログインしている場合です。外部ステーション（クロスサイト）からの要求を開始し、要求されたパラメータ値でき偽（偽リクエスト）、したがって、これら2点をCSRF開始検出さ：のより詳細な分析。
転送するには、例えば、アカウントと金額を入力して、転送を完了するために、[転送]をクリックします。私たちは、機能がCSRFを存在するかどうかを調べました。
駅を通過することができます
クロス駅かどうかを検出するには、あなただけがリクエストにRefererヘッダフィールドを操作する必要があります。要求がないRefererヘッダフィールド、または削除リファラリクエストヘッダフィールドで、要求元を検証していないサーバが、成功応答がされている場合はリファラフィールドは、要求の発信元を記録し、「クロスサイト。」
まず、通常の要求パケットを送信する、それは転送が成功したことがわかりました。
私たちは、値が我々が各地から要求されているページを示し、リファラーリクエストヘッダフィールドがあることがわかります。リファラーフィールド我々は、口座残高が変更されていない表示し、削除して再提出してみてください。
口座残高は、サーバが要求のソースが可能かどうかを検証しませんことを示し、990から980になっていることが見つかり、「クロスサイト。」
偽造を要求することができます
リクエストフォージェリの前提は、我々はパラメータがリクエストに含まれるものを知っていることを、リクエストのパラメータと値を偽造、またはパラメータの範囲の正確な値を知る方法を知っていることです。そのため、要求だけ偽造できるかどうかを検出たちはリクエストのパラメータと値偽物でないことができるかどうかを確認する必要があります。
あなたは、要求の4つのパラメータがある、見ることができ、アカウントはアカウント番号を表し、量が転送量を表し、2は改ざんせずに、直接使用することができ、アクションを表現するための良い、アクションを偽造しました。トークンは何ですか？（トークントークンは見つけます）
token参数的值这么长，一看就知道不好伪造。那删掉token试试，万一和referer字段一样，服务器没有对token进行校验呢。
反复重放了几次请求，发现账户余额保持不变，很显然，token参数必须有。那我们随便改一下token的值，看请求中是不是只要有token参数就行了，但服务器并不会校验token的值。
反复重放几次，发现账户余额依然保持不变，说明服务器对Token做了校验，请求中不能缺失token或token错误。
正打算放弃的时候，无聊的重放着原始请求包，突然发现账户余额变成了900。
WTF，同一个token值好像可以反复使用，均能通过校验，难道这token是永久的？后来发现只要不退出重新登录，token会一直有效，了解了，这叫“韩式半永久”。
验证CSRF
既能“跨站”，又能伪造请求，那CSRF的验证就很简单了。重新抓包，利用抓包工具生成CSRF的POC。
复制其中的HTML代码，在本地新建一个HTML页面，将复制的代码保存其中，然后在同一个浏览器中打开(不懂的请gun去学习Cookie方面的知识)。
点击CSRF页面中的按钮，发现会跳转到转账页面，且账户余额只有400，少了500。
CSRF的检测到此圆满结束。至于CSRF的利用，简单说两句，可以构造一个链接(GET)、隐藏的表单(POST)、图片等，然后想方设法让用户点击或访问就可以了。
03 漏洞修复
请求来源验证；HTTP请求头中有个referer字段，该字段记录了当前HTTP请求的来源。可以通过检查请求是否来自站外，来防御站外发起的CSRF，但不能防御从站内发起的CSRF，且存在被绕过的风险。
Token验证；在请求中添加攻击者无法预测的Token令牌，当请求中缺失Token或Token值不对时，则拒绝请求。请使用一次性的Token，而且记得及时更新，不然还是可以绕过。(这种情况工作中已经遇到过无数次了)
使用图形验证码，但可能会影响用户体验。
04 PS
我这里举了一个既包含referer又包含token的例子，为了让大家更好的理解CSRF的检测，排版可能会与实际情况有些出入。实际工作中，我个人习惯先多次重放，看token是否可重复使用，如果可重复使用，自然不用修改token值或删除，只需要检测是否可“跨站”即可；如果不能重复使用，说明会校验token值，那么就不必修改token值，只需直接删除token试试，最后再测试是否可“跨站”。而且在实际利用中，token值的获取没有这么简单。只是在检测过程中，我们发现token机制存在缺陷，那我们应该防患于未然，将风险降低到零。这里简要解释一下文章内容与实际工作中相出入的几点。
作者：安全小白团
链接：https://www.jianshu.com/p/2524ab092914
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。