程序员人生 网站导航

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

栏目:互联网时间:2017-03-13 16:56:47

XSS

现象

        以下系统是我平时负责的系统,手工进行安全测试时,发现“<”、“script”等特殊字符串都被拦截了,没法进行注入。通过Appscan尽心扫描,发现还是存在xss漏洞。以下图,通过get要求给输入框传入1个onmouseover()的鼠标事件作为参数,可以绕过特殊字符串的拦截,进而进行xss攻击。
查看代码,发现前端控件做了参数绑定,使得get要求的参数直接绑定到输入框了;另外,特殊字符串的过滤只是过滤了1些特殊字符,没有对js函数进行过滤,这才致使了这起漏洞。



解决办法

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

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

总结——Xss注入的防范

  • 完善的过滤体系。使用拦截器把能拼接成htmljs的特殊字符、函数全都过滤掉。
  • Html encode假设某些情况下,我们不能对用户数据进行严格的过滤,那末就需要对输入的html标签之类的特殊字符进行转义。
  • 将重要的cookie标记为http onlysecure,  这样的话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的语意如果变化了,所表达的查询就会变化。

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

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



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



------分隔线----------------------------
------分隔线----------------------------

最新技术推荐