几个实际工作中测出来的web安全漏洞

XSS

现象

        如下系统是我平时负责的系统，手工进行安全测试时，发现“<”、“script”等特殊字符串都被拦截了，没法进行注入。通过Appscan进行扫描，发现还是存在xss漏洞。如下图，通过get请求给输入框传入一个onmouseover（）的鼠标事件作为参数，把鼠标移到输入框上去，就会弹框打印cookie，这样就绕过了特殊字符串的拦截，进而实现了xss攻击。

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

解决办法

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

二、对所有输入框进行完整的过滤，既包括能拼接成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注入

有个用户登录的页面，代码中验证用户登录的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的语意如果变化了，所表达的查询就会变化。

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

最后再总结一句：因为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入,如果不能重用执行计划，就有可能出现SQL注入。存储过程之所以安全，也是一样的道理！

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