10分钟内完成示例的CORS，XSS和CSRF

最新推荐文章于 2024-04-29 22:04:39 发布

cunxiedian8614

最新推荐文章于 2024-04-29 22:04:39 发布

阅读量834

点赞数 1

文章标签： web安全 javascript 数据库 ViewUI

本文应该是现有Web安全标准，最常见的Web攻击及其预防方法的切入点。最后，您还将发现Samy是如何以及为什么成为每个人的英雄（我想除了Rupert Murdoch的英雄）。

CORS

跨域资源共享（CORS）是IE10 +，Chrome 4 +，Firefox 3.5+或2012年之后发布的几乎所有版本的浏览器（Opera Mini除外）的安全功能。

当在域website.com上可用的服务器上配置了CORS时，该域中通过AJAX请求的资源必须从该域提供的资产中启动。

换句话说，如果我们在domain-b.com上启用了CORS并将其配置为仅允许来自domain-b.com GET请求，那么如果您要使用https://domain-b.com/images/example.png下的可用图像https://domain-b.com/images/example.png在您的网站（位于domain-a.com上托管）上的domain-a.com ，对于大多数访问者domain-a.com ，该图片不会被加载。
当任何不遵守CORS policy工具或浏览器提出请求时，您仍然可以使用受CORS保护的资源。

CORS配置

默认情况下 ，CORS被禁用，这意味着没有足够的服务器处理程序来配置CORS，这意味着您无法访问XHR中来自不同来源的资源。基本上，如果您不执行任何操作或仅针对特定域专门启用CORS，则尝试访问您的资源的任何AJAX请求都将被拒绝，因为Web浏览器遵守CORS policy 。
这就是为什么在您开始使用VueJS和NodeJS开发SPA时遇到CORS问题的原因。您的VueJS应用程序托管在http://localhost:8080 ，当您尝试访问http://localhost:8000上的NodeJS服务器应用程序时，会得到“ No Access-Control-Allow-Origin header is present ”，因为这是两个不同的地方ORIGINS （ PROTOCOL ， HOST和PORT组合）。

在VueJS开发模式下解决CORS问题的不错方法是在vue.config.js文件中设置devServer代理，如下所示：

module . exports = {
  ...
  devServer : {
    proxy : ' http://localhost:8000 ' ,
  },
  ...
}

要在生产环境中设置CORS，您应该为OPTIONS请求添加适当的侦听器。该侦听器应该发送no body但带有标Headers响应200 ，标Headers将定义您想要的CORS策略 ：

Access-Control-Allow-Origin: https://domain-b.com
Access-Control-Allow-Methods: GET

有关如何配置CORS的更多信息，请检查https://enable-cors.org/index.html ，并深入研究CORS policy请检查https://livebook.manning.com/book/cors-in-action/part -1 /

XSS

XSS代表跨站点脚本，它是攻击的注入类型。在OWASP 2017年确定的十大漏洞中，它排名第七。跨站点脚本是攻击者将恶意脚本注入受信任的网站的方法。（部分更新，感谢Sandor）此类攻击有3种类型。

存储的XSS-漏洞来自未经保护和未清除的用户输入，这些输入直接存储在数据库中并显示给其他用户
反映的XSS-漏洞来自未直接在网页中使用的URL的未保护和未过滤的值
基于DOM的XSS-与反映的XSS相似，来自直接在网页中使用的URL的不受保护和未经过滤的值，不同之处在于基于DOM的XSS甚至没有进入服务器端

攻击

1.存储的XSS

这是攻击的一个例子。攻击者进入您的网站，找到不受保护的输入字段（例如，注释字段或用户名字段），并输入恶意脚本而不是期望值。之后，每当该值显示给其他用户时，它将执行恶意代码。恶意脚本可能会尝试访问其他网站上的帐户，可能参与DDoS攻击或类似行为。视觉表示（来源geeksforgeeks.org）：

2.反映的XSS

反映的XSS是攻击者发现具有此类漏洞的页面时发生的攻击，例如：

预期的网址： https://mywebpage.com/search?q=javascript : https://mywebpage.com/search?q=javascript
恶意网址： https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script> ： https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script>

<body>
...
<div> showing results for keyword 
<script> document . write ( window . location . href . substr ( window . location . href . indexOf ( ' q= ' ) + 2 ))
</script>
</div>
...
...JavaScript results...
...
</body>

发现后，攻击者诱使用户单击此类恶意URL并瞧瞧。用户敏感数据被利用。

在geekforgeeks.com提供的示例中说明了攻击的生命周期：

3.基于DOM的XSS

这种攻击与所反映的相同，但不同之处在于恶意URL部分根本不会发送到服务器。对于以上示例：

预期的网址： https://mywebpage.com/search?q=javascript : https://mywebpage.com/search?q=javascript
恶意网址（反映为XSS）： https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script> : https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script> q https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script>警报（“很遗憾https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script>
恶意网址（基于DOM的XSS）： https://mywebpage.com/search#q=<script>alert('fortunately, this will not work!')</script> : https://mywebpage.com/search#q=<script>alert('fortunately, this will not work!')</script> alert（“幸运的是https://mywebpage.com/search#q=<script>alert('fortunately, this will not work!')</script>

区别在于使用字符#而不是? 。浏览器不会在＃之后向服务器发送URL的一部分，因此它们会将URL直接传递给您的客户端代码。

保护

用户可以输入并在您的应用中使用的每个值 （在服务器端或客户端）均应视为不可信数据 ，因此应在使用前进行处理！您还应该在服务器应用程序和客户端应用程序中进行安全检查！
如文档所示， VueJS本身会在从变量获取值之前对字符串进行转义。较新版本的Angular也会隐式地对字符串进行转义，因此，如果您使用的是Vanilla JS，JQuery或类似的语言，则应手动实现字符串转义。

下面列出了三种处理不可信数据的最常用方法，理想的方法取决于您需要处理的字段的实际类型。

1.字符串验证

验证是一种方法，用户可以定义规则集，并在继续操作之前要求不受信任的数据来满足这些规则。此方法适用于数字值 ， 用户名 ， 电子邮件 ，密码和具有具体语法规则集的类似字段。

在考虑自己编写验证器之前，请先检查框架的现有库。

2.字符串转义

对于应该使用户能够使用标点符号的情况，转义方法很有用。此方法遍历字符串并查找特殊字符（例如< > ，并用适当的HTML字符实体名称替换它们。这是您可以使用的基本功能：

function escapeText ( text ) {
  return text . replace ( /&/g , ' &amp; ' )
             . replace ( /</g , ' &lt; ' )
             . replace ( />/g , ' &gt; ' )
             . replace ( /"/g , ' &quot; ' )
}

再次，在编写自己的库之前检查现有库。

3.字符串清理

当允许用户在其评论，文章或类似内容中输入一些HTML标签时，将使用消毒字符串。 sanitize方法遍历文本，查找您指定的HTML标记并将其删除。使用这种方法的最受欢迎的库之一是Google Closure 。
这种方法耗费资源并且被认为是有害的，因此在选择它之前需要做更多的研究。

Web浏览器（自哪个版本以来，没有可用的资源，IE在2014年修复了此问题。）在将URL发送到服务器端并使它们在window.location对象中可用之前，它们会自动转义URL，因此这里的第二和第三类型攻击是了解它们，并明确指出URL参数也应视为不可信数据。

有关XSS的更多详细信息，以及如果您轮流使用许多不受信任的数据时如何正确保护应用程序，请查看有关XSS预防的OWASP速查表。

CSRF

跨站点请求伪造或CSRF是当恶意网站，电子邮件，博客，即时消息或程序导致用户的Web浏览器对经过身份验证的其他受信任站点执行有害操作时发生的一种攻击。当浏览器随每个请求自动发送授权资源（例如会话cookie，IP地址或类似内容）时，可能会出现此漏洞。

攻击

假设用户已登录到不受保护的证券交易所Web应用程序，并且您正在使用任一会话cookie或JWT cookie进行身份验证。攻击者还会使用您的服务，并且能够检查您的API的工作方式。攻击者欺骗用户执行脚本（通过单击电子邮件中的SPAM链接或类似内容），该脚本会将请求发送到您的API https://www.stockexchange.com/users/withdraw?how_much=all&address=MY_ADDRESS （糟糕的API设计，不要这样做）问）。由于请求是从浏览器执行的，该浏览器随每个请求发送身份验证有效负载，因此您的股票交换Web服务器将成功地对用户进行身份验证并执行交易，并且欺骗的用户将失去所有余额， 而不会意识到，因为所有事情都在后台发生。视觉表示（来源miro.medium.com）