fu-ture

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

网站的安全性测试

安全性保护数据:防止不合法用户故意造成的破坏;
完整性保护数据:防止合法用户无意中造成的破坏;

安全性测试(security testing)是有关验证应用程序的安全服务和识别潜在问题

注意:安全性测试并不最终证明应用程序是安全的,而是用于验证所设立策略的有效性,这些对策是基于威胁分析阶段所做的假设而选择的。

一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。
一.安全体系测试
1、部署与基础结构:

  • 网络是否提供了安全的通信
  • 部署拓扑结构是否包括内部的防火墙
  • 部署拓扑结构中是否包括远程应用程序服务器
  • 基础结构安全性需求的限制是什么
  • 目标环境支持怎样的信任级别

2、输入验证:
l)如何验证输入
A.是否清楚入口点
B.是否清楚信任边界
C.是否验证Web页输入
D.是否对传递到组件或Web服务的参数进行验证
E.是否验证从数据库中检索的数据
F.是否将方法集中起来
G.是否依赖客户端的验证
H.应用程序是否易受SQL注入攻击
I.应用程序是否易受XSS攻击
l如何处理输入
3、身份验证

  • 是否区分公共访问和受限访问
  • 是否明确服务帐户要求
  • 如何验证调用者身份
  • 如何验证数据库的身份
  • 是否强制试用帐户管理措施

4、授权

  • 如何向最终用户授权
  • 如何在数据库中授权应用程序
  • 如何将访问限定于系统级资源

5、配置管理

  • 是否支持远程管理
  • 是否保证配置存储的安全
  • 是否隔离管理员特权

6、敏感数据

  • 是否存储机密信息
  • 如何存储敏感数据
  • 是否在网络中传递敏感数据
  • 是否记录敏感数据

7、会话管理

  • 如何交换会话标识符
  • 是否限制会话生存期
  • 如何确保会话存储状态的安全

8、加密

  • 为何使用特定的算法
  • 如何确保加密密钥的安全性

9、参数操作

  • 是否验证所有的输入参数
  • 是否在参数过程中传递敏感数据
  • 是否为了安全问题而使用HTTP头数据

10、异常管理

  • 是否使用结构化的异常处理
  • 是否向客户端公开了太多的信息

11、审核和日志记录

  • 是否明确了要审核的活动
  • 是否考虑如何流动原始调用这身份

二.应用及传输安全
WEB系统的安全性从使用角度可以分为:应用级的安全与传输级的安全,安全性测试从这两方面入手。
应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患,主要测试区域如下。
注册与登陆:现在的Web应用系统基本采用先注册,后登录的方式。
A.必须测试有效和无效的用户名和密码
B.要注意是否存在大小写敏感
C.可以尝试多少次的限制
D.是否可以不登录而直接浏览某个页面等。
在线超时:Web应用系统是否有超时的限制,也就是说,用户登陆一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
操作留痕:为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进入了日志文件,是否可追踪。
备份与恢复:为了防范系统的意外崩溃造成的数据丢失,备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段,如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求,某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外,还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
传输级的安全测试是考虑到Web系统的传输的特殊性,重点测试数据经客户端传送到服务器端可能存在的安全漏洞,以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
HTTPS和SSL测试:默认的情况下,安全HTTP(Soure HTTP)通过安全套接字SSL(Source Socket Layer)协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别,但从某种意义上来说,安全性的保证是以损失性能为代价的。除了还要测试加密是否正确,检查信息的完整性和确认HTTPS的安全级别外,还要注意在此安全级别下,其性能是否达到要求。
服务器端的脚本漏洞检查:存在于服务器端的脚本常常构成安全漏洞,这些漏洞又往往被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
防火墙测试:防火墙是一种主要用于防护非法访问的路由器,在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试,以判断本Web系统的安全需求。
安全性测试工具:
Watchfire AppScan:商业网页漏洞扫描器
AppScan按照应用程序开发生命周期进行安全测试,早在开发阶段就进行单元测试和安全保证。Appscan能够扫描多种常见漏洞,例如跨网站脚本、HTTP应答切开、参数篡改、隐藏值篡改、后门/调试选项和缓冲区溢出等等。
Acunetix Web Vulnerability Scanner:商业漏洞扫描器
Acunetix WVS自动检查您的网页程序漏洞,例如SQL注入、跨网站脚本和验证页面弱密码破解。Acunetix WVS有着非常友好的用户界面,还可以生成个性化的网站安全评估报告。
黑盒主要测试点:用户管理模块、权限管理模块,加密系统,认证系统等
工具使用
Appscan(首要)、Acunetix Web Vulnerability Scanner(备用)、HttpAnalyzerFull、TamperIESetup
木桶原理
安全性最低的模块将成为瓶颈,需整体提高
(一)可手工执行或工具执行
输入的数据没有进行有效的控制和验证
用户名和密码
直接输入需要权限的网页地址可以访问
上传文件没有限制(此次不需要)
不安全的存储
操作时间的失效性
1.1)输入的数据没有进行有效的控制和验证
数据类型(字符串,整型,实数,等)
允许的字符集
最小和最大的长度
是否允许空输入
参数是否是必须的
重复是否允许
数值范围
特定的值(枚举型)
特定的模式(正则表达式)(注:建议尽量采用白名单)
1.22)用户名和密码-2
检测接口程序连接登录时,是否需要输入相应的用户
是否设置密码最小长度(密码强度)
用户名和密码中是否可以有空格或回车?
是否允许密码和用户名一致
防恶意注册:可否用自动填表工具自动注册用户? (傲游等)
遗忘密码处理
有无缺省的超级用户?(admin等,关键字需屏蔽)
有无超级密码?
是否有校验码?
密码错误次数有无限制?
大小写敏感?
口令不允许以明码显示在输出设备上
强制修改的时间间隔限制(初始默认密码)
口令的唯一性限制(看需求是否需要)
口令过期失效后,是否可以不登陆而直接浏览某个页面
哪些页面或者文件需要登录后才能访问/下载
cookie中或隐藏变量中是否含有用户名、密码、userid等关键信息
1.3)直接输入需要权限的网页地址可以访问
避免研发只是简单的在客户端不显示权限高的功能项
举例Bug:
没有登录或注销登录后,直接输入登录后才能查看的页面的网址(含跳转页面),能直接打开页面;
注销后,点浏览器上的后退,可以进行操作。
正常登录后,直接输入自己没有权限查看的页面的网址,可以打开页面。
通过Http抓包的方式获取Http请求信息包经改装后重新发送
从权限低的页面可以退回到高的页面(如发送消息后,浏览器后退到信息填写页面,这就是错误的)
1.4)上传文件没有限制(此次不需要)
传文件还要有大小的限制。
上传木马病毒等(往往与权限一起验证)
上传文件最好要有格式的限制;
1.5)不安全的存储
在页面输入密码,页面应显示 “*****”;
数据库中存的密码应经过加密;
地址栏中不可以看到刚才填写的密码;
右键查看源文件不能看见刚才输入的密码;
帐号列表:系统不应该允许用户浏览到网站所有的帐号,如果必须要一个用户列表,推荐使用某种形式的假名(屏幕名)来指向实际的帐号
1.6)操作时间的失效性
检测系统是否支持操作失效时间的配置,同时达到所配置的时间内没有对界面进行任何操作时,检测系统是否会将用户自动失效,需要重新登录系统。
支持操作失效时间的配置。
支持当用户在所配置的时间内没有对界面进行任何操作则该应用自动失效。
如,用户登陆后在一定时间内(例如15 分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
(二)借助工具或了解后手工来进行测试
不能把数据验证寄希望于客户端的验证
不安全的对象引用,防止XSS攻击
注入式漏洞(SQL注入)
传输中与存储时的密码没有加密 ,不安全的通信
目录遍历
2.1)不能把数据验证寄希望于客户端的验证
避免绕过客户端限制(如长度、特殊字符或脚本等),所以在服务器端验证与限制
客户端是不安全,重要的运算和算法不要在客户端运行。
Session与cookie
例:保存网页并对网页进行修改,使其绕过客户端的验证。
(如只能选择的下拉框,对输入数据有特殊要求的文本框)
还可以查看cookie中记录,伪造请求
测试中,可使用TamperIESetup来绕过客户端输入框的限制
2.21)不安全的对象引用,防止XSS等攻击
阻止带有语法含义的输入内容,防止Cross Site Scripting (XSS) Flaws 跨站点脚本攻击(XSS)
防止Cross-site request forgery(CSRF)跨站请求伪造
xss解释:不可信的内容被引入到动态页面中,没有识别这种情况并采取保护措施。攻击者可在网上提交可以完成攻击的脚本,普通用户点击了网页上这些攻击者提交的脚本,那么就会在用户客户机上执行,完成从截获帐户、更改用户设置、窃取和篡改 cookie 到虚假广告在内的种种攻击行为
测试方法:在输入框中输入下列字符,可直接输入脚本来看
HTML标签:<…>…</…>
转义字符:&amp(&);&lt(<);&gt(>);&nbsp(空格) ;
脚本语言:<script>alert(document.cookie);</script>
特殊字符:‘ ’ <>/
最小和最大的长度
是否允许空输入
对Grid、Label、Tree view类的输入框未作验证,输入的内容会按照html语法解析出来,要控制脚本注入的语法要素。比如:javascript离不开:“<”、“>”、“(”、“)”、“;”. 在输入或输出时对其进行字符过滤或转义处理
2.23)注入式漏洞(SQL注入)
对数据库等进行注入攻击。
例:一个验证用户登陆的页面,
如果使用的sql语句为:
Select * from table A

where username=’’ + username+’’ and password …..
则在Sql语句后面 输入 ‘ or 1=1 ―― 就可以不输入任何password进行攻击
SELECT count(*)
FROM users
WHERE username='a' or 'a'='a'
AND
password='a' or 'a'='a'
(资料太多,不显示了此处,借助工具Appscan等吧)
2.24)传输中与存储时的密码没有加密
利用ssl来进行加密,在位于HTTP层和TCP层之间,建立用户与服务器之间的加密通信
进入一个SSL站点后,可以看到浏览器出现警告信息,然后地址栏的http变成https (特点确定)证书认证
检查数据库中的用户密码、管理者密码等字段是否是以加密方式保存。
存储数据库单独隔离,有备份的数据库,权限唯一
2.25)目录遍历
举例:
http://love.ah163.net/Personal_Spaces_List.php?dir=MyFolder
那现在把这个URL改装一下:
http://love.ah163.net/Personal_S ... /local/apache/conf/

/usr/local/apache/conf/里的所有文件都出来了
简要的解决方案 :
1、限制Web应用在服务器上的运行 ,格设定WEB服务器的目录访问权限
2、进行严格的输入验证,控制用户输入非法路径,如在每个目录访问时有index.htm
(三)研发或使用工具才能进行
认证和会话数据不能作为GET的一部分来发送
隐藏域与CGI参数
不恰当的异常处理
不安全的配置管理
缓冲区溢出
拒绝服务
日志完整性、可审计性与可恢复性
3.1)Get or post
认证和会话数据不应该作为GET的一部分来发送,应该使用POST
例:对Grid、Label、Tree view类的输入框未作验证,输入的内容会按照html语法解析出来
可使用TamperIESetup或ScannerHttpAnalyzerFull来判断
3.2)隐藏域与CGI参数
Bug举例:
分析:隐藏域中泄露了重要的信息,有时还可以暴露程序原代码。
直接修改CGI参数,就能绕过客户端的验证了。
如: <input type="hidden" name="h" value="http://XXX/checkout.php">
只要改变value的值就可能会把程序的原代码显示出来。
如大小写,编码解码,附加特殊字符或精心构造的特殊请求等都可能导致CGI源代码泄露
可使用appscan或sss等来检测,检查特殊字符集
3.3)不恰当的异常处理
分析:程序在抛出异常的时候给出了比较详细的内部错误信息,暴露了不应该显示的执行细节,网站存在潜在漏洞,有可能会被攻击者分析出网络环境的结构或配置
通常为其他攻击手段的辅助定位方式
举例:如www.c**w.com ,搜索为空时,数据库显示出具体错误位置,可进行sql注入攻击或关键字猜测攻击
3.4)不安全的配置管理
分析:Config中的链接字符串以及用户信息,邮件,数据存储信息都需要加以保护
配置所有的安全机制,
关掉所有不使用的服务,
设置角色权限帐号,
使用日志和警报。
手段:用户使用缓冲区溢出来破坏web应用程序的栈,通过发送特别编写的代码到web程序中,攻击者可以让web应用程序来执行任意代码
例:数据库的帐号是不是默认为“sa”,密码(还有端口号)是不是直接写在配置文件里而没有进行加密。
3.5)缓冲区溢出
WEB服务器没有对用户提交的超长请求没有进行合适的处理,这种请求可能包括超长URL,超长HTTP Header域,或者是其它超长的数据
使用类似于“strcpy(),strcat()”不进行有效位检查的函数,恶意用户编写一小段程序来进一步打开安全缺口,然后将该代码放在缓冲区有效载荷末尾,这样当发生缓冲区溢出时,返回指针指向恶意代码
用户使用缓冲区溢出来破坏web应用程序的栈,通过发送特别编写的代码到web程序中,攻击者可以让web应用程序来执行任意代码。
如apach缓冲区溢出等错误,第三方软件也需检测
3.6)拒绝服务
手段:超长URL,特殊目录,超长HTTP Header域,畸形HTTP Header域或者是DOS设备文件
分析:攻击者可以从一个主机产生足够多的流量来耗尽狠多应用程序,最终使程序陷入瘫痪。需要做负载均衡来对付。
详细如:死亡之ping、泪滴(Teardorop)、 UDP洪水(UDP Flood)、 SYN洪水(SYN Flood)、 Land攻击、Smurf攻击、Fraggle攻击、 畸形消息攻击
3.7)日志完整性。可审计性与可恢复性
服务器端日志:检测系统运行时是否会记录完整的日志。
如进行详单查询,检测系统是否会记录相应的操作员、操作时间、系统状态、操作事项、IP地址等
检测对系统关键数据进行增加、修改和删除时,系统是否会记录相应的修改时间、操作人员和修改前的数据记录。
工具篇
Watchfire Appscan——全面自动测试工具
Acunetix Web Vulnerability ——全面自动测试工具
ScannerHttpAnalyzerFull——加载网页时可判断
TamperIESetup——提交表单时改造数据
注:上述工具最好安装在虚拟机中,不影响实际机环境

Appscan、 Web Vulnerability 需安装.net framework,可能与sniffer冲突
ScannerHttpAnalyzerFul与TamperIESetup会影响实际机浏览器平时的功能测试

从用户认证、网络、数据库和Web 四个角度进行安全性测试,需要注意:

(1)用户认证安全性测试

  • 系统中不同用户权限设置;
  • 系统中用户是否出现冲突;
  • 系统不应该因用户权限改变而造成混乱;
  • 系统用户密码是否加密、是否可复制;
  • 是否可以通过绝对途径登录系统;
  • 用户退出后是否删除其登录时的相关信息;
  • 是否可以使用退出键而不通过输入口令进入系统。

(2)网络安全性测试

  • 防护措施是否正确装配完成,系统补丁是否正确;
  • 非授权攻击,检查防护策略的正确性;
  • 采用网络漏洞工具检查系统相关漏洞(常用的两款工具为NBSI 和IPhackerIP);
  • 采集木马工具,检查木马情况;
  • 采用各种防外挂工具检查程序外挂漏洞。

(3)数据库安全性测试

  • 数据库是否具备备份和恢复的功能;
  • 是否对数据进行加密;
  • 是否有安全日志文件;
  • 无关IP 禁止访问;
  • 用户密码使用强口令;
  • 不同用户赋予不同权限;
  • 是否使用视图和存储过程;

(4)Web 安全性测试

  • 部署与基础结构;
  • 输入验证;
  • 身份验证;
  • 授权;
  • 配置管理;
  • 敏感数据;
  • 会话管理;
  • 加密;
  • 参数操作;
  • 异常管理;
  • 审核和日志记录;


————————————————

posted on   *非梦  阅读(537)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!
点击右上角即可分享
微信分享提示