信息收集之js文件

简介

  JavaScript已经成为现代Web浏览器开发中最普遍的技术之一。之前在《PTES-信息收集》中讲到源代码审计也可能获取到一些敏感信息,但有的测试人员只审计html源代码,而忽略审计js文件里的源代码,今天我们就来讲一讲审计js文件都能获取到哪些信息。

详解

  通过审计js文件源代码能获取到的信息,我个人将其分为以下四类:敏感信息、业务逻辑、加密算法、Ajax请求。

敏感信息

  审计js文件最直观的就是很有可能获取到账号密码、配置等敏感信息。

  HTML定义页面结构,CSS定义装修样式,而JavaScript定义前端工作内容,主要是监听事件执行动作,比如逻辑判断,亦或是向服务器发送请求等等。而要正确执行这些动作,通常都会进行一些简单的配置。

  最常见的配置就是设置网站根路径,不过也经常遇到直接在js文件里配置账号密码的情况;更有甚者,有的开发人员直接在js文件里定义SQL语句,然后由前端发送到服务器执行。这不仅泄露了数据库信息,也提高了SQL注入漏洞攻击的风险。

  以上是获取敏感信息的一种情况,还有一种情况就是注释。

  为了更好的维护代码、调试代码,我们经常在源码中见到各种注释。比如为了方便调试,直接把账号密码写在Javascript代码中,调试完后,只是把这条语句注释掉而非删掉;有时候系统更迭,推出一些新的接口,开发人员把老接口注释掉使用新的接口,但服务器端并没有把老接口关掉等等。

  以上情况不仅让我们搜集到了更多目标信息,也增加了系统攻击面,只能说:这些开发人员真他娘的是个人才。

业务逻辑

  除了能获取到敏感信息,审计js文件还可以获取到Web系统的一些业务逻辑。

  说到业务逻辑,就要牵扯到前端校验。有些系统只做了前端校验,只要响应包满足条件,就会执行下一步操作,服务器端不会再进一步检验接下来的请求是否有问题,我们只要修改响应包就可以绕过检测。

  比如输入错误的账号密码,响应false,要求重新输入账号密码;我们把响应包拦截,把false改成true,前端检测到true,认为账号密码正确,发送跳转到系统内部的请求,而服务器没有再校验请求是否有问题,将系统内部页面响应给前端。

  要绕过前端校验,像0/1、true/false这种很容易就能猜到该怎么修改,但有些系统可能有十多个响应码,或者响应码有多位,如果我们耐着性子一个一个去试,时间成本会很大。

  比如0是用户名错误,1是密码错误,2是验证码错误,9999是登陆成功,如果我们从0开始,一个一个去试,说真的还不一定能试出来。除非先输入正确的账号密码得到正确的响应码,然后输入错误的账号密码,再用之前得到的正确响应码替换错误的响应码,尝试看是否存在前端校验的问题。

  问题是:如果是安全服务,客户还有可能提供账号密码,但攻防演练、挖洞一般都是靠自己白手起家,哪里有什么账号密码给你。而前端业务逻辑通常都由js实现,基本都可以通过代码审计来确定如何构造响应包来尝试绕过前端校验。我只想说:信息收集真的很重要。

加密算法

  审计代码能获取到的第三类信息就是加密算法。在当今的大环境下,企业越来越重视安全,运用了各种防护手段来提高系统的安全系数,提高攻击者的攻击成本,其中就有加密机制。

  可能很多测试人员在测试的时候,抓包发现参数值都是加密的,就这么放过了。但这种前端加密都是可以在js中找到加密算法的,要么在html文件的js中,要么包含在js文件中。

  当然我们也可以不需要知道加密算法到底是怎么样的,直接输入测试的明文Payload,系统自然会利用加密算法输出对应的加密数据。这个Payload不行,我们再输入下一个明文Payload去测试。

  以上的方式时间成本会增加很多,而且有时候系统会先检测输入的数据是否含有非法字符,没有非法字符才会加密发送到服务器端。而只要我们找到了对应的加密算法,就可以手工构造或者编写脚本批量生成我们想要的加密数据,进而去测试系统是否存在漏洞。

  据目前工作经历来看,涉及到加密的参数,存在漏洞的几率要高很多。因为前端加密后,后端必须解密才能使用。但很多时候,系统的安全检测只在请求传过来的时候,加密时没有检测到非法字符就绕过了检测,后端解密之后就可以肆意横行。

Ajax请求

  审计js文件能获取到的信息还有Ajax请求,也是漏洞重灾区。而Ajax请求的调用通常很隐蔽,且Ajax请求的触发条件无规律,很容易被遗漏或忽略。

  Ajax请求通常是被各个事件触发调用,而这些事件的触发往往需要满足一定条件。但很多时候,即便事件触发条件未满足,我们去构造Ajax请求的数据包发送给服务器端,依然可以得到服务器的响应。

  服务器访问控制不当,并没有去检测用户是否是通过正常业务逻辑发送Ajax请求,也没有去检测用户是否有操作权限。服务器认为客户端发过来的请求都是正确的,这又要提一下安全的本质:一切输入都是不安全的。而且每一个Ajax请求都对应一个接口,这又增加了攻击面,每个请求都可能形成独立的攻击过程。

  举个真实案例:修改密码,先要通过短信验证码校验才能修改新密码。只有管理员才能修改密码,修改密码的Ajax请求由修改密码功能调用,普通用户没有这个功能。(某些原因,没有截图,意淫一下吧)

  开发人员认为所有的用户都会按照系统业务逻辑一步一步触发请求,先点击发送验证码,然后填写验证码进行校验,通过校验后跳转到修改密码的页面,输入新密码,最后修改成功。而且只有管理员有这个功能页面。

  但通过代码审计,直接在js文件中找到了修改密码的Ajax请求,请求参数只有新密码。现在我们已经找到了修改密码的请求,那么我们可以跳过前面一系列的校验和请求,只需要构造出修改密码请求,就可以修改密码。

  而且这个Ajax请求是写在js文件里的,系统并不会因为用户权限的不同而调用不同的js文件,所以普通用户也能够查到到对应的js代码,不存在管理员一说。

总结

  本文简单讲述了审计js文件源代码能获取到的四类信息:敏感信息、业务逻辑、加密算法、Ajax请求。

  当然,这也仅仅是我个人的归类,审计代码能获取到的信息远不止这些,需要大家去深入挖掘,我纯碎起一个抛砖引玉的作用。

  忙里偷闲,差不多半年才写了一篇文章。这波行动差不多要结束了,接下来就是国庆重保。国庆重保后不出意外的话应该,可能,也许会稍微轻松一点,争取一个月能写篇文章吧。感谢大家的关注!

免责声明

  安全小白团是帮助用户了解信息安全技术、安全漏洞相关信息的微信公众号。安全小白团提供的程序(方法)可能带有攻击性,仅供安全研究与教学之用,用户将其信息做其他用途,由用户承担全部法律及连带责任,安全小白团不承担任何法律及连带责任。

0%