My Cyber Endeavors

Cross-Site Scripting

Cross-Site Scripting (XSS) is an extremely prevalent web vulnerability. XSS occurs when a malicious user or threat actor can inject custom JavaScript code into a web page. This code is either reflected or stored on the web page. Subsequent users that visit the altered page will trigger the JavaScript code, resulting in a number of potential outcomes. In the most severe cases, XSS can be used to steal session cookies and result in session hijacking.

XSS occurs when user input is trusted without sensitization. For example, consider the following scenario: You login to a website. The website greets you with your name, displaying "Hello Chris" on the page. However, a malicious user sets his or her name to the following string:

<script>alert(1)</script>

In turn, the website would now try to display the following text: "Hello <script>alert(1)</script>". If the website was not properly sanitizing this code, the script tags would render and execute the alert function. This is a very simple example, but demonstrates the basic fundamentals of XSS. In my career I have discovered and reported over 130 XSS vulnerabilities. The three major types of XSS are:

• Reflected XSS
• Stored XSS
• DOM XSS

SQL Injection

SQL Injection is a much more severe web vulnerability. With SQL injection, a malicious user is able to directly pass their own custom SQL queries to a back-end database. This allows them to run malicious queries that oftentimes result in full database compromise. SQL injection once again occurs when a website blindly trusts user input. For example, consider the example URL below:

http://example.com/profile.php?userID=1

This fictitious webpage would load the profile page for the user with userID equal to 1. A back-end SQL query for this may look similar to the following:

SELECT * FROM users WHERE userID='1';

However, consider if a malicious user injected the following SQL query into the URL:

http://example.com/profile.php?userID=1' AND userID='2

Now, the backend SQL query would be altered. It would query the following:

SELECT * FROM users WHERE userID='1' AND userID='2';

This would now select the information for userID 1, but it would also display the information for userID 2. Consider if userID 2 was meant to be private, the information would still show on user 1's page. Again, this is a very simple example but it demonstrates the potential dangers of SQLi. In my career I have found roughly 15 SQL injection vulnerabilities. The main types of SQLi are shown below:

1. Error-Based SQLi
2. Union-Based SQLi
3. Boolean-Blind SQLi
4. Time-Based SQLi

Local File Inclusion

Local file inclusion (LFI) is a relatively rare vulnerability; however, it is generally critical in severity. LFI occurs when a web server is attempting to retrieve an internal file or page through a URL parameter. Consider the following URL:

http://example.com/gallery.php?file=dog.jpg

This code might be a website with a gallery where a user is viewing a cute dog picture. However, consider if the user injected the following path in the file parameter:

http://example.com/gallery.php?file=../../../etc/passwd

Now, instead of fetching the dog.jpg picture, this web server will instead retrieve the /etc/passwd file (a sensitive file for Linux web servers). If the user can control this parameter with no restrictions they can view any file on the file system. As previously mentioned, this vulnerability is relatively rare, I have only discovered 3 in my career.

XSS Examples

As an example, I have intentionally created an intentionally vulnerable page to step you through exploiting XSS.

Steps to Exploit:

1. First, enter some text and press "Submit", observe as it is reflected on the page.
2. Next, try to place an HTML tag before your text, for example <h1>, submit your text again and observe as the HTML is rendered.
3. Finally, attempted to execute JavaScript code by submitting the following payload: <img src=x onerror=alert('xss!')>
4. Upon pressing "Submit" the JavaScript code will execute, creating a pop-up.
5. While the alert box is a simple proof of concept, it illustrates that this field is vulnerable and could facilitate future attacks.