CSRF
Posted 软慧网
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CSRF相关的知识，希望对你有一定的参考价值。
黑客技术教程：跨站请求伪造（CSRF）
概观
描述
有时可能将CSRF攻击存储在易受攻击的站点本身。这种漏洞被称为“存储的CSRF缺陷”。这可以通过简单地将IMG或IFRAME标记存储在接受html的字段中，或通过更复杂的跨站点脚本攻击来实现。如果攻击可以在站点中存储CSRF攻击，则攻击的严重程度会被放大。特别是，可能性会增加，因为受害者比Internet上的某个随机页面更有可能查看包含攻击的页面。可能性也增加了，因为受害者肯定已经被认证到了该网站。
同义词
CSRF攻击也被许多其他名称所知，包括XSRF，“Sea Surf”，会话骑马，跨站点参考伪造和敌对链接。微软将这种类型的攻击称为威胁建模过程中的一键式攻击，并将其中的许多地方用于在线文档中。
预防措施做不工作
使用秘密cookie
请记住，所有的cookies，即使是秘密的，都会在每次请求时提交。无论最终用户是否被欺骗地提交请求，所有认证令牌都将被提交。此外，应用程序容器仅使用会话标识符将请求与特定的会话对象相关联。会话标识符不会验证最终用户是否打算提交请求。
只接受POST请求
应用程序可以开发为只接受POST请求以执行业务逻辑。误解是由于攻击者无法构造恶意链接，因此无法执行CSRF攻击。不幸的是，这个逻辑是错误的。攻击者可以通过许多方法欺骗受害者提交伪造的POST请求，例如托管在攻击者网站中的带有隐藏值的简单表单。这种形式可以由javascript自动触发，也可以由认为表单会做其他事情的受害者触发。
随着时间的推移，许多有瑕疵的抗击CSRF攻击的想法已经形成。以下是我们建议您避免的一些问题。
多步骤事务
多步交易不足以预防CSRF。只要攻击者可以预测或推断已完成事务的每个步骤，CSRF就是可能的。
URL重写
这可能被视为一种有用的CSRF预防技术，因为攻击者无法猜测受害者的会话ID。但是，用户的会话ID将显示在URL中。我们不建议通过引入另一个来修复一个安全漏洞。
HTTPS
HTTPS本身对CSRF没有任何防范。
但是，应将HTTPS视为任何预防措施值得信赖的先决条件。
例子
攻击如何工作？
有许多方法可以欺骗最终用户从Web应用程序加载信息或向Web应用程序提交信息。为了执行攻击，我们必须首先了解如何为我们的受害者执行生成有效的恶意请求。让我们考虑下面的例子：Alice希望使用易受CSRF攻击的bank.com web应用程序将$ 100转移给Bob 。玛丽亚是一个攻击者，他想欺骗艾丽斯把钱汇给她。这次袭击将包括以下步骤：
建立一个利用URL或脚本
诱骗爱丽丝执行社交工程的行动
GET场景
如果应用程序的设计主要是使用GET请求传输参数并执行操作，则汇款操作可能会减少到如下请求：
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
玛丽亚现在决定利用Alice作为受害者来利用这个Web应用程序漏洞。玛丽亚首先构建了以下利用URL，将从Alice的账户中转账100,000美元到她的账户。她采用原始命令URL并用自己的名字取代受益人名称，同时显着提高转账金额：
http://bank.com/transfer.do?acct=MARIA&amount=100000
当她登录银行应用程序时，攻击的社会工程方面欺骗Alice加载该URL。这通常通过以下技术之一来完成：
发送包含HTML内容的未经请求的电子邮件
在他们也在网上银行的同时，在受害者可能访问的网页上植入漏洞网址或脚本
利用URL可以伪装成普通链接，鼓励受害者点击它：
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
或者作为0x0假图片：
<img width="0" height="0" border="0">
如果该图像标签包含在电子邮件中，Alice将不会看到任何内容。但是，浏览器仍然会将请求提交给bank.com，而没有任何可视的指示已经发生转移。
一个使用GET的应用程序对CSRF攻击的实际例子是从2008年开始的一个大规模下载恶意软件的uTorrent漏洞。
POST场景
GET和POST攻击的唯一区别是受害者如何执行攻击。假设银行现在使用POST，并且易受攻击的请求如下所示：
POST http://bank.com/transfer.do HTTP/1.1acct=BOB&amount=100
这样的请求无法使用标准A或IMG标签传递，但可以使用FORM标签交付：
<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST"><input type="hidden" name="acct" value="MARIA"/><input type="hidden" name="amount" value="100000"/><input type="submit" value="View my pictures"/></form>
这个表单将要求用户点击提交按钮，但这也可以使用JavaScript自动执行：
<body onload="document.forms[0].submit()"><form...
其他HTTP方法
现代Web应用程序API经常使用其他HTTP方法，例如PUT或DELETE。假设脆弱的银行使用以JSON块为参数的PUT：
PUT http://bank.com/transfer.do HTTP/1.1{ "acct":"BOB", "amount":100 }
这些请求可以使用JavaScript嵌入到漏洞利用页面中执行：
<script>function put() {var x = new XMLHttpRequest();x.open("PUT","http://bank.com/transfer.do",true);x.setRequestHeader("Content-Type", "application/json");x.send(JSON.stringify({"acct":"BOB", "amount":100}));}</script><body onload="put()">
幸运的是，由于同源策略限制，此请求不会被现代Web浏览器执行。此限制是默认启用的，除非目标网站通过使用带有以下标头的CORS明确打开攻击者（或所有人）来源的跨域请求：
Access-Control-Allow-Origin：*
以上是关于CSRF的主要内容，如果未能解决你的问题，请参考以下文章