Exploiting Web Application Vulnerabilities
Web applications are complex ecosystems consisting of application code, web platforms, operating systems, databases, and interconnected application programming interfaces (APIs). The complexity of these environments makes many different types of attack possible and provides fertile ground for penetration testers. Cross-Site Scripting (XSS)
Cross-site scripting (XSS) attacks occur when web applications allow an attacker to perform HTML injection, inserting their own HTML code into a web page. In other words, it works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application. Reflected XSS If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can: Perform any action within the application that the user can perform. View any information that the user is able to view. Modify any information that the user is able to modify. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user. Stored/Persistent XSS Another common technique is to store cross-site scripting code on a remote web server in an approach known as stored XSS. These attacks are described as persistent, because they remain on the server even when the attacker isn’t actively waging an attack. This XSS attack could also be used to redirect users to a phishing site, request sensitive information, or perform another attack. DOM XSS (Document Object Model Cross-Site Scripting) is a type of Cross-Site Scripting (XSS) attack where the malicious payload is executed as a result of modifying the DOM environment in a victim's browser. Unlike traditional XSS attacks where the malicious payload is injected into the response from the server, DOM XSS operates exclusively on the client side. While DOM XSS attacks don't inherently hide code, attackers often use obfuscation techniques to disguise their malicious payloads, making them harder to detect and understand. Request Forgeries
Cross-site request forgery Attacks (XSRF) or (CSRF) exploit the trust that remote sites have in a user’s system to execute malicious commands on the user’s behalf. This attack is based on a lot of assumptions, but when it sticks it sticks. An online banking site. An attacker who wants to steal funds from user accounts might go to an online forum and post a message containing a link. That link actually goes directly into the money transfer site that issues a command to transfer funds to the attacker’s account. The attacker then leaves the link posted on the forum and waits for an unsuspecting user to come along and click the link. If the user happens to be logged into the banking site, the transfer succeeds. Server-Side Request Forgery (SSRF) attacks exploit a similar vulnerability but instead of tricking a user’s browser into visiting a URL, they trick a server into visiting a URL based on user input. If the server has access to private URLs, an SSRF attack can disclose that information to an attacker. Injection Vulnerabilities
Injection Vulnerabilities allow an attacker to supply some type of input code to the web application and trick the web server into either executing that code or supplying it to another server to execute. Code Injection Attacks
SQL injection attacks are a specific example of a general class of attacks known as code injection attacks. These attacks seek to insert attacker-written code into the legitimate code created by a web application developer. These are among the primary mechanisms that attackers use to break through a web application and gain access to the systems supporting that application. Blind SQL Injection Attacks A Blind SQL injection attack type attackers use to Find out if the website has a blind SQL Injection Vulnerability to begin with. If the website does have said vulnerability, they can exploit it to extract various forms of information. A subtype of blind SQL injection where the attacker observes the behavior of the database server and the application after combining legitimate queries with SQL commands that cause time delays. If after the attacker queries the table and time delays occur, they can get more data about the table structure of the SQL table and finally extract data from the table. An attacker can cycle through all the possible password combinations to narrow down the password character by character. This may seem tedious, but security tools like SQLmap and Metasploit automate blind timing–based attacks. Dynamic Link Libraries (DLL) Injection A missing DLL or a DLL which is implemented in an unsecure method can be utilized in order to trick the running system to execute a malicious payload. Injected commands may even attempt to load dynamically linked libraries (DLLs) containing malicious code in a DLL injection attack. LDAP (Lightweight Directory Access Protocol) Injection Attack LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. Extensible Markup Language (XML) Injection Attack XML Injection Attacks is a category of vulnerabilities where an application doesn’t correctly validate/sanitize user input before using it in an XML document or query. Bad guys can then have full control to modify whatever is in your XML documents. XML injections enable unvalidated user data (attacker input) to construct queries that allow an attacker to read or modify XML documents or execute commands in your XML-enabled database. This enables an attacker to get around your application’s front end to gain access to the juicy stored data they seek by taking advantage of vulnerabilities that exist in input fields (e.g., the user’s name, password, and search input fields). Pointer/Object Deference
Pointers are a commonly used concept in application development. They are simply an area of memory that stores an address of another location in memory. Ex. We might have a pointer called ‘photo’ that contains the address of a location in memory where a photo is stored. When an application needs to access the actual photo, it performs an operation called pointer de-referencing. (The application follows the pointer and accesses the memory referenced by the pointer address). In the case a Pointer is mapped to a blank or null value, the application will crash, providing an attacker with access to debugging information that may be used for reconnaissance of the application's security. In the worst case, a null pointer exception may allow an attacker to bypass security controls.
Buffer Overflows
Buffer Overflow Attacks occur when an attacker manipulates a program into placing more data into an area of memory than is allocated for that program’s use. The goal is to overwrite other information in memory with instructions that may be executed by a different process running on the system. A static analysis can easily detect a buffer overflow. Race Conditions
Race Conditions take advantage of the need that computing systems must execute some tasks in a specific sequence. In any such sequence, there is a small period of time when the system has carried out the first task but not started on the second. If this period is long enough, a race condition vulnerability exists where an attacker can trick the system into carrying out unauthorized actions in addition to its normal processes. Time of Check to Time of Use (TOCTOU):
TOCTOU is a type of race condition that occurs when a system's state changes between the time a property is checked (time of check) and the time that property is used (time of use).
If an attacker can exploit this window of opportunity between the check and the use, they can manipulate the outcome. Analogy:
Imagine you're a security guard at an exclusive event. Your job is to check the guest list (time of check) and then let the person enter (time of use).
At 8:00 PM, you check the guest list and see that "John Doe" is on it. Just as you're about to let John Doe in, an imposter (attacker) quickly takes his place and enters the event pretending to be John Doe. In this scenario, the time between checking the guest list and letting the guest in is the vulnerable window. The imposter exploited the race condition (the brief moment between checking and using) to gain unauthorized access.
In Computing:
A classic example of TOCTOU in computing is with file operations:
A program checks if a file exists and if the user has permissions to access it (time of check). Before the program actually accesses the file (time of use), an attacker replaces the file or changes its permissions. The program, thinking it's accessing the original file, ends up accessing or executing the attacker's file. This race condition can lead to unauthorized access, data corruption, or even system compromise if the replaced file contains malicious code.
In summary, TOCTOU is a race condition where the state of a system can change between the moment it's checked and the moment it's used, leading to potential security vulnerabilities.
Error Handling
Developers must write their code so that it is resilient to unexpected situations that an attacker might create in order to test the boundaries of code. Developers must anticipate unexpected situations and write Error Handling Code that steps in and handles these situations in a secure fashion. Improper error handling may expose code to unacceptable levels of risk. Ex. If a web form requests an age as input, it’s insufficient to simply verify that the age is an integer (number). Attackers might enter a 50,000-digit integer in that field in an attempt to perform an Integer Overflow Attack. Proper error handling and planning must be implemented to prepare and mitigate this type of attack. If error handling routines explain too much about the inner workings of code, they may allow an attacker to find a way to exploit the code.
Improper Input Handling
Input Validation and Improper Input Handling Applications that allow user input should perform validation of that input to reduce the likelihood that it contains an attack. Input validation techniques are the go-to standard for protecting against injection attack Improper input handling practices can expose applications to injection attacks, cross-site scripting attacks, and other exploits. Input Whitelisting When the developer describes the exact type of input that is expected from the user and then verifies that the input matches that specification before passing the input to other processes or servers. Ex. If an input form prompts a user to enter their age, input whitelisting could verify that the user supplied an integer value within the range 0–120. The application would then reject any values outside that range. It is very important to ensure that validation occurs Server-Side rather than within the client’s browser. Browser-side validation can easily be bypassed and compromised by attackers and penetration testers. Input Blacklisting can be used when it may be difficult to describe the exact inputs needed for validation. 
1.3 Given a scenario, analyze potential indicators associated with application attacks.
