Questions tagged «csrf»

跨站点请求伪造是一种恶意攻击，它利用网站对用户浏览器的信任。

4
将CSRF预防令牌放在cookie中为什么很常见？
我正在尝试了解CSRF的整个问题以及适当的预防方法。（我已阅读，理解并同意的资源：OWASP CSRF预防速查表，关于CSRF的问题。） 据我了解，CSRF周围的漏洞是由以下假设引入的：从Web服务器的角度来看，传入HTTP请求中的有效会话cookie反映了经过身份验证的用户的意愿。但是，源域的所有cookie都被浏览器神奇地附加到了请求上，因此，实际上服务器可以从请求中是否存在有效的会话cookie推断出，该请求来自具有经过身份验证的会话的浏览器。它无法进一步假设有关代码的任何信息在该浏览器中运行，或者是否确实反映了用户的意愿。防止这种情况的方法是在请求中包括其他身份验证信息（“ CSRF令牌”），该信息由浏览器的自动cookie处理以外的其他方式携带。松散地说，会话cookie对用户/浏览器进行身份验证，而CSRF令牌对在浏览器中运行的代码进行身份验证。 简而言之，如果您使用会话cookie来验证Web应用程序的用户，则还应该向每个响应中添加CSRF令牌，并在每个（变异）请求中要求匹配的CSRF令牌。然后，CSRF令牌从服务器到浏览器再返回到服务器，以向服务器证明发出请求的页面已被该服务器批准（由该服务器生成，甚至由该服务器生成）。 关于我的问题，这是关于该往返行程中用于该CSRF令牌的特定传输方法。 似乎很常见（例如在AngularJS，Django，Rails中），将CSRF令牌作为cookie从服务器发送到客户端（即在Set-Cookie标头中），然后让客户端中的Javascript将其从cookie中刮出并附加它作为单独的XSRF-TOKEN标头发送回服务器。 （另一种方法是Express推荐的方法，其中服务器生成的CSRF令牌通过服务器端模板扩展包含在响应主体中，并直接附加到将其提供回服务器的代码/标记中，例如作为隐藏的表单输入。该示例是一种更像Web 1.0的工作方式，但可以推广到使用更多JS的客户端。） 为什么使用Set-Cookie作为CSRF令牌的下游传输如此普遍/为什么这是个好主意？我想所有这些框架的作者都仔细考虑了他们的选择，并没有弄错这一点。但乍看之下，使用cookie来解决cookie的本质设计限制似乎很愚蠢。实际上，如果您使用cookie作为往返传输（服务器的Set-Cookie：下游标头告诉浏览器CSRF令牌，浏览器的cookie：上游标头将浏览器返回给服务器），则会重新引入此漏洞正在尝试修复。 我意识到上述框架并未在CSRF令牌的整个往返过程中使用cookie；他们在下游使用Set-Cookie，然后在上游使用其他内容（例如X-CSRF-Token标头），这确实消除了该漏洞。但是，即使使用Set-Cookie作为下游运输工具，也可能会产生误导和危险；浏览器现在将CSRF令牌附加到每个请求，包括真正的恶意XSRF请求；最好的情况是使请求大于所需的大小，最坏的情况是一些善意却被误导的服务器代码实际上可能会尝试使用它，这确实很糟糕。而且，由于CSRF令牌的实际预期接收者是客户端Javascript，这意味着该cookie不能仅通过http保护。
283 security  cookies  web  csrf  owasp 
17
警告：无法验证CSRF令牌的真实性
我正在使用AJAX将数据从视图发送到控制器，但出现此错误： 警告：无法验证CSRF令牌的真实性 我想我必须将此令牌与数据一起发送。 有人知道我该怎么做吗？ 编辑：我的解决方案 我是通过将以下代码放入AJAX帖子中来完成此操作的： headers: { 'X-Transaction': 'POST Example', 'X-CSRF-Token': $('meta[name="csrf-token"]').attr('content') },
20
jQuery Ajax调用和Html.AntiForgeryToken（）
根据我在互联网上的一些博客文章中所阅读的信息，我已经在我的应用程序中实施了缓解CSRF攻击的措施。这些帖子尤其是我实施的驱动力 来自ASP.NET和Web工具开发人员内容团队的ASP.NET MVC最佳实践 Phil Haack博客的跨站点请求伪造攻击剖析 ASP.NET MVC框架中的AntiForgeryToken- David Hayden博客的Html.AntiForgeryToken和ValidateAntiForgeryToken属性 基本上，这些文章和建议都说，为防止CSRF攻击，任何人都应实施以下代码： 1）[ValidateAntiForgeryToken]在接受POST Http动词的每个动作上添加 [HttpPost] [ValidateAntiForgeryToken] public ActionResult SomeAction( SomeModel model ) { } 2）在<%= Html.AntiForgeryToken() %>将数据提交到服务器的表单内添加帮助程序 <div style="text-align:right; padding: 8px;"> <%= Html.AntiForgeryToken() %> <input type="submit" id="btnSave" value="Save" /> </div> 无论如何，在我的应用程序的某些部分中，我都使用jQuery将Ajax POST进行到服务器，而没有任何形式。例如，在发生这种情况时，我让用户单击图像来执行特定操作。 假设我有一个包含活动列表的表。我在表的列上有一幅图像，上面写着“将活动标记为已完成”，当用户单击该活动时，我正在执行Ajax POST，如以下示例所示： $("a.markAsDone").click(function (event) { event.preventDefault(); $.ajax({ type: "post", dataType: …
18
Django CSRF检查失败，并带有Ajax POST请求
我可以通过我的AJAX帖子向遵循Django CSRF保护机制的人员提供帮助。我按照这里的指示进行： http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ 我已经完全复制了该页面上的AJAX示例代码： http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax 我getCookie('csrftoken')在xhr.setRequestHeader呼叫之前打印了警报内容，并确实在其中填充了一些数据。我不确定如何验证令牌是否正确，但是我鼓励它正在查找并发送一些消息。 但是Django仍然拒绝我的AJAX帖子。 这是我的JavaScript： $.post("/memorize/", data, function (result) { if (result != "failure") { get_random_card(); } else { alert("Failed to save card data."); } }); 这是我在Django中看到的错误： [23 / Feb / 2011 22:08:29]“ POST / memorize / HTTP / 1.1” 403 2332 我确定我缺少某些东西，也许很简单，但是我不知道它是什么。我在SO周围搜索，并看到了一些有关通过csrf_exempt装饰器关闭CSRF检查以获取我的视图的信息，但是我发现这没有吸引力。我已经尝试过了，并且可以工作，但是我宁愿让POST按照Django期望的方式工作。 以防万一，这是我的观点正在做的要点： def myview(request): profile …
180 python  ajax  django  csrf 
11
在ASP.NET MVC中的Ajax中包含antiforgerytoken
我在使用Ajax的AntiForgeryToken时遇到麻烦。我正在使用ASP.NET MVC3。我在jQuery Ajax调用和Html.AntiForgeryToken（）中尝试了该解决方案。使用该解决方案，令牌现在可以通过： var data = { ... } // with token, key is '__RequestVerificationToken' $.ajax({ type: "POST", data: data, datatype: "json", traditional: true, contentType: "application/json; charset=utf-8", url: myURL, success: function (response) { ... }, error: function (response) { ... } }); 当我删除该[ValidateAntiForgeryToken]属性只是为了查看数据（带有令牌）是否作为参数传递给控制器​​时，我可以看到它们正在传递。但是由于某种原因，A required anti-forgery token was not supplied or …
4
登录表单是否需要针对CSRF攻击的令牌？
根据到目前为止的了解，令牌的目的是防止攻击者伪造表单提交。 例如，如果某个网站的表单向您的购物车中输入了添加的商品，那么攻击者可能会向您的购物车中发送您不想要的商品。 这是有道理的，因为购物车表单可能有多个有效输入，攻击者要做的就是知道该网站正在销售的商品。 我了解令牌在这种情况下的工作原理并增加了安全性，因为它们可确保用户实际上已填写并为添加到购物车中的每个商品按下了表单的“提交”按钮。 但是，令牌是否为需要用户名和密码的用户登录表单增加了任何安全性？ 由于用户名和密码非常独特，攻击者必须知道两者才能使登录伪造正常工作（即使您没有设置令牌），并且如果攻击者已经知道，则可以登录网站他自己。更不用说，使用户登录自己的CSRF攻击也没有任何实际用途。 我对CSRF攻击和令牌的理解正确吗？而且我怀疑它们对用户登录表单没有用吗？
161 php  token  csrf 
3
在浏览器中的何处存储JWT？如何防范CSRF？
我知道基于cookie的身份验证。SSL和HttpOnly标志可以应用于保护来自MITM和XSS的基于cookie的身份验证。但是，将需要采取更多特殊措施来保护它免受CSRF的侵害。它们只是有点复杂。（参考） 最近，我发现JSON Web令牌（JWT）作为身份验证的解决方案非常热门。我知道有关编码，解码和验证JWT的知识。但是，我不明白为什么某些网站/教程告诉您使用JWT不需要CSRF保护。我已经阅读了很多，并尝试总结以下问题。我只希望有人可以提供JWT的概况，并阐明我对JWT误解的概念。 如果JWT存储在cookie中，则我认为它与基于cookie的身份验证相同，除了服务器不需要会话来验证cookie /令牌。如果不采取特殊措施，CSRF仍有风险。JWT是否存储在cookie中？ 如果JWT存储在localStorage / sessionStorage中，则没有cookie，因此不需要防御CRSF。问题是如何将JWT发送到服务器。我在这里发现建议使用jQuery通过Ajax请求的HTTP标头发送JWT。那么，只有ajax请求可以进行身份​​验证吗？ 此外，我还发现了另一个博客节目，使用“ Authorization标头”和“ Bearer”发送JWT。我不了解博客谈论的方法。有人可以解释一下“授权标头”和“承载者”吗？这是否会使通过所有请求的HTTP标头传输的JWT？如果是，CSRF怎么样？
3
跨域表单过帐
我已经看过有关该主题的文章和帖子（包括SO），并且普遍的评论是，同源策略阻止跨域的POST形式。我见过有人建议将同源政策不适用于表单帖子的唯一位置是此处。 我想从一个更“官方”或正式的来源获得答案。例如，是否有人知道解决同源性如何影响表单POST的RFC？ 澄清：我不是在问是否可以构造GET或POST并将其发送到任何域。我在问： 如果Chrome，IE或Firefox允许域“ Y”中的内容将POST发送到域“ X” 如果接收POST的服务器实际上将看到所有表单值。我之所以这样说，是因为大多数在线讨论记录的测试人员都说服务器收到了该帖子，但是表单值全部为空/已剥离。 哪个正式文档（即RFC）说明了预期的行为（无论浏览器当前已实现了什么）。 顺便说一句，如果同源源不影响表单POST，那么这使得为什么需要使用防伪令牌更加明显。我之所以说“有点”，是因为很难相信攻击者可以简单地发出HTTP GET来检索包含反伪造令牌的表单，然后进行包含相同令牌的非法POST。注释？
2
使用无状态（=无会话）身份验证时需要CSRF令牌吗？
当应用程序依赖无状态身份验证（使用HMAC之类的东西）时，是否有必要使用CSRF保护？ 例： 我们只有一个页面应用程序（否则，我们必须在每个链接上附加令牌：<a href="...?token=xyz">...</a>。 用户使用进行身份验证POST /auth。成功认证后，服务器将返回一些令牌。 令牌将通过JavaScript存储在单页应用程序内的某个变量中。 该令牌将用于访问受限制的URL，例如/admin。 令牌将始终在HTTP标头中传输。 没有Http会话，也没有Cookie。 据我了解，应该不会（？！）使用跨站点攻击，因为浏览器不会存储令牌，因此它无法自动将令牌发送到服务器（使用Cookies /时会发生这种情况。会话）。 我想念什么吗？
18
“由于不活动，页面已过期”-Laravel 5.5
我的注册页面正确显示了表单{{ csrf_field() }}，并且表单中存在CsrfToken（）。 表格HTML <form class="form-horizontal registration-form" novalidate method="POST" action="{{ route('register') }}"> {{ csrf_field() }} .... </form> 我正在为用户使用内置身份验证。除了路由和重定向外，没有任何更改。 当我提交表单时（也就是重新加载后），它表明该页面由于不活动而已过期。请刷新，然后重试。错误。 我是我想念的一件很小的事。但不确定是什么。有什么帮助吗？ 更新资料 找到了问题。会话驱动程序设置为数组。将其更改为文件，错误现在消失了。但是，如果我使用数组怎么办？
111 php  laravel  csrf  laravel-5.5 
12
Django Rest Framework移除CSRF
我知道有关于Django Rest Framework的答案，但是我找不到解决问题的方法。 我有一个具有身份验证和某些功能的应用程序。我向其中添加了一个新应用程序，该应用程序使用Django Rest Framework。我只想在此应用程序中使用库。我也想发出POST请求，并且总是收到以下响应： { "detail": "CSRF Failed: CSRF token missing or incorrect." } 我有以下代码： # urls.py from django.conf.urls import patterns, url urlpatterns = patterns( 'api.views', url(r'^object/$', views.Object.as_view()), ) # views.py from rest_framework.views import APIView from rest_framework.response import Response from django.views.decorators.csrf import csrf_exempt class Object(APIView): @csrf_exempt def post(self, …
3
在Rails 3中关闭CSRF令牌
我有一个Rails应用，可为iPhone应用提供一些API。我希望能够简单地在资源上发布，而不必考虑获取正确的CSRF令牌。我尝试了一些我在stackoverflow中看到的方法，但似乎它们不再适用于rails 3。 感谢你们对我的帮助。
2
具有CORS Origin标头和CSRF令牌的CSRF保护
此问题仅与防止跨站点请求伪造攻击有关。 具体来说，它是：通过Origin标头（CORS）进行的保护是否与通过CSRF令牌进行的保护一样好？ 例： 爱丽丝使用她的浏览器（使用cookie）登录到“ https://example.com ”。我认为她使用的是现代浏览器。 爱丽丝访问“ https://evil.com ”，evil.com的客户端代码对“ https://example.com ” 执行某种请求（经典CSRF场景）。 所以： 如果我们不检查Origin头（服务器端），也没有CSRF令牌，则我们有一个CSRF安全漏洞。 如果我们检查CSRF令牌，我们是安全的（但这有点乏味）。 如果我们确实检查了Origin标头，则应与使用CSRF令牌时一样阻止evil.com客户端代码的请求-除了，除非evil.com的代码可以某种方式设置Origin标头。 我知道，如果使用XHR（例如，跨域资源共享的安全性），这应该是不可能的，至少不能，如果我们相信W3C规范可以在所有现代浏览器中正确实现的话（可以吗？） 但是其他类型的请求呢？例如表单提交？加载脚本/ img / ...标签？还是页面可以用来（合法）创建请求的任何其他方式？还是一些已知的JS hack？ 注意：我不是在说 本机应用程序 操纵的浏览器 example.com页面上的跨站点脚本错误， ...
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.