elementui 做的网站,温州红酒网站建设,中国域名管理中心,网站备案号规则本博文翻译自#xff1a;https://dotnetcoretutorials.com/2017/10/25/owasp-top-10-asp-net-core-cross-site-scripting-xss/在这篇文章的前几次迭代中#xff0c;我用了一个很长的篇幅解释了什么是跨站脚本(XSS)。但在花了好几个小时来完善它之后#xff0c;我觉得向你展示… 本博文翻译自https://dotnetcoretutorials.com/2017/10/25/owasp-top-10-asp-net-core-cross-site-scripting-xss/在这篇文章的前几次迭代中我用了一个很长的篇幅解释了什么是跨站脚本(XSS)。但在花了好几个小时来完善它之后我觉得向你展示一个简单的屏幕截图就更容易了。这例子很简单。我有一个用户的“搜索”页面并且他们输入的任何查询都以“搜索查询{您的查询在这里}”的形式回传给他们。代码如下所示h2Search Results for Html.Raw(Context.Request.Query[query])/h2因此我们要把用户搜索的东西(或者输入用来查询的字符串)直接放到页面上。这样用户就可以输入脚本标签或者任何他们想要的东西。这本质上是XSS的核心。获取未经验证的用户输入并在网页上批量显示。在这篇文章中我将引用“我之前编写的代码”。这个代码在Github上如果你想看一下自己测试一下XSS。你可以在这里下载。什么是XSSXSS是指跨站脚本攻击它能让攻击者将客户端脚本通常为JavaScript尽管可能有其他类型的注入注入到网页上然后再向其他用户显示。通常这些脚本试图窃取私人数据例如cookies或浏览器存储重定向浏览器或者有时甚至欺骗用户进行他们通常不会做的动作。XSS通常被定义为两种不同的类型反射性XSS反射性XSS是指在用户输入结果时立即发生跨站点脚本攻击。例如当用户搜索时该搜索查询就会立即显示在页面上。通常XSS的危险来自于将链接发送给不知情的用户而用户看到的是全出乎意料的页面。存储式XSS存储式XSS是指把恶意脚本存储到被攻击者的网站的数据库。其他人访问数据库中的恶意脚本代码后浏览器执行恶意脚本被攻击。如果我们使用一个博客的例子,接受评论文章。如果您能够在博客评论中存储XSS漏洞那么从那时起查看该博客文章的所有人都将受到影响。很明显这有可能比反射性XSS漏洞要大得多因为它不依赖于用户发送一个不可靠的链接也不需要在他们的部分做任何额外的事情。有人可以用XSS做什么使用Javascript当然要是能够在网页上注入脚本标签。世界真的是攻击者砧板上的肉。他们可以做一些简单的事情比如将用户重定向到不同的页面(然后他们窃取用户的凭证)他们可以在页面上插入javascript来构建一个虚假的登录表单(然后他们窃取用户的凭证)或者他们甚至可以用它来盗取用户的登录cookie(然后他们窃取用户的凭证)。这可能是毁灭性的。虽然在页面上注入javascript完全是毁灭性的但是保护你的站点不仅仅是不允许在任何地方提交“script”这个词。实际上你可以在没有CSS的情况下做一些相当危险的事情。CSS通过向页面中注入样式攻击者可以改变页面的整个布局来欺骗用户做他们不想做的事情。我之前看到的一个“巧妙”漏洞是攻击者重新设计了一个页面通过移动删除按钮并更改文本现在可以添加CSS中的“内容”来欺骗用户删除自己的帐户。单独使用CSS你几乎可以重写整个网站。让我们快速浏览一下我早期使用的网站。再次你可以在这里获得Github上的源代码。默认情况下它看起来有点像这样现在让我们尝试。让我们尝试在这里注入以下CSS负载:style.container, .navbar{display:none;}
body { padding: 5px }
body:before { content:We have moved. Head over to www.bogussite.com to continue; }/style所以这个URL看起来像这样http://localhost:57423/?querystyle.container,.navbar{display:none;}body {padding:5px}body:before{content:We have moved. Head over to www.bogussite.com to continue;}/style看这个URL:IFrames注入iframe也是一种XSS漏洞它可以在相当长的一段时间内不被发现因为它对终端用户基本上是不可见的。ifram可以是“无害的”当人们试图在他们自己的网站上建立视图时视图里面包含了付费的广告这是一种有害的东西就像把一个虚假的登录表单写进页面一样。用户输出HTML编码现在如果你一直在看我的示例代码你可能会注意到一些事情。我正在谈论这个Html.Raw(Context.Request.Query[query]) 。我想承认我作弊了。默认情况下当ASP.net Core Razor 将值输出到页面上时它总是对它们进行编码。如果我们删除这个原始标签助手并尝试注入一个脚本标签我们可以在页面上看到那么为什么没有真正运行脚本标签它看起来应该是对的让我们来看看页面的源代码。看看我们的脚本标签是如何被写入HTML的。它已经被我们转义了这意味着脚本标记还没有被实际运行很棒因此对于直接写入页面的内容实际上我们有受到框架的保护。我们正在展示这些数据的其他地方呢也许我们正在构建一个SPA而不是使用ASP.net Core Razor。每个JavaScript库甚至jQuery都会为您编码数据。但是检查这是一个自动还是手动的过程是值得的并且将用户输入直接输出到HTML中的任何地方都应该进行三重检查以获得有效的编码。值得注意的一个有趣的观点是我遇到了一些开发人员他们坚持HTML编码因为他们存储在数据库中然后在网页上显示它们通常你不使用Razor所以你没有得到自动编码。这将起作用但我认为这是一个不好的做法。当您仅在存储数据时对数据进行编码时您就会对反射性XSS攻击保持开放因为这些数据从未存储在任何地方(直接显示给用户)。用户输入址编码在将用户数据直接输出到HTML中时HTML编码很好。但有时您可能需要接受用户输入并将其放入URL中。URL不会使用与HTML相同的字符进行编码因此您可能会发现自己试图用Raw标签助手来覆盖所有内容。 不要这样做 因为.NET core 已经覆盖了URL编码。要访问它首先需要在Visual Studio的软件包管理器控制台中安装以下nuget软件包Install-Package Microsoft.AspNet.WebUtilities -Pre然后您可以像这样在视图中编码您的URLa href/linktosomething?querySystem.Net.WebUtility.UrlEncode(Context.Request.Query[query])Search Query/a浏览器保护需要注意的一点是浏览器正在跳入以保护用户免受XSS攻击。 在Chrome中使用script alert “this is a XSS” / script这个非常简单的负载 我最终得到了以下结果说到这个你基本在这里可以找到一个试图绕过Chrome的XSS过滤器的用户写的好文章用户试图绕过Chrome的XSS过滤器可以在这里找到一个很好的写作https://blog.securitee.org/?p37。从本质上讲这将是一场军备竞赛依靠浏览器来保护你的用户将是非常困难的。更不用说那些不更新浏览器的用户了。X-XSS-Protection头这是另一种保护你的用户的方法“很好但是请编码你的输出。”。使用X-XSS-Protection头文件您可以指导浏览器如何最好地处理它检测到的任何XSS漏洞。标题有4个不同的值您可以使用。X-XSS-Protection: 0试图在浏览器中禁用XSS保护如果你想尝试和测试的话这是很好的选择。X-XSS-Protection: 1启用XSS保护但如果检测到XSS则会尝试清理输出例如对其进行编码或去除字符。这样做可能很危险因为生成的HTML可能同样危险。看到这里http://blog.innerht.ml/the-misunderstood-x-xss-protection/。X-XSS-Protection: 1; modeblock启用XSS保护并在检测到任何XSS漏洞的情况下阻止加载页面。X-XSS-Protection: 1; reportreporting-uri这是一个chromium内核的头文件它允许您向您报告任何在XSS攻击中被检测到的URL。实际上你应该使用的唯一选项是阻止因为这将保护你的最佳状态。您可以在代码或服务器级别设置标题。对于代码级别它和在管道中添加额外的中间件一样简单。类似这样:public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory){app.Use(async (context, next) {context.Response.Headers.Add(X-Xss-Protection, 1); await next();});app.UseMvc();
}如果您有兴趣进一步阅读我们有一篇专门讨论X-XSS-Protection header的文章另外还有一篇关于每个站点都应该有的3个安全标题.。总结跨站脚本攻击是那些拒绝死亡的攻击之一主要是因为人们没有做基本的事情。正如我们所看到的在ASP.net Core中我们的razor 标签助手是一个保护我们非常好的的解决方案事实上框架解决我们的大部分问题事实上都是HTML编码。浏览器在保护人们方面也正在取得重大进展但这并不意味着开发者能对自己在保护终端用户方面的角色感到自满。相关文章ASP.NET Core中的OWASP Top 10 十大风险-SQL注入ASP.NET Core中的OWASP Top 10 十大风险-失效的访问控制与Session管理原文地址:http://www.cnblogs.com/chen-jie/p/owasp-top-10-asp-net-core-cross-site-scripting-xss.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
