NodeJS应用程序身份验证绕过漏洞分析
本文主要针对的是我参加一个漏洞赏金计划的过程中发现的NodeJS应用程序身份验证绕过漏洞进行分析。我们将重点讲述我所使用的方法，以便在遇到类似的Web界面（仅提供单一登录表单）时可以利用这种方法来寻找漏洞。
方法论
如果大家曾经对大型网站（例如GM、Sony、Oath或Twitter）进行过漏洞挖掘，那么进行的第一项工作可能就是运行子域名发现工具，从而进入到初始侦查过程中。这样一来，我们就能获得潜在目标的列表，有时这一列表可能会达到数百个、数千个不同的主机。如果有人专注于网络应用程序的漏洞挖掘，可能会使用Aquatone这类工具，这类工具能够对常用端口上运行的Web服务进行扫描，同时列举出网站的响应标题，并打印出屏幕，最终提供一份HTML格式的报告。
但是，当我们查看报告时，会注意到，大多数情况下，这些Web服务器会呈现出“404 Not Found”、“401 Unauthorized”、“500 Internal Server Error”、默认Web界面或各种服务页面。其中，服务页面又包括VPN或网络设备登录页面、第三方软件、cPanels、WordPress登录页面等。我们可能无法直接获得Web应用程序的位置，这样就无法直接进入到寻找XSS或SQL注入漏洞的步骤。至少，到目前为止，我还没有这样的运气。
但有时，我们实际上可以找到一些看起来像自定义应用程序的界面，其中包含一些其他选项，例如注册或忘记密码。在这里，我们是可以进行一些操作的。遇到此类情况，我通常采用以下的处理方式：
1、首先要做的，就是检查页面的源代码，我们可以找到例如JavaScript或CSS这样的资源链接，并且能从中发现一些应用程序目录，例如/assets、/public、/scripts等。我们应该对这些目录进行检查，以发现其中是否存在可以利用的文件。
2、Wappalyzer（支持在所有流行浏览器上作为扩展使用）能够提供技术上的充分信息，包括Web服务器、服务器端使用的技术、JavaScript库等。这样一来，我们将掌握该页面的整体情况，并为进一步的测试选择正确的方法。在这里，如果应用程序是使用Ruby on Rails构建的，那么可以尝试使用针对JavaEE的RCE Payload。
3、如果发现任何JavaScript文件，我会执行一些静态分析，以确认是否有任何API终端暴露问题，以及是否存在任何客户端身份验证和用户输入验证逻辑。
4、在完成上述步骤并掌握一定信息后，我开始使用Burp Suite测试所有功能（包括登录、注册、忘记密码等）的实际逻辑，并拦截对服务器的请求。然后，我将请求发送到Repeater进行重放。具体而言，我们在application/json、application/xml和其他类型的位置更改Content-Type，使用多个Payload作为请求的主题，在不同的HTTP方法之间切换，或更改HTTP请求标头，并观察上述尝试是否能导致服务器端出现错误。如果应用程序存在任何漏洞，现在就是发现这些漏洞的最佳时机，我们需要认真观察每个响应，并且注意任何一点细小的变化。例如，我们使用PUT替换GET发出请求，标头是否出现缺少？如果我们发送一个格式错误的JSON，响应正文中是否会出现不寻常的字符？
5、最后，我运行wfuzz，尝试发现服务器上一些不需要的文件或文件夹。我自定义的“Starter Pack”字典中，包含一些Web服务器上常见的内容，例如.git或.svn这些源版本控制系统文件夹、JetBrain的.idea这类IDE目录、.DS_Store文件、配置文件、常见Web接口路径、管理员接口，以及Tomcat、JBoss、Sharepoint的特定文件或文件夹。这个字典中，共包含约45k的条目，我发现利用这一字典总能找到一些有趣的内容，可以帮助我进一步发现漏洞。
如果进行上述步骤后，没有任何发现，那么我认为这一应用程序的安全性较强，很可能没有漏洞能够绕过身份验证或进入应用程序。
在实际尝试中，通过分析认证的请求，我们得到了一些线索。实际上，这是一个简单的登录表单，但经过我们对HTTP响应标头进行分析并使用Wappalyzer进行扫描后，结果表明这是一个使用ExpressJS框架构建的NodeJS应用程序。我之前担任Web开发人员时，JavaScript是我最为常用的语言，并且我已经在寻找JavaScript相关的栈漏洞这一方面积累了充分的经验。因此，我决定深入挖掘这一漏洞，看看我能够做些什么。
漏洞发现
我们使用Payload，对侦查阶段发现的终端进行测试，在这里，找到了一个凭据错误的漏洞，该漏洞是在JSON的POST过程中包含用户名和密码：
POST /api/auth/login HTTP/1.1
Host: REDACTED
Connection: close
Content-Length: 48
Accept: application/json, text/plain, */*
Origin: REDACTED
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3558.0 Safari/537.36 DNT: 1
Content-Type: application/json;charset=UTF-8
Referer: REDACTED/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,pl-PL;q=0.8,pl;q=0.7
Cookie: REDACTED
{“username”:”bl4de”,”password”:”secretpassword”}
在本文的后续，我将省略HTTP标头，因为我们没有对标头进行任何更改。
在响应中，没有看到任何令人兴奋的内容，除了其中的一个细节：
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Vary: X-HTTP-Method-Override, Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
本文主要针对的是我参加一个漏洞赏金计划的过程中发现的NodeJS应用程序身份验证绕过漏洞进行分析。我们将重点讲述我所使用的方法，以便在遇到类似的Web界面（仅提供单一登录表单）时可以利用这种方法来寻找漏洞。
方法论
如果大家曾经对大型网站（例如GM、Sony、Oath或Twitter）进行过漏洞挖掘，那么进行的第一项工作可能就是运行子域名发现工具，从而进入到初始侦查过程中。这样一来，我们就能获得潜在目标的列表，有时这一列表可能会达到数百个、数千个不同的主机。如果有人专注于网络应用程序的漏洞挖掘，可能会使用Aquatone这类工具，这类工具能够对常用端口上运行的Web服务进行扫描，同时列举出网站的响应标题，并打印出屏幕，最终提供一份HTML格式的报告。
但是，当我们查看报告时，会注意到，大多数情况下，这些Web服务器会呈现出“404 Not Found”、“401 Unauthorized”、“500 Internal Server Error”、默认Web界面或各种服务页面。其中，服务页面又包括VPN或网络设备登录页面、第三方软件、cPanels、WordPress登录页面等。我们可能无法直接获得Web应用程序的位置，这样就无法直接进入到寻找XSS或SQL注入漏洞的步骤。至少，到目前为止，我还没有这样的运气。 本文来自无奈人生安全网
但有时，我们实际上可以找到一些看起来像自定义应用程序的界面，其中包含一些其他选项，例如注册或忘记密码。在这里，我们是可以进行一些操作的。遇到此类情况，我通常采用以下的处理方式：
1、首先要做的，就是检查页面的源代码，我们可以找到例如JavaScript或CSS这样的资源链接，并且能从中发现一些应用程序目录，例如/assets、/public、/scripts等。我们应该对这些目录进行检查，以发现其中是否存在可以利用的文件。
2、Wappalyzer（支持在所有流行浏览器上作为扩展使用）能够提供技术上的充分信息，包括Web服务器、服务器端使用的技术、JavaScript库等。这样一来，我们将掌握该页面的整体情况，并为进一步的测试选择正确的方法。在这里，如果应用程序是使用Ruby on Rails构建的，那么可以尝试使用针对JavaEE的RCE Payload。
3、如果发现任何JavaScript文件，我会执行一些静态分析，以确认是否有任何API终端暴露问题，以及是否存在任何客户端身份验证和用户输入验证逻辑。
4、在完成上述步骤并掌握一定信息后，我开始使用Burp Suite测试所有功能（包括登录、注册、忘记密码等）的实际逻辑，并拦截对服务器的请求。然后，我将请求发送到Repeater进行重放。具体而言，我们在application/json、application/xml和其他类型的位置更改Content-Type，使用多个Payload作为请求的主题，在不同的HTTP方法之间切换，或更改HTTP请求标头，并观察上述尝试是否能导致服务器端出现错误。如果应用程序存在任何漏洞，现在就是发现这些漏洞的最佳时机，我们需要认真观察每个响应，并且注意任何一点细小的变化。例如，我们使用PUT替换GET发出请求，标头是否出现缺少？如果我们发送一个格式错误的JSON，响应正文中是否会出现不寻常的字符？
无奈人生安全网
5、最后，我运行wfuzz，尝试发现服务器上一些不需要的文件或文件夹。我自定义的“Starter Pack”字典中，包含一些Web服务器上常见的内容，例如.git或.svn这些源版本控制系统文件夹、JetBrain的.idea这类IDE目录、.DS_Store文件、配置文件、常见Web接口路径、管理员接口，以及Tomcat、JBoss、Sharepoint的特定文件或文件夹。这个字典中，共包含约45k的条目，我发现利用这一字典总能找到一些有趣的内容，可以帮助我进一步发现漏洞。
如果进行上述步骤后，没有任何发现，那么我认为这一应用程序的安全性较强，很可能没有漏洞能够绕过身份验证或进入应用程序。
在实际尝试中，通过分析认证的请求，我们得到了一些线索。实际上，这是一个简单的登录表单，但经过我们对HTTP响应标头进行分析并使用Wappalyzer进行扫描后，结果表明这是一个使用ExpressJS框架构建的NodeJS应用程序。我之前担任Web开发人员时，JavaScript是我最为常用的语言，并且我已经在寻找JavaScript相关的栈漏洞这一方面积累了充分的经验。因此，我决定深入挖掘这一漏洞，看看我能够做些什么。 本文来自无奈人生安全网
漏洞发现
我们使用Payload，对侦查阶段发现的终端进行测试，在这里，找到了一个凭据错误的漏洞，该漏洞是在JSON的POST过程中包含用户名和密码：
POST /api/auth/login HTTP/1.1
Host: REDACTED
Connection: close
Content-Length: 48
Accept: application/json, text/plain, */*
Origin: REDACTED
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3558.0 Safari/537.36 DNT: 1
Content-Type: application/json;charset=UTF-8
Referer: REDACTED/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,pl-PL;q=0.8,pl;q=0.7
Cookie: REDACTED
{“username”:”bl4de”,”password”:”secretpassword”}
在本文的后续，我将省略HTTP标头，因为我们没有对标头进行任何更改。
在响应中，没有看到任何令人兴奋的内容，除了其中的一个细节：
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Vary: X-HTTP-Method-Override, Accept-Encoding
Access-Control-Allow-Origin: * 无奈人生安全网
Access-Control-Allow-Methods: GET