Web应用安全测试清单
第 1 部分: 数据输入
简介：本文为系列文章"Web 软件测试Checklist 应用系列"中的第一篇。该系列文章旨在阐述Checklist（检查清单）在Web 软件产品测试中的应用，以帮助您了解如何利用Checklist 这种重要的测试手段，更高效的寻找Web 产品中的defect（缺陷）。Checklist 汇集了有经验的测试人员总结出来的最有效的测试想法，可以直接有效的指导测试工作，开阔测试人员的思路，能够快速的发现产品的缺陷并实现较好的测试覆盖，更重要的是该Checklist 在不同的项目中具有很强的通用性。
回页首
表格输入Checklist
表1. 表格输入Checklist 总结
1.1 接收到非法输入时是否能恰当处理？
一个好的软件，当接收到非法输入时，能够恰当的处理，不能给出不可预知的错误信息。请看下面的例子。
图1. 电子邮件地址和电话号码
从图 1 的例子中可以发现，当我们在该页面的邮件地址中输入非法的邮件地址时，产品给出了适当的错误提示，并且当用户将鼠标至于红色错误警示标志之上时，可以得到更加详细的提示窗口，该实例对邮件地址的非法输入给出了恰当的提示。而在该图的电话号码输入框中，我们输入一串字母作为非法输入，而并没有得到任何非法输入警告提示，这是一个软件缺陷。
1.2 该输入是可选输入还是必填输入？
Web 产品页面上，输入域是必填项还是可选项需要进行验证。有两个方面的验证需要完成: 第一，必填输入域确实是必须填的，当没有输入时会有错误提示；可选输入域是可以不填的。第二，确保必填输入域是确实必要的，而可选输入域是非必要的。下面我们提供两个实例。
图2. 可选项邮件地址未输入时报错
图 2 的实例中，电子邮件地址为可选输入项，当用户没有填写该项时，产品提示需要输入邮件地址，而这与可选项的定义不符。这是产品的一个缺陷。
图3. 不合理的可选项输入设置
图 3 的实例中显示为创建一个群组的窗口页面，该页面上唯一的输入即群组名称，而该群组名称作为群组的唯一标识，是应该为必填输入项的。而这里，产品并未将该输入项作为必填项。当用户不做任何输入，直接点击确定时，一个没有名字的群组将被创建。这是不合理的，是产品的缺陷。
1.3 输入超过允许长度的数据
正常情况下，每个输入域对输入数据的长度需要进行约束，给出最小长度和最大长度限制。如果用户输入的数据长度超过最大允许长度，程序需要做出恰当处理。例如，测试人员可以创建一个1,000,000 字节或者更长的字符串，将该字符串输入到输入区域内，并继续后续操作，比如保存或者运行，看程序是否能够给出错误提示或者对字符串长度进行自动截断处理等操作。
1.4 页面装载或重装载后默认值
当网页产品的页面装载完成以后，页面上显示的初始默认值，需要满足一致性和准确性。一致性是指，每次从不同的路径到达相同页面后，在做进一步操作之前，页面默认值需要保持一致。准确性是指，页面上的默认值需要布局合理，需要使能的按钮和操作都是可用的，需要被禁止的功能要确保不可用。
图4. 初始加载页面
图 4 显示的为打开一个用户配置文件页面，该页面打开后在不做任何更新的情况下，保存和取消按钮处于使能状态。而实际上此时点击两个按钮是没有意义的，因为根本没有任何信息的更新，不需要保存也不需要取消。这是产品的一个缺陷，正确的处理方法是在初始加载页面上禁止两个按钮的工作，使其处于禁止状态。
1.5 组合框中的数据可以正常选择和更改
组合框中的数据需要保证所有的列表内容都可以被正常选择到，同时在已选择一项时可以更改为另外一项内容。下面的例子中将演示一个组合框的缺陷。
图5. 组合框缺陷实例
图 5 的例子中，左侧图显示的是初始状态下组合框的列表内容，默认选择的是Custom Group, 展开列表后可以看到Search Results。右侧图显示的是，当更改列表选择到Search Results 后，再次展开选择列表，列表中不能看到另外的选项Custom Group，这是产品的一个缺陷。产品需要确保不同时期都可以看到所有的列表选项内容。
1.6 表格是否显示了所有的部分？是否十分正确的排列？文字内容是否处于正确的位置？
一个表格需要多个部分，首先需要确保所有的部分都存在，并且他们都正确的排列在页面上，还需要保证文字的内容位置是合理的。
图6. 表格内容排列未对齐的例子
如图 6 所示，在图中所示的表格中，不同组件的排列不齐，左边属性名称和右边的属性值输入域应该是水平对齐的。这里是产品的一个缺陷。
1.7 滚动条是否在需要时出现？
滚动条的作用是为了保证当页面待显示内容超过显示区域尺寸时，可以通过拖动滚动条来看到显示区域之外的内容。而软件产品有时未能对该情况进行合理的处理。下图是我们测试中遇到的一个网页产品缺陷。
图7. 滚动条缺失
如图7 所示，注意红色圈内位置有一个未显示完全的按钮，其实下方还有其他更多内容，该部分内容已经超出显示区域的范围，应该在右侧有一个垂直滚动条使用户能看到下方的内容。这里垂直方向滚动条的缺失为产品的缺陷。
回页首数据验证Checklist
2.1 任何时候当输入非法数据时，系统都不能表现糟糕
尽管软件产品设计的目的不是仅为了接收非法数据输入，但是产品需要确保当得到非法数据时依然不会表现的很糟糕，而依然应该做出恰当的处理。非法数据的类型分为很多种，包括数据长度、数据的大小、数据中的非法字符、数据输入的顺序等方面。
2.2 如果用户在产品使用过程中删除cookie 会有什么后果？
Cookie 是产品为了识别用户身份、保存用户配置信息、进行会话跟踪等而保存在本地终端上的数据。产品设计需要保证在用户使用过程中，如果用户删除cookie，产品依然处理得当，不会有太糟糕的、不可预知的行为出现。
2.3 如果用户在使用产品后删除cookie 会有什么后果？
如果用户在使用产品之后删除cookie，当用户再次访问产品时，需要保证产品依然做出恰当的处理，不会有出乎意料的动作发生。
回页首数据一致性Checklist
3.1 检查输入最大字符长度时显示、工作是否正常
每个输入域都有自己的输入字符长度限制，当输入长度达到最大长度时，需确保产品显示和工作都正常。通常情况下，属于最大长度字符时，给页面的显示难度带来很大挑战，因为此时需要在有限的页面显示的内容最多。以下实例显示了一个最大长度显示相关的产品缺陷。
图8. 最大长度输入时显示缺陷
如图8 所示的例子中，当名字和姓氏都输入达到最大长度时，保存之后显示框中无法将两部分内容完整的呈现，并且没有水平滚动条辅助显示。这是软件产品的一个显示缺陷。
3.2 验证数字输入域是否接受负值及接受负值是否合理
数字数与区域有些情形下是不应该接受负值输入的，此时如果处理不当，当有负值输入时，将会有不可预知的情况出现。如果允许接受负值，测试对负值的处理是否正确也是测试中重要的一个方面。
3.3 确保数据保存之后所有的数值在数据库中都得到完整的保存
在产品页面上对数据进行保存之后，需要确保所有数值都完整的保存到了数据库中。从不同途径访问到相同的数据都是一致的、同步的。为了验证这一点，测试人员需要尝试在保存之后重新打开并查看显示，看是否跟保存之前的数据完全一致，同时努力从不同的路径访问和应用相同的输入，验证是否能得到一致的结果。
回页首日期输入Checklist
4.1 验证闰年被正确验证并且不引起计算错误
闰年是公历纪年中比较特殊的年份，因为该年有366 天。基本的计算方法是：四年一闰，百年不闰，四
百年再闰。因为涉及到日期的输入时，测试人员需要考虑在闰年出现时，产品依然正确的响应。闰年比平
年多出来的一天，出现在 2 月的最后一天，即 2 月29 日。
除了闰年需要考虑外，跨年的一天以及整百年的年份也需要加以考虑，因为这些特殊的年份可能会引起不
可预知的错误。
4.2 网页版权信息中的日期是否已更新？
网页的版权信息通常位于About（关于）页面中，其中记录了产品的名字、公司版权、详细版本信息、版权年份等信息。测试人员需要确保版权信息是及时、准确的，跟产品的实际版本是一致的。
回页首数字输入Checklist
表5. 数字输入Checklist 总结
5.1 确保最小、最大值正确处理
对于数字输入域，一般都有自己的最大值和最小值，这两个极值的处理需要特别验证。除了验证最大最小
值之外，测试人员最好一起验证比最小值小的值和比最大值大的值是否能被产品恰当处理。
举例，在定义一个连接的过程中需要输入一个端口号，该端口号的最小值为1。而当用户输入端口号为0 时，可以成功添加该连接。而当用户去验证该连接时，提示端口号0 是非法的。这是产品的一个缺陷。正确的处理方式是，当用户视图添加端口号为0 时，就给出错误提示信息，告知用户该端口号是非法的。
另外一个需要考察的地方，当输入超出最大最小值时，产品需要给出清晰明确的警告和提示，告知用户正
确的范围是什么。下面的例子给出了一个不恰当的错误提示信息。
图9. 数值输入超出范围提示错误不够具体
图9 的例子中，输入的数值超出了允许的范围，但是提示信息非常模糊，看到该提示消息，用户依然不知道该数值的范围应该是多少。这是产品的缺陷，它需要给出更加的明确的信息，使用户一看就能知道数值的有效范围是多少。
5.2 确保数值输入框的第一个字符位置输入空格时报错
当数值输入框的第一个字符为空格时，该输入已经不再是一个数值，应当做非法输入处理。产品处理过程中，需要给出错误信息。
5.3 确保输入值输入框的最后一个字符位置输入空格时报错
当数值输入框的最后一个字符为空格时，该输入已经不再是一个数值，应当做非法输入处理。产品处理过程中，需要给出错误信息。
5.4 确保正号(+) 和负号(-) 被正确处理
每个涉及到数值输入的地方，都涉及到一个数值符号的问题。因为数值有正负之分，需要保证产品对正负数的处理都准确恰当。对于能够接受带正号数值的输入框，处理结果应该跟不含符号( 默认为正数) 的数值输入的结果相同，因为本质上两个数值是相等的( 对输入数值的再显示除外，因为单纯显示上，两者相差一个+ 号)。
5.5 避免除数为0
除数为0 是所有的运算中需要避免的。在软件产品中，如果涉及到除法运算，需要特别注意避免除数为0 的情况发生。其中包含各种情况下的除数为0，包括除数为输入值0，除数为某中间计算结果为0 等。
5.6 在所有的运算中加入0
因为0 在所有的运算中具有重要的作用，也是一个非常特殊的数值。因此在测试过程中，在所有涉及到的运算中加入0 值对测试产品具有很好的效果，能测试到较多的与0 相关的情况。
回页首数字字符输入区检查Checklist
6.1 尝试空数据和非空数据
空数据的处理在数据输入测试中，具有非常重要的作用。对空数据的处理方式可能有多重情况：可能是当作用户无输入而采用默认值处理，这时需要验证空数据处理结果和默认值处理结果是否一致；可能把空数据当作非法数据处理，这时候需要验证出现的错误提示是否清楚有效；有时，空数据也作为0 值处理，这时需要比较空数据的输出结果跟0 值的处理结果是否一致。
6.2 尝试输入非法字符和符号
在负面测试中，一个很重要的方面就是对非法字符和符号的测试。通常，一个产品有自己的一套命名规范，对产品中使用的符号哪些是允许的、有效的，都有明确的定义，也就是合法的输入。而合法输入之外的字符和符号，就是非法的。测试人员需要将此类非法字符和符号输入到产品中，看产品是否恰当的处理。
拿数据集和成员的名字作为例子。它们有自己完整清晰的命名规范。从合法字符的角度来讲，数据集和成员的名字中，只能采用26 个英文字母、数字和三个特殊字符&、#、@，同时数字不能出现在数据集名字分段的首个字符或成员名称的首字符。下面一个例子描述的就是关于此方面的一个产品缺陷。
图10. 数据集名字和成员名字中的非法字符输入
图10 中，当用户在数据集名字和成员名字中输入非法字符$ 和% 时，产品页面并没有提供警告信息，这是产品的一个缺陷，而该缺陷在后期的数据处理阶段将会暴露出来，因为包含非法字符的名字是无法被主机接受和处理的。
6.3 尝试合法字符
通常来讲，合法字符的测试是功能测试中最基本的内容。但是，合法字符的测试也包含众多方面。最基本的是简单输入，就是单个合法字符或者字符串的输入。其次，将不同的简单输入组合在一起，可以组成复杂输入。此外，还可以对最大允许字符长度进行测试，甚至多个输入域均取最大允许长度进行测试。
回页首总结
数据输入是Web 产品测试中非常重要的一部分，它就好似产品的血液，流淌在产品的每一部分。而数据输入包含很多不同的方面，包括表格输入、日期数字和字符输入，还需要涉及到用户的验证和一致性检查。要想做好所有这些类型的测试和检查，单凭测试人员的经验和记忆是很难给出全面测试的。
本文介绍了利用Checklist 的思想对各数据类型数据点进行最高效的攻击和测试，能非常高效的发现产品的缺陷。Checklist 很好的利用了前人的经验应用到现在的项目中，极大的提高了工作效率，同时可以克服单个测试人员的一些缺点，比如思维的局限性、经验的缺失、思维的疏忽以及记忆的局限性。总之，Checklist 可以最大化测试人员的工作效率，在有限的时间内发现最多的产品缺陷，从而提高产品的质量。
第 2 部分: 导航和链接
软件产品测试中的应用，以帮助读者了解如何利用Checklist 这种重要的测试手段，更高效的寻找Web 产品中的defect（缺陷）。Checklist 汇集了有经验的测试人员总结出来的最有效的测试想法，可以直接有效的指导测试工作，开阔测试人员的思路，能够快速的发现产品的缺陷并实现较好的测试覆盖，更重要的是该Checklist 在不同的项目中具有很强的通用性。该系列文章中，将在每个部分给出具体的有效的Checklist 并提供相关应用实例，以便于您的理解和应用。
导航和链接测试包含的范畴
在Web 开发测试中，导航和链接为用户提供了丰富的操作体验，用户可以通过导航和链接实现对各类数据的访问。导航，从基本意义上理解，就是当用户触发该导航操作后，用户界面将被指向当前系统的另外一个目的页面的过程，换句话说，导航实现了在系统内部从一个数据页面到另外一个数据页面的变化过程，这有助于用户更加方便快捷的访问关联的数据内容。链接，在这里我们指的是从Web 产品内部直接连接到外部目的地址的超链接。
对于本文中提到的导航和链接，简单来说，可以这样理解：导航是Web 产品内部的跳转和移动，链接是从Web 产品内部对外部地址的访问。
回页首导航Checklist 介绍
表1. 导航Checklist 总结
1.1 检查滚动条在需要时是否能正确显示
滚动条的显示在网页导航中的作用非常重要。在需要时，滚动条的恰当显示是必要的。下面通过几个例子来演示滚动条在网页产品中可能遇到的一些缺陷实例。
图1. 冗余的滚动条显示
从图 1 中可以看到，该网页窗口中，当前并没有显示任何超出窗口显示范围的内容，但依然显示了水平和垂直两个方向的滚动条。此时，这两条滚动条是多余的，是产品的一个缺陷。
图2. 滚动条在窗口尺寸变化需相应变化
通常情况下，滚动条位于一个显示区域的边缘，当位于该边缘的另外一个区域尺寸发生变化时，滚动条的位置也需要随之发生变化。如图 2 中所示，当图中下端的预览窗口尺寸发生变化时，上端的滚动条并未跟随相应的移动到预览窗口的上边界，从而出现了中间的空白区域，此问题是一个产品缺陷。
1.2 验证网页上的所有操作均可以通过键盘操作完成
考虑到软件产品的用户很广泛，需要保证在仅操作键盘的情况下，依然可以完整的使用网页产品的所有功能。也就是说，用户可以仅用键盘上的操作，比如回车、文本输入、Tab 键、空格等，就可以顺畅的应用产品功能。
图3. 键盘操作无法选择下拉框内容实例
图 3 所示，该页面下，当通过键盘Tab 键将光标移动到框体“Select One”后，当试图通过上下键选择具体下拉列表中的内容时，没有任何反应。应用本条目，既然选择列表项目可以通过鼠标完成，这里也应该可以通过键盘操作完成，此问题为产品的一个缺陷。
1.3 面包屑导航是否存在？
面包屑导航是指用户在访问过程中能获得当前位于网站中的位置，并知道如何返回。本项checklist 需要考察页面上显示的位置和路径是否是正确的、有效的，并且不包含冗余信息。
图4. 面包屑导航问题实例
如上图 4 中显示，该产品在访问相关数据的过程中，按照用户需求，当用户点击某一个资源时，将显示该资源的信息，并且将其名字显示在顶端的“面包屑”中。但当前显示的页面上，当用户快速连续多次点击该资源时，就会出现多个重复的资源面包屑，但其实真正显示的数据只有一份。这些冗余的显示信息是产品的一个缺陷，将会给用户带来困扰。
1.4 确保在未保存当前页面时离开页面有用户提示信息
在网页上的用户输入页面，当用户输入了一部分信息之后，如果需要离开当前页面但并没有对数据进行保存，产品需要提示用户当前页面输入的数据没有保存，确认是否需要保存。从用户使用产品的角度来考虑，当用户在一个输入页面输入了大量信息之后，万一出现鼠标的误操作，以致点击到某个按钮而导致离开页面，对于用户来说这属于非常糟糕的体验，在开发过程中应尽量避免此类问题的发生。
回页首链接Checklist 介绍
2.1 检查站点地图中的所有链接并查看是否存在损坏的链接
通常网页中都会提供各种外部链接，以便用户方便的获取相关联的网站以外的信息。我们需要检查所有显示的外部链接，找出其中的损坏的链接并加以修复。
图5. 损坏链接实例
如图 5 所示，该页面为点击一个外部链接以后显示的内容，该链接已经被损坏，无法指向正确的页面。
2.2 确保所有链接的目的地址跟标题描述相符
通常每个超链接都有属于自己的标题描述信息，该描述信息应尽可能清楚简洁的描述它指向的目的地址。我们在开发测试过程中，需要确保该描述和实际目的地址的一致性，以免出现不一致性而导致不好的用户体验。
超链接的标题是引导用户点击的第一路标，它的描述是否清楚，关系到用户是否能清晰的理解该链接的作用和目的地址的信息。同时，链接的标题描述中，应尽量简洁，且包含必要的信息提示，尽量避免使用“点击这里”等词语，应使用更有意义的用词。
2.3 确保没有孤儿页面（没有链接指向它）
我们需要保证产品页面中，不存在孤儿页面，也就是永远没有链接指向它的页面。该类页面对用户来说没有价值，并且是对资源的浪费，在设计阶段需加以避免。
2.4 检查所有引用的网络站点和邮箱地址是否添加了超链接
正常情况下，所有引用到的网络站点和邮箱地址都需要增加超链接，这样可以保证用户轻易的知道这些站点和邮箱地址是超链接，用户通过点击这些超链接就可以轻易到达不同的目的地址。否则，用户将只能通过复制这些链接和邮箱到浏览器中，这将大大增加操作的复杂程度，给用户带来不便。
2.5 确保光标置于超链接之上时呈现为手形
当光标置于超链接之上时，这时光标由原图标变为手形，这样有助于提醒用户当前区域为超链接的范围，点击可以触发超链接跳转。如果手形未能恰当显示，将是产品的缺陷。此外，当光标位于可以点击的按钮的上方时，也应该显示为手形图标，以提醒用户现在是可点击跳转区域。
图6. 超链接光标不显示为手形实例1
如上图 6 中所示，当光标处于红圈标记的超链接区域时，并未显示为手形。而用户直接点击鼠标时，则会跳转到描述中提示的目标页面。
图7. 超链接光标不显示为手形实例2
图7 中显示的是一个帮助按钮的页面，当光标位于帮助按钮上方时，会出现弹出帮助信息提示“点击帮助图标了解更多”。用户此时确实可以通过点击帮助按钮图标跳转到更多帮助页面，但是当光标位于帮助图标上方时，光标并未显示为手形，这也是产品的缺陷。
2.6 确保所有的链接都带下划线
为了给用户明确的提示，所有的链接都需要带下划线，这样用户在页面上很清楚就可以知道哪里是超链接的范围，哪里不是。当然超链接的字体颜色通常也跟周围不同，访问过的链接和未访问的链接颜色也不同。具体颜色的定义各个产品不尽相同，但所有的链接都有下划线这点是一致的。
2.7 确保相关信息链接出现在内容的底端或者靠近顶端位置
通常情况下，“相关信息”是用来帮助用户获取对当前页面内容更深入的了解的相关信息，一般位于当前内容页面的底端或者靠近顶端的位置。这样最有利于用户定位和寻找相关信息。设想如果相关信息链接出现在内容中间，将会跟内容中本身自带的超链接发生混淆，用户将难以定位和寻找需要的相关链接。
回页首总结
导航和链接作为用户使用网页产品的重要工具，是用户直接操作的对象，对用户体验的提升具有重要作用。两者的设计应该力求简练、高效，在提供给用户提供便捷的导航和移动的同时，也力求杜绝各种冗余的信息。
本文分别讨论了网页产品中的导航和链接中Checklist 的应用，并给出了实际测试工作中的一些应用实例，演示了具体产品缺陷出现的场景。本文的目的主要是让网页产品开发人员和测试人员在导航和链接两个方面能尽量提供高效的产品，并依据本文提到的Checklist 相关条目杜绝相关产品缺陷。
第 3 部分: 颜色和字体
软件产品测试中的应用，以帮助读者了解如何利用Checklist 这种重要的测试手段，更高效的寻找Web 产品中的defect（缺陷）。Checklist 汇集了有经验的测试人员总结出来的最有效的测试想法，可以直接有效的指导测试工作，开阔测试人员的思路，能够快速的发现产品的缺陷并实现较好的测试覆盖，更重要的是该Checklist 在不同的项目中具有很强的通用性。该系列文章中，将在每个部分给出具体的有效的Checklist 并提供相关应用实例，以便于您的理解和应用。
颜色和字体测试包含的范畴
用户通过使用网页产品获取大量的数据信息，这些信息的显示方式包括图形和文字两大部分。而在向用户呈现图形和文字的过程中，颜色和字体扮演了非常重要的角色。合理恰当的颜色和字体设置可以保证用户以最高效、清晰的方式获取到需要的信息，而如果颜色和字体设置的不恰当，用户将花费更多的时间获取相同的信息量，从而导致用户获取信息的效率下降。
本文中，将列举一些Web 产品开发中需要注意的事项，通过避免这些事项，可以从一定程度上杜绝此类的问题给用户带来的不良体验，从而提高产品的用户满意度。本文也会举例说明一些具体的Web 产品缺陷实例。
回页首颜色测试Checklist
表1. 颜色测试Checklist 总结
1.1 检查超链接的颜色
超链接的颜色显示通常呈现三种形式：缺省颜色、有光标时的颜色、访问后颜色，如图 1 所示。
图1. 超链接的三种颜色显示
按照以上一致性的要求，可以保证用户在不同的产品之间切换时，能有一致的用户感受和体验，对用户流畅的应用新的产品很有帮助。
1.2 确保所有页面的背景颜色都被测试
对于一款用户用好的网页产品，所有页面的背景颜色需要具有一致性，以保证提供给用户一致的用户体验。
图2. 页面背景颜色不一致实例
图 2 中所示，该实例中，当水平滚动条出现后，拖动水平滚动条查看右侧内容，可以发现左右两侧的页面背景颜色是不一致的，这会让用户体验下降，是产品的一个缺陷。
1.3 检查警告消息的颜色是否符合规范
警告消息需要对用户进行醒目的提醒和警告，需要很容易即可被用户发现。因此，通常警告消息的颜色设置为粉红色，如图 3 所示。
图3. 警告消息实例
在网页产品开发和测试过程中，开发测试人员需要检查警告消息的颜色是否保持一致，是否符合以上的颜色规范。
1.4 确保相似页面的颜色一致
为了保持网页产品页面设计的一致性，为用户提供一致的体验，相似页面的颜色需保持一致。
图4. 相似页面背景色不一致实例
上图 4 中所示的实例，是以往我们遇到的一例相似页面背景色颜色不一致的情况。该实例中，左侧Exceptions 和右侧Reports 窗口组件在没有数据显示时，呈现出不同的背景颜色，而在用户看来，这两种情况均反映了没有数据的情况。两个窗口组件此时应显示一致的背景色，这是产品的一个缺陷。
图5. 相似窗体背景色不一致实例
以上图 5 的实例中，显示的是同一个表格中不用列的标题部分背景颜色不一致的例子。第一列的标题窗体呈现为均匀的颜色显示，而右侧其余的列则出现了不平滑的颜色跳跃，这也是产品的缺陷。
1.5 确保前景色和背景色是易读的
由于人眼对颜色对比度的敏感性，为了保证用户对显示内容的易读性，需要保证前景色和背景色有一定的差异，达到一定的对比度。否则，如果前景色和背景色颜色过于接近，将给用户带来较大的阅读困难。举例，同时是蓝色的前景色，如果背景颜色也是蓝色，前景和背景将混在一起，使得用户无法区分。
图6. 前景色和背景色太接近的实例
web安全测试
————————————————————————————————作者：————————————————————————————————日期：
Web安全测试——手工安全测试方法及修改建议发表于：2017-7-17 11:47 作者：liqingxin 来源：51Testing软件测试网采编 字体：大中小 | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签：软件测试工具XSS安全测试工 具 常见问题 1.XSS(CrossSite Script)跨站脚本攻击 XSS(CrossSite Script)跨站脚本攻击。它指的是恶意攻击者往Web 页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web 里面的html 代码会被执行，从而达到恶意用户的特殊目的。 测试方法： 在数据输入界面，添加记录输入：，添加成功如果弹出对话框，表明此处存在一个XSS 漏洞。 或把url请求中参数改为，如果页面弹出对话框，表明此处存在一个XSS 漏洞 修改建议： 过滤掉用户输入中的危险字符。对输入数据进行客户端和程序级的校验（如通过正则表达式等）。 Eg:对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”’”等字符是否做过滤 2.CSRF与跨站脚本(XSS) CSRF与跨站脚本(XSS)，是指请求迫使某个登录的浏览器向易受攻击的Web应用发送一个请求，然后以受害者的名义，为入侵者的利益进行所选择的行动。
DKBA 华为技术有限公司内部技术规范 DKBA Web应用安全测试规范 2009年7月5日发布2009年7月5日实施华为技术有限公司 Huawei Technologies Co., Ltd. 版权所有侵权必究 All rights reserved
修订声明Revision declaration 本规范拟制与解释部门： 安全解决方案部电信网络与业务安全实验室、软件公司安全TMG、软件公司测试业务管理部本规范的相关系列规范或文件： 《Web应用安全开发规范》 相关国际规范或文件一致性： 《OWASP Testing Guide v3》 《信息安全技术信息安全风险评估指南》 《Information technology Security techniques Management of information and communications technology security》－ISO 13335 替代或作废的其它规范或文件： 无 相关规范或文件的相互关系： 本规范以《Web应用安全开发规范》为基础、结合Web应用的特点而制定。
目录Table of Contents 1概述错误!未定义书签。 背景简介错误!未定义书签。 适用读者错误!未定义书签。 适用范围错误!未定义书签。 安全测试在IPD流程中所处的位置错误!未定义书签。 安全测试与安全风险评估的关系说明错误!未定义书签。 注意事项错误!未定义书签。 测试用例级别说明错误!未定义书签。 2测试过程示意图错误!未定义书签。 3Web安全测试规范错误!未定义书签。 自动化Web漏洞扫描工具测试错误!未定义书签。 AppScan application扫描测试错误!未定义书签。 AppScan Web Service 扫描测试错误!未定义书签。 服务器信息收集错误!未定义书签。 运行帐号权限测试错误!未定义书签。 Web服务器端口扫描错误!未定义书签。 HTTP方法测试错误!未定义书签。 HTTP PUT方法测试错误!未定义书签。 HTTP DELETE方法测试错误!未定义书签。 HTTP TRACE方法测试错误!未定义书签。 HTTP MOVE方法测试错误!未定义书签。 HTTP COPY方法测试错误!未定义书签。 Web服务器版本信息收集错误!未定义书签。 文件、目录测试错误!未定义书签。 工具方式的敏感接口遍历错误!未定义书签。 Robots方式的敏感接口查找错误!未定义书签。 Web服务器的控制台错误!未定义书签。 目录列表测试错误!未定义书签。 文件归档测试错误!未定义书签。 认证测试错误!未定义书签。 验证码测试错误!未定义书签。 认证错误提示错误!未定义书签。 锁定策略测试错误!未定义书签。 认证绕过测试错误!未定义书签。 找回密码测试错误!未定义书签。 修改密码测试错误!未定义书签。 不安全的数据传输错误!未定义书签。 强口令策略测试错误!未定义书签。 会话管理测试错误!未定义书签。 身份信息维护方式测试错误!未定义书签。 Cookie存储方式测试错误!未定义书签。 用户注销登陆的方式测试错误!未定义书签。 注销时会话信息是否清除测试错误!未定义书签。 会话超时时间测试错误!未定义书签。
DKBA DKBA 2355-2009.7 .2cto.红黑联盟收集整理 Web应用安全测试规V1.2 2009年7月5日发布2009年7月5日实施 所有侵权必究 All rights reserved
修订声明Revision declaration 本规拟制与解释部门： 安全解决方案部电信网络与业务安全实验室、软件公司安全TMG、软件公司测试业务管理部 本规的相关系列规或文件： 《Web应用安全开发规》 相关国际规或文件一致性： 《OWASP Testing Guide v3》 《信息安全技术信息安全风险评估指南》 《Information technology Security techniques Management of information and communications technology security》－ISO 13335 替代或作废的其它规或文件： 无 相关规或文件的相互关系： 本规以《Web应用安全开发规》为基础、结合Web应用的特点而制定。
目录Table of Contents 1概述 (7) 1.1背景简介 (7) 1.2适用读者 (7) 1.3适用围 (7) 1.4安全测试在IPD流程中所处的位置 (8) 1.5安全测试与安全风险评估的关系说明 (8) 1.6注意事项 (9) 1.7测试用例级别说明 (9) 2测试过程示意图 (10) 3WEB安全测试规 (11) 3.1自动化W EB漏洞扫描工具测试 (11) 3.1.1AppScan application扫描测试 (12) 3.1.2AppScan Web Service 扫描测试 (13) 3.2服务器信息收集 (13) 3.2.1运行权限测试 (13) 3.2.2Web服务器端口扫描 (14) 3.2.3HTTP方法测试 (14) 3.2.4HTTP PUT方法测试 (15) 3.2.5HTTP DELETE方法测试 (16) 3.2.6HTTP TRACE方法测试 (17) 3.2.7HTTP MOVE方法测试 (17) 3.2.8HTTP COPY方法测试 (18) 3.2.9Web服务器版本信息收集 (18) 3.3文件、目录测试 (20) 3.3.1工具方式的敏感接口遍历 (20) 3.3.2Robots方式的敏感接口查找 (21)
精品文档 1 Web安全测试技术方案 1.1 测试的目标更好的发现当前系统存在的可能的安全隐患，避免发生危害性的安全事件更好的为今 后系统建设提供指导和有价值的意见及建议 1.2 测试的范围 本期测试服务范围包含如下各个系统： Web系统： 1.3 测试的内容 1.3.1 WEB^ 用 针对网站及WEB系统的安全测试，我们将进行以下方面的测试： Web 服务器安全漏洞 Web 服务器错误配置 SQL 注入 XSS （跨站脚本） CRLF 注入 目录遍历 文件包含 输入验证 认证 逻辑错误 Google Hacking 密码保护区域猜测字典攻击特定的错误页面检测脆弱权限的目录危险的HTTP 方法（如：PUT、DELETE） 1.4 测试的流程 方案制定部分： 精品文档 获取到客户的书面授权许可后，才进行安全测试的实施。并且将实施范围、方法、时间、人员等具体的方案与客户进行交流，并得到客户的认同。 在测试实施之前，让客户对安全测试过程和风险知晓，使随后的正式测试流程都在客户的控制下。 信息收集部分：
这包括：操作系统类型指纹收集；网络拓扑结构分析；端口扫描和目标系统提供的服务识别等。采用商业和开源的检测工具（AWVS burpsuite、Nmap等）进行收集。 测试实施部分： 在规避防火墙、入侵检测、防毒软件等安全产品监控的条件下进行：操作系统可检测到的漏洞测试、应用系统检测到的漏洞测试（如：Web应用），此阶段如果成功的话，可能获得普通权限。 安全测试人员可能用到的测试手段有：扫描分析、溢出测试、口令爆破、社会工程学、客户端攻击、中间人攻击等，用于测试人员顺利完成工程。在获取到普通权限后，尝试由普通权限提升为管理员权限，获得对系统的完全控制权。此过程将循环进行，直到测试完成。最后由安全测试人员清除中间数据。 分析报告输出： 安全测试人员根据测试的过程结果编写直观的安全测试服务报告。内容包括：具体的操作步骤描述；响应分析以及最后的安全修复建议。 下图是更为详细的步骤拆分示意图： 精品文档 1.5 测试的手段 根据安全测试的实际需求，采取自动化测试与人工检测与审核相结合的方式，大大的减少了自动化测试过程中的误报问题。
安全测试方面应该参照spi的web安全top 10来进行。 目前做软件测试人员可能对安全性测试了解不够，测试结果不是很好。如果 经验不足，测试过程中可以采用一些较专业的web安全测试工具，如WebInspect、Acunetix.Web.Vulerability.Scanner等，不过自动化web安全测试的最大缺陷就是误 报太多，需要认为审核测试结果，对报告进行逐项手工检测核对。 对于web安全的测试用例，可以参照top 10来写，如果写一个详细的测试用例，还是比较麻烦的，建议采用安全界常用的web渗透报告结合top10来写就可以了。 现在有专门做系统和网站安全检测的公司，那里做安全检测的人的技术都很好，大多都是红客。 再补充点，网站即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。 目录设置 Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执 行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径 "…com/objects/images".然后在浏览器地址栏中手工输入该路径，发现该站点所有 图片的列表。这可能没什么关系。我进入下一级目录"…com/objects" ，点击jackpot.在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月 都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他 们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。 SSL 很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器 出现了警告消息，而且在地址栏中的HTTP 变成HTTPS.如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面（适用于3.0 以下版本的浏览器，这些浏 览器不支持SSL.当用户进入或离开安全站点的时候，请确认有相应的提示信息。 是否有连接时间限制？超过限制时间后出现什么情况？ 登录
1 Web 安全测试技术方案 1.1测试的目标 更好的发现当前系统存在的可能的安全隐患，避免发生危害性的安全事件 更好的为今后系统建设提供指导和有价值的意见及建议 1.2测试的范围 本期测试服务范围包含如下各个系统： Web 系统： 1.3测试的内容 1.3.1WEB 应用 针对网站及WEB 系统的安全测试，我们将进行以下方面的测试： Web 服务器安全漏洞 Web 服务器错误配置 SQL 注入 RSS （跨站脚本） CRLF 注入 目录遍历 文件包含 输入验证 认证逻辑错误 GoogleHacAing 密码保护区域猜测字典攻击特定的错误页面检测脆弱权限的目录危险的HTTP
方法（如：PUT、DELETE） 1.4测试的流程 方案制定部分：获取到客户的书面授权许可后，才进行安全测试的实施。并且将实施范围、方法、时间、人员等具体的方案与客户进行交流，并得到客户的认同。 在测试实施之前，让客户对安全测试过程和风险知晓，使随后的正式测试流程都在客户的控制下。 信息收集部分：这包括：操作系统类型指纹收集；网络拓扑结构分析；端口扫描和目标系统提供的服务识别等。采用商业和开源的检测工具（AWVS 、burpsuite 、Nmap 等）进行收集。 测试实施部分：在规避防火墙、入侵检测、防毒软件等安全产品监控的条件下进行：操作系统可检测到的漏洞测试、应用系统检测到的漏洞测试（如：Web 应用），此阶段如果成功的话，可能获得普通权限。 安全测试人员可能用到的测试手段有：扫描分析、溢出测试、口令爆破、社会工程学、客户端攻击、中间人攻击等，用于测试人员顺利完成工程。在获取到普通权限后，尝试由普
WEB 安全性测试 第一章：预备知识： 1.1 SQL 语句基础 1.2 HTML语言 HTML（HyperTextMark-upLanguage）即超文本标记语言，是WWW的描述语言。html 是在 sgml 定义下的一个描述性语言，或可说 html 是 sgml 的一个应用程式，html 不是程式语言，它只是标示语言。 实例：
表单提交中Get和Post方式的区别有5点 1. get是从服务器上获取数据，post是向服务器传送数据。 2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单各个字段与其容放置在HTML HEADER一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。WEB的安全性测试主要从以下方面考虑： 目录 1.SQL Injection(SQL注入) (1) 2.Cross-site scritping(XSS):(跨站点脚本攻击) (3) 3.CSRF:(跨站点伪造请求) (6) 4.Email Header Injection(邮件标头注入) (6) 5.Directory Traversal(目录遍历) (7) 6.exposed error messages(错误信息) (7) 1.SQL Injection(SQL注入) (1)如何进行SQL注入测试? ?首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等. 注1:对于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在
的标签中间的每一个参数传递都有可能被利用. 注 2:当你找不到有输入行为的页面时,可以尝试找一些带有某些参数的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10 ?其次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断,如在登录页面的URL中输入HTTP://DOMAIN /INDEX.ASP?USERNAME=HI' OR 1=1--一、Web 应用安全威胁分为如下六类： (2) 二、常见针对Web 应用攻击的十大手段 (2) 三、Rational AppScan功能简介 (3) 四、Web安全体系测试 (4) 五、web安全测试的checklist (5) 六、跨站点脚本攻击测试要点 (7) 七、Cookie： (10) 八、跨站点攻击： (12) 九、DOS攻击： (13) 十、暴力破解 (14) 十一、 sql注入 (15)
一、Web 应用安全威胁分为如下六类： Authentication（验证） 用来确认某用户、服务或是应用身份的攻击手段。 Authorization（授权） 用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。 Client-Side Attacks（客户侧攻击） 用来扰乱或是探测Web 站点用户的攻击手段。 Command Execution（命令执行） 在Web 站点上执行远程命令的攻击手段。 Information Disclosure（信息暴露） 用来获取Web 站点具体系统信息的攻击手段。 Logical Attacks（逻辑性攻击） 用来扰乱或是探测Web 应用逻辑流程的攻击手段 二、常见针对Web 应用攻击的十大手段 应用威胁负面影响后果跨网站脚本攻击标识盗窃，敏感数据丢失…黑客可以模拟合法用户，控 制其帐户。 注入攻击通过构造查询对数据库、LDAP 和其他系统进行非法查询。黑客可以访问后端数据库信息，修改、盗窃。 恶意文件执行在服务器上执行Shell 命令 Execute，获取控制权。被修改的站点将所有交易传送给黑客 不安全对象引用黑客访问敏感文件和资源Web 应用返回敏感文件内 容 伪造跨站点请求黑客调用Blind 动作，模拟合法 用户黑客发起Blind 请求，要求进行转帐
网站安全测评 一．Web应用系统的安全性测试区域主要有： （1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 （2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 （3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。 （4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 （5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 二．一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。 1.安全体系测试 1) 部署与基础结构 a. 网络是否提供了安全的通信 b. 部署拓扑结构是否包括内部的防火墙 c. 部署拓扑结构中是否包括远程应用程序服务器 d.基础结构安全性需求的限制是什么 e.目标环境支持怎样的信任级别 2) 输入验证
a. 如何验证输入 b.是否清楚入口点 c.是否清楚信任边界 d. 是否验证Web页输入 e.是否对传递到组件或Web服务的参数进行验证 f.是否验证从数据库中检索的数据 g.是否将方法集中起来 h.是否依赖客户端的验证 i.应用程序是否易受SQL注入攻击 j. 应用程序是否易受XSS攻击 k.如何处理输入 3)身份验证 a. 是否区分公共访问和受限访问 b.是否明确服务帐户要求 c.如何验证调用者身份 d. 如何验证数据库的身份 e.是否强制试用帐户管理措施 4)授权 a.如何向最终用户授权 b.如何在数据库中授权应用程序 c.如何将访问限定于系统级资源 5)配置管理 a.是否支持远程管理 b.是否保证配置存储的安全 c.是否隔离管理员特权 6)敏感数据 a.是否存储机密信息 b.如何存储敏感数据 c.是否在网络中传递敏感数据 d.是否记录敏感数据
常见的web安全性测试重点 1.XSS(CrossSite Script)跨站脚本攻击 XSS(CrossSite Script)跨站脚本攻击。它指的是恶意攻击者往Web 页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web 里面的html 代码会被执行，从而达到恶意用户的特殊目的。 测试方法： 在数据输入界面，添加记录输入：，添加成功如果弹出对话框，表明此处存在一个XSS 漏洞。 或把url请求中参数改为，如果页面弹出对话框，表明此处存在一个XSS 漏洞 修改建议： 过滤掉用户输入中的危险字符。对输入数据进行客户端和程序级的校验（如通过正则表达式等）。 Eg:对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”’”等字符是否做过滤 2.CSRF与跨站脚本(XSS) CSRF与跨站脚本(XSS)，是指请求迫使某个登录的浏览器向易受攻击的Web 应用发送一个请求，然后以受害者的名义，为入侵者的利益进行所选择的行动。 测试方法： 同个浏览器打开两个页面，一个页面权限失效后，另一个页面是否可操作成功 使用工具发送请求，在http请求头中不加入referer字段，检验返回消息的应答，应该重新定位到错误界面或者登陆界面。 修改建议： 在不同的会话中两次发送同一请求并且收到相同的响应。这显示没有任何参数是动态的（会话标识仅在cookie 中发送），因此应用程序易受到此问题攻击。因此解决的方法为 1.Cookie Hashing(所有表单都包含同一个伪随机值)： 2. 验证码 3.One‐Time Tokens(不同的表单包含一个不同的伪随机值)客户端保护措施：应用防止 CSRF攻击的工具或插件。 3.注入测试 SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。 测试方法：
看完入门篇和进阶篇后，稍加练习，破解一般的网站是没问题了。但如果碰到表名列名猜不到，或程序作者过滤了一些特殊字符，怎么提高注入的成功率？怎么样提高猜解效率？请大家接着往下看高级篇。 第一节、利用系统表注入SQLServer数据库 SQLServer是一个功能强大的数据库系统，与操作系统也有紧密的联系，这给开发者带来了很大的方便，但另一方面，也为注入者提供了一个跳板，我们先来看看几个具体的例子： ①;exec master..xp_cmdshell “net user name password /add”-- 分号;在SQLServer中表示隔开前后两句语句，--表示后面的语句为注释，所以，这句语句在SQLServer中将被分成两句执行，先是Select出ID=1的记录，然后执行存储过程xp_cmdshell，这个存储过程用于调用系统命令，于是，用net命令新建了用户名为name、密码为password的windows的帐号，接着： ②;exec master..xp_cmdshell “net localgroup name administrators /add”-- 将新建的帐号name加入管理员组，不用两分钟，你已经拿到了系统最高权限！当然，这种方法只适用于用sa连接数据库的情况，否则，是没有权限调用xp_cmdshell的。 ③;;and db_name()>0 前面有个类似的例子and user>0，作用是获取连接用户名，db_name()是另一个系统变量，返回的是连接的数据库名。 ④;backup database 数据库名to disk=’c:\inetpub\wwwroot\1.db’;-- 这是相当狠的一招，从③拿到的数据库名，加上某些IIS出错暴露出的绝对路径，将数据库备份到Web目录下面，再用HTTP把整个数据库就完完整整的下载回来，所有的管理员及用户密码都一览无遗！在不知道绝对路径的时候，还可以备份到网络地址的方法（如\\，但成功率不高。
安全测试工作规范 深圳市xx有限公司 二〇一四年三月
修订历史记录 A - 增加M - 修订D - 删除
目录 1 概述 (5) 1.1 背景简介 (5) 1.2 适用读者 (5) 1.3 适用范围 (5) 1.4 安全测试在项目整体流程中所处的位置 (6) 1.5 安全测试在安全风险评估的关系说明 (6) 1.6 注意事项 (6) 1.7 测试用例级别说明 (7) 2 Web安全测试方法 (8) 2.1 安全功能验证 (8) 2.2 漏洞扫描 (8) 2.3 模拟攻击实验 (8) 2.4 侦听技术 (8) 3 Appscan工具介绍 (9) 3.1 AppScan工作原理 (9) 3.2 AppScan扫描阶段 (10) 3.3 AppScan工具使用 (11) 3.4 AppScan工具测试覆盖项说明...................... 错误！未定义书签。 4 测试用例和规范标准 (19) 4.1 输入数据测试 (20) 4.1.1 SQL注入测试 (20) 4.1.2 命令执行测试 (25) 4.2 跨站脚本攻击测试 (26) 4.2.1 GET方式跨站脚本测试 (28) 4.2.2 POST方式跨站脚本测试 (29) 4.2.3 跨站脚本工具实例解析 (30) 4.3 权限管理测试 (32)
4.3.1 横向测试 (32) 4.3.2 纵向测试 (33) 4.4 服务器信息收集 (38) 4.4.1 运行账号权限测试 (38) 4.4.2 Web服务器端口扫描 (38) 4.5 文件、目录测试 (39) 4.5.1 工具方式的敏感接口遍历 (39) 4.5.2 目录列表测试 (41) 4.5.3 文件归档测试 (43) 4.6 认证测试 (44) 4.6.1 验证码测试 (44) 4.6.2 认证错误提示 (45) 4.6.3 锁定策略测试 (46) 4.6.4 认证绕过测试 (47) 4.6.5 修复密码测试 (47) 4.6.6 不安全的数据传输 (48) 4.6.7 强口令策略测试 (49) 4.7 会话管理测试 (51) 4.7.1 身份信息维护方式测试 (51) 4.7.2 Cookie存储方式测试 (51) 4.7.3 用户注销登陆的方式测试 (52) 4.7.4 注销时会话信息是否清除测试 (53) 4.7.5 会话超时时间测试 (54) 4.7.6 会话定置测试 (54) 4.8 文件上传下载测试 (55) 4.8.1 文件上传测试 (55) 4.8.2 文件下载测试 (56) 4.9 信息泄漏测试 (57) 4.9.1 连接数据库的账号密码加密测试 (57) 4.9.2 客户端源代码敏感信息测试 (58)
web安全测试---AppScan扫描工具 2012-05-27 22:36 by 虫师, 48076 阅读, 4 评论, 收藏, 编辑 安全测试应该是测试中非常重要的一部分，但他常常最容易被忽视掉。 尽管国内经常出现各种安全事件，但没有真正的引起人们的注意。不管是开发还是测试都不太关注产品的安全。当然，这也不能怪我们苦B的“民工兄弟”。因为公司的所给我们的时间与精力只要求我们对产品的功能的实现以及保证功能的正常运行。一方面出于侥幸心理。谁没事会攻击我？ 关于安全测试方面的资料也很少，很多人所知道的就是一本书，一个工具。 一本书值《web安全测试》，这应该是安全测试领域维数不多又被大家熟知的安全测试书，我曾看过前面几个章节，唉，鄙视一下自己，做事总喜欢虎头蛇尾。写得非常好，介绍了许多安全方面的工具和知识。我觉得就算你不去做专业的安全开发\测试人员。起码可以开阔你的视野，使你在做开发或测试时能够考虑到产品安全方面的设计。防患于未然总是好的，如果你想成为一个优秀的人。 一个工具，其实本文也只是想介绍一下，这个工具----AappScan，IBM的这个web安全扫描工具被许多人熟知，相关资料也很多，因为我也摸了摸它的皮毛，所以也来人说两句，呵呵！说起sappScan，对它也颇有些感情，因为，上一份工作的时候，我摸过于测试相关的许多工具，AappScan是其它一个，当时就觉得这工具这么强大，而且还这么傻瓜！！^ _^! 于是，后面在面试的简历上写了这个工具，应聘现在的这家公司，几轮面试下来都问 到过这个工具，因为现在这家公司一直在使用这个工具做安全方面的扫描。我想能来这家公司和我熟悉AappScan应该有一点点的关系吧！呵呵 AappScan下载与安装 IBM官方下载;https://www.doczj.com/doc/3a18772548.html, ... 2-AppScan_Setup.exe 本连接为7.8 简体中文版本的 破解补丁；https://www.doczj.com/doc/3a18772548.html,/down/index/4760606A4753 破解补丁中有相应的注册机与破解步骤，生成注册码做一下替换就OK了，这里不细说。
1Web安全测试技术方案 1.1测试的目标 ●更好的发现当前系统存在的可能的安全隐患，避免发生危害性的安全事件 ●更好的为今后系统建设提供指导和有价值的意见及建议 1.2测试的范围 本期测试服务范围包含如下各个系统： ●Web系统： 1.3测试的内容 1.3.1WEB应用 针对网站及WEB系统的安全测试，我们将进行以下方面的测试： ?Web 服务器安全漏洞 ?Web 服务器错误配置 ?SQL 注入 ?XSS（跨站脚本） ?CRLF 注入 ?目录遍历 ?文件包含 ?输入验证 ?认证 ?逻辑错误 ?Google Hacking ?密码保护区域猜测 ?字典攻击 ?特定的错误页面检测 ?脆弱权限的目录 ?危险的 HTTP 方法（如：PUT、DELETE） 1.4测试的流程 方案制定部分：
获取到客户的书面授权许可后，才进行安全测试的实施。并且将实施范围、方法、时间、人员等具体的方案与客户进行交流，并得到客户的认同。 在测试实施之前，让客户对安全测试过程和风险知晓，使随后的正式测试流程都在客户的控制下。 信息收集部分： 这包括：操作系统类型指纹收集；网络拓扑结构分析；端口扫描和目标系统提供的服务识别等。采用商业和开源的检测工具（AWVS、burpsuite、Nmap等）进行收集。 测试实施部分： 在规避防火墙、入侵检测、防毒软件等安全产品监控的条件下进行：操作系统可检测到的漏洞测试、应用系统检测到的漏洞测试（如：Web应用），此阶段如果成功的话，可能获得普通权限。 安全测试人员可能用到的测试手段有：扫描分析、溢出测试、口令爆破、社会工程学、客户端攻击、中间人攻击等，用于测试人员顺利完成工程。在获取到普通权限后，尝试由普通权限提升为管理员权限，获得对系统的完全控制权。此过程将循环进行，直到测试完成。最后由安全测试人员清除中间数据。 分析报告输出： 安全测试人员根据测试的过程结果编写直观的安全测试服务报告。内容包括：具体的操作步骤描述；响应分析以及最后的安全修复建议。 下图是更为详细的步骤拆分示意图：
Web安全测试——手工安全测试方法及修改建议发表于：2017-7-17 11:47 作者：liqingxin 来源：51Testing软件测试网采编 字体：大中小 | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签：软件测试工具XSS安全测试工 具 常见问题 1.XSS(CrossSite Script)跨站脚本攻击 XSS(CrossSite Script)跨站脚本攻击。它指的是恶意攻击者往Web 页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web 里面的html 代码会被执行，从而达到恶意用户的特殊目的。 测试方法： 在数据输入界面，添加记录输入：，添加成功如果弹出对话框，表明此处存在一个XSS 漏洞。 或把url请求中参数改为，如果页面弹出对话框，表明此处存在一个XSS 漏洞 修改建议： 过滤掉用户输入中的危险字符。对输入数据进行客户端和程序级的校验（如通过正则表达式等）。 Eg:对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”’”等字符是否做过滤 2.CSRF与跨站脚本(XSS) CSRF与跨站脚本(XSS)，是指请求迫使某个登录的浏览器向易受攻击的Web应用发送一个请求，然后以受害者的名义，为入侵者的利益进行所选择的行动。
测试方法： 同个浏览器打开两个页面，一个页面权限失效后，另一个页面是否可操作成功 使用工具发送请求，在http请求头中不加入referer字段，检验返回消息的应答，应 该重新定位到错误界面或者登陆界面。 修改建议： 在不同的会话中两次发送同一请求并且收到相同的响应。这显示没有任何参数是动态的 （会话标识仅在cookie 中发送），因此应用程序易受到此问题攻击。因此解决的方法为 1.Cookie Hashing(所有表单都包含同一个伪随机值)： 2. 验证码 3.One‐Time Tokens(不同的表单包含一个不同的伪随机值)客户端保护措施：应用防止 CSRF攻击的工具或插件。 3.注入测试 SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符 串，最终达到欺骗服务器执行恶意的SQL命令。 测试方法： 在需要进行查询的页面，输入正确查询条件and 1=1等简单sql语句，查看应答结果， 如与输入正确查询条件返回结果一致，表明应用程序对用户输入未进行过滤，可以初步判断 此处存在SQL注入漏洞 修改建议： 对用户的输入进行校验，可以通过正则表达式，或限制长度；对以下关键字进行转换等; itename|netuser|xp_cmdshell|or|+|,|like'|and|exec|execute|insert|create|drop|table|from|grant|group_concat|column_name|information_sche
WEB安全测试分类及防范测试方法 1 Web 应用程序布署环境测试 (3) 1.1HTTP 请求引发漏洞的测试 (3) 1.2 操作系统目录安全性及Web 应用程序布署环境目录遍历问题测试 (3) 2 应用程序测试 (4) 2.1 SQL 注入漏洞测试 (4) 2.1.1 SQL注入漏洞攻击实现原理 (4) 2.1.2 SQL注入漏洞防范措施 (5) 2.1.3 SQL注入漏洞检测方法 (6) 2.2 表单漏洞测试 (7) 2.2.1 表单漏洞实现原理 (7) 2.2.2 表单漏洞防范措施 (7) 2.2.3 表单漏洞检测方法 (7) 2.3 Cookie欺骗漏洞测试 (9) 2.3.1 Cookie欺骗实现原理 (9) 2.3.2 Cookie欺骗防范措施 (9) 2.3.3 Cookie欺骗监测方法 (9) 2.4 用户身份验证测试 (10) 2.4.1 用户身份验证漏洞防范措施 (10) 2.4.2 用户身份验证检测方法 (10) 2.5 文件操作漏洞测试 (10) 2.5.1 文件操作漏洞实现原理 (10) 2.5.2 文件操作漏洞防范措施 (10) 2.5.3 文件操作漏洞检测方法 (11) 2.6 Session 测试 (11) 2.6.1 客户端对服务器端的欺骗攻击 (11) 2.6.2直接对服务器端的欺骗攻击 (12) 2.6.3 Session漏洞检测方法 (13) 2.7 跨网站脚本(XSS)漏洞测试 (13) 2.7.1 跨网站脚本（XSS）漏洞实现原理 (13) 2.7.2 跨网站脚本（XSS）漏洞防范措施 (14) 2.7.3 跨网站脚本（XSS）漏洞测试方法 (14) 2.8 命令注射漏洞测试 (15) 2.9 日志文件测试 (15) 2.10 访问控制策略测试 (15) 2.10.1 访问控制策略测试方法 (15) 3 数据库问题测试 (16) 3.1 数据库名称和存放位置安全检测 (16) 3.2 数据库本身的安全检测 (16) 3.3 数据使用时的一致性和完整性测试 (16) 4 容错测试 (16) 4.1 容错方案及方案一致性测试 (16) 4.2 接口容错测试 (17)
DKBA 华为技术有限公司内部技术规范 DKBA 2355-2009.7 Web应用安全测试规范V1.4 2009年7月5日发布2009年7月5日实施 华为技术有限公司 Huawei Technologies Co., Ltd. 版权所有侵权必究 All rights reserved
修订声明Revision declaration 本规范拟制与解释部门： 安全解决方案部电信网络与业务安全实验室、软件公司安全TMG、软件公司测试业务管理部 本规范的相关系列规范或文件： 《Web应用安全开发规范》 相关国际规范或文件一致性： 《OWASP Testing Guide v3》 《信息安全技术信息安全风险评估指南》 《Information technology Security techniques Management of information and communications technology security》－ISO 13335 替代或作废的其它规范或文件： 无 相关规范或文件的相互关系： 本规范以《Web应用安全开发规范》为基础、结合Web应用的特点而制定。
目录Table of Contents 1概述 (9) 1.1背景简介 (9) 1.2适用读者 (9) 1.3适用范围 (9) 1.4安全测试在IPD流程中所处的位置 (10) 1.5安全测试与安全风险评估的关系说明 (10) 1.6注意事项 (11) 1.7测试用例级别说明 (11) 2测试过程示意图 (12) 3WEB安全测试规范 (13) 3.1自动化W EB漏洞扫描工具测试 (13) 3.1.1AppScan application扫描测试 (14) 3.1.2AppScan Web Service 扫描测试 (15) 3.2服务器信息收集 (15) 3.2.1运行帐号权限测试 (15) 3.2.2Web服务器端口扫描 (16) 3.2.3HTTP方法测试 (16) 3.2.4HTTP PUT方法测试 (17) 3.2.5HTTP DELETE方法测试 (18) 3.2.6HTTP TRACE方法测试 (19) 3.2.7HTTP MOVE方法测试 (20) 3.2.8HTTP COPY方法测试 (20) 3.2.9Web服务器版本信息收集 (21) 3.3文件、目录测试 (22) 3.3.1工具方式的敏感接口遍历 (22) 3.3.2Robots方式的敏感接口查找 (24)
工具扫描 目前web安全扫描器针对XSS、SQL injection 、OPEN redirect 、PHP File Include漏洞的检测技术已经比较成熟。 商业软件web安全扫描器：有IBM Rational Appscan、WebInspect、Acunetix WVS 免费的扫描器：W3af 、Skipfish 等 根据业务资金，可以考虑购买商业扫描软件，也可以使用免费的，各有各的好处。 首页可以对网站进行大规模的扫描操作，工具扫描确认没有漏洞或者漏洞已经修复后，再进行以下手工检测。 手工检测 对于CSRF、越权访问、文件上传、修改密码等漏洞，难以实现自动化检测的效果，这是因为这些漏洞涉及系统逻辑或业务逻辑，有时候还需要人机交互参与页面流程，因此这类漏洞的检测更多的需要依靠手动测试完成。 手工检测网站URL、后台登陆是否具有SQL注入 Admin-- ‘or -- ‘and ( ) exec insert * % chr mid and 1=1 ; And 1=1 ; aNd 1=1 ; char(97)char(110)char(100) char(49)char(61)char(49) ; %20AND%201=2 ‘and 1=1 ; …And 1=1 ; …aNd 1=1 ; and 1=2 ; …and 1=2 and 2=2 and user>0 and (select count(*) from sysobjects)>0 and (select count(*) from msysobjects)>0 and (Select Count(*) from Admin)>=0 and (select top 1 len(username) from Admin)>0(username 已知字段) ;exec master..xp_cmdshell “net user name password /add”— ;exec master..xp_cmdshell “net localgroup name administrators /add”— and 0<>(select count(*) from admin) XSS：对于get请求的URL一般漏洞扫描软件都可扫描到是否存在XSS漏洞。（但是软件没有完美的，也有误报，或者有遗漏的情况） 对于POST的请求的（例如留言板，评论，等等），就是要在输入框输入的情况，则要进行以下测试 ★~!@#$%^&*()_+<>,./?;'"[]{}\- ★%3Cinput /%3E ★%3Cscript%3Ealert('XSS')%3C/script%3E ★ ★ ★alert('xss') ★ ★ ★javascript.:alert(/xss/) ★javascript.:alert(/xss/)