# Web Vulnerabilities POC

## "Sting" Web Applications for Vulnerabilities

### Web Application 1: Your Wish is My Command Injection

This is a VERY simple example of a command injection for a text field in the DVWA web application.  Here we can see an interactive input field that requires the user to enter an IP address.  Because of the poor security measures surrounding input validation, however, I was able to utilize the field to inject a command `&& cat ../../../../../etc/passwd` to reveal sensitive information a standard user should not have access to.  This vulnerability exploits the system's trust of input information, and is clearly in need of security measures to prevent data leakage such as this.

<figure><img src="https://812812072-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfSo1wAY1N2Kj0pCQgHU7%2Fuploads%2Fp0h9ISMyQKpPtTCS0HSF%2Fimage.png?alt=media&#x26;token=763f56d1-cb79-4c84-a0b4-9b80fba79e27" alt=""><figcaption></figcaption></figure>

| The most important mitigation strategy here is input validation.  Certain characters that the application server would interpret as commands need to be labelled as "bad characters" so they are rejected before any action is performed.  Vulnerabilities like this can exist in truly any text input field, or even in a URL header.  It is important to always validate input and only allow exactly what is expected as input. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

### Web Application 2: A Brute Force to Be Reckoned With

| This is a high level overview of a dictionary attack on a bWAPP application.  The goal here was to utilize a predetermined wordlist of both usernames and passwords, in conjunction with Burp Suite, to test varying credentials for access to the application interface.  This method simulates the scenario of a leaked credentials list from a previous breach that could have been obtained on the Dark Web.  These credential lists are sold often, and utilized to attack other applications that a company or enterprise may utilize.  Using `Intruder` from Burp, I was able to gain access with the proper credentials using the username and password lists provided. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

<figure><img src="https://812812072-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfSo1wAY1N2Kj0pCQgHU7%2Fuploads%2FbK0b6VnU3JFpRqNHkWXo%2Fimage.png?alt=media&#x26;token=39451879-aae7-4441-b5f1-d76ca1736f19" alt=""><figcaption></figcaption></figure>

| Based on the simplicity of usernames and passwords, I feel that a more complex password requirement will aid in mitigating the effects of this attack. Along with this, I am a firm believer that multifactor authentication helps like a code being sent to a device or backup email.  From an enterprise perspective, this is why password rotation and policy are so important.  If a company is requiring all employees to change their passwords every 3 months, then the hypothetical leaked credentials will be depreciated over time.  Strong, unique passwords are a must if the first line of defense needs to remain shut against brute forcing, but rotation of passwords maintains ephemeral access credentials, should they ever be leaked and sold on the Dark Web. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

### Web Application 3: Where's the BeEF?

| In this example of a BeEF hook URL, I was able to obtain access in a simulated phishing attack with a malicious link.  I delivered the link (to myself for a proof of concept), and once selected by the "victim," a phony Facebook page was presented to the unsuspecting target.  This allowed me to monitor them from the attacker perspective, and gain credentials they entered when attempting to log in to the false page with their ACTUAL credentials. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

<figure><img src="https://812812072-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfSo1wAY1N2Kj0pCQgHU7%2Fuploads%2FKKWDIn07o5qg32oEE3m5%2Fimage.png?alt=media&#x26;token=652f406c-0168-4f02-b21e-8b389fd05074" alt=""><figcaption></figcaption></figure>

| It is a little hard to see, but I utilized a combination of the BeEF Hook script and Burp Suite to intercept the POST request and edit it. The character limit on the DVWA was a hurdle to jump over, but intercepting the traffic and adding that script allowed me to bypass it.  A major mitigation strategy would be recurring employee training.  If the employee hadn't clicked on the malicious link, and followed guidelines to inspect the legitimacy of an email, the hook script would not have been able to run and traffic would not have been intercepted in the first place. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

\\
