以下系统是我平时负责的系统，手工进行安全测试时，发现“<”、“script”等特殊字符串都被拦截了，没法进行注入。通过Appscan尽心扫描，发现还是存在xss漏洞。以下图，通过get要求给输入框传入1个onmouseover（）的鼠标事件作为参数，可以绕过特殊字符串的拦截，进而进行xss攻击。

查看代码，发现前端控件做了参数绑定，使得get要求的参数直接绑定到输入框了；另外，特殊字符串的过滤只是过滤了1些特殊字符，没有对js函数进行过滤，这才致使了这起漏洞。

1、取消控件的参数绑定。

2、对所有输入框进行完全的过滤，既包括能拼接成html和js的特殊字符，也包括所有的js函数。

总结——Xss注入的防范

• 完善的过滤体系。使用拦截器把能拼接成html或js的特殊字符、函数全都过滤掉。
• Html encode。假设某些情况下，我们不能对用户数据进行严格的过滤，那末就需要对输入的html标签之类的特殊字符进行转义。
• 将重要的cookie标记为http only或secure,  这样的话Javascript中的document.cookie语句就不能获得到cookie了，或只有用https才能使用cookie
• 开启阅读器中的XSS过滤器。具体方法，大家可以自行百度。
• 完善的测试。手工脚本注入测试+自动化xss漏洞扫描工具扫描。

CSRF

和上面xss的解决方法类似。

总结——CSRF的防范措施

• 完善过滤和拦截机制。
• 正确使用GET,POST和Cookie。
• 查询操作用get，增加、删除和修改等操作用post。
• 在非GET要求中使用securityToken。服务端收到用户要求后，把客户端传过来的securityToken和通过session计算出来的进行比对就能够判断是不是是合法要求了。

我们有个用户登录的页面，代码中验证用户登录的sql 以下：select COUNT(*) from Users where Password = 'a' and UserName = 'b' 

这段代码返回Password和UserName都匹配的用户数量。

注入方法以下：

如果将UserName设置为 “b' or 1=1 –”.那末，上述sql就变成了： select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'

不难看出，SQL的语意产生了改变。为何产生改变呢？由于没有重用之前的履行计划，对注入后的SQL语句重新进行了编译，重新履行了语法解析。

其实，要保证SQL语义不变，即我写的SQL就是我想表达的意思，不因sql注入而改变语义，就应当重用履行计划。从这个角度说，任何动态的履行SQL 都有注入的风险，由于动态意味着不重用履行计划，而如果不重用履行计划的话，那末就基本上没法保证你写的SQL所表示的意思就是你要表达的意思，SQL的语意如果变化了，所表达的查询就会变化。

重用履行计划，这就好像小学时做的填空题：查找密码是(____) 并且用户名是(____)的用户。不管你填的是甚么值，我所表达的就是这个意思。只要语义不变，就没有风险。

最后再总结1句：由于参数化查询可以重用履行计划，并且如果重用履行计划的话，SQL所要表达的语义就不会变化，所以就能够避免SQL注入,如果不能重用履行计划，就有可能出现SQL注入。存储进程之所以安全，也是1样的道理！

~这是最近1个月发现的系统中的web安全问题，做个记录，加深点印象，以时时提示自己革命还没有成功，测试还需警省！