前端绕过的攻与防(上)

admin 2025年2月17日21:29:31评论13 views字数 5979阅读19分55秒阅读模式

前言

说到前端绕过,让我们想到更多的是在黑盒的渗透测试过程中的采取的一种攻击手法,通过绕过前端的代码设计缺陷,达到漏洞利用的目的,相比白盒来说,是可以直接源代码进行分析的,而黑盒的代码绕过,通常就是面对一个后台页面,这相对更符合渗透工程师的日常攻击场景,那么今天我们就介绍几种常见的前端绕过方法,仅供参考。

免责声明:本文仅作安全交流,请勿用于其他目的,本文解释权归君立华域渗透测试研究中心所有。

场景1-登录页面

首先是面对一个后台登陆页面

一般拿到一个后台页面的时候,我们能做的就是测试一下常规的漏洞,那么可以测试哪些方法呢,首先就是SQL注入,一般遇到后台页面,可以测试的就是’having 1=1 ,看是否报错,如果报错,可以进行手工盲注,或者直接使用SQLmap的 --forms参数去自动查找参数实现注入,或者抓包进行分析,也可以进行万能密码注入(这个较少),那么除此之外,我们还可以对目录结构进行分析,今天我们先介绍第一种绕过方法,修改状态码,协议头......

前端绕过的攻与防(上)

我们打开源代码进行分析

前端绕过的攻与防(上)

找到login.js文件

http://www.xxx.com/../script/login.js 这样去访问

前端绕过的攻与防(上)

找到代码处,可以分出这里的代码的判断

这里就是判断了如果等于200状态码页面,则对编码进行decodeURL解码处理,解码后储存在变量C中,然后提取包含?page的值,这里还是用了 substring 方法进行截取&params后面的部分,我们要测试的就是看看他的回显包是否真的可以绕过。

具体测试方法

输入任意密码,抓包

前端绕过的攻与防(上)
HTTP/1.1 401 Unauthorized401代表未鉴权

我们可以修改成200尝试

前端绕过的攻与防(上)

然后重放

前端绕过的攻与防(上)

再尝试把statusValue的值改成200

这样做的目的,就是状态码欺骗,看看数据怎么传的

我们来尝试

前端绕过的攻与防(上)

重放后发现

前端绕过的攻与防(上)

可以发现代码走到了这里,加载到了/doc/page/main.asp ,就跟我们之前分析过的代码是一样的。这里会正常加载cookie。

前端绕过的攻与防(上)

当我们访问功能的时候,依然是401,我们需要再次修改成200进行绕过,这样功能就可以正常使用了。

前端绕过的攻与防(上)

我们通过修改协议头,statusValue的值绕过了登录,进入了后台,不需要正确的密码。

漏洞利用成功,这种绕过方法在实际的攻击场景中,很常见,可以使用这种方法,看看具体数据的走向,达到绕过的目的

场景2-扩展页面

扩展其实也就是我们输入正常用户密码,登录成功后加载的一种扩展初始化页面,那么扩展可以理解为验证过后的页面。

而我们要利用就是直接访问扩展页面进行绕过,如果扩展页面加载了COOKIE,那可以不用登录就进入后台管理了。

前端绕过的攻与防(上)

后台页面是这样的,我们打开源代码分析

前端绕过的攻与防(上)

这里对登录分别做了不同的验证方法,其实正确就是1,其他都是各种错误,那我们测试的时候可以把返回包的itemjson参数改成1进行绕过。

前端绕过的攻与防(上)

这里,还有一个load加载函数,访问后为:

前端绕过的攻与防(上)

成功进入了后台,没登录,相当于这个页面就是扩展,加载了COOKIE造成的

那我们随便输入数据,来试试修改绕过

前端绕过的攻与防(上)

注意"Message信息,我们改成1,然后进行绕过

前端绕过的攻与防(上)

这里提示验证成功,然后会自动跳转

前端绕过的攻与防(上)

可以看到直接加载到这个页面,跟我们之前访问的是一样的

前端绕过的攻与防(上)

这两种方法,都是绕过的,所以这里存在两个漏洞

  1. 1. 通过修改message为1,可绕过到扩展页面
  2. 2. 通过直接访问扩展页面,可加载cookie进行绕过
免责声明:本文仅作安全交流,请勿用于其他目的,本文解释权归君立华域渗透测试研究中心所有。

场景3-回显包绕过

比较通用,这里通常包含token,Set-cookie绕过

首先说一下漏洞成因是在做数据处理的时候没有判断用户的token或者set-cookie的实际身份,直接以默认身份通过了验证,无需正确密码,直接以默认token绕过了实际的用户强校验即可进入后台,使用管理员全部功能

Set-cookie绕过

我们做测试的时候就是找一个可以登录的set-cookie回显包来尝试绕过

前端绕过的攻与防(上)
前端绕过的攻与防(上)

拿到了set-cookie信息

HTTP/1.1 200 OKConnection: closeX-Powered-By: PHP/4.4.9Set-Cookie: timestamp=-4; expires=Fri, 24 Jan 2025 09:04:24 GMT; path=/Set-Cookie: cooLogin=1; expires=Fri, 24 Jan 2025 09:04:24 GMT; path=/Set-Cookie: cooUser=admin; expires=Fri, 24 Jan 2025 09:04:24 GMT; path=/Content-type: text/htmlContent-Length: 12

注意包中Set-Cookie: cooUser=admin;和post值2

我们要做的就是,把这个回显包,进行同类系统的绕过,去测试其他的系统是否可以通过回显包绕过。

注意这里,2025 09:04:24 时间,如果有时间判断,则不能延期时间绕过,如果没判断时间,则可以直接绕过。

找到一个同类系统

前端绕过的攻与防(上)

随便输入密码,提示密码错误,这时候尝试绕过

前端绕过的攻与防(上)

回显包是1 将其改为 2

前端绕过的攻与防(上)
前端绕过的攻与防(上)

免责声明:本文仅作安全交流,请勿用于其他目的,本文解释权归君立华域渗透测试研究中心所有。

场景4-template模板绕过

本绕过是依赖于回显包绕过上的一种创新型绕过方法,目的是绕过被禁止函数,加载JS,模板等工功能,那么这个模板参数也会加载,那么我们在进入了A网站的登录口,目标却是B的同类系统,这个时候可以尝试A的模板参数进行绕过,即使是被禁止判断的函数也可以使用该方法绕过。

前端绕过的攻与防(上)

我们来尝试一个可以登录的回显包

HTTP/1.1 302 Moved TemporarilyServer: Mini web server 1.0 ZTE corp 2005.Accept-Ranges: bytesConnection: closeContent-Type: text/html; charset=utf-8Cache-Control: no-cache,no-storeContent-Length: 0Location: /start.ghtml

正常登录成功的回显是这样,加载模板,进行加载。

前端绕过的攻与防(上)

这里有个TOP布局,我们看看数据包,复制这一段,进行重放

前端绕过的攻与防(上)

前端绕过的攻与防(上)

可以看到有模板文件了

前端绕过的攻与防(上)
前端绕过的攻与防(上)

我们分别拿了一个top和template文件,再次重放就进入后台了。

那么接下来我们去测试一个同类系统,在不知道用户密码情况下,进行测试。

前端绕过的攻与防(上)

直接就没过验证

前端绕过的攻与防(上)

我们先来尝试使用

HTTP/1.1 302 Moved TemporarilyServer: Mini web server 1.0 ZTE corp 2005.Accept-Ranges: bytesConnection: closeContent-Type: text/html; charset=utf-8Cache-Control: no-cache,no-storeContent-Length: 0Location: /start.ghtml

进行绕过,让他跳转到start.ghtml页面,看看数据走向

前端绕过的攻与防(上)

重放

前端绕过的攻与防(上)

这个时候,他加载到了布局,我们看看回显包

前端绕过的攻与防(上)

可以看到模板这里的回显包,判断是这样的,这里有一个

logout_redirect()函数判断alert("Session timeout, please login again.");document.getElementById("flogout").submit();

这里就是没取到session的值,导致退出登录

前端绕过的攻与防(上)
前端绕过的攻与防(上)

接着会弹出窗口。

前端绕过的攻与防(上)

跳转到登录页面,说明绕过失败,那么这个时候我们怎么进行绕过呢,我们先来看看成功的模板代码,分析下这里:

前端绕过的攻与防(上)
前端绕过的攻与防(上)

关键判断就在这里,这里有一个获取token的操作function addToken2AllForms()

前端绕过的攻与防(上)

这里有一个强验证,相当于模板加载的的时候会获取用户的session token

前端绕过的攻与防(上)

这里分别做了函数的调用 ,让doAddLogic()函数生效

所以就为什么会出现logout_redirect()的判断就是因为有验证,那么实际测试的时候,可以把相关调用的函数去掉,不让他进行调用,然后进行传参,这也是一种绕过方法

另外一个就是利用模板加载进行绕过,我们把模板错误的加载换成成功的模板页面

前端绕过的攻与防(上)

在模板处进行替换

前端绕过的攻与防(上)

前端绕过的攻与防(上)

然后会加载到布局

前端绕过的攻与防(上)

这个时候进入了后台页面了,但是不要高兴太早,你需要去解决,addToken2AllForms的函数的验证,所以即便能成功,只是过了模板页面的绕过,还是需要进一步分析怎么能逃过函数的检查

这是需要去思考的,这里只提供一种模板绕过的思路。

场景5-302重定向+跳转绕过

这个漏洞是基于302重定向基础上加载了cookie,导致跳转到初始化页面的绕过,漏洞原因就是在重定向加载了cookie,初始化页面就是管理员页面

如果你直接请求初始化页面是绕不过去的,这个页面会判断COOKIE

但是你使用重定向302跳转+初始化页面则可以进行绕过后台

前端绕过的攻与防(上)

先来看看源代码

前端绕过的攻与防(上)

这里有传值自动登录的,可能有传输参数的风险点,这里还有一个正则区配,接着来其他的代码

前端绕过的攻与防(上)

这里分别就是变量了ID和PW,提取值,然后判断不等于null 值,然后调用了setcookie函数,完成登录

前端绕过的攻与防(上)

Setcookie代码在这里,传cookie的函数是基于NVSID的cookie

else hostaddr = temp; now=new Date(); now.setTime(now.getTime() + 1000 * 60 * 30);这里有一个cookie的过期时间设置nameValue=escape(document.login.cnname.value + "#N1"                 + document.login.cnpwd.value +"#N2"                 + hostaddr + "#N3"                 + "sz160sa120sb116sc0");

这里的代码就是提交表单的验证了,escape是对字符进行编码,并对字符串进行拼接处理

前端绕过的攻与防(上)

这里有参数页面,我们试试提交错误数据,然后拿到目录,搭配访问

前端绕过的攻与防(上)

可以看到不能访问,没有定义表单,那么我们先来看看正确的验证过程

前端绕过的攻与防(上)

注意这里,预览页面,那么可以理解为扩展了

我们先来进行一个正确的验证:

HTTP/1.0 302 RedirectServer: GoAhead-WebsDate: Fri Jan 24 18:21:28 2025Pragma: no-cacheCache-Control: no-cacheContent-Type: text/htmlLocation: http://www.xxx.com/content/advc.asp<html><head></head><body>        This document has moved to a new <a href="http://www.xxx.com/content/advc.asp">location</a>.        Please update your documents to reflect the new location.        </body></html>

正确是这样回显,那么我们先看一下错误的验证

HTTP/1.0 302 RedirectServer: GoAhead-WebsDate: Fri Jan 24 18:22:23 2025Pragma: no-cacheCache-Control: no-cacheContent-Type: text/htmlLocation: http://www.xxx.xcom/content/msg.asp?msg=5&time=3<html><head></head><body>        This document has moved to a new <a href="http://www.xxx.com/content/msg.asp?msg=5&time=3">location</a>.        Please update your documents to reflect the new location.        </body></html>

两者有什么变化HTML协议,注意href这里,content/msg.asp?msg=5&time=3",这里相当于错误提示而content/advc.asp就是正确的验证

那我们能不能直接访问直接content/advc.asp,绕过呢,我们来尝试。

前端绕过的攻与防(上)
前端绕过的攻与防(上)

加载到这里,本以为绕过去了

前端绕过的攻与防(上)
前端绕过的攻与防(上)

还是跳转到这里,content/msg.asp?msg=201&time=3

前端绕过的攻与防(上)
前端绕过的攻与防(上)

弹回登录页面了,这个时候还是没过验证

那么我们想一下,能否利用302重定向+跳转进行绕过呢

前端绕过的攻与防(上)

尝试修改location为content/advc.asp,然后进行跳转

前端绕过的攻与防(上)

这时候加载到这里,进行重放

前端绕过的攻与防(上)
前端绕过的攻与防(上)

这个时候没有跳转到登录页面了,漏洞利用成功了。

这个绕过说明,直接请求content/advc.asp会有cookie判断,如果利用重定向+跳转则可以绕过检查,在302重定向到初始化页面这里,没有做COOKIE判断了。

防御思路

既然知道了前端绕过攻击的原理和方法,那我们就要想办法防止这些攻击。以下是一些简单有效的防御措施:

前后端都要严格验证

不能只依赖前端验证,后端也必须认真检查。比如登录功能,前端可以检查输入格式,但后端一定要核对用户名和密码是否正确。只有前后端都验证通过,才允许用户登录。这样即使前端被绕过,后端也能挡住攻击。

管好Cookie和Token

Cookie和Token相当于用户的“通行证”,必须严格管理。设置合理的过期时间,避免被攻击者利用。传输时要用加密方式,防止被窃取。每次请求时,后端都要仔细核对Token是否真实有效,确保是合法用户在操作。

限制敏感页面的访问

后台管理页面和重要功能页面不能随便访问。系统要检查用户是否通过正常登录流程进入,比如检查会话状态或来源页面。如果发现用户试图直接访问敏感页面,应直接拒绝访问。

注意302重定向的安全性

302重定向时,目标页面要进行严格的权限验证。不能只依赖跳转逻辑,而要确保用户已经登录。这样可以防止攻击者通过伪造跳转逻辑绕过验证。

定期检查代码漏洞

代码里可能有漏洞,所以要定期检查。可以用自动化工具扫描,也可以人工审计代码。重点关注逻辑漏洞、SQL注入等问题。发现漏洞后,要及时修复,避免被攻击者利用。

部署Web应用防火墙(WAF)

WAF可以实时监控网络流量,识别并阻止异常请求,比如伪造状态码或篡改Cookie。部署WAF后,可以有效降低被攻击的风险。

我们介绍了几种基于前端绕过的方法,也是对绕过的思路分享,下一章节,我们介绍介绍其他的绕过方法。

免责声明:本文仅作安全交流,请勿用于其他目的,本文解释权归君立华域渗透测试研究中心所有。

原文始发于微信公众号(君立渗透测试研究中心):前端绕过的攻与防(上)

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年2月17日21:29:31
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   前端绕过的攻与防(上)http://cn-sec.com/archives/3752255.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息