xss反射型和存储型

1、反射型

1.1 发生场景

目标网站某处，用户可以get或post基于url的直接参数或路径参数提交数据，或者get或post基于表单form提交数据。(具体取决于服务端接收的编程方法)

服务端接收到数据后，未经过充分检测，将其写入到响应的html页面中。

如果该数据是攻击者构造的payload，可以包含某些敏感字符，造成响应html文档的结构的改变，从而payload的部分文本解析为js脚本执行。

1.2 利用过程

攻击者在测试发现目标网站某处存在反射型xss漏洞后，可以构造包含执行危害功能的脚本代码的payload。

(1)payload在url中

攻击者将url通过聊天工具、邮件、短信、站内通信等将url发送给受害者，其点击之后访问目标网站，自动触发漏洞。

还可以是用户访问攻击者控制的网站，主动点击页面中链接或者基于脚本被动跳转，从而请求包含payload的url。

(2)payload在表单中

只能是用户访问攻击者控制的网站，主动点击页面中按钮或者基于脚本被动向目标网站，提交体部以form形式包含payload的请求。

1.3 测试步骤

(1)分析请求-响应的基本信息

• 状态码并不严格要求是200,404和500等也有可能
• 需要存在参数，一般是url的直接参数和请求体部参数，路径参数也有可能
• 响应类型必须是html，即响应content-type必须包含text/html关键字
• 响应体部长度必须大于0，不能为空

(2)测试响应中是否包含返回

• 测试是先对一个参数进行完全的测试，再测试下一个参数
• 如果待测参数在响应中并不包含，那么就完全不可能存在反射型xss。只有存在，才进行后续测试
• 注意，这里的待测参数的值
  • 一般是设置为abx、zaz这种短小、不包含敏感字符、且在响应中不固定包含的关键词
  • 另一种情况，是设置为包含敏感字符或特殊的，以使响应为异常状态而包含关键词作为提示，比如500、404、防火墙或搜索未发现、参数异常提示

(3)分析输出点情况

如果响应中包含测试的一般文本，可能并不只一处输出，而这些输出点的类型可能不同。

不同输出点类型，需要采取不同的构造payload的策略。

• 输出到一般html元素的文本中
  • 可以尝试构造script元素，直接引入外部脚本
  • 可以尝试构造script元素，编写内部脚本
  • 可以尝试构造img等元素，基于事件编写脚本
• 输出到特殊html元素的文本中
  • 比如title、style元素
  • 在这些元素中，其他元素并不会被解析执行，因此必须先使用结束标签关闭，然后构建新的元素
• 输出到script标签的内容中
  • 任意处，如果能够写入</script>，那么可以关闭script标签再构建新的元素
  • 可能是作为注释内容，也可能是变量字面值，或者方法实参
  • 一般的措施是关闭当前结构，比如引号、括号，然后基于;或+或\n拼接新的脚本代码
• 输出到html元素的属性或事件中
  • 可以考虑关闭当前元素的开始标签，构建新的元素。还可以再关闭当前元素的结束标签，再构建新的元素
  • 当然，也可以在某些特殊的元素的特殊属性进行篡改，比如form的action
  • 还可以直接在当前元素的事件中写入脚本
  • 需要注意，如果服务端是对敏感字符'转写为\'，在html元素的开始标签中是不起作用的。正确的应该是进行html实体编码
• 输出到html注释中
  • 关闭注释，构建新的元素

(3)测试敏感字符

payload一般会使用到以下敏感字符，而服务端的检查代码和防护墙一般也是针对这些字符进行。

在正式测试前，测试敏感字符哪些被过滤可以减轻测试任务量。

'"<>\/

(4)分析返回的输出点以及敏感字符过滤情况，构造或筛选payload集合

• 能够直接引入外部js的payload作为优先测试
• 其次是构造script内部脚本、事件脚本、地址属性

(5)对payload集合进行遍历测试，分析是否测试成功，注意防火墙基于关键词的干扰因素

(6)构造可造成危害的脚本

1.4 防护

(1)编码

• 输出到各处时，结合输出点类型进行编码
• 一般场景是进行html实体编码，包括元素属性值、元素事件中的字面量、元素包含的文本
• 对于script内的脚本的字面量，进行js转义编码，即添加\前缀
• 某些方案中，对元素的地址属性值中的敏感字符，会使用url编码，即%编码。比如a的href、form的action、script的src、link的href等

(2)cookie添加httponly标志，以避免脚本读取

(3)一些响应字段的设置

XSS（跨域脚本攻击）应对之道 | XSS (lmlphp.com)

2、存储型

xss反射型和存储型具有很大的类似性。

2.1 发生场景

目标网站某处，用户可以基于ajax或非ajax保存数据到服务端。

其他用户可以请求访问包含该数据的html页面，服务端未经过严格检查，将其写入到响应的html页面中。

如果该数据是攻击者构造的payload，可以包含某些敏感字符，造成响应html文档的结构的改变，从而payload的部分文本解析为js脚本执行。

反射型是在一个请求-响应中发生。而存储型是两个请求-响应。

2.2 利用过程

攻击者在测试发现目标网站某处存在存储型xss漏洞后，可以构造包含执行危害功能的脚本代码的payload保存到服务端。

可能的触发过程：用户自然状态下浏览到包含payload的页面，或者主动在通信工具中点击链接，或者在攻击者控制站点跳转。

注意相比包含payload的反射型xss请求，存储型xss中受害者提交的请求中，服务端并不会检查到恶意参数。

2.3 测试步骤

和反射型基本一致，区别是作为分析的响应应该是提交payload后的第二个请求的响应

2.4 防护

和反射型基本一致，都是在服务端对参数输出到html页面中时，进行转码处理，当然也包括其他措施。