安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程.
主要安全需求包括:
(i) 认证 Authentication: Is the information sent from an authenticated user?
(ii) 访问控制 Access Control: Is data protected from unauthorized users?
(iii) 完整性 Integrity: Does the user receive exactly what is sent?
(iv) 机密性 Delivery: Is the information delivered to the intended user?
(v) 可靠性Reliability: What is the frequency of a failure? How much time does the network take to recover from a failure? What measures are taken to counter catastrophic failure?
(vi) 不可抵赖 Non-repudiation: Is the receiver able to prove that the data received came from a specific sender?
常见的安全威胁,如下图
对于CSRF、越权访问、文件上传、修改密码 等漏洞,难以实现自动化检测的效果,这是因为这些漏洞涉及系统逻辑或业务逻辑,有时候还需要人机交互参与页面流程,因此 这类漏洞的检测更多的需要依靠手动测试完成。
手工检测网站URL、后台登陆是否具有SQL注入
就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。
这种范例向您展示了怎样使用 SQL 注入来耗尽一个结构糟糕的登录应用程序:
一个网络应用程序会催促您输入一个用户名和密码来进行登录,而 SQL 语句是按照下面的方式组织的:
String query = "SELECT * FROM users WHERE user ='"username+"' AND password ='"passwd"'";
变量 username 以及 password 没有得到细致的处理,并分配给用户在应用程序中输入的值。这就使得一些恶意的用户可以输入 username 之类的值:
anything' OR 1=1 --
密码可以是任意值。在这种情况下,假设它是一个星号:*。
对于输入来说,当代码替换 username 以及 password 变量时,结构化的查询是:
SELECT * FROM users WHERE username ='anything' OR 1=1 -- AND password ='*'
该语句解释了密码需求,并插入状况 1=1,这条语句的值一直都是真的。就算没有相关的权限,攻击者也会被确认为一个有效的用户。
其它还有
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)
Cross-site scritping(XSS):(跨站点脚本攻击)
在这种一般的攻击中,恶意代码会植入到第三方的受信网站之中。如果 HTTP 请求可以将其注入到最终 HTML 页面上的话,那么跨站点脚本漏洞就向这种攻击开放了。
例如,一项服务会接受名为 image 的参数,来接受来自于文件系统的图片,来执行一些处理:
http://somedomain/myImageProcessor?image=myimage.jpg
一个入侵者可以通过向 image 参数插入 JavaScript 代码,来占用该应用程序。其意图是耗尽错误处理系统的资源。如果一个包含恶意脚本的出错信息会被生成的话,那么入侵者就可以利用这一点了:
http://somedomain/myImageProcessor?image=myimage.jpg<script>...malicious code ...</script>
如果出错信息返回图片参数的内容,而不用筛选的话,那么代码就会封闭到 <script>
标签内。脚本有可能访问本地缓存,以攻击网页,甚至更改预呈现页面的内容。通过电子邮件发送恶意链接,或者将它们加入到恶意网页上,就可以利用这些网络漏洞了。
对于get请求的URL一般漏洞扫描软件都可扫描到是否存在XSS漏洞。
(1)如何进行XSS测试?
- <!–[if !supportLists]–>首先,找到带有参数传递的URL,如 登录页面,搜索页面,提交评论,发表留言 页面等等。
- <!–[if !supportLists]–>其次,在页面参数中输入如下语句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)来进行测试:
注:其它的XSS测试语句
- 最后,当用户浏览 时便会弹出一个警告框,内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。
- 试想如果我们注入的不是以上这个简单的测试代码,而是一段经常精心设计的恶意脚本,当用户浏览此帖时,cookie信息就可能成功的被 攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。
(2) 如何预防XSS漏洞?
从应用程序的角度来讲,要进行以下几项预防:
- 对Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等 语句或脚本进行转义.
- 在 服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端 拒绝进行关键性的处理操作.
从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查:
- 在需求检查过程中对各输入项或输出项进行类型、长度以及取 值范围进行验证,着重验证是否对HTML或脚本代码进行了转义。
- 执行测试过程中也应对上述项进行检查。
对于POST/GET 的请求,就是要在输入框输入的情况,则要进行以下测试:
CSRF:(跨站点伪造请求)
CSRF尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左。
XSS是利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。
XSS也好,CSRF也好,它的目的在于窃取用户的信息,如SESSION 和 COOKIES(关于SESSION 和COOKIES的介绍
http://www.51testing.com/?49689/action_viewspace_itemid_74885.html),
(1)如何进行CSRF测试?
关于这个主题本人也正在研究,目前主要通过安全性测试工具来进行检查。
(2)如何预防CSRF漏洞?
关于上传:
1.上传文件是否有格式限制,是否可以上传exe文件;
2.上传文件是否有大小限制,上传太大的文件是否导致异常错误,上传0K的文件是否会导致异常错误,上传并不存在的文件是否会导致异常错误;
3.通过修改扩展名的方式是否可以绕过格式限制,是否可以通过压包方式绕过格式限制;
4.是否有上传空间的限制,是否可以超过空间所限制的大小,如将超过空间的大文件拆分上传是否会出现异常错误。
5.上传文件大小大于本地剩余空间大小,是否会出现异常错误。
6.关于上传是否成功的判断。上传过程中,中断。程序是否判断上传是否成功。
7.对于文件名中带有中文字符,特殊字符等的文件上传。
下载:
避免输入:\..\web.
修改命名后缀。
输入验证
客户端验证 服务器端验证(禁用脚本调试,禁用Cookies)
1.输入很大的数(如4,294,967,269),输入很小的数(负数)
2.输入超长字符,如对输入文字长度有限制,则尝试超过限制,刚好到达限制字数时有何反应
3.输入特殊字符,如:~!@#$%^&*()_+<>:”{}|
4.输入中英文空格,输入字符串中间含空格,输入首尾空格
5.输入特殊字符串NULL,null,0x0d 0x0a
6.输入正常字符串
7.输入与要求不同类型的字符,如: 要求输入数字则检查正值,负值,零值(正零,负零),小数,字母,空值; 要求输入字母则检查输入数字
8.输入html和javascript代码
9.对于像回答数这样需检验数字正确性的测试点,不仅对比其与问题最终页的回答数,还要对回答进行添加删除等操作后查看变化
例如:
1.输入<html”>”gfhd</html>,看是否出错; 2.输入<input type=”text” name=”user” onclick="alert(1)"/>,看是否出现文本框; 3.输入<script type=”text/javascript”>alert(“提示”)</script>看是否出现提示。 4.输入”><script type=”text/javascript”>alert(“提示”)</script>看是否出现提示。 5.输入 ”><script><” 看是否出现代码溢出
页面权限泄露
测试在不登陆的情况下是否可以访问到后台的页面,这个只要把后台的目录的URL全部浏览一遍即可
关于任意文件下载
查看上传的图片文件是否可以删除,如果可以删除,查看删除的URL里面的参数是否可以修改
信息泄露
一个有意志的攻击者可以通过识别缺点来研究一项应用程序。例如,一个攻击者可以按照不同的方式来获取信息:
- 手动研究应用程序以做到隐藏的目录
- 系统性地收集例外情况,以查看应用程序是否给出了详细的例外情况
- 扫描 HTML 以得到揭示应用程序基础及行为具体内容的注释
- 系统性地输入用户名以找出已存在的账户
对于应用程序来说,信息泄漏需要受到人们的重视,开发人员的意识是最好的防御手段。记住这一点,开发人员可以考虑一些减轻问题的措施。
- 所有评论的清晰 HTML 代码会揭示应用程序的实际情况。
- 不要在浏览器中显示特定的例外。如果必须登录,将它们存储在服务器上,并显示常见的错误。
- 不要揭示哪一部分的认证错误。
- 同样,配置网络服务器和应用程序服务器设置,以避免在网站和应用程序上任意的导航。
cookie 破坏
所谓的 cookie(缓存)就是服务器向客户端发送的信息,作为关键字/值对存储在一个文本文件或者内存之中。它的内容可以被创建该内容的网络应用程序使用。在执行一次网络应用程序之后编辑缓存的内容,缓存 破坏 攻击就发生了。
反制措施
- cookie 破坏的反制措施包括参数认证,以及应用程序代码和逻辑的仔细检查。
- 高级安全性机制也可以得到应用。
- 一种常见的方法是使用数字签名,来确认文本文件存储没有受到篡改。
- 另一种反制措施是在传递期间将其加密,以保护缓存。
Security testing checklist 核对表
认证,访问控制和隐私 Authentication, Access Control and privacy
1. Are unauthorized users restricted from viewing privatedata?
2. Is sensitive organization information restricted from public access?
3. Are users aware of the privacy polices?
4. Are legal consequences of policies known to the user?
5. Are authentication mechanisms adequate to prevent malicious intrusion to the application?
6. Does the web application ask for login id and password?
7. Does the web server lock the users who try to access the website multiple times with invalid login ids/passwords?
8. Have you tested the combinations of invalid and validlogin ids/passwords?
9. Is there any provision for forget/change password?
10.Are levels of authentication defined?
防火墙 Firewall
11. Does the firewall properly implement all the security policies of the company?
12. Are firewalls’ adequacy tested?
13. Is the ‘security in charge’ aware of the known faults in the
14. Is the location of the firewall effective?
15. Is any penetration possible in the security boundaries
数据安全 Data Security
16. Are the data validations tested?
17. Is sensitive information (such as password, credit card
18. Are privileges to access data enforced?
19. Are file download permissions established and tested?
20. Is sensitive and important data kept at secure locations?
加密 Encryption
21. Are encryption standards enforced?
22. Is there any procedure followed to identify what is to be encrypted?
23. Is sensitive and critical information (such as password,
24. Is Security Socket Layer (SSL) used to provide encryption of sensitive elements?
25. Does the enforcement of encryption standard affect the speed of the web page?
病毒 Virus
26. Are mechanisms used to identify and remove viruses?
27. Are anti-virus softwares scheduled for periodical updates?
28. Does the anti-virus software identify the unprotected sites?
29. Are viruses sent for analysis to the anti-virus software company?
30. Are users trained for virus prevention and recovery procedures?
31. Is the procedure for handling a virus attack adequate?
32. Are users alerted from downloading insecure items?
33. Is legitimate anti-virus software installed on the client’s machine?
34. Is virus scan scheduled periodically?
35. Is spyware removal software installed and run periodically?
故障管理与恢复 Failure Management and Recovery
36.Are back-ups schedules at defined intervals?
37. Does the recovery take a long time?
38. In case of site crash, is there any provision to route to another server?
39.Have recovery mechanisms been defined and tested
40. Is any criteria followed to ensure the completion and correction of recovery procedures?
常规 General
41. Are any warning messages issued when the user enters or leaves the secured website?
42. Is the user allowed to login with the same account from different machines (simultaneously)?
43. Are unauthorized external sites identified and screened out?
44. Can the previous page be accessed after signing out from the website?
45. Is the user able to access restricted pages after the session is timed out?
46. Is auditing performed periodically in order to keep a record of all the operations?
47. Are all payment methods tested thoroughly?
48. Are enough security mechanisms enforced, if customer registration is compulsory on your website?
49. Does the application use digital signature to sign a files?
50. Does the source code reveal any critical information?
如有想了解更多软件研发 , 系统 IT集成 , 企业信息化,项目管理 等资讯,请关注我的微信订阅号:
原文链接:https://www.cnblogs.com/wintersun/p/4964102.html
原创文章,作者:优速盾-小U,如若转载,请注明出处:https://www.cdnb.net/bbs/archives/17716