SOC - User Input Threats (Lesson)

User Input Threats

Introduction

In this lesson, you will learn about how malicious actors exploit vulnerabilities in areas of a webpage designed for user input and what we can do to mitigate those attacks. Most programmers are focused on making their applications work and meeting deadlines to publish the code. Security is often not considered a priority during the coding process.

However, this practice is very short-sighted due to numerous website vulnerabilities. In this lesson, we will discuss each of these types of code-based vulnerabilities. The common thread is that the code is interactive, as you have learned in a previous lesson, and it is the user input that offers the adversary an attack opportunity.

User Input Threats

User input refers to numbers, characters, text strings, or script code that is provided by the user to a website. For example, when a user fills out a form, when they log in, or when they add a comment to a forum.

Whenever a website accepts user input, there can be an opportunity for one of these attacks:

  • Directory Traversal
  • Buffer Overflow
  • Command Injection
  • Cross-Site Scripting (XSS)
  • SQL Injection

Directory Traversal Attack

Directory traversal attacks, also known as path traversal or directory climbing, are pretty old school as there should be many layers in place on a website to avoid this type of attack.  However, directory traversal can also be integrated into other methods of intrusion, so it is very important to understand this concept and its execution.  Understanding directory traversal is essentially about understanding file system structure.

Many website URLs and software code refer to the path to retrieve a needed file. They will accept changes to the path made by the user. The goal of malicious actors is to access files that are outside the permitted system space, such as the root folder. The tactic is to insert a series of ../ characters into the URL or software code to move (aka traverse) up the file system tree.  The cd ..  command will move us from the current folder to its parent folder. In the image, from the Bob folder, typing cd ../../.. will move us to the Root folder.

Directory Traversal Attack Example

  • The server has a URL that points to access files, such as users/profiles/bob/resume.txt
  • If the server accepts user changes to the URL, then an attacker could add text to the URL like below to traverse up to Root and then access another folder and file. Attacker adds this to the URL: ../../../etc/passwd
  • This would cause the server to process this:
    /users/profiles/bob/../../../etc/passwd
    • the first ../ takes us to /users/profiles/
    • the next ../ takes us to /users/
    • the final ../ takes us to / (root)
  • It would print out the passwd file, a successful attack! Granted, the passwd file does not hold actual passwords, but it would give us the list of users. It is also possible that this would work to read the shadow file if our changed URL is accepted as a system request.

Buffer Overflow Attack

Buffer overflow means inserting code into the memory buffer of a process where the data is larger than the input variable can hold and overflows into process execution space to run hostile code. The extra data received by the program is dumped over onto the CPU without any security restrictions. At that point, it can execute with system-level privileges!

Buffer overflows are a common result of mismanagement of memory on the part of application developers who may not be educated in these security risks.  In essence, if a hacker provides too much data in exactly the right spot in the code, it is possible for that data to be processed as if it were application code instead of user input. 

Buffer Overflow Example Animation Video

In the animated example above, the programmer assumed that all names provided by the user would be a maximum of five characters, so five spots have been allocated in the buffer storage.  When the hacker Ironman comes along, his name fills up all five spots in the buffer storage and then flows over into the next part of storage.  If that part of code storage includes executable code that is expected to be processed, then any code the hacker attaches to his name input will also be processed!

Command Injection Attack

A Command Injection vulnerability exists when a website takes user input and runs it using operating system processes. This means that an attacker can provide commands in the input field and the website will run the commands as if they were in the terminal.

The goal is usually to run terminal commands on the hosting server. The attacker can fool the website into accepting multiple commands by using special characters to connect Part 1 and Part 2 of the user input:

  1. User input that is processed according to the web page code.

Insert a special character (like ; or $) to tell the process “this is a new command.”

  1. Follow with a command to run in the operating system (OS) of the hosting device.

Here is an example:

Enter your name First column: Website Second column: Joe Schmo ;cat /etc/passwd

The key is to make the website think there are TWO pieces of information to collect and process!

#1 is the answer to the website’s form question – in the image above, the question is “Enter Your Name,” so we provide Joe Schmo. This will be added to a database or list as per the website process code.

Inserting a special character will trick the website into accepting a new command because it is interpreted in code as “here is another command.”  The ; (semicolon) is often used in code but there are many other characters that can achieve the same thing.

#2 is the command that is injected.

Cross-Site Scripting (XSS) Attack

In an XSS attack, a malicious actor adds script code into a user input field on the website, which later is executed in a visitor’s browser (aka “client side”).

Here is how XSS works:

  1. Cybercriminals exploit the XSS vulnerability by injecting scripts containing malicious code into a web page.
  2. The webpage is accessed by the victim and the malicious scripts unknowingly pass to their browser. 
  3. The malicious script can access any cookies, session tokens, or other sensitive information about the user, which is sent back to the cybercriminal.
  4. Armed with this information, the cybercriminal can impersonate the user – yikes!

XSS attacks are prevalent across the Internet. However, in most cases the victim will never know that anything happened as it does not need to have any visible action. XSS can be implemented so the victim does not need to click on anything for the XSS to work. They just need to visit the affected website -- aka a “drive by”.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page!

XSS takes advantage of a basic web security concept – Same Origin Policy. If content comes from one site, like Amazon for example, that is granted permission to access resources on my PC, then ANY content from that site will share these permissions. XSS exploits coding holes to fold malicious content into the content being delivered from a website. When the combined real and malicious content arrives at the client’s browser, it has all been delivered from the trusted source and operates under the permissions granted to that system! Sneaky, huh?

Cross Site Scripting Video

XSS Learning Scenario

SQL Injection Attack Video

SQL Injection attacks involve adding conditional inputs that form “true” statements. They are used to attack databases. We will learn more about databases and how SQL injection attacks work in the next lesson.

Input Validation to Secure Online Code

As we have discussed already, web applications have become interactive and often have features that accept input from the users, usually in a form field of some sort.  However, that user input can be a perfect opportunity for a hacker to insert malformed data. This is why validating the input is one of the most important methods of “defensive programming” -- programming with security in mind! Input validation is used to stop attacks that manipulate input to create an attack vector.

Here is how to use input validation:

  • Check each and every input received before processing it – character type, length, language, integers, fractions, credit card or telephone numbers, etc. Validating input could mean making sure that a password field does not accept more than 15 characters as it would be possible to pass a script code into a larger field. The program may need to validate the input as being an integer before it is passed to the executable code because if the user provides a fraction, it will crash the code.
  • Configure the website to replace special characters (called escaping characters) that are often used in scripts or attacks with their HTML equivalent so they can’t be executed as code.
  • Control input values – in fields where input can be predicted, use an allowlist filter or control with a drop-down list. Allowlisting is a very sensible reaction to the fact that we cannot predict what a user will do. However, when the possible acceptable answers to a question can be listed, it makes sense to limit the user to just those answers. Addresses are the perfect field to allowlist because it is possible to load a list of states, countries, or zip codes. Even better – don’t let the user type anything in at all! Provide a dropdown list of the acceptable choices and take out all risks of script injection.

Reflection and Wrap-up

In this lesson, we have learned about the critical importance of defensive programming to mitigate threats arising from user input vulnerabilities on websites. We explored several types of attacks that malicious actors employ to exploit these vulnerabilities, including Directory Traversal, Buffer Overflow, Command Injection, Cross-Site Scripting (XSS), and SQL Injection. Each of these attacks leverages the interactive nature of web applications, exploiting user input fields to execute malicious activities. To combat these threats, we discussed the principle of input validation as a cornerstone of defensive programming. This approach involves rigorously checking user input before processing, employing techniques like character type and length validation, escaping special characters, and using allow list filters to control input values. By prioritizing security in the coding process and adopting these defensive measures, programmers can significantly reduce the risk of attacks and safeguard their web applications against unauthorized access and data breaches.

[CC BY-NC-SA 4.0 Links to an external site.] UNLESS OTHERWISE NOTED | IMAGES: LICENSED AND USED ACCORDING TO TERMS OF SUBSCRIPTION - INTENDED ONLY FOR USE WITHIN LESSON. Video 1 courtesy of Wisc-Online, CC-BY; Video 2 courtesy of Secure Code Warrior, CC-BY