http-header-安全策略

2019-09-30

1.简介

一个java web项目使用华为云漏洞扫描服务，扫出了几百个低危漏洞，仔细查看一下，大多数是http header 安全策略配置。解决思路，使用Filter过滤大多数请求，添加请求头，解决大部分问题，剩下的具体分析。

2. 方法1 Filter过滤

2.1 MySecurityFilter

/**
 * @ClassName: MySecurityFilter 
 * @Description: 请求安全过滤
 * @author: aimigit
 * @date: 2019年9月26日 上午11:03:24
 */
public class MySecurityFilter implements Filter {
	@Override
	public void init(FilterConfig filterConfig) throws ServletException {
		// TODO Auto-generated method stub
	}
	@Override
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {
		HttpServletRequest req = (HttpServletRequest) request;
		HttpServletResponse res = (HttpServletResponse) response;
		res.setHeader("x-frame-options", "SAMEORIGIN");
		res.setHeader("X-XSS-Protection", "1; mode=block");
		res.setHeader("X-Content-Type-Options", "nosniff");
//		res.setHeader("Content-Security-Policy", "default-src 'self';");
		chain.doFilter(request, response);
	}
	@Override
	public void destroy() {
		// TODO Auto-generated method stub
	}
}

2.2web.xml配置

<filter>
	<filter-name>MySecurityFilter</filter-name>
	<filter-class>com.fourfaith.baseManager.filters.MySecurityFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>MySecurityFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

方法2，使用apache HttpHeaderSecurityFilter

tomcat8+版本支持HttpHeaderSecurityFilter,tomcat8以下版本需要下载httpHeaderSecurity.jar这个包.

<filter>
	<filter-name>httpHeaderSecurity</filter-name>
	<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
	<async-supported>true</async-supported>
	<init-param>
		<param-name>antiClickJackingEnabled</param-name>
		<param-value>true</param-value>
	</init-param>
	<init-param>
		<param-name>antiClickJackingOption</param-name>
		<param-value>SAMEORIGIN</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>httpHeaderSecurity</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

3.http header 参数说明

3.1x-frame-options

The X-Frame-Options HTTP 响应头是用来给浏览器 指示允许一个页面 可否在 <frame>, <iframe>, <embed> 或者 <object> 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免 clickjacking 攻击。

The added security is only provided if the user accessing the document is using a browser supporting X-Frame-Options. Content-Security-Policy HTTP 头中的 frame-ancestors 指令会替代这个非标准的 header。CSP 的 frame-ancestors 会在 Gecko 4.0 中支持，但是并不会被所有浏览器支持。然而 X-Frame-Options 是个已广泛支持的非官方标准，可以和 CSP 结合使用。

X-Frame-Options 有三个可能的值：
X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/
换一句话说，如果设置为 deny，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为sameorigin，那么页面就可以在同域名页面的 frame 中嵌套。
deny
表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
sameorigin
表示该页面可以在相同域名页面的 frame 中展示。
allow-from uri
表示该页面可以在指定来源的 frame 中展示。

参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/X-Frame-Options

3.2X-XSS-Protection

HTTP X-XSS-Protection 响应头是Internet Explorer，Chrome和Safari的一个功能，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。虽然这些保护在现代浏览器中基本上是不必要的，当网站实施一个强大的Content-Security-Policy来禁用内联的JavaScript (‘unsafe-inline’)时, 他们仍然可以为尚不支持 CSP 的旧版浏览器的用户提供保护。

语法
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
0
禁止XSS过滤。
1
启用XSS过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。
1;mode=block
启用XSS过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。
1; report=<reporting-URI>  (Chromium only)
启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。

参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-XSS-Protection

3.3X-Content-Type-Options

X-Content-Type-Options 响应首部相当于一个提示标志，被服务器用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型的设定，而不能对其进行修改。这就禁用了客户端的 MIME 类型嗅探行为，换句话说，也就是意味着网站管理员确定自己的设置没有问题。

这个消息首部最初是由微软在 IE 8 浏览器中引入的，提供给网站管理员用作禁用内容嗅探的手段，内容嗅探技术可能会把不可执行的 MIME 类型转变为可执行的 MIME 类型。在此之后，其他浏览器也相继引入了这个首部，尽管它们的 MIME 嗅探算法没有那么有侵略性。

站点安全测试人员通常欢迎对这个首部进行设置。

注意: nosniff 只应用于 “script” 和 “style” 两种类型。事实证明，将其应用于图片类型的文件会导致与现有的站点冲突。

语法
X-Content-Type-Options: nosniff
下面两种情况的请求将被阻止：
请求类型是"style" 但是 MIME 类型不是 "text/css"，
请求类型是"script" 但是 MIME 类型不是  JavaScript MIME 类型。

参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-Content-Type-Options

3.4 Content-Security-Policy

内容安全策略 (CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段。

CSP 被设计成完全向后兼容（除CSP2 在向后兼容有明确提及的不一致; 更多细节查看这里章节1.1）。不支持CSP的浏览器也能与实现了CSP的服务器正常合作，反之亦然：不支持 CSP 的浏览器只会忽略它，如常运行，默认为网页内容使用标准的同源策略。如果网站不提供 CSP 头部，浏览器也使用标准的同源策略。

为使CSP可用, 你需要配置你的网络服务器返回 Content-Security-Policy HTTP头部 ( 有时你会看到一些关于X-Content-Security-Policy头部的提法, 那是旧版本，你无须再如此指定它)。

1
2
3

除此之外,  <meta>  元素也可以被用来配置该策略, 例如
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

使用 CSP
配置内容安全策略涉及到添加 Content-Security-Policy  HTTP头部到一个页面，并配置相应的值，以控制用户代理（浏览器等）可以为该页面获取哪些资源。比如一个可以上传文件和显示图片页面，应该允许图片来自任何地方，但限制表单的action属性只可以赋值为指定的端点。一个经过恰当设计的内容安全策略应该可以有效的保护页面免受跨站脚本攻击。本文阐述如何恰当的构造这样的头部，并提供了一些例子。
制定策略
你可以使用  Content-Security-Policy HTTP头部 来指定你的策略，像这样:
Content-Security-Policy: policy
policy参数是一个包含了各种描述你的CSP策略指令的字符串。
描述策略
一个策略由一系列策略指令所组成，每个策略指令都描述了一个针对某个特定类型资源以及生效范围的策略。你的策略应当包含一个default-src策略指令，在其他资源类型没有符合自己的策略时应用该策略(有关完整列表查看default-src )。一个策略可以包含 default-src  或者 script-src 指令来防止内联脚本运行, 并杜绝eval()的使用。 一个策略也可包含一个 default-src 或  style-src 指令去限制来自一个 <style> 元素或者style属性的內联样式。

4.其他

IBM的AppScan软件也可以用来漏洞检测。

EOF.

点击量次