跨站脚本XSS防范

跨站脚本是最普遍的web应用安全漏洞。当应用程序在发送给浏览器的页面中包含用户提

供的数据，但没有经过适当验证或转译，就会导致跨站脚本漏洞。目前常见的XSS漏洞有反射式、存储式以及DOM三种类型。防御XSS攻击的主要手段是对关键字进行过滤或转义。

在CAP4J 4.0中，XSS防御原理是：对于页面传入的数据，根据sys.speChars配置进行字符串替换（由于是强制替换原则，如配置了＼＞，égt:则表示对于传入数据中，“＞”符号全部替换为“＆gt”符号，所以此处建议不进行配置，避免页面传入数据被修改；如果涉及敏感字符串过滤，则可以配置相应数据）；对于后台返回页面的数据，则根据character.properties配置进行字符转义（如返回数据中，字符逗号“，”的ASCII码值为34,将会被转义转为“在quot”，即逗号），页面收到转义后的数据，在做展示时，会转义为原字符进行显示。其中，sys.speChars配置是以分号“：”为间隔。每一段里以逗号“，”为间隔，逗号前面的如“＼＞”是待替换字符，逗号后面的是替换后的字符“＆gt”

跨站请求伪造CSRF防范

跨站请求伪造（CSRF)是利用了网站允许攻击者预测特定操作的所有细节这一特点。由于浏览器自动发送会话cookie等认证凭证，导致攻击者能够创建恶意的web页面来产生伪造请求。这些伪造的请求很难和合法的请求区分开。CSRF与XSS不同，XSS利用站点内的信任用户，而CSKF则通过伪装来自受信任用户的请求来利用受信任的网站。

CSRF 攻击一般针对是数据变化类的操作如POST方法，不针对资源请求类操作如GET方法，故表单提交或者ajax请求应严格使用post方提交，CAP4J平台V4.0中已经集成CSRF防御框架

检验CSRF功能是否生效，可在浏览器工具中查看请求（F12打开），在数据提交请求中可看到x-csrf-token字段（若请求没有此token或值不正确，会报没有权限的错误），表明相关防御机制已经生效。

Host Header、Referer 攻击防范

Host Header 及Referer攻击容易造成网页被恶意重定向。为防范请求头中Host和Referer

被恶意篡改的情况

任意文件上传防御

任意文件上传下载容易造成恶意文件上传

通过配置码表, 只允许用户上传.txt,.doc,.docx,.pdf等文件, 不允许上传.exe, .sh等可执行文件. 为进一步限制文件类型伪造, 支持对文件头, 文件尾特征值配置

当用户上传的文件类型不符时, 会拒绝不允许上传

任意文件下载防御

任意文件下载会出现下载未经授权的文件等问题

点击劫持防范

点击劫持，也被称为UI覆盖攻击，攻击者将一个网页嵌入到一个透明的、不可见的 iFrame中，

用户在某页面正常点击时因为嵌入的页面不可见，导致恶意点击了某些链接。为防范点击劫持，点击劫持一般通过在页面中限制iframe的使用避免。可通过下面方式进行配置：

Apache可配置http.cof如下：

<IfModule headers_module>Header always append-X-Frame Options "DENY"</IfModule>

Ngix可以在’http’’,’server’,’location’中增加

<span add_header_X-Frame Optians DENY ;></span>
```    

# 不安全的浏览器方法防范
    
当服务器进行HTTP请求,请求使用了OPTIONS方法时, 服务器会返回所有支持的HTTP方法:

由于OPTIONS方法可以获取服务器的信息, 此种机制有助于恶意攻击者收集信息,并准备更高级的攻击. 

所以需要拒绝OPTIONS请求 (对OPTIONS请求使用403 forbidden)

# HTTP参数篡改防御
    
post请求参数在传输的过程中有可能被篡改, 所以需要编写过滤器验证所有的post请求参数在传输的过程中是否被篡改的校验

# X-Content-Type-Options配置
    
部分浏览器具备MIME sniffing或者MIME类型检测方法，当response的 Content-Type格式和实际返回内容类型不一致或者不存在Content-Type时，该功能将尝试按照文件的实际类型解析文件类型，因而存在嗅探攻击的漏洞。因此，建议用户为每个response设置具体的Content-Type格式，并禁止浏览器进行MIME类型检测。为防止Content-Type嗅探，可在 response响应头配置 X-Content-Type-Optians:nosniff标志，该标志提示浏览器－定要遵循Content-Type中对MIME的设定，而不尝试进行类型检测。

# X-XSS-Protection配置
    
浏览器一般都内置有防范反射型XSS攻击的功能,当response返回头中有X-XSS-Protection时,表示启用了该功能
```text
X-XSS-Protection:0禁用XSS过滤器
X-XSS-Protection:1:mode=block 若找到XSS,则不要渲染文档
X-XSS-Protection:2删除不安全的部分

跨域站点访问

X-Forward-For/IP伪造防御

应用程序中一般有记录用户IP地址的需求，HTIP协议中的X-Forwarded-For头可用于标识用户IP,但该信息存在被伪造的可能，IP地址伪造的防御和应用具体的场景有关，除了在应用编码中需要注意外，中间件配置也需要留意。

场景1:如果CAP4J应用在部署中未使用Apache、Hginx、F5等负载均衡设备，则在PlatforaCorfiguration码表的isUseProxy设置为0,应用程序将直接使用 Java API中的getRemoteAddr0方法获取客户IP,该场景下能很好地抵御IP伪造。

场景2:如果CAP4J应用部署中使用了Apache、Nginx、F5等负载均衡设备，那么上述开关设置为0时，应用程序获取到的客户IP地址为Apache、Nginx、F5的地址，而非实际的客户机IP地址，若此时需要真实记录客户IP地址，则需要读取X-Forwarded-For 中的IP信息，为了防御IP地址伪造，此时需要在Apache、Ngirx、F5上进行相应的配置以防御IP伪造。如果项目组使用了Apache、Nginx、F5等负载均衡设备，但应用中对客户机IP地址没有非常准确的要求，建议使用场景1方案，此场景下虽然获取到的客户IP是代理设备的IP,但是能很好地避免IP伪造。

备注：

isUseProxy设置为0,应用仅会使用 getRemoteAddr 0方法获取 IP;

isUseProxy设置为1,会按”X-Real-IP”,”X-Forwarded-For”, “WL-Proxy-Client-IP”, getRenateAddr 0的顺序取值。

垂直越权防御

垂直越权是指低权限用户可以访问到高权限用户才能访问到的数据, 可以使用高权限用户才能使用的功能

水平越权防御

水平越权是指同级权限的人员能访问到同级权限其他人员的信息

水平越权解决的是数据操作问题，如果把数据按照“行”的形式看待，一般一行数据包括主键等关键信息字段，为了解决同级别权限的人员通过修改此类关键字段从而访问到不应访问的数据，业务逻辑后台需要在修改、删除等业务逻辑处对是否能访问关键数据进行校验，校验成功才能继续后续的业务处理。

审计日志

对系统某个关键功能进行的操作要写审计日志

数据脱敏

对客户敏感的数据要做脱敏, 比如电话号码

对数据库等密码进行加密(参照程序羊B站的博客)

未验证的重定向和转发

应用程序经常将用户重定向到其他网页，或以类似的方式进行内部转发。当目标网页是通过一个未验证的参数来指定时，就容易被攻击者利用。

攻击者通过诱使受害人去点击未经验证的重定向链接，从而利用不安全的转发绕过安全检测。攻击者通过重定向可以试图安装恶意软件或者诱使受害人泄露密码等敏感信息，通过转发可以绕过访问控制。

项目组在业务逻辑开发中，也需要注意：避免使用重定向和转发如果使用了重定向和转发，则不要在确定目标时涉及到用户参数如果无法避免使用目标参数，则应确保目标参数值对于当前用户是有效的并已授权

限制启用目录列表

用户通过直接访问url可能会查看和下载特定Web 应用程序虚拟目录的内容，可能会泄露用户环境中的文件结构，给第三方的web攻击提供信息。

例如直接访问某个应用的资源目录地址，如http://127.0.0.1:8080/test/resources/会列出下面的文件目录

该问题不属于代码问题，一般需要在所在的中间件上进行配置，参考配置方式如下：

在apache中编辑conf/httpd conf,将“Options Indexes FollowSymLinks”改为“OptionsFollowSymLinks”.

在weblogic中查询weblogic.xml 下的标签，值为true或者false,默认为false(不显示目录列表）。

在tomcat中查询conf/web.xml中名字为 default的servlet,将其中的listings的值配置为false·如下

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org-apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-nane>listings</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

为cookie增加http only,expire,secure属性

为cookie设置HTTP-ONLY属性后,无法通过JS中的document.cookie方法获取cookie,但浏览器本身还是能够读取到cookie值,该配置属于防御XSS的手段之一,能够有效提升应用安全.

tomcat: 在conf/context.xml中配置

weblogic: 生成的JSESSIONID不需要手动配置, 默认自带HttpOnly属性

1.如果项目组在业务代码中有使用cookie存储数据,也需要在代码层面为cookie设置HTTP-ONLY属性, 示例代码如下:

StringBuffer cookieBuffer = new StringBuffer();
cookieBuffer.append("newcookie=defalutName");
cookieBuffer.append(":path="+request.getContextPath());
cookieBuffer.append(":HttpOnly");
response.addHeader("Set-cookie",cookieBuffer.toString());
```    

2.在web.xml中新增配置, 为cookie新增expire,secure属性

注意: max-age超时时间单位为秒, session-timeout超时时间单位为分钟

cookie超时后, 再次访问系统时无法获取用户的jsessionid会导致重新登录

secure属性在https的情况下才会生效
```xml
<session-config>
    <session-timeout>30</session-timeout>
    <cookie-config>
        <max-age>300</max-age>
        <secure>true</secure>
    </cookie-config>
</session-config>

QinCloudShaw

学习记录: 记录前端,后端,Java开发相关知识