This article explains how to perform white-box penetration testing on a Python web application running in a Docker container. In this white-box pentest, we will go through how to debug Python in VS Code in order to track our payloads throughout the process, and understand how security filters can hide vulnerabilities in plain sight.

Improve future black-box testing with code analysis

Visual Studio Code aka VS Code (or your preferred IDE)

, you can install the Python debugger extension from the extension tab on the left-hand side. Simply search for "Python debugger" and install it:

Our project will use the following file structure:

Certain files are extra-important when debugging Python, and must be added or modified. The files below contain the final file content:

This is the vulnerable Python web application that we will run in a dockerised environment.

In our supervisord.conf file the only thing we need to modify is the 

python -m debugpy --listen 0.0.0.0:5678 --wait-for-client /app/6-ssti-classic.py

 to make sure our debugger listener starts once our Docker container boots up.

This will be the configuration used to tell Visual Studio Code how to connect to the Python Debugger running in a Docker container.

As well as building the Docker image, the Dockerfile installs and activates our Python debugger inside the Docker container.

To this file we will add a network called debug-net. We will then add a static IPv4 address to our Python web application: 172.20.0.111. Finally, we will open Python's debugger port: 5678.

This setup allows us to more effectively connect and communicate with the Python debugger running in the Docker container.

To validate that our setup is working properly, we need to start our Docker container, connect to Python Debugger, set up breakpoints in Visual Studio Code and, finally, perform a request to the web application to see if the debugger stops at these breakpoints.

Usually, you want to start this command in the background (using the argument 

), but if you’re unfamiliar with Docker, I recommend running the command as it appears above so that you can see the logs. Once the Docker container has finished the build process and starts, we notice this message from our Python debugger:

This message shows that our Docker started successfully and that Python’s debugger is now listening for a connection and primed to start debugging Python.

Now let's set up some breakpoints inside the Python web application code located in Visual Studio Code!

We can set up breakpoints by clicking on the red dot that appears when you hover over the line number.

Inside VS Code, go to the debugger section on the left-side panel (shortcut: 

). Once inside the debug section, press the green arrow icon located at the top (

With the debugger in Visual Studio Code is up and running and connected to Python's debugger, you should now see in the terminal that the Python web application is running.

Now our debugger is connected, it's time to perform a HTTP request to trigger the Visual Studio Code breakpoints. We can use the command line interface (CLI) tool cURL to send a GET request to our web application:

If everything goes as expected, you should not get a response back directly. Instead you should have some code highlighted inside VS Code that proves the debugger is working and that it stopped at the first breakpoint:

Now we know our setup and debugger are working as expected, it's time for the bug hunt.

As you may have already noticed, our web application is vulnerable to a server-side template injection (SSTI) vulnerability. Let’s try an SSTI payload: 

Next we analyse the request we sent containing our payload in the 

 GET parameter. In Visual Studio Code, we can see a breakpoint hit:

We then click the blue, triangular arrow at the top (the first arrow from left to right):

Take a close look at the debug side panel to the left: our payload, which was included in the GET parameter 

 Python variable. But you might also notice that the payload has been HTML-escaped – so in theory, if the web application is vulnerable to a SSTI, we should get an error.

Let's move to our next breakpoint to see what final input is given to the template engine:

, is HTML-escaped by the Python function 

And as predicted, we got a 500 server error in our HTTP response!

To confirm that the vulnerability now exists, we can use the payload 

 and see how Python reacts this time using VS Code's debugger:

Looking at our debugger result, we can see that everything looks good!

 appearing in the HTTP response from our vulnerable web application!

Now that we understand how our payload is being escaped and inserted, we can adapt the payload to exploit the web application and achieve a remote code execution (RCE)!

Because our payload is HTML-escaped before it is inserted into the template string, we cannot take advantage of quotes. And without being able to write the command as a pure string, it will be more challenging to provide a system command. Luckily, we have a solution: Read ‘

Limitations are just an illusion: Advanced server-side template exploitation with RCE everywhere

’ to learn how to achieve RCE without using quotation marks in your payload.

, which converts a hex decimal value to its string character and use this to generate a string. As an example, we can generate the 

Then we can use this string as our argument in Python's 

 function, which will execute our system command and give us RCE:

This results in a successful remote code execution on our web application!

Below are three common Python weaknesses associated with the Python programming language.

: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Although prototype pollution vulnerabilities mainly affect the JavaScript programming language, Python can contain flaws that fall into this category, namely 

: Improper Neutralisation of Special Elements Used in a Template Engine

While this vulnerability is not specifically related to Python, it is important to note that most Python template engines are very powerful. Since they typically provide the ability to run pure Python code within the template engine, there’s a particularly significant risk of high-impact vulnerabilities.

Any programming language can be vulnerable to this CWE. With Python, absolute path traversal can arise when developers use 

 insecurely. This function is often used when joining paths and filenames, but many developers don’t realise that if 

 contains a filename with a front-slash prefix such as 

, it may have unexpected and unwanted results.

As we hoped, our SSTI payload generated a HTTP response containing a 500 server error. By using the debugger, we discovered that the payload failed not because of an error in the payload itself, but because the server HTML-escaped the payload, rendering it invalid.

As a takeaway for future black-box testing, it’s worth testing out multiple payloads with various tweaks when trying to detect the same vulnerability. Deploying a wide variety of payloads is a great way of detecting possible changes from the back-end server and to avoid false negatives.

Debugging your target’s source code helps you to track executed code triggered by the client (attacker). The process we’ve detailed can optimise your testing flow and surface behaviours that help you identify how user input is being handled.

If the server HTML encodes your SSTI payload and makes it invalid in the execution process, it is important to understand how this will affect your future exploitation of the vulnerability. To this end, practising debugging and code analysis on vulnerable targets will teach you how different filters are used and how various programming languages implement protection mechanisms.

White-box penetration testing: Debugging for Python vulnerabilities

This article explains some novel techniques for exploiting 

 (SSTIs) with complex, unique payloads that leverage default methods and syntax from various 

. Even better, we will show how to do so without needing any quotation marks or extra plugins within the templates. All server-side template injection payloads detailed below can achieve 

By default, many template engines have auto-escape enabled or perform HTML escape before the template rendering process. This sometimes makes our exploitation scenario much more difficult because of quote filtering used to render string-based data. Without string-based data in some form, RCE is significantly harder to achieve for some template engines, 

 being a notable example. For others, however, exploitation remains relatively simple even without the use of quotation marks. Our 

 exploit was simplified, for instance, by the availability of the 

The goal of our research was simple: to create payloads for some of the most popular template engines with the impact being an RCE. The payloads should not rely on any resources, such as HTTP parameters, outside of the payload itself. Achieving this would ensure the payload works in as many exploitation scenarios as possible.

Our research attempted to achieve a payload in relation to our goal on the following template engines:

As we said before, all payloads use only the default functions and methods from the template engine and don’t take advantage of any quotes or resources available outside the template engine itself, such as parameters in the HTTP request. Despite these limitations, all payloads  can be used to achieved a RCE on an application vulnerable to a server-side template injection.

, the default template engine used within Flask, is very powerful since it makes it possible to write and execute pure Python code.

To write a simple string, we can write this payload (note: index values may vary):

, which contains all global variables accessible to that function. This is then converted to a string with the help of the 

 method. To build our string, we take advantage of index positions 1786 and 1788 from the converted 

 string, which finally returns the string: id.

We can now leverage this technique to build a payload that performs a remote code execution and runs system command 

A similar payload structure can be used to exploit one of the 

 that used Jinja2 as it's template engine and filtered out all quotation marks.

 is another template engine compatible with Python and is used by default by Python frameworks Pyramid and Pylons.

In Mako, a payload such as the one below will generate the string 

We can then use this crafted string within Python’s 

Although you could also use a payload like the one below, it requires the use of "less-than" (

) characters – putting it outside the scope of our research objective:

, the PHP template engine, was one of the most challenging template engines to find a working payload for. The biggest challenge of all was making a string from its built-in and default configurations. 

Fortunately, I managed to craft a payload by leveraging the 

 variable. Finally, I nested them together, which resulted in a successful payload:

I also discovered an interesting payload that takes advantage of the built-in 

This payload allows you to achieve RCE if a

 template engine has performed a double rendering process

 function to generate a string based on the Hexadecimal value. We then use the variable modifier 

 to concatenate our other generated chars and complete the string. The resulting string 

Similar to Twig, we can use the function 

 to execute our generated string and achieve RCE:

 is the default template engine for the Laravel framework. We can use the 

 function to convert hexadecimal values to characters, insert the characters into an array map, and use 

 to join all generated characters into a string.

Combined with the string generated from our previous payload, we can use 

 command, which results in remote code execution:

 is a Java-based template engine mainly used in the Grails framework. It’s a powerful engine. In Groovy, you can craft a string using either of the following methods:

 function to run the resulting string-based command as a system command:

If you prefer the payload to have no spaces, you can always use a multi comment (

 is a popular template engine used in Java-based applications and is supported by a variety of frameworks, including Spring and Apache struts.

Our efforts to generate a suitable string in FreeMarker led to the discovery of a pretty neat function: 

. This function converts int based values into a string – but not in the way you might expect from functions such as 

, etc. This is the same logic that you can see in column labels in spreadsheet applications (like Excel or Calc). The lowest allowed number is 

. There's no upper limit. If the number is 

 or less or it isn't an integer number then the template processing will be aborted with error.

So if you wanted a string that represents the letter "

", meanwhile, can be generated with the payload:

By using this method, you can build a string that can be used to create a payload such as the following, with the impact being RCE:

 is a powerful template engine that can run pure 

 code. The ability to generate a string by taking full advantage of the 

 programming language opens up a wide range of payload possibilities.

For instance, the following payload generates the string 

If you then want to run this command as a system command, you can use 

Achieving RCE in various popular template engines in this manner – with unique payloads that use only built-in methods/functions – shows just how much you can do with a program even when limited to using minimal resources.

There are still plenty of template engines that I personally have yet to investigate. For anyone interested in building on my research, I believe there are payloads following the same structure that could also achieve RCE in the template engines not covered here. I would say that is a good way to start.

 made by Hackmanit! They made the payload testing a lot easier!

Finally, I would like to thank the guys at SCH Tech for their research: 

Limitations are just an illusion - advanced server-side template exploitation with RCE everywhere

Having access to your target’s source code is obviously an invaluable advantage of white-box penetration testing.

This article will help you leverage that benefit in the context of PHP applications and using the Xdebug PHP debugger.

Specifically, you will learn how to set up a PHP web application within a docker environment; how to set up 

; how to detect PHP vulnerabilities using Xdebug; common PHP vulnerabilities; and how to leverage your white-box pentest findings to enhance future black-box testing.

Follow these steps to not only unearth vulnerabilities during white-box engagements, but to also craft custom payloads you can unleash to great effect in future black-box tests.

CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

CWE-624: Executable Regular Expression Error

CWE-434: Unrestricted Upload of File with Dangerous Type

Visual Studio Code (VS Code) (or your preferred IDE)

Once you have installed Visual Studio Code, you can install the Xdebug extension from the extension tab on the left-hand side. Simply search for "

For our demonstration, we will use a vulnerable PHP code snippet from YesWeHack’s 

 Github repository (which also contains snippets written in a variety of other programming languages).

If you are completely new to using Xdebug, we recommend using the same snippet: 

. Otherwise, feel free to take a different code snippet that better suits your preferences.

Our project will use the following file structure: 

Certain files are extra-important and must be added or modified, including:

This will be the Xdebug listener configuration that is used inside Visual Studio Code on our host system.

This file contains the configurations for our vulnerable web application, which is running inside a docker container.

As well as building the docker image, the Dockerfile installs and activates PHP Xdebug inside the docker container.

To this file we will add our host’s hostname to enable our docker container to communicate with Xdebug, which will be hosted by our host system in Visual Studio Code.

 folder provided, we will create a new file in 

, we will add the code below immediately under the first line (which is: 

). This will allow us to install and enable Xdebug in our vulnerable docker container.

 file will be used to set up services for the docker container to run and make the PHP web application accessible via port 

 parameter and the value we give it is used to enable the docker container to communicate with our host system, where the Xdebug listener is running in our Visual Studio Code IDE.

Take note that we added two final lines to the 

Now our setup is ready, we can start debugging our vulnerable web application.

To make sure our debugger works, we will open Visual Studio Code on our host system and set a couple of breakpoints in the vulnerable code snippet. You can do this by simply clicking on the left side of the line number identifiers. This will make red dots appear, as you can see in the image below. This red dot represents a breakpoint that our debugger will stop at.

When a HTTP request is sent by a client to the vulnerable web application, our debugger will stop at our first breakpoint (

) and display all necessary debugging information.

We can trigger the Xdebug listener in Visual Studio Code by sending a HTTP request to our vulnerable web application with curl:

If you want to debug a HTTP request in Visual Studio Code, make sure you include the cookie 

 before you send it. This tells our Xdebug listener to start debugging. It will stop debugging at the first breakpoint, which is triggered by our HTTP request.

Xdebug is a great tool to use both for development and white box penetration testing. By providing a detailed overview of debugging results generated from each code section encountered, this utility means you, as a penetration tester, can more easily see where your input is used and how the payload is modified.

By using our previously described setup (see ‘

’), we can now start analysing our vulnerable code.

Let’s start by sending another HTTP request with curl, this time with a simple SQL injection payload (

After sending this HTTP request we can see that it hit our source code and, in the left sidebar, that our 

 parameter’s value has been determined by our payload.

Next, by pressing the curved blue arrow (second blue icon from the left) in the debug bar (on the top-left of Visual Studio Code by default), we will jump to the second breakpoint we set in the source code.

Continue pressing the arrow until you reach line 

 as shown in the image below. Then right click on the 

Once added to the Watch section, these two variables will appear at the bottom left under the debug sidebar.

We are now monitoring these two variables because 

 is the character to be escaped. If our payload contains the value presented in the variable 

, a backslash will be added before all characters within the payload (this backslash is the 

Continue pressing the blue debug arrow until the 

). This indicates that this character should be escaped in the next loop, and our payload should be modified by the filter.

Press the blue debug arrow again and you will see that our payload was modified by the filter, as shown in the image below:

 character, which it just used to escape our single quote (

) character. This means that, for the next loop, it should escape the backslash character in our payload.

As you can see below, this is exactly what happens. The backslash character 

 replace the backslash character that was previously used to escape our single quote. This makes our current backslash escape itself in the payload, leaving the single quote character unescaped.

By pressing the blue debug arrow one more time, we can see that we have jumped outside the filter and that our final payload remains as:

Finally, we stop the debugging process by pressing the red square in the debug field. We can then see that our curl contains the results from the 

Below are three of the most common weaknesses associated with the PHP programming language.

Source: https://cwe.mitre.org/data/definitions/98.html

The application uses input data that can be controlled by the user. This input value is then later used within an include, require or similar function. 

An attacker can exploit this by creating a specific value that dupes the application into including an unintended file, which can then be used to obtain arbitrary file reads or, in most cases, a remote code execution (RCE). This vulnerability is mainly known as Local/Remote File Inclusion.

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

Writing an effective Bug Bounty report is not as easy as it might seem if you haven’t written one before.

Getting it right is crucial for proving the validity and severity of a vulnerability and getting paid promptly and fairly for your discovery.

As with the severity score, well-written bug reports will earn points that propel you up the leaderboard and unlock lucrative new hacking opportunities.

Whether your bug is low, moderate or critical severity, the following best practices for vulnerability disclosure can build trust with security teams and earn invitations to private Bug Bounty programs.

Before you report a vulnerability, you should first evaluate whether it is valid under the rules of the Bug Bounty Program. Do this by answering the following questions:

 As a bug hunter, you must respect the program rules and only hunt on perimeters authorised as within scope.

Does your bug fall within the program’s list of qualifying vulnerabilities? 

A non-qualifying vulnerability risks the report being rejected and closed in RTFS (

Does the bug have any potential security impact?

 As a general rule, validation requires some direct security impact (unless the program policy says otherwise).

The impact of a vulnerability directly influences the severity of your findings and, subsequently, the reward you might receive. Demonstrate impact by:

: Assess what data could be compromised or which functionality could be abused and to what effect. For example, could the vulnerability lead to unauthorised access to sensitive information or lead to financial losses? What is a realistic worse-case scenario?

: Provide a realistic attack scenario that demonstrates how an attacker could exploit the vulnerability. This helps the program’s security team grasp the practical implications of the security flaw.

This SQL injection vulnerability could allow attackers to retrieve the entire user database, including sensitive customer information such as passwords and credit card numbers.

Write a behaviour analysis that explains how you identified the vulnerability by inducing the application or system into behaving abnormally. For instance:

: Understand how the application or system is 

 to function based on documentation, use cases and legitimate user interactions

: Show deviations from expected behaviour that are indicative of a vulnerability, such as unexpected error messages, undocumented features or inconsistent application responses to user inputs.

During the analysis, it was observed that submitting a specially crafted payload in the user login form caused an unusual delay in the application response. This behaviour is indicative of a time-based SQL injection vulnerability, as the application's response time varied significantly with different payloads, suggesting it was executing unauthorised SQL commands.

A report can be divided into the following sections:

 related to the vulnerability. This gives the reader a broad understanding of the vulnerability you discovered.

A description of the process of how you discovered the vulnerability.

Learn Bug Bounty

White-box penetration testing: Debugging for Python vulnerabilities

Limitations are just an illusion - advanced server-side template exploitation with RCE everywhere

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

How to write an effective Bug Bounty report

Smart Automation With Burp Suite

PimpMyBurp #10: Hackvertor – unleashing the power of Burp Suite

How to write an effective Bug Bounty report

Firefly v1.1.0: A smart black-box fuzzer for testing web applications

PimpMyBurp #9 – Use BCheck to improve vulnerability scanning

Web Application Black-Box Testing

Firefly v1.1.0: A smart black-box fuzzer for testing web applications

PimpMyBurp #8 – Perform Advanced Fuzzing With Turbo Intruder

Server side prototype pollution, how to detect and exploit

Firefly: a smart black-box fuzzer for web applications testing

PimpMyBurp #8 – Perform Advanced Fuzzing With Turbo Intruder

Produits

Chercheurs

Ressources

A propos

Suivez-nous