web安全工作总结Word格式.docx
《web安全工作总结Word格式.docx》由会员分享，可在线阅读，更多相关《web安全工作总结Word格式.docx（15页珍藏版）》请在冰豆网上搜索。
后果黑客可以模拟合法用户，控制其帐户。
黑客可以访问后端数据库信息，修改、盗窃。
跨网站脚本攻击注入攻击
恶意文件执行在服务器上执行Shell命令Execute，获被修改的站点将所有交易传送给黑客
取控制权。
不安全对象引用
伪造跨站点请求
信息泻露和不正确的
错误处理
被破坏的认证和
Session管理
不安全的木马存储
不安全的通讯黑客访问敏感文件和资源黑客调用Blind动作，模拟合法用户黑客得到详细系统信息web应用返回敏感文件内容黑客发起Blind请求，要求进行转帐恶意的系统检测可能有助于更深入的攻击Sessiontoken没有被很好的保护在用户推出系统后，黑客能够盗窃session。
过于简单的加密技术导致黑客破解编密码隐秘信息被黑客解密盗窃敏感信息在不安全通道中以非加密方式传
送黑客可以通过嗅探器嗅探敏感信息，模拟合法用户。
黑客可以强行访问一些登陆网页、历
史网页。
URL访问限制失效黑客可以访问非授权的资源连接
三、RationalappScan功能简介
RationalappScan同时提供了很多高级功能，帮助客户对复杂应用进行检测。
支持的扫描配置有：
?
StartingURL：
起始URL，制定被测应用的起始地址customErrorPages：
制定错误网页提高测试效率Sessionids：
管理测试过程中的sessionautomaticServerdetection：
自动检测应用所在的应用服务器、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安全测试的checklist1.不登录系统，直接输入登录后的页面的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.注册用户时是否可以以&
#39;
--,&
or1=1--等做为用户名
10.传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（&
&
and1=1--,&
and1=0--,&
or
1=0--）时是否可以正常处理
11.执行新增操作时，在所有的输入框中输入脚本标签（alert（““））后能否保存
12.在url中输入下面的地址是否可以下载：
http:
//url/download.jsp?
file=c:
\windows\system32\drivers\etc\hosts,http:
file=/
etc/passwd
（:
web安全工作总结）13.是否对session的有效期进行处理
14.错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等
15.id/密码验证方式中，同一个账号在不同的机器上不能同时登录
16.id/密码验证方式中，连续数次输入错误密码后该账户是否被锁定
17.新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中
使用autocomplete=off来关闭自动完成功能
18.EmailHeaderinjection（邮件标头注入）
EmailHeaderinjection：
如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），
我们要验证subject中应能escape掉“\n”标识。
因为“\n”是新行，如果在subject中输入
“hello\ncc:
spamvictim@”，可能会形成以下
Subject:
hello
cc:
spamvictim@
如果允许用户使用这样的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.开始测试并注意输出结
升级会员 