测试跨站脚本


每当应用程序获取不受信任的数据并将其发送到客户端(浏览器)而不进行验证时,就会发生跨站点脚本(XSS)。这使得攻击者可以在受害者的浏览器中执行恶意脚本,从而导致用户会话劫持、破坏网站或将用户重定向到恶意网站。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

3.跨站脚本

XSS 的类型

  • 存储型 XSS - 当用户输入存储在目标服务器(例如数据库/消息论坛/评论字段等)上时,存储型 XSS 也称为持久型 XSS。然后受害者能够从 Web 应用程序检索存储的数据。

  • 反射型 XSS - 当 Web 应用程序立即在错误消息/搜索结果中返回用户输入或用户作为请求的一部分提供的输入且不永久存储用户提供的数据时,会发生反射型 XSS 也称为非持久性 XSS 。

  • 基于 DOM 的 XSS - 基于 DOM 的 XSS 是 XSS 的一种形式,数据源位于 DOM 中,接收器也在 DOM 中,并且数据流永远不会离开浏览器。

例子

该应用程序在构建过程中使用了不可信的数据,且未经验证。特殊字符应该被转义。

http://www.webpage.org/task/Rule1?query=try

攻击者将浏览器中的查询参数修改为 -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

动手

步骤 1 - 登录 Webgoat 并导航至跨站脚本 (XSS) 部分。让我们执行存储跨站脚本 (XSS) 攻击。下面是该场景的快照。

3.xss

步骤 2 - 根据场景,让我们以 Tom 身份登录,密码为“tom”,如场景本身所述。单击“查看个人资料”并进入编辑模式。由于 Tom 是攻击者,让我们将 Java 脚本注入到这些编辑框中。

<script> 
   alert("HACKED")
</script> 
3.xss

步骤 3 - 更新结束后,汤姆会收到一个警告框,其中显示消息“已被黑客攻击”,这意味着该应用程序容易受到攻击。

3.xss

步骤 4 - 现在根据场景,我们需要以 jerry (HR) 身份登录并检查 jerry 是否受到注入脚本的影响。

3.xss

步骤 5 - 以 Jerry 身份登录后,选择“Tom”并单击“查看个人资料”,如下所示。

3.xss

当从杰瑞的帐户查看汤姆的个人资料时,他能够看到相同的消息框。

3.xss

步骤 6 - 此消息框只是一个示例,但实际攻击者可以执行的不仅仅是显示消息框。

预防机制

  • 开发人员必须确保根据 HTML 上下文(例如数据所在的正文、属性、JavaScript、CSS 或 URL)转义所有不受信任的数据。

  • 对于那些需要特殊字符作为输入的应用程序,在接受它们作为有效输入之前应该有强大的验证机制。