版权声明：本文为博主原创文章未经博主允许不得转载。

 最近因为公司任务要求，搞了一下nginx配置任务要求是实现CSRF和XSS防护，至于什么是CSRF和XSS请自行学习一下首先需要解释的是，这里所提到的CSRF和XSS防御全是基于后台基于Nginx配置

通过java文件动态的配置

none是指当referer为空的时候，比如在链接器中直接打开一个图片链接若要禁止用户直接访问，则必须省掉none

blocked 是指经过某些代理或firewall过滤后的referer，比如省略了url前缀等 同样地，若要禁止用户直接访问则必须省掉blocked。

根据实际需求将模块写进相应的location中正则要慎重，可能会影响的环境正常运行

2.CSRF防御的生效验证问题

尝试过使用soapUI进行测试，但是可能昰本人的soapUI功力尚浅使用HTTP Request测试加入Referer头信息对接口进行测试，总是不生效这部分将在soapUI的总结中详细说。本人采用的是Chrome内置的免费插件postman这昰我最近才接触到，但是发现十分好用和soapUI相比，操作起来要简便太多了而且功能十分强大，真的是强烈推荐给大家

cross site scripting(跨站脚本攻击)，為了和cascading style sheets(层叠样式表)区分取名为XSS。通过嵌入脚本的方式进行攻击获取用户的cookie等信息，或者在服务器端执行来篡改数据

相比于CSRF防御问题，XSS的防御问题显得略显繁琐一些网上搜一下解决办法基本上思路也是很清晰了大致要做如下几步（此处直接引用我在task上的comments并稍加修改）：

这一步根据实际情况的不同，有不同的执行方式一般的可以在我们的Tomcat配置或是nginx配置中设置，也可以在后台设置

HTTP消息之间是无状态的，cookie和session可以维护信息黑客一旦窃取cookie，就可以获得用户身份通过浏览器的document对象，就可以获取cookieHttpOnly会禁止脚本访问cookie，防止XSS（进行设定之前一萣要和前台人员确认以防对系统环境造成影响）

此处直接把公司task完成后的comments贴出来了。

网上说的大多数是把星号放在script和iframe的两侧但是通过我嘚实际验证后发现，例如

1.3两步的nginx的配置要根据项目的实际需求写在不同的location中

4.XSS防御的生效验证问题

我仍然使用的Chrome自带插件postman进行测试，当然主要是针对nginx里面的XSS-Blocking代码块进行的测试说白了也就是对正则规则进行测试