Get Started with Web Application Penetration Testing

This blog post covers some important topics about being a web penetration tester, such as:

• Fundamental concepts
• Methodology
• Common web vulnerabilities
• Helpful study materials

As it’s not a comprehensive article, it doesn’t dive too deep into an individual topic. Hopefully, you’ll find some useful nuggets that will help you on your path to specialization.

Fundamental Concepts

A good penetration tester understands the fundamental topics of what he/she is testing. In a web environment, it means:

Understanding how the Web Works

There are some network protocols used on the web, and the most important is HTTP (HyperText Transfer Protocol). It’s described in RFC2616. It works in a client-server architecture in which a computer acts as a client (normally a web browser) and another as a server (where the website is). In the HTTP world, there is a request and a response. A request is sent by the client and a response by the server.

HTTP Requests

A request can be in various ways: to get something, to send something, and so on. What dictates that is the HTTP verb that is used:

• GET: get something
• POST: send some data to get something
• PUT: send some data
• DELETE: delete some entry point
• HEAD: like a GET request but get only the headers
• OPTIONS: get which verbs are available

To go deeper on this topic, a study of RFC2616 is recommended.

HTTP Responses

After a client sends a request to a web server, the server processes this request and returns a response that may have been successfully treated or may not. A server responds with an HTTP return code. There are several categories of codes, which are:

• 1xx: Return codes that start with 1xx are informational. It means that the request was received and is processing;
• 2xx: This category represents that everything went well;
• 3xx: Status codes starting with 3xx means that some action needs to be taken to complete the request, as in a redirection that the request needs to be sent elsewhere;
• 4xx: A 4xx status code represents a client error in the request. A famous one is a 404 error, which means the resource was not found;
• 5xx: This category means a server error has occurred. Maybe the server is overwhelmed, has an error in the application, or something prevented the server from treating it well.

HTTP Headers

Some additional information could be sent in the HTTP request and response. This information is the HTTP header, and it exists to guide the server or the client on how to treat the request or the response, respectively. Some examples:

• Content-Type: Make explicit which content is being sent: an image, or text, for example.
• Accept-Language: Informs which language is accepted: such as English or Portuguese.
• User-Agent: A string with some information about the client, e.g., Browser type.

There is a lot of possible information that could be found in an HTTP header. Wikipedia has a good list of it.

HTTP Body

In an HTTP conversation, there is data being transmitted, and it occurs mainly using the HTTP body. When a browser wants to get an image from a web server, it sends a request to the server, and the server responds with an HTTP response that contains the image in its body. The same happens when requesting a web page, and so on.

Cookies

HTTP cookies are a mechanism to store some information in the client to be used in later requests. This piece of data is sent in every request that matches the criteria, such as if it is from the same website. Cookies are a crucial point in web security because they are used to ensure an HTTP session is maintained.

Examples

After all this introduction, let’s take a look at an example of an HTTP request:

$ nc cybrary.it 80 GET / /HTTP/1.1 Host: cybrary.it

And an HTTP response:

HTTP/1.1 301 Moved Permanently Server: awselb/2.0 Date: Sat, 25 Jul 2020 17:19:57 GMT Content-Type: text/html Content-Length: 150 Connection: keep-alive Location: https://cybrary.it:443/

Other Fundamentals Topics

There are other important fundamental topics, such as:

• Cryptography
• Encoding
• Client-side technologies (Javascript, HTML, CSS…)

Methodology

Like any other penetration test engagement, a web penetration test consists of phases. Generally, they are:

• Information gathering: A pentester needs to gather as much information as possible about the target. This phase covers discovery, for example: What webserver is running? Which programming language is being used? Is it using a CMS or libraries, if so, which one? Are there known vulnerabilities in this software? Especially for a web environment, it’s important to understand where data inputs are allowed within the application, to be tested for any web vulnerability;
• Exploitation: Any known vulnerability discovered in the previous phase must be tested. Working in a web scenario it’s important to treat all data entry as dangerous and testing all of them is in the best effort to trigger a security issue;
• Report: After all the testing is done, it’s time to write the report to cover which security issues were found in the application; How dangerous are they; the steps to reproduce or show evidence of issues; and recommendations on how to fix them.

Common Web Vulnerabilities

It is important to remember wherever there is an input capability; there may be an underlying flaw or vulnerability that could be exploited. For example, input fields for name, birthday, photo, and everything else could have a security issue.

Some common web security problems are:

• SQL injection
• Cross-site script
• Session management
• Upload management
• Misconfiguration
• Cross-site request forgery
• XML external entity

This is a simple list, and there are many more web vulnerabilities. OWASP maintains a project that lists the Top 10 web vulnerabilities over the years.

Web Applications Differences

Almost all common web security flaws could occur in any web application. However, it is important to pay attention because different web applications may need to be treated differently. Examples:

• eCommerce: Besides common vulnerabilities, an eCommerce system must be tested looking for compliance and the pentester needs to pay attention in the coupon and cart subsystem and the CC storage;
• Health: In a health system, user data is very important and should not be leaked. There are also many laws and regulations on personal health data.

Every web application must be treated as unique, looking for its industrial sector guidelines, standards, and requirements.

Good Study Materials

There are some great resources when getter deeper into web application penetration testing, depending on your needs. There are some great pathways, books, and labs, to name a few.

Pathways

A good way to learn is following a pathway with topics approached strategically in materials and labs. In Cybrary, there is the Penetration Tester Career Path.

Books

The de facto book about web penetration testing: The Web Application Hacker’s Handbook, written by Dafydd Stuttard and Marcus Pinto. Nowadays, they maintain the Web Security Academy by PortSwigger.

Labs

It is a great idea to test and improve skills using a lab. Cybrary has many hands-on learning labs. An ad-hoc method is also available using the Vulnhub virtual machines.

Conclusion

Of course, there are many things to learn, depending on your needs and available time. Fundamentally, it is important to learn how the web works. Then, you can learn how to subvert these things and how to break them. Finally, it is important to remember some key points:

• Most web applications are different from each other.
• Every entry point can lead to a vulnerability.