针对防火墙HTTP严格传输安全保障、Http响应头缺失 、CSRF漏洞说明

漏洞一：检测到缺少Strict-Transport-Security响应头

【原理介绍】

Strict-Transport-Security响应头是要求客户端（即PC浏览器）禁用HTTP协议。尝试后续都通过HTTPS协议进行通信。

由于HTTPS协议存在加密层，本身更安全，故该响应头也是为了安全考虑，希望服务端能返回。

漏洞二：检测到缺少Content-Security-Policy响应头

扫漏软件，应该只检测HTTP响应报文中是否存在Content-Security-Policy字段。并不关心其他防范XSS注入的操作。

漏洞三：CSRF漏洞

【CSRF漏洞简述】

用户登录了我司设备网址，COOKIE中记录了我司的session信息（第一步）

------>我司设备网站没有退出时，用户登陆了钓鱼网站B。（第二步）

------->钓鱼网站B伪造了一个类似我司设备网站的请求，并发送给了我司设备网站，请求的URL是我司域名，请求会携带我司设备网站的COOKIE----这是浏览器客户端的行为。（第三步）

                            ------>我司网站如果没有对CSRF漏洞进行规避，这样就会认为，第三步发送的请求是个正常合法的请求，并响应第三步的请求。（第四步）

至此，从上面四步，就进行了一次CSRF的攻击。

以上漏洞我司均不涉及。详细解释如下：

漏洞一：检测到缺少Strict-Transport-Security响应头

【原理介绍】

Strict-Transport-Security响应头是要求客户端（即PC浏览器）禁用HTTP协议。尝试后续都通过HTTPS协议进行通信。

由于HTTPS协议存在加密层，本身更安全，故该响应头也是为了安全考虑，希望服务端能返回。

【扫漏原理】

扫漏软件应该只检测HTTP响应报文中是否存在Strict-Transport-Security该响应报文，并不关心设备侧具体配置。所以报了这个漏洞

【规避措施】

从该报文实现原理上可以有如下解释：

由于现场设备本身不开启HTTP，只开启HTTPS。本身已经可以确保所有请求通过HTTPS协议进行传输。所以该报文头即使不返回，也不会有安全隐患。

漏洞二：检测到缺少Content-Security-Policy响应头

【原理介绍】

Content-Security-Policy又称内容安全策略，实际上就是告诉客户端（即PC浏览器）什么行为是被授权的，什么行为是被禁止的。主要用来解决XSS注入漏洞。

他的响应内容主要包括如下表格

指令名  Demo    说明

default-src  'self' ***.***   默认策略,可以应用于js文件/图片/css/ajax请求等所有访问

script-src     'self' ***.***      定义js文件的过滤策略

style-src      'self' ***.***    定义css文件的过滤策略

img-src 'self' ***.***  定义图片文件的过滤策略

connect-src 'self'      定义请求连接文件的过滤策略

font-src ***.***    定义字体文件的过滤策略

object-src    'self'      定义页面插件的过滤策略,如 <object>, <embed> 或者<applet>等元素

media-src    ***.*** 定义媒体的过滤策略,如 HTML6的 <audio>, <video>等元素

frame-src    'self'      定义加载子frmae的策略

sandbox       allow-forms allow-scripts     沙盒模式,会阻止页面弹窗/js执行等,你可以通过添加allow-forms allow-same-origin allow-scripts allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, and allow-top-navigation 策略来放开相应的操作

report-uri    /some-report-uri     指定报告发送的地址

从上面可以看到，这个响应内容包括了基本上所有页面上可以使用的资源。

响应报文的值：大多数都是两个选择（1）站点内部加载，（2）某个域名下加载。

目的：为了解决XSS注入攻击

【XSS注入攻击】

简单介绍一下XSS注入攻击。

XSS注入攻击可以解释为：攻击者在本网站站点，通过篡改客户端代码，或者引用外部代码，向服务端或数据库中注入一段攻击代码。

当攻击代码再次被请求或者，在服务端运行时，达到攻击效果。

【扫漏原理】

扫漏软件，应该只检测HTTP响应报文中是否存在Content-Security-Policy字段。并不关心其他防范XSS注入的操作。

【解释】

1.    首先我司设备之前已经分析过，XSS注入攻击时不生效的。注入代码不会执行。达不到攻击动作。

2.    其次，为了防止XSS注入攻击，我司设备也返回了响应头X-XSS-Protection要求客户端开启XSS防护器。

漏洞三：CSRF漏洞

【CSRF漏洞简述】

用户登录了我司设备网址，COOKIE中记录了我司的session信息（第一步）

------>我司设备网站没有退出时，用户登陆了钓鱼网站B。（第二步）

------->钓鱼网站B伪造了一个类似我司设备网站的请求，并发送给了我司设备网站，请求的URL是我司域名，请求会携带我司设备网站的COOKIE----这是浏览器客户端的行为。（第三步）

                            ------>我司网站如果没有对CSRF漏洞进行规避，这样就会认为，第三步发送的请求是个正常合法的请求，并响应第三步的请求。（第四步）

至此，从上面四步，就进行了一次CSRF的攻击。

【CSRF漏洞业界方案】

方案一：采用HTTP报文中的Referer字段，处理CSRF漏洞攻击。 -------- 我司采用

1.    HTTP中的referer字段，标明了请求的来源地址。HTTP协议规范中说明，该字段是由客户端自动生成，不允许人为修改

2.    例如：上述攻击的第三步，当钓鱼网站B，伪造了一个攻击请求，此时该攻击请求的HTTP报文中，携带的referer字段为钓鱼网站B的域名地址。而该攻击请求的URL为我司域名地址

3.    我司设备HTTP服务器，对于请求会校验请求的URL和referer是否相同。当referer和URL相同时，我认为当前请求来源是我司设备网站。当referer和URL不同时，我认为请求来源为第三方网站，并拒绝该请求的回复

方案二：采用携带随机token值的方案，对请求进行检测。 ------方案二有很多种不同的思路，下述大概思路流程

1.    我司设备的HTTP 服务器在生成session信息的时候，同时对session绑定一个随机生成的token，并返回给网站前端。

2.    网站前端存储该token随机值，在下一次请求的时候携带该随机值。

3.    我司设备的HTTP服务器在收到下一次请求的时候，解析该随机值，并进行校验。若校验通过，则更新随机值返回前台，并认为该次请求为合法请求。若校验不通过则认为该次请求不合法，拒绝该请求。

4.    前台每一次请求都会对应一个新的随机值。后台的随机值也在不断变化。

【结论】

1.    当前扫漏软件，给出的是使用token的方案取解决CSRF漏洞。推测可能该三方扫漏软件只认可token的修改方案。

2.    实际上，我司使用的referer修改方案，同样可以解决CSRF漏洞。