web安全测试必须注意的五个方面
随着互联网的飞速发展,web应用在软件开发中所扮演的角色变得越来越重要,同时,web应用遭受着格外多的安全攻击,其原因在于,现在的网站以及在网站上运行的应用在某种意义上来说,它是所有公司或者组织的虚拟正门,所以比较容易遭受到攻击,存在安全隐患。
今天主要给大家分享下有关安全测试的一些知识点以及注意事项。
一、安全测试的验证点
一个系统的安全验证点包括上传功能、注册功能/登陆功能、验证码功能、密码、敏感信息泄露、越权测试、错误信息、session等。
1、上传功能
-
上传中断,程序是否有判断上传是否成功
-
上传与服务器端语言(jsp/asp/php)一样扩展名的文件或exe等可执行文件后,确认在服务器端是否可直接运行
2、注册功能/登陆功能
-
请求是否安全传输
-
重复注册/登陆
-
关键cookie是否httponly
-
会话固定:利用session的不变机制,获取他人认证和授权,然后冒充
3 、验证码功能
-
短信轰炸
-
验证码一次性
4、 忘记密码
-
通过手机号/邮箱找回
-
程序设计不合理,导致可以绕过短信验证码,从而进行修改(使用burpsuite抓包,修改响应值true)
5 、敏感信息泄漏
- 数据库/日志/提示
6 、越权测试
-
不登陆系统,直接输入下载文件的URL是否可以下载/直接输入登录后页面的URL是否可以访问
-
手动更改URL中的参数值能否访问没有权限访问的页面
-
不同用户之间session共享,可以非法操做对方的数据
7 、错误信息
- 错误信息中释放含有sql语句,错误信息以及web服务器的绝对路径
8、 Session
- 退出登陆后,点击后退按钮是否能访问之前的页面
主要归结为以下几点:(后期可以优化成一个安全测试的框架结构)
- 部署与基础结构
- 输入验证
- 身份验证
- 授权
- 配置管理
- 敏感数据
- 会话管理
- 加密
- 参数操作
- 异常管理
- 审核和日志安全,
二、结合实际情况(现有系统)发现的问题
1、日志/提示
在系统的初期,一般比较容易发现的问题就是在进行一些错误或者反向测试时,在页面的提示中会出现带有明显的数据库的表或者字段的打印,或者会出现一些敏感词,日志里面类似密码,卡号,身份证号没有相应的明密文转换,而这些敏感词/明密文不互转的存在,就会导致攻击者能够获取到,从而进行简单粗暴的攻击,轻易的攻击服务器或者数据库,这就会危害到整个系统!
2、重复性
大部分的web网站都会有注册功能,而类似我们负责支付这块也都会有开户,就注册跟开户,基本上需求上都会有唯一性的校验,在前端就会进行拦截,但如果使用jmter进行参数以及参数值的新增,有可能新增成功,就会导致页面系统里面会出现相同数据,可能导致整个功能的出错。
3、次数限制
类似发单,登录或者短信,如果没有进行相应的限制,如短信,没有进行限制次数,攻击者就会通过短信轰炸,攻击系统,导致系统瘫痪,其他客户就会使用不了该系统。
4、越权测试
(基本上大部分系统都没有明确的写出越权方面的需求)一个web系统,一般地址栏都会有参数的带入,如:用户号,订单号或者是其他的一些参数,而在这个基础上一个系统都会有很多用户,或者很多等级,如:A大于B大于C,那我使用C用户进行登录,查看C用户所属的订单,在地址栏中会有订单号的参数带入,如果系统没有进行相应的限制,此时C用户就可以修改订单号从而可以看到B乃至A用户的数据,这就可能导致数据的泄露,再者,如果可以修改用户的用户号,没有做处理,这样就可以对所有数据进行操作,整个系统就乱了,影响很大。
5、SQL注入/XSS攻击
主要是输入框的校验/拦截以及是否转义,如果没有系统没有对输入的内容进行处理,那攻击者就可以输入一段SQL语句,或者一段代码,在后台进入到相应的功能,就会导致整个功能是错乱的,其他正常用户所提交的数据也查看操作不了,或者提交的代码是死循环(">),就会关闭不掉,所以这点是非常重要的。
基本上上述的五点都是在测试中,系统真实存在,发生的问题,还有其他问题就不一一例举了,其中越权跟SQL注入以及XSS攻击都是重中之重!
三、克服的小困难
上面所述的都是需要人工进行手动参与,且人力操作时不会那么饱满全面,所以这是一个遇到的小问题。现在有一个针对web系统进行漏洞扫描的工具:AWVS,它通过网络爬虫测试你的网站安全,检测流行安全漏洞,针对漏洞主要分为四个等级:高危、中危,低危以及优化,它会进行内外链接的安全性,文件是否存在以及传输是否安全,也包含SQL注入跟XSS攻击,输入地址,用户名密码后,进行扫描完成后会展示相应的数据:漏洞的数量,漏洞的描述,建议性的修复;扫描网站的时长,文件数据量,环境信息等,较为全面!
四、安全测试的思路跟框架
主要根据以下六点来实现一个较为完整的安全测试的思路,框架就是根据半手工、半自动来实现整个系统的验证。
- 部署与基础结构
- 输入验证
- /身份验证(权限验证)
- 敏感数据
- 参数操作
- 审核和日志安全;
五、目前存在的问题/需要优化的
现在的安全测试大多是半手工、半自动化,但都不是专业级,所以还在摸索阶段,只能尽可能地去发现系统中存在的漏洞,且测试理论很难适用于安全领域;
安全测试基础理论薄弱,当前测试方法缺少理论指导,也缺乏更多的技术产品工具 ;
安全测试需要对系统所采用的技术以及系统的架构等进行分析,这方面也是较为薄弱的环节!
作者:王鹏飞
来源:宜信技术学院
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
且听穿林打叶声———Ashmem机制讲解
且听穿林打叶声———Ashmem机制讲解 侯亮 (Android 7.0) 在Android平台上,提供了一种共享内存的机制——Ashmem。该机制内部其实复用了Linux的共享内存机制。Ashmem机制使用linux的mmap系统调用,可以将同一段物理内存映射到不同进程各自的虚拟地址空间,从而实现高效的进程间共享。 大家都知道,在linux上“一切皆文件”,一块共享内存当然也不例外。因此,在用户态,我们能看到的重要概念就是共享内存的“文件描述符”,文件描述符可以对应一个内核态的ashmem file。file中又可以管理自己的逻辑数据(ashmem_area)。不同进程里的不同文件描述符可以对应同一个内核态的file,这就是跨进程共享的基础。当我们对这个文件描述符做完mmap操作后,一般都会记下映射好的起始地址,这是后续进行读取、写入操作的一个基准值,在后文要说的MemoryFile里,这个基准值会记在mAddress成员变量里。 我们先画一张示意图对ashmem有个大体上的了解: 1.以MemoryFile为切入点 我们不大可能直接使用Ashmem,为此Android提供了一个M...
- 下一篇
Raft 共识算法(高可用+强一致)
Raft算法主要应用于分布式集群系统中,如果保证高可用和数据一致性,它主要定义两方面的规范:选主(Leader Election)和复制日志(Log Replication) 1.选主机制 Raft定义了集群节点三个状态:Leader(主)、Follower (从)、Candidate(候选) 主:负责与对接外部输入 ,并保持与从的心跳 从:备份数据、主挂了的时候要挑起重担 候选:当从timeout时间内(150ms 到 300ms,每个节点不一样)没有收到主的心跳,转为此状态 从以下几种情形中分析选主是如何运作的 a.正常初始情况 开始所有节点都是Follower状态,当其中一个节点在timeout过后,就会转变成Candidate并向其它节点发送投票请求,并开始新的timeout。 超过半数Follower节点收到请求并回复确认后,Candidate节点就会转变成Leader节点,并向Follower节点发送心跳 b.Leader 出故障 当Leader出故障后,其它Follower节点按正常初始状态走,直到选出Leader ...
相关文章
文章评论
共有0条评论来说两句吧...