web安全（8）-- 程序缺陷

1.1 漏洞描述

    ● 软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。在软件开发生命周期的后期，修复检测到的软件错误的成本较高。

1.2 漏洞危害

● 程序缺陷的危害可大可小，大的缺陷可能导致系统瘫痪，小的缺陷的可能就是导致操作不方便而已。

● 根据程序缺陷的大小可以将程序缺陷分成以下几个错误严重程度：

1.Critical：不能执行正常工作功能或重要功能。或者危及人身安全。

2.Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）

3.Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）

4.Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

5.Other：其它错误。

● 同时，根据程序缺陷的严重程度，我们给出几种处理优先级：

1.Resolve Immediately：缺陷必须被立即解决。

2.Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。

3.Not Urgent：缺陷可以在方便时被纠正。

1.3 漏洞演示

● 常见问题一：

● 统一性

不要在软件中使用中英文混合的提示，比如对于用户的操作提示，不要一会用“error”一会用“错误”；一会用“succeed”另一会用“成功”总之要统一。某局长使用心得：删除的时候提示Error，幸亏我英语水平好，可是你换成中文不行吗？

比如在我们开发过的系统出现过：

1：operation is  succeed，具体看一下我们公司jira中哪个系统出现的问题。

2：另外，项目初期阶段，日期控件有的采用中文，有的采用英文形式。

● 常见问题二：

● 容错性

对于保存提交的数据输入信息，在输入长度方面要么就限制用户的输入，要么就在客户端给出用户的醒目的提示、判断。不要出现系统崩溃，保存缓慢系统等无法响应等现象。

做好容错处理，异常要及时捕获，别输出到日志文件中，不要将异常抛出到前台界面，这样也会造成信息泄露的漏洞。

● 常见问题三：

● 互动性

在要求用户大量输入信息后，点击“保存”或者“提交”按钮，仅仅是因为用户的某个地方输入或者选中不正确，点击“确定”后发现所有输入的内容全部都被清空了，花费很长时间的输入，仅仅是因为某个地方的输入不正确，而把该用户的所有其他的输入地方的输入都清空了，假如你是这个软件的使用者，你肯定会感觉到很恼火的。（保存不成功也可以理解，但是不能把用户所有的输入信息全部清空吧，就算你清空你也至少告诉用户是什么输入错误，让用户知道怎么重新输入，才能保存成功）。

另外，在需要用户输入信息的时候，特别是填写个人信息的资料的时候，必填项后面，一律要用*等醒目的提示。让用户知道这个地方是必填写的。

还有，下拉框不选值的时候，应该有个默认值，并且要多检查程序中多处下拉框，因为很多情况下下拉框取不到值。我们的有些系统，有些地方，现在的下拉框取不到任何值。

● 常见问题四：

● 用户体验

页面上的提示信息要让用户明白，比如不要对用户使用“记录”、“字段”、“ID”等一些很专业的术语。

举例：比如电商项目中，用户下单失败，你给用户一个提示，要求用户根据订单号去进行对应的重新下单操作。订单号是开发人员为方便数据库操作设定的一个唯一键约束，是给开发人员用的，那么长一串数字，你要求用户记住，这是多不合理的体验。

另外，对于编辑功能，点击“编辑”后，所有的值都要默认保持编辑前的初始值。比如某员工的籍贯是“上海市”，点击“编辑”按钮后，在籍贯这个地方默认的仍然是“上海市”。

其他字段信息也是如此。

● 常见问题五：

● 兼容性

现在遇到的情况是程序人员的浏览器的版本都比较高（比如IE10，IE11），在他们的开发机器上确实没有问题，但是在用户的环境中(比如用户环境中Winxp机器上的IE8.0浏览器下)就有问题。

同时兼容性还要考虑移动平台的兼容，比如手机和平板，还要考虑不同的手机系统，以及不同的手机分辨率、不同的网络类型（WIFI、3G、4G）下的情况。

另外一些常用软件的兼容也需要考虑，比如导出操作，导出的EXCEL等OFFICE文件要考虑版本之间的兼容性。

● 常见问题五：

● 互动性

对于所有的删除信息在删除之前都要给出是否删除确认的提示或者放弃的提示。

扩展下：不仅仅是删除，包括危险操作之前、或者改变数据状态等。

另外，新增/修改信息保存提交后，系统应该给出“保存/提交/修改成功”提示信息，并自动更新显示。

● 常见问题六：

● 易用性

对于要求用户大量录入信息的页面，要支持Tab键的输入，Tab键的走向要一般要遵循从做左到右，从上到下的的原则。

● 常见问题七：

● 错别字

另外，要对程序中的错别字进行检查，比如把“登录”写成“登陆”；把“我同意”改成“我统一”。

目前：很多外面的系统都把“登录”写成“登陆”，其实这样是不正确的。

举例：如果系统中首页中的错别字，属于优先级比较高的问题。

● 常见问题八：

● 开发人员纰漏

开发人员经常会在程序调试中加入一些弹框输出操作，但是后来又忘记删除这些调试信息，这些调试信息给用户造成误解，认为该调试信息是系统严重的Bug。

程序提交测试之前，程序员必须要仔细检查，删除该类型的调试信息。

● 常见问题九：

● 界面UI

界面布局缺陷：比如“删除”按钮和“保存”按钮挨得很近（这样很容易造成用户的误操作）。（注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。另外，注意按钮的大小是合理一致。

界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

● 常见问题九：

● 资源释放

对于有资源连接的地方（比如数据库、文件、索引等），使用完毕后要及时关闭。否则会造成系统资源内存泄漏。

这样的问题，要在编码阶段就需要避免，否则到最后上线，用户量激增后，用户体验会很差，甚至造成系统崩溃。

● 常见问题九：

● 性能体验

对于经常大数据量的查询，对于查询的关键字段是不是要考虑使用到索引等或者其它方法提高查询的效率，2-5-8原则。

对提高查询效率，1)可以考虑对查询关键字建立索引、2)可以考虑添加缓存、3)可以考虑添加文件索引(lucene等)

PS:2-5-8原则

就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

● 常见问题十：

● 接口

程序在接口方面容易出错。1)内部借口：事先协商好借口规范，入参是多少，出参是多少；2)外部借口：做好容错处理，如果对方借口不通，要做好应答。

● 常见问题十一：

● 安全性

● SQL注入

SQL语言对于特殊字符的处理，尤其是查询语句的单引号的处理，

SQL注入本质有2个关键条件：

第一个是用户能够控制输入。

第二个是原本程序要执行的代码，拼接了用户输入的数据。

比如在文本框中输入‘ or ’1‘=’1，看是否构成：

Select * FROM member Where username='magci'and password='' or '1'='1'

‘1’=‘1’是永真的，这条SQL语句是能通过验证的。

● XSS

任一输入文本域输入：<script>alert(“xss”);</script>，提交保存，下次再次访问时，直接把用户的输入直接反射给浏览器，如下图：

 

● 将sessionId拼接在param里

现在网站开发已经注意到：登录网站进入其内部网页后，直接拷贝网址，然后粘贴到另一浏览器，如果GET请求的param参数里面拼接了sessionId，则直接可以绕过登录。

● 给session会话设置合理的失效时间

对于需要登录的系统，在用户不操作的一定时间内，出于安全性考虑，最好要让用户重新登录才能重新使用该系统。

● 关闭窗口或者窗口tab页应该让session失效

现在很多网站没有做这个设计，当我关闭浏览器或者关闭网站对应的tab页，应该让网站的session失效。没有这个设计，如果用户在一些公共场合，忘记关电脑的话，别人就可以通过浏览器历史直接进入网站后台，而不用登录。

● 配置文件中尽量不要出现用户名密码

有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。如果万不得已要写到配置文件中，也尽量加密处理。

● 合理处理弹框

安全缺陷还可能存在于弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个缺陷。

1.4 修复方案

1、首先提高开发人员的安全意识，对一些常见的安全隐患应该有自己敏感的嗅觉，在平时的开发中尽量避免出现这些错误

2、配合测试人员，找出对应的缺陷，制定对应的修复方案，然后修复升版。

1.5 相关参考

http://blog.csdn.net/jcy58/article/details/51931652