Xss Dom型

对于这种安全问题，太复杂，得仔细分析页面和理解服务端的处理逻辑。就好比这次的安全测试，某一项功能的业务需求是考生一次考试只允许选择报考该考试的某一个职位，那分析一下应该是考试是一套表，职位是一套表，靠考试和职位关联在一起，那问题出现了，考试和职位的关联是否做了有效性和合法性校验？于是做了个测试，通过热修改页面提交了一个报名，果然成功了。结果刷出来居然还没报错。然后就看到考公务员的考试报名了雇员类的职位。这样在分配考场时会引起很严重的问题导致考场无法分配，事务会回滚，如果提示信息处理不好只是单纯的报分配错误，呵呵呵 ，那用户只能手动筛查哪个报名出错了。面对一个几十万人的国考，筛查报名信息简直就是噩梦。 类似这样的问题太多了，最主要的，还是因为程序员在写Controller的时候懒得构造DTO，而是直接把参数Map到Entity instance 里面，如果我参数猜出来几个字段名，提交之后不该被保存的字段内容就被保存了。还是程序猿太懒的原因造成的，不过也不怪程序员，外包公司就是剥皮公司，拿着低的可怜的工资加班加点，如何能写出有质量的代码。

Xss 反射型

这个处理的比较好，不过不是应用本身处理，而是服务器前面还有一个过滤服务器，会过滤所有数据，发现有什么怪异字符的全给你过滤了，而且是直接Deny且15分钟无法再连入 不是过滤完再提交给服务器。所以这一块，目前来看没什么好的方法，除非仔细分析过滤器的过滤漏洞，字符集啊，编码啊 后台的处理啊等等。 Struts 2 之前的那种大Bug就不说，百年一遇，遇到就得死。

Xss 存储型

这个和上面的一样，目前被过滤器直接Deny并且15分钟无法再连入，所以尝试起来不是那么的有效率。也就没怎么深挖了，除非我知道他们的过滤器是哪家做的，过滤规则是什么，是否转译字符集编码等等，那个就太耗费时间了所以这里就一笔代过吧。

小总结一下： 网页前端安全处理的最高宗旨就是完全不依赖前端提交的数据是否合法，而是后台自己的一套校验标准。靠Js来校验，只能说是提高了一点用户体验，完全不能避免任何安全问题。当然，校验数据是很繁琐的，而且也一定会加重服务器的负担，所以也要考虑什么功能该后台校验，什么功能后台不需要校验。