Seek and Destroy With Offensive Security — My First Web Penetration Testing

Sep 5, 2023 Luis Rodriguez Castro

In a world where data breaches and cyber attacks are becoming more frequent and sophisticated, the need for skilled professionals in the field of offensive security is higher than ever. Web penetration testing, a subset of offensive security, involves identifying and exploiting vulnerabilities in web applications to assess their security posture.

I am writing this article to share my experience of conducting my first web penetration testing project. I hope it will help those in this field understand what to expect, how to prepare, and how to improve their skills in web application security (AppSec) and penetration testing.

Background

When I first started working as an Application Security Engineer and got more experienced in web vulnerabilities like XSS, NoSQLi, Prototype Pollution, SSRF, CSRF, RCE, etc.. and built a scanning tool, my two Security and AppSec leaders Rune and Harrison requested a meeting with me to talk about an internal Web Pentesting project they needed to assign to me and also had to present to our CTO Cullen.

I was requested to perform an Internal Web Pentest and write a report that includes the

  • Introduction
  • Objectives
  • Scope
  • Assessment period/duration
  • Methodology
  • Vulnerabilities, also including the remediation for each finding.

I started performing the web pentest on April 4, 2022.

Experience

During the assessment, my leaders provided valuable feedback and encouraged me to improve my presentation, English speaking (as my main language is Spanish), and report-writing skills. Report writing, although tedious, is a crucial part of a penetration testing project, and one should become comfortable with it.

It is common to feel incapable of performing at a level you think you can’t in this field. This feeling is often a result of anxious overthinking. It is essential not to pay much attention to such pointless emotions.

Objectives

The objective of this web assessment is to be able to identify the following points:

  • Identify if a data exfiltration is possible
  • Help us identify if the internal web application has vulnerabilities
  • To make sure no sensitive information is leaked
  • Refactor code based on the report
  • Make sure customers cannot be targeted via our internal web tool

Web Penetration Testing

For this project, I had two weeks for completion, one week for assessment, and one week for reporting. Later in the Resources section, you will see the tools and articles that helped me with this project.

Enumeration

The first thing I did when starting the process was to enumerate the application. I got as much information as I could that could help me find ways to understand its attack surface. This information can include details about available services, user names, files, subdomains, endpoints, or any other information or patterns that might be useful to an attacker.

Assessment

I used two approaches for the assessment: a source code review (whitebox) and an external assessment (blackbox). These two, combined with debugging, helped me understand the application’s data flow better, allowing me to identify sinks or dangerous code that could be exploited. Sanitization and Filtering were also things I checked for during the assessment.

Definitions

Sink

A “sink” is a function or method that can potentially be a security risk if an attacker can control its input. These are especially important to be aware of in languages and environments like NodeJS, which is used for server-side scripting and is particularly vulnerable to attacks like remote code execution (RCE), SQL injection, or cross-site scripting (XSS)

Whitebox security testing

Also known as clear box, glass box, or structural testing, whitebox testing involves a detailed examination of the internal logic and structure of the code. Whitebox testing can identify hidden errors that may not be visible from the application’s interface.

Blackbox security testing

Also known as dynamic or behavioral testing, blackbox testing involves testing the application’s functionality without knowing its internal workings or source code. Blackbox testing can be conducted without any knowledge of the application’s code or architecture, and it can identify vulnerabilities that may not be apparent from a static analysis of the code.

Sanitization

Sanitization is cleaning and validating user input to ensure that it does not contain malicious code or data. This might involve removing or escaping special characters, stripping out HTML tags, or converting the input to a safe format.

Filtering

Filtering is the process of restricting user input to a specific set of allowed values or characters. This might involve checking the input against a whitelist of allowed values or using a regular expression to ensure the input conforms to a specific format.

As our application is mainly a NodeJS / JavaScript application, here is a list of some common Node.js sinks that should be aware of for security testing:

  1. Remote Code Execution (RCE)
    • eval(): Evaluates JavaScript code represented as a string.
    • Function(): Constructor creates a new function instance.
    • setTimeout(): Executes a function or an evaluated expression after a specified number of milliseconds.
    • setInterval(): Executes a function or an evaluated expression repeatedly, with a specified delay between each call.
    • exec(): A method from the child_process module that spawns a shell and runs a command.
  2. Command Injection
    • exec(): A method from the child_process module.
    • execFile(): A method from the child_process module.
    • spawn(): A method from the child_process module.
  3. SQL Injection
    • Any method that interacts with a database (e.g., using libraries like mysql, mongoose, sequelize, etc.), especially when user input is involved.
  4. Path Traversal
    • fs.readFile(): A method from the fs module that reads the content of a file.
    • fs.readdir(): A method from the fs module that reads the contents of a directory.
    • fs.writeFile(): A method from the fs module that writes data to a file.
  5. Cross-Site Scripting (XSS)
    • res.send(): A method from the express module that sends a HTTP response.
    • res.json(): A method from the express module that sends a JSON response.
  6. Denial of Service (DoS)
    • Buffer(): Constructor creates a new buffer instance.
    • Any method that reads from the filesystem or the network.
  7. Server-Side Request Forgery (SSRF)
    • Any method that makes HTTP requests to other servers (e.g., using libraries like axios, request, fetch, etc.), especially when user input is involved.

Reporting

While performing the web penetration test, I simultaneously documented what was tested: the vulnerabilities found, their severity, and potential impact. A good report will not only list the vulnerabilities but also provide recommendations on how to fix them. This helps in understanding the current security posture of the application. Detailed reporting can be a requirement for legal or compliance reasons. Different stakeholders (e.g., management, developers, security team, auditors, and clients) may need to be informed about the penetration test results. As an AppSec Engineer, I am responsible for providing as much information as possible so developers have an easier time remediating the vulnerabilities.

During this phase of the assessment, This is the order of the structure I used for the reporting:

# Table of Contents

1. [Introduction](#introduction)

2. [Objectives](#objectives)

3. [Scopes](#scopes)

4. [Test Period and Duration](#test-period-and-duration)

5. [Penetration Test Methodologies](#penetration-test-methodologies)

6. [Assessment](#assessment)

## Introduction

(Content of the Introduction section)

## Objectives

(Content of the Objectives section)

## Scopes

(Content of the Scopes section)

## Test Period and Duration

(Content of the Test Period and Duration section)

## Penetration Test Methodologies

(Content of the Penetration Test Methodologies section)

## Assessment

(Content of the Assessment section, including remediation after the vulnerability description and explanation)

Conclusion

In conclusion, my first web penetration testing project was an eye-opening experience. Not only did it enhance my technical skills, but it also improved my report-writing and communication skills. Remember that being thorough and detailed in your testing and reporting is crucial for the security of the application and the organization. Also, do not be too hard on yourself; it is normal to feel overwhelmed, but with practice and determination, you will get better.

Recommendations

For those starting in web penetration testing, I would recommend the following:

  • Learn the basics: Understanding the fundamentals of web technologies, programming languages, and security concepts is crucial.
  • Practice: Use platforms like Hack The Box, CTF challenges, Portswigger Academy, Pentesterlabs, and other online resources to practice your skills.
  • Seek feedback: Don’t be afraid to ask for feedback from your colleagues or the online community.
  • Stay updated: The world of cybersecurity is always evolving, so it is essential to stay updated with the latest trends, tools, and vulnerabilities.
  • Report writing: Don’t underestimate the importance of report writing. It is not only essential for communicating your findings but also for legal and compliance reasons.

Resources

Below are some useful resources:

Acknowledgments

I want to thank my leaders, Rune and Harrison, for their guidance and feedback throughout this project. Remember, the journey into offensive security can be challenging, but it is incredibly rewarding and essential for the security of the digital world. Good luck on your journey!

Luis Rodriguez Castro

Luis is an Application Security Engineer at FloQast who is a web security enthusiast, enjoys eating Korean and Japanese food, and also likes practicing Muay Thai and online gaming.



Back to Blog