Web安全前端常见问题以及处理方法
近期收到一些客户的安全问题，有很多前端的问题，被客户用工具扫描处理，下面是将这些问题整理出来一下:
目录
1. 加密会话（SSL）Cookie 中缺少 Secure 属性
3. “Content-Security-Policy”头缺失或不安全
4.“X-Content-Type-Options”头缺失或不安全
1. 加密会话（SSL）Cookie 中缺少 Secure 属性
安全威胁：
- 任何以明文形式发送到服务器的 cookie、会话令牌或用户凭证之类的信息都可能被窃取，并在稍后用于身份盗窃或用户伪装，此外，若干隐私法规指出，用户凭证之类的敏感信息要始终以加密的方式发送到 Web 站点。
产生原因:
- web服务器是apache http server，配置了ssl加密传输，这个问题说的是在ssl传输中，系统所用的cookie没有进行设置secure属性
修复方法
首先cookie分为两种，一种是用户浏览器请求应用服务器建立的会话所存的会话cookie，cookie名称为JSESSIONID，第二种为系统运行时因记录登录信息或其他用途而产生的各种cookie。
第一种修复配置如下：
第二种修改代码，参考如下：
1）服务器配置为HTTPS SSL方式
2）Servlet 3.0 (Java EE 6)的web.xml 进行如下配置：
<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>
3）ASP.NET的Web.config中进行如下配置：
<httpCookies requireSSL="true" />
4）php.ini中进行如下配置
session.cookie_secure = True
或者
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain
[, bool $secure= false [, bool $httponly= false ]]]] )
或者
bool setcookie ( string $name [, string $value [, int $expire= 0 [, string $path
[, string $domain [, bool $secure= false [, bool $httponly= false ]]]]]] )
5）weblogic中进行如下配置：
<wls:session-descriptor>
<wls:cookie-secure>true</wls:cookie-secure>
<wls:cookie-http-only>true</wls:cookie-http-only>
</wls:session-descriptor>
2. Cookie没有HTTP Only标志漏洞
安全威胁：
- 会话cookie中缺少HttpOnly属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的cookie信息，造成用户cookie信息泄露，增加攻击者的跨站脚本攻击威胁
产生原因:
- HttpOnly是微软对cookie做的扩展，该值指定cookie是否可通过客户端脚本访问。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie属性HttpOnly。如果在Cookie中没有设置HttpOnly属性为true，可能导致Cookie被窃取。窃取的Cookie可以包含标识站点用户的敏感信息，攻击者可以重播窃取的Cookie，以便伪装成用户或获取敏感信息，进行跨站脚本攻击等。如果在Cookie中设置HttpOnly属性为true，兼容浏览器接收到HttpOnly cookie，那么客户端通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这将有助于缓解跨站点脚本威胁
修复方法
- 在Web工程上增加对Cookie进行处理，设置httponly属性
修复代码参考：
-
response.setHeader("Set-Cookie", "cookiename=httponlyTest;Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly"); 例如： //设置cookie response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly") //设置多个cookie response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly"); response.addHeader("Set-Cookie", "timeout=30; Path=/test; HttpOnly"); //设置https的cookie response.addHeader("Set-Cookie", "uid=112; Path=/; Secure; HttpOnly"); 具体参数的含义再次不做阐述，设置完毕后通过js脚本是读不到该cookie的，但使用如下方式可以读取。 Cookie cookies[]=request.getCookies();
3. “Content-Security-Policy”头缺失或不安全
安全威胁：
- 可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置
- 可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息。
产生原因:
- Web 应用程序编程或配置不安全
修复方法
将服务器配置为发送“Content-Security-Policy”头。
- 关于 Apache，请参阅：http://httpd.apache.org/docs/2.2/mod/mod_headers.html
- 关于 IIS，请参阅：https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx
- 关于 nginx，请参阅：http://nginx.org/en/docs/http/ngx_http_headers_module.html
前端修复代码参考：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'"/>4.“X-Content-Type-Options”头缺失或不安全
安全威胁：
- 可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置
- 可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息。
产生原因:
- Web 应用程序编程或配置不安全
修复方法
将服务器配置为针对所有外发请求发送具有值“nosniff”的“X-Content-Type-Options”头。
- 关于 Apache，请参阅：http://httpd.apache.org/docs/2.2/mod/mod_headers.html
- 关于 IIS，请参阅：https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx
- 关于 nginx，请参阅：http://nginx.org/en/docs/http/ngx_http_headers_module.html
前端修复代码参考：
<meta http-equiv="X-Content-Type-Options" content="nosniff" />5.“X-XSS-Protection”报头缺失或不安全
安全威胁：
- 可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置
- 可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息。
产生原因:
- Web 应用程序编程或配置不安全
修复方法
配置您的服务器，以确保在所有传出请求上发送值为“1”（即已启用）的“X-XSS-Protection”报头。
- 关于 Apache，请参阅：http://httpd.apache.org/docs/2.2/mod/mod_headers.html
- 关于 IIS，请参阅：https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx
- 关于 nginx，请参阅：http://nginx.org/en/docs/http/ngx_http_headers_module.html
前端修复代码参考：
<meta http-equiv="X-XSS-Protection" content="1; mode=block" />6.HTTP 严格传输安全头缺失或不安全
安全威胁：
- 可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置
- 可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息。
产生原因:
- Web 应用程序编程或配置不安全
修复方法
通过将“Strict-Transport-Security”响应头添加到 Web 应用程序响应来实施 HTTP 严格传输安全策略。
前端修复代码参考：
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload7. 发现可高速缓存的 SSL 页面
安全威胁：
- 可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置
产生原因:
-
浏览器可能已将敏感信息高速缓存
修复方法
在所有 SSL 页面及含有敏感数据的所有页面上，禁用高速缓存。
通过使用你您 SSL 页面标题中的“Cache-Control: no-store”和“Pragma: no-cache”或“Cache-Control: no-cache”响应伪指令来实现此操作。
Cache-Control: private - 此伪指令可向代理指示某个页面中包含私有信息，因此不能由共享高速缓存进行高速缓存。但是，它不会指示浏览器阻止高速缓存此页面。
Cache-Control：no-cache - 此伪指令也可向代理指示某个页面中包含私有信息，因此不能高速缓存。它还会指示浏览器重新验证服务器以检查是否有新的版本可用。这意味着浏览器可能会存储敏感页面或要在重新验证中使用的信息。某些浏览器不一定会跟踪 RFC，因此可能会将 no-cache 视为 no-store。
Cache-Control：no-store - 这是最安全的伪指令。它同时指示代理和浏览器不要高速缓存此页面或将其存储为它们的高速缓存文件夹。
Pragma: no-cache - 对于不支持高速缓存控制标题的较旧浏览器，该伪指令是必需的。
8. X-Frame-Options(点击劫持)
安全威胁：
1. 点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的iframe，覆盖在一个网页上，然后诱使用户在网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。
2. HTTP响应头信息中的X-Frame-Options，可以指示浏览器是否应该加载一个iframe中的页面。如果服务器响应头信息中没有X-Frame-Options，则该网站存在ClickJacking攻击风险。
产生原因:
-
网站可以通过设置X-Frame-Options阻止站点内的页面被其他页面嵌入从而防止点击劫持。
修复方法
修改web服务器配置，添加X-Frame-Options响应头。赋值有如下三种：
1、DENY：不能被嵌入到任何iframe或者frame中。
2、SAMEORIGIN：页面只能被本站页面嵌入到iframe或者frame中
3、ALLOW-FROM uri：只能被嵌入到指定域名的框架中
apache可配置http.conf如下：
<IfModule headers_module> Header always append X-Frame-Options "DENY" </IfModule>比如如果我们使用phpstudy搭建的环境，我们可以 其他选项菜单—> php扩展及设置—>Apache模块，勾选 headers_module 模块，然后在Apache的配置文件 httpd.conf 中的空白行加入 Header always append X-Frame-Options SAMEORIGIN 即可！
9. 文件上传类型不做限制漏洞
安全威胁：
- 文件上传的类型，前后端没有做限制的话，存在将可执行文件上传到服务器的风险，攻击者可以利用此漏洞达到远程控制系统的母的。
产生原因:
-
前后端上传类型没有做限制。
修复方法
- 因为该主要是针对前端的处理，所以该处的主要是前端针对上传的文件类型做限制。如exe, sh等可执行程序禁止上传。
10. 输入校验
安全威胁：
- 对于表单的输入处，没有进行处理或限制，攻击者可以利用该漏洞进行XSS 攻击
产生原因:
- 输入类型没有做限制，可能会引起XSS的攻击
- 输入长度没有做限制。第一，可能会引起功能问题，第二，可能会引起在弹出的错误提示钟敏感信息泄露。
修复方法
- 对前端输入进行校验，针对涉及到XSS的特殊字符和关键字进行过滤
- 对输入处文本框的长度和类型做正确的限制。
11. 前端加密
针对这块，会单独更新一个博客来阐述。。。。。
扫一扫
459
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
