你的网站安全吗？ZAP应用实例_未启用web浏览器xss保护
赞
踩
按照清华大学出版社出版的新书《软件测试实战教程》第8章安全性测试，测试了一个Web应用，发现了5种问题。如图所示：
对每一种问题进行了分析，并提出了解决方案。解决问题后，再用ZAP扫描，已经没有这些问题了。
X-Frame-Options Header Not Set
X-Frame-Options HTTP 响应头未设置
说明：HTTP响应中不包含X-Frame-Options头，以防止“clickjacking”（点击劫持）攻击。
X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object>中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，避免点击“clickjacking”（点击劫持） 的攻击。
X-Frame-Options有三种可配置值
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
DENY
表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
SAMEORIGIN
表示该页面可以在相同域名页面的 frame 中展示。
ALLOW-FROM uri
表示该页面可以在指定来源的 frame 中展示。
注: 在网页中设置meta标签是无用的!例如，<meta http-equiv="X-Frame-Options" content="deny"> 是没有效果的。不要使用这种方式。可以在Web服务器中配置，使得HTTP响应中包含X-Frame-Options。
解决方案：在web.xml中增加如下配置：
<filter>
<filter-name>HeaderFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.HeaderFilter</filter-class>
<init-param>
<param-name>headerConfig</param-name>
<param-value>
set X-Frame-Options: SAMEORIGIN,
"add Cache-Control: no-cache, no-store, must-revalidate",
setDate Expires: 31540000000,
addDate Date: 0,
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>HeaderFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
我测试的项目是用Maven构建的，我增加了如下依赖：
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlets</artifactId>
<version>9.4.19.v20190610</version>
</dependency>
Cookie No HttpOnly Flag
Cookie没有HttpOnly标志
说明：一个cookie被设置为不带HttpOnly标志，这意味着该cookie可以被javascript访问。如果可以在此页面上运行恶意脚本，则cookie将可以被恶意脚本访问，并可以传输到其他站点。如果这是会话cookie，则可能发生会话劫持。
解决方案：确保为所有cookie设置了HttpOnly标志。Servlet 3.0支持在web.xml进行会话cookie设置:
<web-app>
<session-config>
<cookie-config>
<!--
Specifies whether any session tracking cookies created
by this web application will be marked as HttpOnly
-->
<http-only>true</http-only>
</cookie-config>
</session-config>
</web-app>
在我测试的Web应用中，web.xml原来包含如下代码：
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
我修改为如下的代码，以支持进行会话cookie设置：
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
X-Content-Type-Options Header Missing
X-Content-Type-Options HTTP 响应头缺失
说明：X-Content-Type-Options 是用来禁用浏览器内容嗅探行为的。内容嗅探技术可能会把不可执行的 MIME 类型转变为可执行的 MIME 类型。反MIME嗅探头x-content-type-options未设置为“nosniff”，这允许旧版本的Internet Explorer和Chrome在响应主体上执行mime嗅探，可能导致响应主体被解释并显示为声明的内容类型以外的内容类型。
注意: nosniff 只应用于 "script" 和 "style" 两种类型。事实证明，将其应用于图片类型的文件会导致与现有的站点冲突。
X-Content-Type-Options: nosniff
这个设置使得下面两种情况的请求将被阻止：
- 请求类型是"style" 但是 MIME 类型不是 "text/css"，
- 请求类型是"script" 但是 MIME 类型不是 JavaScript MIME 类型。
解决方案：在web.xml中增加如下配置：
<filter>
<filter-name>HeaderFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.HeaderFilter</filter-class>
<init-param>
<param-name>headerConfig</param-name>
<param-value>
set X-Content-Type-Options: nosniff
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>HeaderFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
未启用Web浏览器XSS保护
说明：Web浏览器XSS保护未启用，或被Web服务器上“x-xss-protection”HTTP响应头的配置禁用。
XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的. 比如获取用户的Cookie，导航到恶意网站,携带木马等。
为了防止发生XSS， 很多浏览器厂商都在浏览器中加入安全机制来过滤XSS。 例如IE8，IE9，Firefox, Chrome. 都有针对XSS的安全机制。 浏览器会阻止XSS。
解决方案：通过将X-XSS-Protection HTTP响应头设置为“1”，确保已启用Web浏览器的XSS筛选器。在web.xml中增加如下配置：
<filter>
<filter-name>HeaderFilter</filter-name>
<filter-class>org.eclipse.jetty.servlets.HeaderFilter</filter-class>
<init-param>
<param-name>headerConfig</param-name>
<param-value>
set X-XSS-Protection:1
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>HeaderFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Loosely Scoped Cookie
说明：cookies可以按域或路径划分范围。此检查仅与域作用范围有关。应用于cookie的域作用范围确定哪些域可以访问它。例如，一个cookie可以严格地限定在子域范围内，例如www.nottrusted.com，或者松散地限定在父域范围内，例如nottrusted.com。在后一种情况下，nottrusted.com的任何子域都可以访问cookie。范围松散的cookie在像google.com和live.com这样的大型应用程序中很常见。从app.foo.bar等子域设置的cookie只能通过浏览器传输到该域。但是，作用于父级域的cookie可以传输到父级域或父级域的任何子域。
解决方案：始终将cookie范围限定到一个FQDN（完全限定的域名）。
我测试的Web应用网址是http://localhost:9000，修改为http://www.example.org，ZAP就没有报这个警报了。
