Jonathan Winter

Command Injection is a vulnerability (Also known as Remote Code Execution(RCE)) where an attacker is able to execute commands through an application that will execute on a target machine on the operating system, using the privileges that the application is running with. For example, achieving command injection on a web server running as root will execute commands on the target with root privileges.  Command Injection vulnerabilities are dangerous because they give an attacker the ability to directly interact with a vulnerable system, allowing the attacker to access sensitive data.  Command Injection Cheat Sheet can be found here. Discovering Command Injections The Command Injection vulnerability exists because applications use functions in programming languages to pass data to and to make system calls on the machines OS. For example, the below code takes data from a user in an input field named $title to search a directory for a song title. The application stores MP3 files in a d

Cross-Site Scripting (XSS) is an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by other users.  XSS Payloads In XSS the payload is the JavaScript code we wish to be executed on the targets machine. The payload is comprised of two parts, the intention and the modification. The intention is what the attacker intends the JavaScript to execute and the modification is the changes the attacker needs to do on the code to make it execute in each specific scenario.  Proof of Concept This is a simple payload in order to prove that an attacker can actually achieve XSS on a website: <script>alert('XSS');</script> Session Stealing Details of a users session, such as log in tokens are often kept in cookies on the targets machine. The below JavaScript takes the target's cookie, base64 encodes it to ensure successful transmission and then posts it to a website under the attackers control <script>fetch

Server-side Request Forgery (SSRF) is a vulnerability that allows and attacker to cause the webserver to make an additional or edited HTTP request to the resource of the attackers choosing. There are two types of SSRF, the first is a regular SSRF where data is returned to the attacker and the second is a blind SSRF, but no information is returned to the attackers screen. A successful SSRF can result in any of the following: Access to unauthorised areas. Access to confidential data. Ability to Scale to internal networks. Reveal authentication tokens/credentials. Examples of SSRF: In the below example, the attacker has complete control over the page requested by the web server. The attacker has requested the URL of some data for a user and it has been returned by the web server. The below example shows that an attacker can combine a SSRF attack with a directory traversal vulnerability. More information on directory traversal can be found here. In the below example the attacker can contro

File Inclusion Vulnerabilities is a vulnerability that often affects web applications when a user is allowed to requests files with poor input sanitation or validation. This becomes a risk if the attacker is able to read, edit, or create files on the server. Web applications can be written to request files on a system, such as images or text files, via parameters. Parameters are query parameter strings attached to the URL that can be used to retrieve data or perform actions based on user input. See below for a breakdown of the essential parts of a URL. In this example the user is requesting a file called userCV.pdf via a GET request. File inclusion vulnerabilities occur when a web application is poorly written. The main area of concern where user input is not sanitized or validated when they user controls them. For example, an attacker could visit http://webapp.tbh/get.php?file=userCV.pdf and if there is no authentication that the user who requested the file is allowed the file (for