Web项目中常见的安全问题及其解决方案

2018-12-24钱小军

无线互联科技 2018年20期

吴全，钱小军，金龙

（江苏金盾检测技术有限公司，江苏南京 210013）

目前，国内的软件服务外包行业发展迅速，对人才的需求量也急剧攀升，使软件服务外包人才供不应求，而当前高校的教学内容又与企业的用人需求存在明显的差距，高校毕业生无法立即投入工作。国内有很多的培训机构，他们各有着自己的一套培训流程和教学方案，水平参差不齐。近年来虽然很多高校为了加强学生的实践编程能力，与这些培训机构合作在教学大纲中加入了实践课程，但是靠着短短几周的突击填鸭式教学，所完成的项目多半是不严谨的，存在着诸多安全问题。不仅是培训机构会忽视开发中的安全问题，很多软件公司的从业人员也很少考虑过项目的安全性。尤其是在开发小型系统或者针对内网的系统时，为了方便调试和使用，开发方和运维方都会忽视应用的安全问题。下面我们以Web系统为例，简略地探讨在外包项目中开发人员很少会关注到却又十分重要的安全问题。

1 密码明文传输

在很多需要权限分级管理的系统中，开发人员在登录、注册等页面里处理用户的密码时，通常的做法只是将用来填写密码的文本框的type属性设置为password，使得密码字段中的字符通过特殊符号进行替换以达到隐藏的作用[1]。但在用户提交信息到服务器时，却让密码以明文的方式进行传输。看起来是一个很小的问题，但是，在实际应用中，这是个很大的隐患。很多开发人员可能也考虑过这个问题，只是鉴于应用用户较少，而且只能处于内网环境中，就直接忽略了[2]。但是表单中明文传送密码，一旦流量被恶意攻击者嗅探到，就可能产生一定的不良影响。最简单的解决方式是将密码通过js加密后再传递到后台，然后控制器在校验密码时直接取数据库中的密文进行匹配[3]。

2 用户名、密码等信息可被暴力枚举

这个问题可能出现在密码校验逻辑中：校验结果的不同分支，返回给页面提示信息不同，密码错误和用户名不存在是两个不同分支中的。这样一来，居心叵测者就可能通过多次输入并提交而猜中系统中可能存在的用户名。同时，攻击者还可以暴力枚举来尝试获得用户的密码，如果用户的密码强度较为脆弱，很容易被攻击者枚举出密码[4]。因此，对于用户的操作需要作出跟踪限制，对于可能是非法操作的用户，暂停对其的服务；或者在提交数据时加上验证码等防止自动化攻击的方式，这样加大攻击者的攻击成本来进行防御，同时对用户的使用影响可以降到最低。

3 对用户的输入没有进行检查

“永远不要相信用户的输入”是对设计人员和编码人员说的，是进行安全设计和安全编码的重要准则。换一句话来说，就是用户在任何时候所输入的数据在证明其无害之前，都是有害的。许多危险的漏洞就是因为过于相信用户的输入是善意的而导致的。而很多不成熟、速成的开发者，只关注功能上的实现，很容易忽视对用户的输入的检查。有些开发者在前端页面上使用js对用户的输入进行限制，将数据通过POST方法提交后便觉得高枕无忧，在后端便放松了对用户输入数据的检查，认为传递来的参数一定是符合设计规则的。然而，攻击者可以使用burpsuite和fiddler等代理工具，对数据包中的数据进行修改。这时候，如果后端的程序没有对用户输入数据进行检查，这样的恶意数据如果传递到拼接的sql语句中，就可能会造成sql注入漏洞；如果被显示在页面上，可能造成跨站脚本攻击漏洞等。项目的开发一般是由团队完成的，稍微复杂一些的项目，更会有数不清的用户输入点，一旦其中的一个输入点没有对用户输入进行检查，便有可能对整个系统的产生威胁。

有些开发人员会说对输入数据进行如此多的检查会影响性能，实际上，大多数输入检查并不对性能造成大的损害，即使有损害，一个稍慢但是相对安全的系统也比一个快速但容易受到攻击的系统要好。如果客户对你的系统性能不满意，应寻找其他途径提高性能，不要通过减少安全检查来提高性能，因为当客户的系统因漏洞被攻破以后，你面临的就不是几句抱怨，而是一场灾难了。正确的做法是在客户端和服务端都作相同的检查，客户端的检查的目的是为了界面的友好、节省用户的时间，服务端的检查才是为了数据的完整和安全。

4 敏感信息泄漏

一些Web应用的404、500页面使用的是容器默认的页面，而有些默认报错页面不仅对用户不友好，还会造成服务器敏感信息的泄露[5]。增强安全意识，应该避免使用服务器默认的错误页面信息。

很多网站管理维护人员，为了维护网站时的便利，会在服务器上留下有规律的备份文件。这些文件如果被攻击者枚举猜测到，便会造成不同程度的安全威胁[6]。

近年来随着版本控制系统的流行，很多团队在结束开发时会忘记删除版本控制系统的目录，比如.git，.svn目录，这种项目部署后可能会造成网站应用代码泄露的风险。此外，开发人员在使用版本控制系统时可能会将代码同步到公开的平台上，在这一过程中会将开发或者生产环境中的配置文件里可能存在的敏感信息删除，便会导致攻击者通过公开在平台里的项目获取到敏感信息[7]。

5 目录遍历漏洞

目录遍历漏洞指通过在URL或参数中构造 ../，./ 和类似的跨父目录字符串的ASCII 编码、unicode 编码等，完成目录跳转，读取操作系统各个目录下的敏感文件，也可以称作“任意文件读取漏洞”[8]。

目录遍历漏洞原理从根本上来说还是因为开发人员在编写程序时没有充分检查用户的输入，没有过滤用户输入的../ 之类的目录跳转符，导致用户可以通过提交目录跳转来遍历服务器上的任意文件。使用多个.. 符号，不断向上跳转，最终停留在根 /，通过绝对路径去读取任意文件。因此，更应当针对不同功能时刻注意检查用户的输入。

此外，对于nginx等HTTP和反向代理服务器的配置失误，也可能造成目录遍历漏洞。

例如，在nginx的网站配置中，使用如下的配置：

location /xxxx {

alias /var/www/html/xxxx/;

}

location /admin {

alias /var/www/html/admin/;

}

location没限制后面，那/admin./就会被好心的nginx处理成/admin/./，同理/admin../就会被nginx处理成/admin/../，便可能将网站根目录里的信息通过nginx的Directory list列出来。

6 跨站请求伪造攻击

CSRF（Cross-Site Request Forgery），中文名称即为“跨站请求伪造攻击”。攻击者可以盗用用户的登录信息，以用户的身份模拟发送各种请求[9]。攻击者只要借助少许的社会工程学的诡计，例如通过QQ等聊天软件发送的链接（有些还伪装成短域名，用户无法分辨），攻击者就能迫使Web应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个QQ好友发来的链接，那么该用户银行账户中的资金就有可能被转移到攻击者指定的账户中。所以遇到CSRF攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员账户的时候，CSRF攻击将危及整个Web应用程序。

CSRF的防御可以从服务端和客户端两方面着手，从服务端着手的防御效果比较好的，现在一般的CSRF防御也都在服务端进行。服务端的预防CSRF攻击的方式方法有多种，但思路上都是差不多的，主要从两方面入手，一方面是正确使用GET，POST请求和cookie，另一方面是在非GET请求中增加token。

一般而言，普通的Web应用都是以GET和POST请求为主，还有一种请求是cookie方式。在常规的开发模式中，GET请求常用在查看、列举、展示等不需要改变资源属性的时候；POST请求常用在表单提交，改变一个资源的属性或者做其他一些事情的时候。

当正确地使用了GET和POST请求之后，剩下的就是在非GET方式的请求中增加随机数，主要通过3种方式来进行：（1）要为每个用户生成一个唯一的cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为理论上攻击者不能获得第三方的cookie。（2）让每个POST请求使用验证码，这个方案算是比较完美的，但是需要用户多次输入验证码，用户体验比较差，所以不适合在业务中大量运用。（3）在渲染表单的时候，为每一个表单包含一个csrf Token，提交表单的时候，带上csrf Token，然后在后端做csrf Token验证[10]。