Web安全前端常见问题以及修复方法

　　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 严格传输安全策略。

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

前端修复代码参考：

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload

7. 发现可高速缓存的 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 即可！

Web安全前端常见问题以及修复方法

9. 文件上传类型不做限制漏洞

安全威胁：

文件上传的类型，前后端没有做限制的话，存在将可执行文件上传到服务器的风险，攻击者可以利用此漏洞达到远程控制系统的母的。

产生原因:

前后端上传类型没有做限制。

修复方法

因为该主要是针对前端的处理，所以该处的主要是前端针对上传的文件类型做限制。如exe, sh等可执行程序禁止上传。

10. 输入校验

安全威胁：

对于表单的输入处，没有进行处理或限制，攻击者可以利用该漏洞进行XSS 攻击

产生原因:

输入类型没有做限制，可能会引起XSS的攻击
输入长度没有做限制。第一，可能会引起功能问题，第二，可能会引起在弹出的错误提示钟敏感信息泄露。

修复方法

对前端输入进行校验，针对涉及到XSS的特殊字符和关键字进行过滤
对输入处文本框的长度和类型做正确的限制。

11. 前端加密

针对这块，会单独更新一个博客来阐述。。。。。

Web安全前端常见问题以及修复方法

Web安全前端常见问题以及处理方法

1. 加密会话（SSL）Cookie 中缺少 Secure 属性

2. Cookie没有HTTP Only标志漏洞

3. “Content-Security-Policy”头缺失或不安全

4.“X-Content-Type-Options”头缺失或不安全

5.“X-XSS-Protection”报头缺失或不安全

6.HTTP 严格传输安全头缺失或不安全

7. 发现可高速缓存的 SSL 页面

8. X-Frame-Options(点击劫持)

9. 文件上传类型不做限制漏洞

10. 输入校验

11. 前端加密

Web编程入门 1.3 前端与后台的交互--ajax方法以及ajax方法下get与post 的区别

web前端高级 - 深挖new的实现原理并封装自己的new以及实现内置类原型方法的扩展