WEB项目的安全性注意事项

近期接受了一个维护项目，客户组织了一次第三方安全测试，发现了一些问题，需要整改。整改内容，操作系统、数据库、代码都有涉及。整改过程中，我们自己也深受教育。现将代码部分的整改内容及相关措施整理如下：

一、任意类型的文件上传

【高危】

【描述】
任意文件上传漏洞主要是由于程序员在开发文件上传功能时，没有考虑对文件格式后缀的合法性进行校验或只考虑在应用前端（Web浏览器端）通过javascript进行后缀校验，攻击者可上传一个包含恶意代码的动态脚本（如jsp、asp、php、aspx文件后缀）到服务器上，攻击者访问该脚本时服务器将对包含恶意代码的动态脚本解析，最终执行相应的恶意代码。

【应对】
处理用户上传文件，要做以下检查：
1、 检查上传文件扩展名白名单，不属于白名单内，不允许上传。
2、 上传文件的目录必须是http请求无法直接访问到的。如果需要访问的，必须上传到其他（和web服务器不同的）域名下，并设置该目录为不解析jsp等脚本语言的目录。
3、 上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。
4、 图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。

二、口令明文传输

【中危】

【描述】
在测试过程中，检测到基于不安全的传输请求。由于采用未加密的方式发送敏感的登录请求，有可能被同一个局域网内的攻击者嗅探到用户输入的登录数据，如账号和密码。

【应对】
1、采用https
2、如果没有条件采用用https，则将口令加密后再提交。这是在客户端进行加密，服务器端解密。目的是在客户端提交到服务器端的传输过程中，即使是被截获，也起到保险的作用。加密方式是非对称加密。

有条件当然是采用https最简单。

三、CSRF攻击

【中危】
【描述】
CSRF（Cross-Site Request Forgery，跨站点伪造请求）。名字很长很拗口，其实核心在于“伪造”二字。就是这个请求不是网站本身提供的，是站外伪造的。

这里面又包含两个方面：

1）请求伪造
自己拼凑出URL，直接在浏览器里输入，或者写在邮件里诱使你去点击。要害主要在这个URL是伪造的，在一个系统里面，系统提供的URL，其中的用户ID啦，一些参数啦，都是中规中矩。但伪造的可能就不一样，比如，是高权限用户的ID，参数可能是删除记录的指令。

【应对】
对于这种情况的防范，一方面程序自己要有所防御，比如检查用户的登录情况，用户权限，等等。另外一方面，就是从根源上检查，凡不是从网站跳过来的请求，一律回绝：

1、检测HTTP header中的referer字段。服务器可以查看referer是否为自己的站点，如果不是，则拒绝服务；
2、同时在重要请求中的每一个URL添加token。
3、加上“X-XSS-Protection”头，强制将跨站点脚本编制过滤器加入“启用”方式，即使用户已禁用时也是如此。该过滤器被构建到最新的 web 浏览器中（IE 8+，Chrome 4+），通常在缺省情况下已启用。

2）表单伪造
黑客伪造一个表单，然后提交给系统，以达到一些目的。

【应对】
验证表单是不是亲生的。原理很简单。网站输出表单的时候，在表单里放置一个隐藏控件，里面带上验证码。表单提交后，校验验证码。伪造的表单，由于对应不上，甚至根本没有这个验证码，所以就被识破了。

四、Session伪造

【中危】
【描述】
应用系统在用户登录成功或登录失败后并未对当前的会话标志（Session ID）进行更新，从而攻击者可构造一个未登录且带有Session ID的URL并发送到用户，用户点击该URL并进行登录成功后，攻击者可通过该Session ID冒充用户并成功进入应用系统，从而可进一步发起对应用系统的攻击。

【应对】
1、用户登录成功后重新创建一个Sesssion ID，并销毁该用户之前登陆使用的Sesssion ID。
2、限制Sesssion ID的时效性，一段时间后销毁Sesssion ID。
3、添加其他认证因素，如User-Agent验证及Token校验等。

五、服务器信息泄露

【中危】
【描述】
系统存在绝对路径泄露，绝对路径是指目录下的绝对位置，直接到达目标位置，通常是从盘符开始的路径。攻击者可通过此漏洞了解到整个服务器的目录结构，同时如果存在注入漏洞，攻击者可通过绝对路劲直接获得服务器权限。

【应对】
1、 关闭错误调试
2、 设置自定义错误跳转页，避免非200响应状态返回默认错误信息
3、隐藏一些报头，尽量少透露服务器信息。

六、页面被嵌套

【低危】
【描述】
攻击者可以使用一个透明的、不可见的iframe，覆盖在目标网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击iframe页面的一些功能性按钮上，导致被劫持

【应对】
设置X-Frame-Options参数。当然，在实际开发过程中，系统本身可能会有一些要求，要求一些页面采用iframe进行嵌套，要注意区别处理。

七、cookie

【低危】
【描述】
网站Cookie特别是用于用户身份认证的JSESSIONID未设置HttpOnly选项，当网站存在跨站脚本漏洞时，攻击者可获取该Cookie，并登陆受害者账号。

【应对】
设置HttpOnly。目的是不让脚本访问到cookie。

八、其他

【低危】
【描述】
中间件配置缺陷主要是由于开发人员或运维人员在安装部署中间件后，并未对默认的中间件配置进行安全加固，导致产生一系列诸如目录遍历、默认示例文件、错误信息泄露等缺陷，从而导致应用系统产生信息泄露隐患。

【应对】
中间件配置缺陷主要是由于开发人员或运维人员在安装部署中间件后，并未对默认的中间件配置进行安全加固，导致产生一系列诸如目录遍历、默认示例文件、错误信息泄露等缺陷，从而导致应用系统产生信息泄露隐患。

九、总结

以上项目中，还少了一个“SQL注入式攻击”，可能是因为太过有名，程序员普遍知道，采取了一些防范措施，可能就没有列出来。但是，老坑重陷，一个在同一条河里栽倒两次也不是什么新鲜事。