JavaScript 安全性问题和最佳做法 (关于 XSS 和 CSRF)


众所周知,JavaScript是一种非常完善的编程语言。JavaScript通常应用在动态网页中,用来提供扩展功能,例如表单提交/验证,交互性,动画,用户活动跟踪等。但是一些用户对JavaScript的安全性方面非常怀疑。

JavaScript漏洞既可能是客户端问题,也可能是服务器端问题。黑客通过应用程序中的各种路径可能潜在地损害您的业务。这些威胁需要以一种或另一种方式进行评估和处理。

我们将讨论这些常见威胁中的两个以及如何使应用程序免受威胁。

跨站点脚本(XSS)攻击

跨站点脚本是最常见的浏览器端漏洞之一。XSS本身是由客户端脚本语言(例如HTML和JavaScript)的Internet安全漏洞引起的威胁。在XSS中,攻击者能够操纵合法但易受攻击的Web应用程序执行恶意任务。

XSS攻击可能导致身份和数据盗窃。它们甚至可能导致病毒传播,有时甚至导致对用户浏览器的远程控制。

让我们看一个简单的XSS攻击示例。

您可以使用Codepen在调试模式下尝试上述代码。当您插入img带有空src标签的标签时,它将触发该onerror方法。因此,如果您在其中插入脚本,它将运行。

例如,如果您输入以下内容作为文本框的输入,那么您将能够看到正在控制台中打印的cookie。
如果将上面的代码query作为参数复制粘贴到URL中,则可以实现上面的输出。

如果您的网站不安全,则黑客可以轻松地将一些JS代码注入您的参数中并获取用户有权访问的任何数据。此代码将允许将受害者的会话ID转移到黑客的站点,因此当黑客获得对它的访问权时,它可能会被滥用。

预防

  • 到达时过滤输入-每当您从用户那里得到输入时,都应根据预期或有效输入尽可能严格地过滤输入。
  • 使用适当的响应标头-为了防止HTTP响应中不包含任何HTML或JavaScript的XSS,可以使用Content-TypeX-Content-Type-Options标头来确保浏览器按照您期望的方式解释响应。
  • 输出时对数据进行编码-当在HTTP响应中输出用户输入的数据时,请对输出进行编码,以防止将其识别为活动内容。
  • 内容安全策略(CSP)-如果实施正确的CSP规则集,则可以阻止浏览器执行嵌入式 JavaScript,eval()setTimeout()或来自不受信任URL的任何JavaScript之类的操作。

    跨站请求伪造(CSRF)攻击

    CSRF或XSRF是一种攻击,黑客通过劫持会话cookie来接管或冒充受害者的身份。当目标站点仅使用cookie对请求进行身份验证,从而允许黑客窃取或劫持cookie并假冒合法用户时,这是可能的。这种攻击可能导致帐户篡改,数据盗窃,欺诈等。目标包括社交媒体,浏览器内电子邮件客户端,在线银行和网络设备的Web界面等Web应用程序。

让我们看一个简单的例子。

让我们假设我们有一家银行。在我们的网站上,典型的银行转帐请求就是这样的GET请求。

我们的银行使用会话Cookie对请求进行身份验证。因此,为了使用户转移资金,事件流将是:

  • 登录银行账户
  • 输入详细信息,然后单击转移

当用户登录到银行帐户时,该网站会存储一个会话cookie,该会话cookie以后将用于授权每笔交易。

黑客的操作

当黑客进入现场时,黑客会创建一个看起来非常有用但有隐藏议程的网站。假设它是一个博客网站。当用户添加新博客帖子时,恶意应用程序将执行隐藏代码,该代码会将GET请求发送到银行网站。为了使这种黑客成功,用户应该登录到他的银行帐户-会话令牌应该就位。

这是黑客操纵GET请求的方式。

当用户单击“添加博客文章”时,此隐藏请求将被执行,并且在用户不知情的情况下,这笔钱将被转移到黑客的银行帐户中。

以上技术也可以用于POST请求。黑客要做的就是创建一个<form>带有隐藏输入的,并向银行URL发送POST。

预防

  • 始终对会话cookie使用SameSite Cookie属性
  • 引荐来源标头或来源必须经过验证
  • 考虑为高度敏感的操作实施基于用户交互的保护-基于用户交互的保护包括重新认证(密码或更强),一次性口令,CAPTCHA。如果正确实施,这些可以充当强大的CSRF防御。
本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!
请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!