本文主要是介绍Web应用安全测试-业务功能滥用（二），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Web应用安全测试-业务功能滥用（二）
7、未验证的URL跳转
漏洞描述：服务端未对传入的跳转url变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；也可能引发的XSS漏洞（主要是跳转常常使用302跳转，即设置HTTP响应头，Locatioin: url，如果url包含了CRLF，则可能隔断了http响应头，使得后面部分落到了http body，从而导致xss漏洞）。另外在struts2 中存在重定向的漏洞，是因为struts2由于缩写的导航和重定向前缀“action:”、 “redirect:”、 “redirectAction:” 等参数前缀的内容没有被正确过滤导致的开放式重定向漏洞。
测试方法：
- 首先找到网站相关url中存在跳转链接的参数（如登录页面）。
- 在检测的同时，可以修改参数中的合法URL为非法URL，然后查看是否能正常跳转或者通过抓包工具获取其HTTP响应头中Host:的值是否包含了构造的URL。
- 如果是struts2重定向漏洞，则可通过web扫描工具扫描发现，或者手工验证，直接在URL后添加?redirect:+指定钓鱼链接，例如：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com进行验证。
风险分析：攻击者利用URL跳转漏洞来欺骗安全意识低的用户，从而导致“中奖”之类的欺诈事件发生。同时利用URL跳转，也可以突破常见的基于“白名单方式”的一些安全限制，如传统IM里对于URL的传输会进行安全校验，但是对于知名网站的域名及URL将直接允许通过并且显示为可信的URL，一旦该可信的URL里包含URL跳转漏洞将导致安全限制被绕过。URL跳转最典型的例子就是登录跳转，示例代码如下：
public void doRedirect(HttpServletRequest req, HttpServletResponse res){String jumpURL=request.getParameter(“jumptoURL”);response.setHeader("Location",jumpURL);}若程序未过滤jumptoURL参数，攻击者将恶意链接：http://www.xxx.com/login.jsp?jumptoURL=http://www.evil.com发给其他用户，安全意识较低的用户会认为该链接展现的内容是www.xxx.com，从而产生欺诈行为。同时由于QQ、淘宝旺旺等在线IM都是基于URL的过滤，对部分站点会通过白名单的方式直接通过，因此恶意URL可以在IM里传播。例如IM认为www.xxx.com是可信的，但是通过在IM里点击上述链接将导致用户最终访问http://www.evil.com。
风险等级：
【高危】：URL 跳转参数可控，且未对参数做白名单限制导致任意地址跳转可被利用钓鱼。
修复方案：对传入的URL做有效性的认证，保证该URL来自于信任域。限制的方式可参考以下两种：
- 限制Referer（Referer是HTTP header中的字段，当浏览器向web服务器发送请求时，一般会带上Referer，告诉服务器是从哪个页面链接过来的），通过限制Referer保证将要跳转URL的有效性，避免攻击者生成自己的恶意跳转链接；
- 加入有效性验证Token，保证所有生成的链接都来自于可信域，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验。
注意事项：暂无
8、服务器端请求伪造（SSRF）
漏洞描述：服务端请求伪造攻击（Server-side Request Forgery）: 很多web应用都提供了从其他的服务器上获取数据的功能。使用用户指定的URL，web应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的web应用作为代理攻击远程和本地的服务器。这种形式的攻击称为服务端请求伪造攻击（Server-side Request Forgery）。一般情况下， SSRF攻击的目标是从外网无法访问的内部系统 。（ 正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统 ）.SSRF 形成的原因大都是由于 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制 。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。攻击者利用ssrf可以实现的攻击主要有5种:
- 可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息;
- 攻击运行在内网或本地的应用程序（比如溢出）;
- 对内网web应用进行指纹识别，通过访问默认文件实现;
- 攻击内外网的web应用，主要是使用get参数就可以实现的攻击（比如struts2，sqli等）;
- 利用file协议读取本地文件等。
测试方法：从WEB功能上寻找：我们从上面的概述可以看出，SSRF是由于服务端获取其他服务器的相关信息的功能中形成的，因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。
- 通过分享功能：通过URL地址分享网页内容：
早期分享应用中，为了更好的提供用户体验，WEB应用在分享功能中，通常会获取目标URL地址网页内容中的<tilte></title>标签或者<meta name="description" content=“”/>标签中content的文本内容作为显示以提供更好的用户体验。例如人人网分享功能中：http://widget.renren.com/*****?resourceUrl=https://www.nsfocus.com
通过目标URL地址获取了title标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞。
2、转码服务：通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览：由于手机屏幕大小的关系，直接浏览网页内容的时候会造成许多不便，因此有些公司提供了转码功能，把网页内容通过相关手段转为适合手机屏幕浏览的样式。例如百度、腾讯、搜狗等公司都有提供在线转码服务。
3、在线翻译：通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等。
4、图片加载与下载，通过URL地址加载或下载图片：图片加载远程图片地址此功能用到的地方很多，但大多都是比较隐秘，比如在有些公司中的加载自家图片服务器上的图片用于展示。（此处可能会有人有疑问，为什么加载图片服务器上的图片也会有问题，直接使用img标签不就好了？ ，没错是这样，但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等，所以就可能造成SSRF问题）。
5、图片、文章收藏功能：此处的图片、文章收藏中的文章收藏就类似于功能一、分享功能中获取URL地址中title以及文本的内容作为显示，目的还是为了更好的用户体验，而图片收藏就类似于功能四、图片加载。
6、未公开的api实现以及其他调用URL的功能：此处类似的功能有360提供的网站评分，以及有些网站通过api获取远程地址xml文件来加载内容.
风险分析：如果应用程序对用户提供的URL和远端服务器返回的信息没有进行合适的验证和过滤，则可能存在服务器端请求伪造攻击。服务器端请求伪造攻击场景如下图所示：
攻击者想要访问主机B上的服务，由于存在防火墙的原因无法直接访问，这时可以借助主机A来发起服务器端请求伪造攻击，通过主机A向主机B发起请求，从而完成攻击。SSRF攻击方式主要有以下5种：
- 对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息（一般包括服务器的类型、版本，服务器上启动的服务信息）；
- 攻击运行在内网或本地的应用程序（比如堆栈溢出）；
- 通过访问默认文件实现对内网Web应用的指纹识别；
- 攻击内外网的Web应用，主要是使用GET参数就可以实现的攻击（比如Struts2，Sqli等）；
- 利用file协议读取本地文件等。
风险等级：
【高危】：有回显，可探测内网，文件访问
【中危】：无回显，但可访问外网
修复方案：通常从以下几点来防御服务器端请求伪造攻击：
- 过滤内网服务器对公网服务器请求的响应。如果Web应用是获取某一类型的文件，在把返回结果展示给用户之前应先验证返回的信息是否符合文件类型标准，比如返回信息应为图片，如果返回信息是HTML，则停止将返回信息返回客户端。
- 统一错误提示信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
- 在内网服务器的防火墙上限制公网服务器的请求端口为HTTP等协议常用端口，如：80、443、8080、8090。
- 若公网服务器的内网IP与内网无业务通信，建议将公网服务器对应的内网IP列入黑名单，避免应用被用来获取内网数据。
- 内网服务器禁用不必要的协议，仅允许HTTP和HTTPS请求，防止类似于file:///、gopher://、ftp:// 等协议引起的安全问题。
注意事项：暂无
9、短信内容可控
漏洞描述：短信内容可从客户端指定
测试方法：在客户端编辑任意短信内容，测试是否过滤特殊内容。
风险分析：攻击者可利用该漏洞，借助短信平台，编辑钓鱼短信发送给其他用户。
风险等级：
【高危】：短信内容可控，且接收人可任意指定
【中危】：短信内容可控，但接受人不可控
修复方案：建议在不影响业务的前提下，禁止客户端编辑短信内容。
注意事项：暂无
10、邮件内容可控
漏洞描述：应用系统发送邮件的邮件内容可由客户端任意指定
测试方法：在客户端编辑任意邮件内容，测试是否过滤特殊内容。
风险分析：攻击者可利用该漏洞，借助邮件平台，编辑钓鱼邮件发送给其他用户。
风险等级：
【高危】：邮件内容可控，且收件人可任意指定
【中危】：邮件内容可控，但收件人地址不可控
修复方案：建议在不影响业务的前提下，禁止客户端编辑邮件内容。
注意事项：暂无
11、请求重放攻击
漏洞描述：关键业务操作未作token或者唯一标识码，导致攻击者可以重复多次进行请求，导致恶意操作。如重复交易等问题。
测试方法：重放http/tcp请求，查看第二次请求是否被正常处理。
风险分析：攻击者恶意或欺诈性地重复发送一个有效的数据包，如果服务器未检查此类重复提交的请求数据的有效性，那么转账充值等敏感操作将有可能会被重复执行。
风险等级：
【高危】：关键业务操作请求未设置 token 或标识码，导致业务数据越界或错误
修复方案：服务端应用程序应检查客户端提交的数据的唯一性，如使用流水号、时间戳、token等，并将流水号、时间戳等进行签名。
注意事项：暂无
12、批量提交
漏洞描述：应用程序未使用验证码等防自动化操作的方法，可批量提交请求，如批量注册。
测试方法：
- 编写自动提交HTTP数据包的脚本；
- 或使用burpsuite的intruder功能批量提交请求。
风险分析：注册不需要验证码时，攻击者通过编写自动化脚本，实现程序自动提交注册信息；若注册需要验证码，但验证码位数不多于4位且为纯数字时，通过使用软件burpsuite的intruder功能穷举得到正确的验证码后，再结合自动化脚本工具即可实现批量注册垃圾账号。
风险等级：
【高危】：正常业务为单条数据请求，且不存在防自动化批量操作措施，可批量自动化提交。
【低危】：正常业务为单条数据请求，且存在防自动化批量操作措施，但在单个数据包中写入批量数据，可成功提交，并且服务器能批量执行。
修复方案：
- 使用安全性强的验证码，验证码应从以下方面保证其安全性：验证码长度不低于4位，避免使用容易被程序自动识别的验证码，验证码不应返回客户端。
- 用户注册功能处，提交注册信息后进行邮箱或短信验证通过后再将注册信息写入数据库。
- 对同一IP地址短时间内提交请求的次数进行限制。
注意事项：暂无
这篇关于Web应用安全测试-业务功能滥用（二）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
