Penetration Testing 101

Penetration testing or security testing is an attempt to evaluate the security of an IT system by safely trying to exploit vulnerabilities. Usually, this kind of work is associated with penetration testers, whose job is to help organizations identify and resolve security vulnerabilities.

But why is this also relevant for developers?

There is a principle called "hack yourself first", which refers to how developers should build up their own cyber skills. In that way, they can proactively seek out security vulnerabilities in their own web applications and fix them before they are exploited by someone with bad intentions. This kind of mindset makes us more aware of risks when we are writing code and able to create more secure and robust systems.

Penetration testing can be split into two main categories: (web) application testing and infrastructure testing. In this article, we will mainly provide som tips on how to get started with (web) application penetration testing.

First, it's worth to mention that it is necessary to have some understanding of information security, networks and IT systems to be able to perform even the most basic security testing. Thus, the tools that we present in this article will (unfortunately) not magically make you a penetration tester. However, to have some tools in your toolbox is very useful and also sometimes necessary to help you along.

The good news is that you don't need access to advanced tools in order to perform basic penetration testing of your own application. The DevTools available in browsers have a lot of functionality that can help you get started, and we will show you some examples of how you can use it.

However, if you want to take it up a notch, a proxy tool like Burp Suite or OWASP ZAP can be very useful to intercept requests between the browser and server, and also to modify and replay them. In addition, Offensive Security Ltd maintains a selection of Kali Linux distributions designed for penetration testing, which contains a wide range of various tools. Some examples of useful tools are Nikto, Nmap, Dirb, SQLmap, etc.

So where do we start? A very good place to start is to familiarize yourself with the OWASP Top 10 Web Application Security Risks, which is a list of the most critical risks of web applications that should be minimized to increase the security. Then, you can start with the security testing. Here, we outline some of the basics on how to start.

In order to be able to identify vulnerabilities in your application, it is necessary to gain an overview over the application's functionality and identify possible entrypoints.

By scanning through the application, you can identify sites or subdirectories that should be hidden for specific users, or possibly discover information in the GUI or in the source code that should not be available. You can manually map out an application by using DevTools, for example by looking into the source code or the items available in storage (Local Storage Session Storage, Cache Storage Cookies, Tokens etc). Additionally, you can take a first glance at which network calls are performed in the Network tab.

Burp Suite and OWASP ZAP can also assist you with the mapping of the application, both with manual mapping or by providing you with tools to perform automatic spidering/crawling of your application or passive and active scans for known vulnerabilities.

Dirb is another useful tool for mapping out a web application. The tool is a Web Content Scanner and works by launching a dictionary based attack against a web server. By analyzing the responses we can identify available sites and files.

NB: Automatic functionality should be used with caution during testing. Be aware that spidering will request whatever is available and may requests links that can be dangerous. The same applies to automatic vulnerability scanning, as these tools manipulate request and inject parameters in order to simulate attacks to find known vulnerabilities. This can put the target application at risk.

The second step is to take a look at some of the functionality present in the application. Functionality where users can interact with the application are always interesting, for instance input fields. Are you able to trigger errors from the server by interacting with the input fields? These can be reflected either in the GUI or in the DevTools console and can leak information or even potential weaknesses in the application

Injection vulnerabilities are typical vulnerabilties that can be present where an application accepts user input. Injection attacks happens when an attacker sends invalid data to a web application with the intention to make it do something other than what the application was programmed to do.

Most likely, you have implemented some kind of validation and/or data sanitization in your application. If this is the case, it can be interesting to test whether it is possible to bypass this validation, either at the client side or the server side in order to perform injection attacks.

Beneath is an example that illustrates how SQL injection attacks works. The example is fetched from the "OWASP Juice Shop - Insecure Web Application for Training" learning platform:

By giving ' as input to the email field and any string for password, we provoke an error and by inspecting the network tab in DevTools we can see in the SQL statement that is used to log in a user.

Now we know the SQL query related to logging in, and we can try to manipulate this to always return true in order to bypass authentication. We see that by using ' OR TRUE -- as email input and any string as a password, the resulting statement will be:

"SELECT * FROM Users WHERE email = '' OR TRUE -- AND password = '1aabac6d068eef6a7bad3fdf50a05cc8' AND deletedAt IS NULL"

This will always return true, since

1. the ' will close the email input field
2. the OR TRUE returns the boolean value true
3. the -- comments out the rest of the SQL statement

We are now logged in and have bypassed the authentication. Additionally, since the statement logs in the first user in the database, we also have admin login.

This is of course a very simplified example, but it demonstrates the principles that SQL injection attacks exploits.

An application may also leak more information than intended. When fetching data from the backend, the response may contain further information than what is revealed in the user interface. One way to discover this is by inspecting the network tab in DevTools to see if you get access to more information either about the data structure or other information that can be used to brute force the endpoint. Additionally, by using tools such as Burp Suite, requests can easily be intercepted, modified (e.g change the id of the data object to be retrieved), and replayed to see if this alters the behavior of the application.

In the following example from OWASP Juice Shop we can intercept and modify a request with Burp Suite to view another users shopping basket.

By intercepting and modifying the GET /rest/basket/1 with another number (in this case 4) in the path, we can now see the content of user number 4's basket.

Again, this is a simple example, but there is a reason why broken access control and sensitive data exposure are mentioned on the top of OWASP's list of application security risks. By using available tools and similar techniques to modify requests for different resources in the web application you might be able to discover some security flaws that should be mitigated.

As developers, we often use third open source party packages or services in our applications. These can contain vulnerabilities we are not aware of.

Luckily there exists tools which scans and identifies common known vulnerabilities. As mentioned before, OWASP ZAP and Burp Suite are such tools, but there exist further commercial and open source alternatives covering applications and operative systems. OWASP has a list of examples of these here.

In this article, we have introduced basic penetration techniques and tools in order to test the security of a web application. As developers, we have gained some awareness of how flaws in our application can be exploited.

Want to learn more? Below we have listed some useful resources you can use to challenge yourself and improve your skills in penetration testing.

There are tons of training arenas and cheat sheets out there! OWASP Juice Shop is a good example of an insecure web application where you can find examples of and exploit OWASP top 10 vulnerabilities. Other resources include Vulnhub where you can download vulnerable VMs and Hack the Box.

• OWASP Top 10
• OWASP Testing Guide
• SQL injection cheat sheet by Portswigger
• Kali Linux tools documentation

Disclaimer: You should only perform penetration testing on applications and systems that you have permission to do so on. Always ensure that you have read the guidelines and rules for images or bug bounties before starting to test.