web应用下的安全问题以及tomcat/nginx对应解决方法（持续更新、亲测可解决问题）

时间：2023-03-09 03:52:38
web应用下的安全问题以及tomcat/nginx对应解决方法（持续更新、亲测可解决问题）

最近一券商那边扫描反馈了下面几个非业务型安全漏洞，要求解决，如下：

XSS

自己写个脚本response的时候对特殊字符进行了处理，或者网上搜下一堆（不要忘了回车、换行）。

HTML form without CSRF protection

Cross-site request forgery，即跨站请求伪造，也称为 "One Click Attach" 或者"Session Riding"，常缩写成CSRF。是 通过伪装来自受信任用户的请求来利用受信任的网站 。

其中，说起CSRF，经常会举的一个例子，是这样的：

用户A在访问网上银行，在银行网站里进行了一些操作后。

之后点击了一个陌生的链接。而这个链接，是用户B提供的一个恶意网页W，网页W内也包含访问和用户A相同银行信息的链接，可能是转帐，也可能是修改密码。

此时如果A的认证信息还未过期，就会被直接利用，成功帮助W进行了银行网站的对应操作，而这一切，都是在A不知情的情况下进行的。

为了防范CSRF，常见的方式有：

  • 请求中包含随机token信息

  • Cookie中包含csrf token信息

  • 其他的验证请求头Refer等...（纯粹的refer不能解决问题，只能说是必须的，但不是充分的，这里还需要的是，对于进入系统内部的登录页面和首页面需要时不同的url，不然的话，判断refer的时候就很麻烦了）

    http://netsecurity.51cto.com/art/201308/407554.htm

在Tomcat中，默认提供了一个防范CSRF的好工具: CSRF Prevention Filter（这只能解决极少数部分场景，而且治标不治本，所以根本性解决还是token进行解决） 。

Tomcat默认提供了各类的Filter，处理不同的场景和需求。像我们前面介绍过的处理编码的 Tomcat自带的设置编码Filter ， 还有进行跨域处理的 Tomcat与跨域问题 等等。今天介绍的CSRF Prevention Filter也是其中的一个。

整个Filter的工作流程可以概括成以下内容：

该Filter为Web应用提供了基本的CSRF 保护。它的filter mapping对应到 /*

并且所有返回到页面上的链接，都通过调用 HttpServletResponse # encodeRedirectURL(String) 或者 HttpServletResponse # encodeURL(String) 进行编码。实现机制是生成一个token并且将其保存到session中，URL的encode也使用同样的token，当请求到达时，会比较请求中的token和session中的token是否一致，只有相同的才允许继续执行。

解决方法2：在表单中添加随机的、隐藏的Token信息，并且在使用一次后失效（根本性解决方法）。无奈现有的框架压根没有考虑重复提交的问题，我也是醉了。

为什么方法2是根本性解决方法呢？原因是因为跳转到钓鱼网站之后，session/cookie都可以被附带过来，而且refer也可以仿造，剩下的就只有hidden隐藏域是最难伪造的了，三者结合自然最好，对于一般性的crsf防御、cookie+refer结合就足够了（亲测）。

Slow HTTP Denial of Service Attack

这个攻击的原理和slowloris有点类似，略有不同的是利用的HTTP POST：POST的时候，指定一个非常大的
content-length，然后以很低的速度发包，比如10-100s发一个字节，hold住这个连接不断开。这样当客
户端连接多了后，占用住了webserver的所有可用连接，从而导致DOS。

tomcat解决方法：

<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="8000"  #默认20000，根据实际网络情况更改，亲测
redirectPort="8443" />

昨天，另外一个反馈如下：

web应用下的安全问题以及tomcat/nginx对应解决方法（持续更新、亲测可解决问题）

CVE-2014-3625 Directory Traversal in Spring Framework

Severity

Moderate

Vendor

Spring by Pivotal

Versions Affected
  • Spring Framework 3.0.4 to 3.2.11
  • Spring Framework 4.0.0 to 4.0.7
  • Spring Framework 4.1.0 to 4.1.1
  • Other unsupported versions may also be affected
Description

Some URLs were not santized correctly before use allowing an attacker to obtain any file on the file system that was also accessible to process in which the Spring web application was running.

Mitigation

Users of affected versions should apply the following mitigation:

  • Users of 3.2.x should upgrade to 3.2.12 or later
  • Users of 4.0.x should upgrade to 4.0.8 or later
  • Users of 4.1.x should upgrade to 4.1.2 or later

问题是，我们已经是4.2.8的版本了，经查该问题应该在4.2.9版本才解决。如下：

https://github.com/spring-projects/spring-framework/commit/e2d6e709c3c65a4951eb096843ee75d5200cfcad

https://pivotal.io/security/cve-2016-9878

https://github.com/spring-projects/spring-framework/commit/a7dc48534ea501525f11369d369178a60c2f47d0

https://github.com/spring-projects/spring-framework/commit/43bf008fbcd0d7945e2fcd5e30039bc4d74c7a98

Clickjacking:X-Frame-Options Header is missing

X-Frame-Options HTTP 响应头，可以指示浏览器是否应该加载一个iframe中的页面。网站可以通过设置X-Frame-Options阻止站点内的页面被其他页面嵌入从而防止点击劫持。
X-Frame-Options共有三个值：
DENY
任何页面都不能被嵌入到iframe或者frame中。
SAMEORIGIN
页面只能被本站页面嵌入到iframe或者frame中。
ALLOW-FROM uri
页面自能被指定的Uri嵌入到iframe或frame中。
Nginx 配置X-Frame-Options
到 nginx/conf文件夹下，修改nginx.conf ，添加如下内容：
add_header X-Frame-Options "SAMEORIGIN";

X-Frame-Options HTTP 响应头，可以指示浏览器是否应该加载一个iframe中的页面。网站可以通过设置X-Frame-Options阻止站点内的页面被其他页面嵌入从而防止点击劫持。
X-Frame-Options共有三个值：
DENY
任何页面都不能被嵌入到iframe或者frame中。
SAMEORIGIN
页面只能被本站页面嵌入到iframe或者frame中。
ALLOW-FROM uri
页面自能被指定的Uri嵌入到iframe或frame中。
Nginx 配置X-Frame-Options
到 nginx/conf文件夹下，修改nginx.conf ，添加如下内容：
add_header X-Frame-Options "SAMEORIGIN";

web应用下的安全问题以及tomcat/nginx对应解决方法（持续更新、亲测可解决问题）

CORS

nginx中将Access-Control-Allow-Origin设置为可信域名列表，同时在ajax请求的时候，一定要设置contentType:"application/json"（当contentType设置为三个常用的格式以外的格式，如“application/json”时，会先发送一个试探的OPTIONS类型的请求给服务端。在这时，单纯的在业务接口response添加Access-Control-Allow-Origin 由于还没有走到所以不会起作用。）, 以及crossDomain:true，否则依然会报403错误。

三个常用的格式为：text/html，text/plain，application/x-www-form-urlencoded。

每种主要格式的含义如下：

1.text/html

文本方式的网页文件。

2.text/plain

窗体数据以纯文本形式进行编码，其中不含任何控件或格式字符。空格转换为 “+” 加号，但不对特殊字符编码。

3.application/x-www-form-urlencoded

默认地，表单数据会编码为 “application/x-www-form-urlencoded”。就是说，在发送到服务器之前，所有字符都会进行编码，空格转换为 “+” 加号，特殊符号转换为 ASCII HEX 值。 窗体数据被编码为：名称/值对，这是标准的编码格式。

4.multipart/form-data

窗体数据被编码为一条消息，页上的每个控件对应消息中的一个部分，上传附件用到。在使用包含文件上传控件的表单时，必须使用该值。

5.application/json

数据以json形式进行编码。

6.application/xml

数据以xml形式进行编码，application/xml会根据xml头指定的编码格式来编码。

7.text/xml

文本方式的xml文件，text/xml忽略xml头所指定编码格式而默认采用US-ASCII编码。

参考：

http://www.cnblogs.com/lailailai/p/4528092.html

http://blog.csdn.net/zhaozhanyong/article/details/40397417

http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/filters/CsrfPreventionFilter.html

http://www.cnblogs.com/yjmyzz/p/customize-CsrfFilter-to-ignore-certain-post-http-request.html

http://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html#csrf-configure

http://mp.weixin.qq.com/s?__biz=MzI3MTEwODc5Ng==&mid=2650859236&idx=1&sn=426730453a1a0496594cc6808e497a8f&chksm=f1329937c64510212fa8034f7954583871b2fc8c32a71d0f068f2bccb0d0170e6cd22998ed7f#rd

http://www.iteye.com/news/17928/

http://blog.csdn.net/ultrani/article/details/9775083

http://blog.sina.com.cn/s/blog_53aab5c10101jkj0.html

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

http://blog.chinaunix.net/uid-26349264-id-4455607.html

http://www.jb51.net/hack/190393.html

http://www.freebuf.com/articles/web/66827.html