Web应用安全漏洞简介

5年前

一、 背景


这段时间在产品维护中遇到了不少客户反应过来的安全漏洞问题,这类问题一般会有以下两个特点:


问题很紧急:由于客户都是应用功能测试稳定后,进行总体的安全扫描,发现时间都是在临近上线前,所以要求必须短时间内解决掉;

很难统一处理:由于现在的扫描工具实在太多了,开源的非开源的,商用的非商用的,使得最终风险报告很不一致,漏洞级别定义也不一致。


针对上述情况,只有我们在平台设计时,应用编码时都有意识的注意到漏洞的防范,才能从根本上解决此类问题,借此知识点分享一些个人经验。


二、 漏洞一般分哪几类


漏洞种类很多,这里只想提几种最常见,也是最严重的安全漏洞:


1. SQL Injection


又叫SQL注入,漏洞原理是:通过提交特殊信息,使得后台程序运行时,数据库操作部分未按照既定方式合理运行,举个登录的例子,很多初学者会这么写:



public boolean login(String username, String password){
String sql = "select * from user where username='"username"' and password='"password"'";
Connection conn = ...;
Statement stat = conn.createStatement();
stat.execute(sql);
...
}


一般来说,登录验证没有问题,但如果用户恶意传入:


username:’ or ‘1’=’1


password:任何字符串


那sql语句就变成了:


select * from user where username=’’ or ‘1’=’1’ and password=’*’


显然上述的语句可以查询到不该出现的数据(所有数据)


这就是最常见的sql注入漏洞,危害不言而喻。


2. XSS


XSS又名跨站脚本攻击,一般做法是在界面上嵌入javascript等动态脚本,当其他用户浏览此网页时,脚本自动或通过简单触发执行,达到获取用户cookie等隐私信息的目的。以前很多论坛都会有此问题,比如原先html源码为:


<input type="text" value="aaaa" />

如果对用户输入不做任何校验,那恶意用户就可以输入:


“ onmouseover=”alert(document.cookie)


那最终的html就变成了


<input type="text" value="" onmouseover="alert(document.cookie)" />

当然,示例只是简单的打印cookie信息,危害大小取决于脚本的写法。


3. CSRF


CSRF又名跨站请求伪造,是指盗用者以你的名义去发信息,邮件,购物等,造成个人信息泄密甚至财产损失等。这种漏洞到07年左右才开始被重视起来,包括YouTube,CSDN等都有过此漏洞,这种漏洞的原理是这样的:


有两个网站:


正常网站A


恶意网站B


当用户不小心访问到B时,B网站自动去访问A站,模拟用户进行相关操作(这个当然是有一定前提的,比如很多人在不同网站上注册的用户名和密码都类似,那就非常容易了)


4. 不充分账户封锁


很多测试工具会做这么一个验证,连续用一个错误账户模拟访问一个链接,希望返回结果能有所不同(其实就是希望对于这种类似恶意的尝试有锁定机制,或黑白名单控制),这个漏洞其实不是太危险,更多是系统健壮性的一些保障


三、 如何解决


针对上述的四种漏洞,我们分别来看看有什么解决方案:


1. SQL Injection


JDK在这方面已经有所考虑,PreparedStatment这种参数化的方式就可以很好的防止SQL注入,包括相hibernate这类ORM工具内部都会使用此方式实现,所以有些工具扫出普元产品有sql注入漏洞,要么是其他漏洞引起,要么是应用中自己写了sql语句导致


2. XSS


XSS攻击只要把握住两个口就可以很有效的防御,输入过滤和输出编码:


输入过滤是指对访问后端的URL进行校验,如果出现类似<, >, ”, /等敏感字符,或者script, cookie等敏感词,需要对其进行过滤(一般通过统一的Filter实现),我们的产品中可以考虑在第一个webInteceptor做此功能;


输出编码是指针对一些界面直接将用户输入嵌入到框架界面上而说的,需要对这些信息进行编码,将其变成普通字符,在我们的产品中,很多都有输入的某URL不存在的统一界面提示,这些界面一定要注意输出信息的编码


3. CSRF


了解了CSRF原理后,防御方法就很简单了,既然通过仿造用户请求,那我们就对请求进行校验,常用的方法有两种:


第一种是通过token,对表单进行合法性验证,以前在华为项目中我们是通过HDIV来实现的(表单展现时隐藏token,提交时带上token,后端进行合法性校验后再做后续处理,token是随机生成的,并且只作用于单个请求)


第二种是通过验证码来处理的,因为一般来说仿造的第一步都是登录,如果能从登录口上屏蔽风险,后续很难进行攻击,而验证码这种类似于token的方式能够很好的控制伪装登录


4. 不充分账户封锁


这个方案之前提到过了,就是通过互联网上常用的账号连续3次输入错误,就将其锁定的方案来解决;如果可以再辅以黑白名单控制,口令级别控制等就更安全了


四、 其他


随着互联网化,去IOE化等趋势的到来,后续面临的安全问题会更多的被提出,我们可以后续再发一个产品的安全版,我觉得这又是产品的一大特性补充。


当然,除了我们产品本身的支撑,也要求应用开发人员在系统设计之初就要将安全问题作为一大需求重视起来,正如我们pworld上提出的,安全是靠点点滴滴积累起来的,很难有一个大而全的框架能将其完全杜绝,只有大家都意识到了,才能做出一个更安全,更可靠的产品。

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。