Web应用安全测试问题对策

Web应用的安全性是每个应用必须满足的非功能需求之一，安全测试涉及的内容很多，这里主要对安全测试后常见问题的修改做一个简单记录，如果有相同问题可以略做参考。

下面以常用的appScan的安全测试涉及的主要安全问题的修改方向做一个说明

• SQL 注入

SQL注入可分为普通的SQL注入和SQL盲注，盲注是特殊的SQL注入，盲注不依赖于服务端SQL错误信息来攻击，而是根据不同的注入条件得到的不同结果来推测数据库端的一些关心的信息，可以说攻击方法较难，实现较复杂。
对SQL注入的预防措施基本都是用参数方式构造sql，不使用拼接字符串方式，对hibernate的使用同样不能使用拼接hsql的方式。减少sql注入风险。
不少安全测试工具（如appScan）由于自身的检测机制，可能存在误报的情况，可根据项目实际情况和测试部门多沟通，以免浪费时间来解决本来不是风险的问题。

• 跨站点脚本编制

跨站脚本攻击包括反射型和持久型，也就是按照攻击脚本信息是否保存到应用的数据中来划分的。跨站脚本主要就是客户输入的信息中含有恶意脚本信息，所以防御措施也就是要做好输入信息的验证，同时要知道客户端验证都是不安全的，所有输入项也是不安全的，必须对所有输入项做数据验证。（这里面的输入项不仅是用户输入的信息，也包括所有传入后台会被使用的信息）。
对字段做业务验证是比较好的处理方式，也有采用filter过滤敏感字符，如果存在敏感字符则显示提示信息，并终止请求的方式，但是这种方式由于不区分参数内容，会造成有意义的参数也会被过滤，造成误杀。所以还是项目开始阶段就要求所有开发人员做好业务验证更为妥当，后期为了安全问题再加一个filter带来的副作用将会很头疼。

• 缺少跨帧脚本编制防御

增加响应header设置x-frame-options（SAMEORIGIN：frame）限定页面的地址只能为同源域名下的页面。

• 自动填写未对密码字段禁用的 HTML 属性

设置密码控件autocomplete为off

• 跨站点请求伪造

简单的修改方法是验证请求的header中Referer是否来源为同样的服务。但是Referer也可以被伪造，这样验证就会失效。可靠性高的做法是请求页面中增加一个token字段，通过每次请求的唯一随机字段验证是否是当前页面发送的请求，这么修改需要各个jsp都增加相同处理逻辑。如果只是想通过安全测试的话，验证Referer的方式就可以。

• 会话标识未更新

采用登录页面中将session和cookie失效，登录后重新生成session的方式。