Case Study

PenTesting WebApi

Penetration testing solutions for a company specializing in real estate data, insights, and solutions, catering to the entire real estate industry. The project involved the use of NodeJs and other related technologies, with AWS serving as the cloud infrastructure.

 

The client had a requirement to assess the security of their web application, ensuring the confidentiality, integrity, and availability of their customer’s data. The testing scope included the staging environment of the web application, Static Application Security Testing (SAST) of both the frontend and backend, as well as Dynamic Application Security Testing (DAST).

To conduct the penetration test, we followed the OWASP (Open Web Application Security Project) and OSSTMM (Open Source Security Testing Methodology Manual) methodologies. Our approach involved a combination of automated and manual techniques.

  1. Initially, we conducted a comprehensive review of the web application’s architecture, design, and functionality to identify potential vulnerabilities. 
  2. This was followed by the use of automated tools including vulnerability scanners, fuzzers, and web proxies to uncover additional vulnerabilities. 
  3. Our team also conducted manual testing to identify vulnerabilities that automated tools might miss, such as business logic flaws.
  4. During the reconnaissance phase, we used tools like Zaproxy spidering, Nmap, whatweb, wappalyzer, and dirb to identify API endpoints that were not protected by any API tokens, resulting in excessive data exposure. 
  5. Subsequently, we performed Authorization testing of various functionalities using the data obtained from the reconnaissance step. This uncovered broken object-level authorization, allowing unauthorized access to other users’ details, as well as broken function-level authorization, enabling the manipulation of other users’ data.
  6. Furthermore, we performed a vulnerability analysis based on the OWASP Top 10 2021, which revealed several vulnerabilities. These included missing security headers, hard-coded Google Maps API keys in the page source, the ability for users to register with nonexistent or disposable emails, the transmission of authentication credentials over an unencrypted channel, unexpected file uploads, weak password policies, CSRF (Cross-Site Request Forgery), clickjacking attacks, and HTTP parameter pollution.
  7. In addition, we conducted Whitebox testing of the frontend, identifying vulnerabilities such as hard-coded secrets in the source code and the use of vulnerable and outdated third-party components. 
  8. Similarly, in the backend, we discovered vulnerabilities including hard-coded secrets in the source code, the use of vulnerable and outdated third-party components, NoSQL injection, the usage of cryptographically weak random number generators, SSRF (Server-Side Request Forgery), and Reflected XSS (Cross-Site Scripting).

 

Recommendations:

 

  • Broken Authentication: Implement API tokens with expiry for all API endpoints. Secure user authentication, and only ensure trusted users are authenticated. 
  • Sensitive data exposure: Review all API responses and adapt them to match what the API consumers really need. Limit data exposure to only trusted parties who need it. Identify all the sensitive data or Personally Identifiable Information (PII), and justify its use.
  • Missing header:  Implement helmet npm package.
  • Vulnerable and outdated components: Update to the latest or non-vulnerable versions.
  • Hardcoded Google Maps API keys: Restrict API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them. Go to the Google API Console and generate a key, restricting it to URLs that you own (or want to put maps on) to prevent quota “theft”.
  • Authentication credentials transmitted over an unencrypted channel: Implement HSTS header and close port 80.
  • Unexpected file upload: Applications should be developed with mechanisms to only accept and manipulate “acceptable” files that the rest of the application functionality is ready to handle and expect. Some specific examples include: deny lists or allow lists of file extensions, using “Content-Type” from the header, or using a file type recognizer, all to only allow specified file types into the system.
  • CSRF: Implement CSRF token.
  • Click-Jacking: Implement X-frame-Options http header & Content-Security-Policy.
  • Hard-coded secrets in Front-end and Back-end source code:  Use secret managers.
  • No-SQL injection: Implement Input Validation, Sanitize inputs: Use NPM packages like perfect-express-sanitizer which will prevent injection attacks like SQLI, NOSQL Injection etc. Implement Web application firewall.
  • SSRF: Circumvent SSRF attacks by using Whitelistst, Response handling, Disable unused URL schemas, Authentication on internal services.
  • Cryptographically weak random number generators: Cryptographically strong pseudorandom number generators (CSPRNG) should be used instead.
  • Reflected XSS: Sanitize input – Use NPM packages like perfect-express-sanitizer which will prevent injection attacks like SQLI, NOSQL Injection etc., Implement Web application firewall.

 

Tools/Technologies:

 

  • Nmap
  • Nikto
  • Dirb
  • Wfuzz
  • Wappalyzer
  • Dnsrecon
  • Owasp Zaproxy
  • Nessus
  • Burp Suite
  • Sqlmap
  • W3af
  • Nosqlmap
  • Wireshark
  • Tcpdump
  • Sublist3r
  • Nodejsscan
  • Sonarqube
  • Semgrep
  • Owasp Dependency Check

 

Key Outcomes:

 

  • The client received a thorough analysis of the vulnerabilities present in their web applications through extensive black, gray, and white box penetration testing. They were also given practical instructions on how to address and fix these vulnerabilities.
  • Ensured the protection of data.
  • Enhanced security measures were implemented in their web application, thereby mitigating the potential for a security breach.

 

Deliverables:

Finally, we provided the client with a detailed report outlining all identified vulnerabilities, their impact, proof of concept, and recommendations for mitigating the risks associated with each vulnerability. The final report included the subtopics listed below.

 

  1. a) Executive Summary: A Summary of the Scope, Approach, Findings, and recommendations.
  2. b) Core Findings along with Risk Analysis: A view of the core findings along with screenshots.
  3. c) Detailed Findings: The observations are thoroughly examined and categorized as Critical or Non Critical. Furthermore, the risk associated with each observation is assessed and classified as Very High, High, Medium, or Low, depending on its potential impact.
  4. d) In-depth analysis of findings/Corrective Measures & Recommendations along with Risk Analysis
  5. e) Suggestions and Best Practices.