渗透测试应该怎么做呢?
01、信息收集
1、域名、IP、端口
域名信息查询:信息可用于后续渗透
IP信息查询:确认域名对应IP,确认IP是否真实,确认通信是否正常
端口信息查询:NMap扫描,确认开放端口
发现:一共开放两个端口,80为web访问端口,3389为windows远程登陆端口,嘿嘿嘿,试一下
发现:是Windows Server 2003系统,OK,到此为止。
2、指纹识别
其实就是网站的信息。比如通过可以访问的资源,如网站首页,查看源代码:
看看是否存在文件遍历的漏洞(如图片路径,再通过…/遍历文件)
是否使用了存在漏洞的框架(如果没有现成的就自己挖)
02、漏洞扫描
1、主机扫描
Nessus
经典主机漏扫工具,看看有没有CVE漏洞:
2、Web扫描
AWVS(Acunetix | Website Security Scanner)扫描器
PS:扫描器可能会对网站构成伤害,小心谨慎使用。
03、渗透测试
1、弱口令漏洞
漏洞描述
目标网站管理入口(或数据库等组件的外部连接)使用了容易被猜测的简单字符口令、或者是默认系统账号口令。
渗透测试
① 如果不存在验证码,则直接使用相对应的弱口令字典使用burpsuite 进行爆破
② 如果存在验证码,则看验证码是否存在绕过、以及看验证码是否容易识别
风险评级:高风险
安全建议
① 默认口令以及修改口令都应保证复杂度,比如:大小写字母与数字或特殊字符的组合,口令长度不小于8位等
② 定期检查和更换网站管理口令
2、文件下载(目录浏览)漏洞
漏洞描述
一些网站由于业务需求,可能提供文件查看或下载的功能,如果对用户查看或下载的文件不做限制,则恶意用户就能够查看或下载任意的文件,可以是源代码文件、敏感文件等。
渗透测试
① 查找可能存在文件包含的漏洞点,比如js,css等页面代码路径
② 看看有没有文件上传访问的功能
③ 采用…/来测试能否夸目录访问文件
风险评级:高风险
安全建议
① 采用白名单机制限制服务器目录的访问,以及可以访问的文件类型(小心被绕过)
② 过滤【./】等特殊字符
③ 采用文件流的访问返回上传文件(如用户头像),不要通过真实的网站路径。
示例:tomcat,默认关闭路径浏览的功能:
param-namelistings/param-name
param-valuefalse/param-value
3、任意文件上传漏洞
漏洞描述
目标网站允许用户向网站直接上传文件,但未对所上传文件的类型和内容进行严格的过滤。
渗透测试
① 收集网站信息,判断使用的语言(PHP,ASP,JSP)
② 过滤规则绕过方法:文件上传绕过技巧
风险评级:高风险
安全建议
① 对上传文件做有效文件类型判断,采用白名单控制的方法,开放只允许上传的文件型式;
② 文件类型判断,应对上传文件的后缀、文件头、图片类的预览图等做检测来判断文件类型,同时注意重命名(Md5加密)上传文件的文件名避免攻击者利用WEB服务的缺陷构造畸形文件名实现攻击目的;
③ 禁止上传目录有执行权限;
④ 使用随机数改写文件名和文件路径,使得用户不能轻易访问自己上传的文件。
4、命令注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验,允许用户输入特殊语句,导致各种调用系统命令的web应用,会被攻击者通过命令拼接、绕过黑名单等方式,在服务端运行恶意的系统命令。
渗透测试
风险评级:高风险
安全建议
① 拒绝使用拼接语句的方式进行参数传递;
② 尽量使用白名单的方式(首选方式);
③ 过滤危险方法、特殊字符,如:【|】【】【;】【’】【"】等
5、SQL注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验,允许用户输入特殊语句查询后台数据库相关信息
渗透测试
① 手动测试:判断是否存在SQL注入,判断是字符型还是数字型,是否需要盲注
② 工具测试:使用sqlmap等工具进行辅助测试
风险评级:高风险
安全建议
① 防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔,如Java的预处理,PHP的PDO
② 拒绝使用拼接SQL的方式
6、跨站脚本漏洞
漏洞描述
当应用程序的网页中包含不受信任的、未经恰当验证或转义的数据时,或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时,就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本,并劫持用户会话、破坏网站或将用户重定向到恶意站点。
三种XSS漏洞:
① 存储型:用户输入的信息被持久化,并能够在页面显示的功能,都可能存在存储型XSS,例如用户留言、个人信息修改等。
② 反射型:URL参数需要在页面显示的功能都可能存在反射型跨站脚本攻击,例如站内搜索、查询功能。
③ DOM型:涉及DOM对象的页面程序,包括:document.URL、document.location、document.referrer、window.location等
渗透测试
存储型,反射型,DOM型
风险评级:高风险
安全建议
① 不信任用户提交的任何内容,对用户输入的内容,在后台都需要进行长度检查,并且对【】【】【"】【’】【】等字符做过滤
② 任何内容返回到页面显示之前都必须加以html编码,即将【】【】【"】【’】【】进行转义。
7、跨站请求伪造漏洞
漏洞描述
CSRF,全称为Cross-Site Request Forgery,跨站请求伪造,是一种网络攻击方式,它可以在用户毫不知情的情况下,以用户的名义伪造请求发送给被攻击站点,从而在未授权的情况下进行权限保护内的操作,如修改密码,转账等。
渗透测试
风险评级:中风险(如果相关业务极其重要,则为高风险)
安全建议
① 使用一次性令牌:用户登录后产生随机token并赋值给页面中的某个Hidden标签,提交表单时候,同时提交这个Hidden标签并验证,验证后重新产生新的token,并赋值给hidden标签;
② 适当场景添加验证码输入:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串;
③ 请求头Referer效验,url请求是否前部匹配Http(s)😕/ServerHost
④ 关键信息输入确认提交信息的用户身份是否合法,比如修改密码一定要提供原密码输入
⑤ 用户自身可以通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie;
8、内部后台地址暴露
漏洞描述
一些仅被内部访问的地址,对外部暴露了,如:管理员登陆页面;系统监控页面;API接口描述页面等,这些会导致信息泄露,后台登陆等地址还可能被爆破。
渗透测试
① 通过常用的地址进行探测,如login.html,manager.html,api.html等;
② 可以借用burpsuite和常规页面地址字典,进行扫描探测
风险评级:中风险
安全建议
① 禁止外网访问后台地址
② 使用非常规路径(如对md5加密)
9、信息泄露漏洞
漏洞描述
① 备份信息泄露:目标网站未及时删除编辑器或者人员在编辑文件时,产生的临时文件,或者相关备份信息未及时删除导致信息泄露。
② 测试页面信息泄露:测试界面未及时删除,导致测试界面暴露,被他人访问。
③ 源码信息泄露:目标网站文件访问控制设置不当,WEB服务器开启源码下载功能,允许用户访问网站源码。
④ 错误信息泄露:目标网站WEB程序和服务器未屏蔽错误信息回显,页面含有CGI处理错误的代码级别的详细信息,例如SQL语句执行错误原因,PHP的错误行数等。
⑤ 接口信息泄露:目标网站接口访问控制不严,导致网站内部敏感信息泄露。
渗透测试
① 备份信息泄露、测试页面信息泄露、源码信息泄露,测试方法:使用字典,爆破相关目录,看是否存在相关敏感文件
② 错误信息泄露,测试方法:发送畸形的数据报文、非正常的报文进行探测,看是否对错误参数处理妥当。
③ 接口信息泄露漏洞,测试方法:使用爬虫或者扫描器爬取获取接口相关信息,看目标网站对接口权限是否合理
风险评级:一般为中风险,如果源码大量泄漏或大量客户敏感信息泄露。
安全建议
① 备份信息泄露漏洞:删除相关备份信息,做好权限控制
② 测试页面信息泄露漏洞:删除相关测试界面,做好权限控制
③ 源码信息泄露漏洞:做好权限控制
④ 错误信息泄露漏洞:将错误信息对用户透明化,在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因
⑤ 接口信息泄露漏洞:对接口访问权限严格控制
10、失效的身份认证
漏洞描述
通常,通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌, 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
渗透测试
① 在登陆前后观察,前端提交信息中,随机变化的数据,总有与当前已登陆用户进行绑定的会话唯一标识,常见如cookie
② 一般现在网站没有那种简单可破解的标识,但是如果是跨站认证,单点登录场景中,可能为了开发方便而简化了身份认证
风险评级:高风险
安全建议
① 使用强身份识别,不使用简单弱加密方式进行身份识别;
② 服务器端使用安全的会话管理器,在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中,可以安全地存储,在登出、闲置超时后使其失效。
11、失效的访问控制
漏洞描述
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据,例如:访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
渗透测试
① 登入后,通过burpsuite 抓取相关url 链接,获取到url 链接之后,在另一个浏览器打开相关链接,看能够通过另一个未登入的浏览器直接访问该功能点。
② 使用A用户登陆,然后在另一个浏览器使用B用户登陆,使用B访问A独有的功能,看能否访问。
风险评级:高风险
安全建议
① 除公有资源外,默认情况下拒绝访问非本人所有的私有资源;
② 对API和控制器的访问进行速率限制,以最大限度地降低自动化攻击工具的危害;
③ 当用户注销后,服务器上的Cookie,JWT等令牌应失效;
④ 对每一个业务请求,都进行权限校验。
12、安全配置错误
漏洞描述
应用程序缺少适当的安全加固,或者云服务的权限配置错误。
① 应用程序启用或安装了不必要的功能(例如:不必要的端口、服务、网页、帐户或权限)。
② 默认帐户的密码仍然可用且没有更改。
③ 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
④ 对于更新的系统,禁用或不安全地配置最新的安全功能。
⑤ 应用程序服务器、应用程序框架(如:Struts、Spring、ASP.NET)、库文件、数据库等没有进行相关安全配置。
渗透测试
先对应用指纹等进行信息搜集,然后针对搜集的信息,看相关应用默认配置是否有更改,是否有加固过;端口开放情况,是否开放了多余的端口;
风险评级:中风险
安全建议
搭建最小化平台,该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。在所有环境中按照标准的加固流程进行正确安全配置。
13、使用含有已知漏洞的组件
漏洞描述
使用了不再支持或者过时的组件。这包括:OS、Web服务器、应用程序服务器、数据库管理系统(DBMS)、应用程序、API和所有的组件、运行环境和库。
渗透测试
① 根据前期信息搜集的信息,查看相关组件的版本,看是否使用了不在支持或者过时的组件。一般来说,信息搜集,可通过http返回头、相关错误信息、应用指纹、端口探测(Nmap)等手段搜集。
② Nmap等工具也可以用于获取操作系统版本信息
③ 通过CVE,CNVD等平台可以获取当前组件版本是否存在漏洞
风险评级:按照存在漏洞的组件的安全风险值判定当前风险。
安全建议
① 移除不使用的依赖、不需要的功能、组件、文件和文档;
② 仅从官方渠道安全的获取组件(尽量保证是最新版本),并使用签名机制来降低组件被篡改或加入恶意漏洞的风险;
③ 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁,可以考虑部署虚拟补丁来监控、检测或保护。
详细学习可参考:
如何进行渗透测试才有可能登录到数据库服务器的远程终端
新建一个文本文件,更改扩展名为aabb.udl双击此文件,选数据库类型、设置ip、用户名、密码,数据库可进行连接测试 ,当然对方要开sql服务的测试成功后,点确定将这个文件以文本方式打开, 里面有连接字符串,装sql 查询分析器。
渗透测试成功的关键是什么?
1.知道为什么要测试
执行渗透测试的目的是什么?是满足审计要求?是你需要知道某个新应用在现实世界中表现如何?你最近换了安全基础设施中某个重要组件而需要知道它是否有效?或者渗透测试根本就是作为你定期检查防御健康的一项例行公事?
当你清楚做测试的原因时,你也就知晓自己想从测试中得到什么了,而这可以让测试规划工作更有效率。知道做测试的缘由可以让人恰当地确立测试的范围,确定测试结果将会揭露什么问题。
或许这一步中最重要的一部分,是让团队提前架设好准备从测试结果中得出正确的结论的心理预期。如果测试是要审查IT基础设施的某个特定方面(比如说新的Web应用),那就没必要着墨于公司整体安全。理解做测试的缘由可以让你问出正确的问题,得到能被恰当理解的结果。
2.了解你的网络
漏洞是安全的重点。企业网络上线之日直至如今必然经历种种变迁,只要攻击者比企业自己的IT员工更清楚其中存在的漏洞,企业网络就对攻击者门户洞开。
绘制公司网络地图的责任不落在渗透测试团队身上。如果渗透测试团队在做这项工作,就意味着你有可能错过他们的测试结果,因为你收到的网络架构消息都能把渗透测试结果淹没。
一张更新的网络地图(包括逻辑方面和拓扑方面)应成为渗透测试的强制性前提条件。如果渗透测试员在告诉你你所不知道的网络架构情况,那你就是在为网络地图买单——很贵的那种。
3. 设置范围
红队探测范围有多广,很大程度上取决于你为什么要做这个测试,因为太广或太窄可能都无甚大用。
测试范围过窄的问题很明显:如果想要找出的问题在测试范围外,那就没有任何数据能帮助确定该组件的安全。所以,必须确保测试参数包含事关公司当前安全状态的重要组件。最重要的是,你得确定自己要测试的是整体安全状况还是某特定系统的安全状态,以及人为因素(对网络钓鱼和其他社会工程攻击的敏感性)需不需要被包含进去。
如果测试范围过宽,有可能出现两个问题。第一个问题是经济上的:测试费用会随范围的扩大而增加,而测试价格与所需信息不相匹配的状况又会影响到公司高层对未来测试的热情。
第二个问题就更为致命了。测试范围过大时,测试本身容易返回太多信息,真正所需的数据很容易被淹没在巨量的测试结果中。教训很清楚:想要测试架构中特定部分的安全,就将渗透测试的范围限定在那个部分上。对整个系统的测试可以留待下次进行。
4. 做好计划
弄清测试目的并确定出测试范围后,就可以开始制定测试计划了。定出详细明确的测试条件和需求最为重要,任何松散或须经解释的测试要求都会削减渗透测试的效率。需做好详尽计划的原因有很多,其中最主要的原因与成本控制和提升测试结果可用性有关。
良好的测试计划应分为多个部分。一个部分帮助委托公司巩固其测试方案的要求。一个部分确认测试返回数据的类型。还要有一部分内容为向公司执行委员会解释测试开销做准备。
测试计划不是制定好后就固定不变的,测试过程中可能需作出修订。测试团队被聘用后,他们可能会针对某些测试元素提出一些能产生更好结果的建议。其中关键就在于,公司内部就该测试计划达成一致后
,安全团队就能判断渗透测试员的建议是否能满足测试需求了,不用什么都依靠测试团队的力量。
5. 雇正确的团队
提供渗透测试服务的公司和顾问很多。这些公司都有各自的优势和弱点,他们的技术技巧各有千秋,呈现测试结果的方式也有好有坏。公司有必要确保所选测试团队的能力尽可能地符合测试需要。
要注意的是,测试需求应高于客户要求。确实,有些团队在导引征求建议书(RFP)过程或挤进获批供应商列表上颇有心得,但他们执行测试计划所需渗透测试动作的技术未必比得上这些在应付客户上的技巧。选择渗透测试团队时应将测试技术放在第一位,会计和行政管理方面的能力次之。
可以考察测试团队的老辣程度,看他们如何在不推翻原计划的条件下提出建议,改进客户的测试计划。这也是为什么前期要做好测试计划的一个重要原因。因为可以检查测试过程中的种种改动。
6. 不要干预
人都想得到别人的认同,这是人类天性。但渗透测试的目的就是要展现出公司企业安全状态的实际情况,所以,尽量别为了得到个看起来好看的结果而人为干扰渗透测试员,给防御方提供不公平的优势。
事实上,红队几乎总能某种程度上渗透进公司网络边界。我们当前的技术和操作就是这样的。很多情况下,真正的问题存在于蓝队到底什么时候才能发现已被攻破,会如何响应。
无论测试结果如何,都要让测试过程正常进行,以便结果真实、准确、有用。管理层的任何干预都会毁了渗透测试的有效性,请一定记得在测试完成前不要插手。
7. 注意结果
测试完成后,你会得到一份完整的报告,需仔细研读。渗透测试员应向你呈现出测试的结果,如果你有机会根据测试结果改进安全系统,别放过这种机会。
或许渗透测试是为了满足监管合规要求而做的。也有可能你就没想找任何理由来改变你的安全防御。这都没关系。你的安全防御如今已遭遇过敌军主力,而你可以看清安全计划的成功之处与失败的地方。
如果测试结果被用于做出有意义的改变,渗透测试就是划算的。而划算的渗透测试也更有可能在未来获得公司高层的安全预算。
8. 沟通结果
对大多数公司来说,渗透测试的结果不局限在安全团队范围内。至少,对整个IT部门都有影响,而很多情况下还有高管们需要看到的信息。
很多安全人员都觉得,向非安全专业的经理传达渗透测试结果是过程中最难的部分。不仅需要说明都做了什么,为什么要这么做,还要用他们能听懂的语言解释需要作出什么改动。这往往意味着要用商业术语沟通,而不是以技术语言阐述。
正如渗透测试可被视为真实攻击的预演,将其他部门的同事纳入结果阐述和操作展示的受众范围,也有助于确保被接收的信息确实是你想要传达的。
对很多业务经理而言,网络安全是个令人望而生畏的高难度领域;尽量别用过多的行话让业务经理们在座位上一头雾水坐卧不宁。
今日福利
【Java11期开课啦】
8大实战案例模块,历时三年沉淀,Java4.0震撼发布!
偷偷告诉你前50名,还可获得价值300元的京东购物卡呦~
如有疑问,请留言告知,或者咨询柠檬班 软件测试培训 机构:官网客服哦
留言领取100G软件测试全面课程视频。
0条大神的评论