web安全测试要点总结.docx
《web安全测试要点总结.docx》由会员分享，可在线阅读，更多相关《web安全测试要点总结.docx（25页珍藏版）》请在冰豆网上搜索。
web安全测试要点总结
一、Web应用安全威胁分为如下六类：
Authentication（验证）
用来确认某用户、服务或是应用身份的攻击手段。
Authorization（授权）
用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。
Client-SideAttacks（客户侧攻击）
用来扰乱或是探测Web站点用户的攻击手段。
CommandExecution（命令执行）
在Web站点上执行远程命令的攻击手段。
InformationDisclosure（信息暴露）
用来获取Web站点具体系统信息的攻击手段。
LogicalAttacks（逻辑性攻击）
用来扰乱或是探测Web应用逻辑流程的攻击手段
二、常见针对Web应用攻击的十大手段
应用威胁
负面影响
后果
跨网站脚本攻击
标识盗窃，敏感数据丢失…
黑客可以模拟合法用户，控制其帐户。
注入攻击
通过构造查询对数据库、LDAP和其他系统进行非法查询。
黑客可以访问后端数据库信息，修改、盗窃。
恶意文件执行
在服务器上执行Shell命令Execute，获取控制权。
被修改的站点将所有交易传送给黑客
不安全对象引用
黑客访问敏感文件和资源
Web应用返回敏感文件内容
伪造跨站点请求
黑客调用Blind动作，模拟合法用户
黑客发起Blind请求，要求进行转帐
信息泻露和不正确的错误处理
黑客得到详细系统信息
恶意的系统检测可能有助于更深入的攻击
被破坏的认证和Session管理
Sessiontoken没有被很好的保护
在用户推出系统后，黑客能够盗窃session。
不安全的木马存储
过于简单的加密技术导致黑客破解编密码
隐秘信息被黑客解密盗窃
不安全的通讯
敏感信息在不安全通道中以非加密方式传送
黑客可以通过嗅探器嗅探敏感信息，模拟合法用户。
URL访问限制失效
黑客可以访问非授权的资源连接
黑客可以强行访问一些登陆网页、历史网页。
三、RationalAppScan功能简介
RationalAppScan同时提供了很多高级功能，帮助客户对复杂应用进行检测。
支持的扫描配置有：
∙StartingURL：
起始URL，制定被测应用的起始地址
∙CustomErrorPages：
制定错误网页提高测试效率
∙SessionIDs：
管理测试过程中的session
∙AutomaticServerDetection：
自动检测应用所在的应用服务器、webserver、操作系统
∙ExclusionandInclusion：
制定哪些Web被扫描或者被排除，哪些文件类型不被扫描
∙ScanLimits：
其他高级扫描限制，例如扫描次数限制等
∙Advanced：
扫描的方式，是宽度扫描还是深度扫描
∙CommunicationSettings：
对扫描中的延时、线程数量进行配置
∙ProxySettings：
代理设置vLogin/logout：
对被测应用的登陆进行设置，可以采用录制回放的方式、也可以使用自动登陆的方式
∙configureaTestPolicy:
配置测试测量，即想测试哪些漏洞。
四、Web安全体系测试
一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手。
数据加密：
某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信息、用户登陆密码信息等。
此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。
目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！
注：
对登陆帐户和密码进行加密，可在后台数据库查看是否进行了加密。
登录：
一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名和匹配的密码进行校验，以阻止非法用户登录。
在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，哪些页面或者文件需要登录后才能访问/下载等。
超时限制：
WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候，需要重新登录才能使用其功能。
SSL：
越来越多的站点使用SSL安全协议进行传送。
SSL是SecuritySocketLauer（安全套接字协议层）的缩写，是由Netscape首先发表的网络数据安全传输协议。
SSL是利用公开密钥/私有密钥的加密技术。
（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。
SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，但解密数据必须要通过相应的私人密钥。
进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成https，在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。
服务器脚本语言：
脚本语言是常见的安全隐患。
每种语言的细节有所不同。
有些脚本允许访问根目录。
其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。
找出站点使用了哪些脚本语言，并研究该语言的缺陷。
还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
注：
黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。
这个网站包含了脚本代码（有允许访问根目录的特性）就可能有这个安全隐患。
日志文件：
在服务器上，要验证服务器的日志是否正常工作，例如CPU的占用率是否很高，是否有例外的进程占用，所有的事务处理是否被记录等。
目录：
WEB的目录安全是不容忽视的一个因素。
如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，这样会造成很大的风险和安全性隐患。
我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，将这种隐患降低到最小程度。
注：
每个目录访问时有index.htm目的：
通过首页中的登陆验证功能进行访问权限控制。
五、web安全测试的checklist
1.不登录系统，直接输入登录后的页面的url是否可以访问
2.不登录系统，直接输入下载文件的url是否可以下载，如输入http:
//url/download?
name=file是否可以下载文件file
3.退出登录后按后退按钮能否访问之前的页面
4.ID/密码验证方式中能否使用简单密码。
如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位
5.重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:
alert（doucument.cookie）时是否有重要信息；在html源码中能否看到重要信息
6.手动更改URL中的参数值能否访问没有权限访问的页面。
如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面
7.url里不可修改的参数是否可以被修改,浏览器缓存：
认证和会话数据不应该作为GET的一部分来发送，应该使用POST
8.上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行
9.注册用户时是否可以以'--,'or1=1--等做为用户名
10.传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and1=1--,'and1=0--,'or1=0--）时是否可以正常处理
11.执行新增操作时，在所有的输入框中输入脚本标签（alert（""））后能否保存
12.在url中输入下面的地址是否可以下载：
http:
//url/download.jsp?
file=C:
\windows\system32\drivers\etc\hosts,http:
//url/download.jsp?
file=/etc/passwd
13.是否对session的有效期进行处理
14.错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等
15.ID/密码验证方式中，同一个账号在不同的机器上不能同时登录
16.ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定
17.新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能
18.EmailHeaderInjection（邮件标头注入）
EmailHeaderInjection：
如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），
我们要验证subject中应能escape掉“\n”标识。
∙
--[if!
supportLists]-->
--[endif]-->因为“\n”是新行，如果在subject中输入“hello\ncc:
**********************”，可能会形成以下
Subject:
hello
cc:
**********************
∙
--[if!
supportLists]-->
--[endif]-->如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用户发送垃圾邮件。
19.DirectoryTraversal（目录遍历）
（1）如何进行目录遍历测试？
目录遍历产生的原因是：
程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法：
在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。
（2）如何预防目录遍历？
限制Web应用在服务器上的运行
进行严格的输入验证，控制用户输入非法路径
20.exposederrormessages（错误信息）
（1）如何进行测试？
首先找到一些错误页面，比如404,或500页面。
验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。
（2）如何预防？
测试人员在进行需求检查时，应该对出错信息进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。
六、跨站点脚本攻击测试要点
1.确定站点及其功能--与开发人员和PM交流
绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。
此时，可以安排一些与开发人员和项目经理的会议来建立威胁模型。
在会议上尽可能对应用程序进行深入探讨。
站点公开了Web服务吗？
是否有身份验证表单？
有留言板吗？
有用户设置页面吗？
确保列出了所有这些页面
2.找出并列出所有由用户提供输入的点
对站点地图进行进一步细化。
我通常会为此创建一个电子表格。
对于每个页面，列出所有查询字符串参数、cookie值、自定义HTTP标头、POST数据值和以其他形式传递的用户输入。
不要忘记搜索Web服务和类似的SOAP请求，并找出所有允许用户输入的字段。
分别列出每个输入参数，因为下面需要独立测试每个参数。
这可能是最重要的一个步骤！
如果阅读下面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。
如forwardURL和lang这样的查询字符串。
如name、password、msgBody、msgTitle和这样的POST数据，甚至某些Cookie值。
所有这些都是我们感兴趣的重要测试内容
3.认真思考并列出测试用例
4.开始测试并注意输出结果
在查找漏洞的过程中，最重要的部分并不是您是否找到了漏洞。
而是您是否真正知道究竟发生了哪些事情。
对于XSS，只需检查HTML输出并看看您输入的内容在什么地方。
它在一个HREF标记中吗？
是否在IFRAME标记中？
它在CLSID标记中吗？
在IMGSRC中吗？
某些Flash内容的PARAMNAME是怎样的？
我会检查所有这些情况，如果您对所输入内容的目的十分了解，可以调整您的测试来找出问题。
这意味着您可能需要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记内的一个元素。
或者，您可能需要使用URL或HTML来编码您的字符，例如将双引号变为%22或"。
5.这个站点看来防范比较严密。
现在该怎么办呢？
那么，也许您的简单测试用例alert（‘hi’）并不能产生期望中的警告对话框。
仔细想想这个问题并在可能的情况下与开发人员进行交流。
也许他们对输入中的尖括号、单引号或圆括号进行了过滤。
也许他们会过滤“scrīpt”这个词。
重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST数据）的作用。
“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。
有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。
然后，便可以知道您面对的过滤级别究竟如何。
接着，可以调整测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。
改变测试用例
我恐怕无法充分对此进行说明：
研究输入的值会输出什么样的HTML页面非常重要。
如果它们不能产生输出，那么不要在它们上面浪费时间。
如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。
我使用了各种变化形式来找出能接受和显示脚本代码的参数。
因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：
1.>"'>alert（‘XSS'）
2.>%22%27>alert（%27XSS%27）%22>
3.>"'>
4.AK%22%20style%3D%22background:
url（javascrīpt:
alert（%27XSS%27））%22%20OS%22
5.%22%2Balert（%27XSS%27）%2B%22
6.alert（（[code]）">
7.
8.alert（（[code]）">
升级会员 