Common Attack Techniques

Cybersecurity threats continue to evolve, with attackers using a variety of techniques to exploit vulnerabilities and compromise systems. This page provides an overview of common attack types and the techniques employed by cybercriminals, helping organizations recognize and mitigate these threats effectively.

Replay Attacks

In a replay attack, which is a type of man-in-the-middle attack, an attacker sniffs communications being sent on a channel in order to intercept them and resend them while still appearing to be genuine messages. The replay attack is particularly dangerous since the attacker can trick the recipient into believing that the message they have just received is valid without ever decrypting it.

Example:

Defenses against replay attacks

1. The first defense against replay attacks is to provide timestamps or sequence numbers with every message that is transmitted. The receiver will be able to ignore any message that contains a repeated timestamp or sequence number as a result.
2. Using digital signatures to make it simpler for the recipient to verify that the sender is who they think they are is another preventative method.
3. The use of random-session session keys, which are time-specific and change over time to make it more difficult for an attacker to trick the recipient with an outdated message, can also reduce replay assaults.

URL Manipulation

A hacker can force a web server to deliver web pages that they are not authorized to view by changing specific elements of a URL.

Malicious actors use URL manipulation tactics to commit directory traversal attacks by altering the paths of a targeted URL.

Dynamic websites serve pages based on URL parameters, malicious users can manipulate the URL with unexpected values. Vulnerable web applications can render pages which the user is not authorized to.

For example:

http://website.com/pages?cat=public

The above URL can be manipulated as

http://website.com/pages?cat=private

which leads to sensitive data exposure

Defenses against URL manipulation attacks

1. Validate each important parameters before processing the requests.
2. Disable the display of files present in a directory that does not contain an index file (also known as Directory Browsing).
3. Remove unnecessary configuration options.
4. Remove useless directories and files.
5. Ensure the server protects access to directories containing sensitive data.
6. Ensure that the server accurately interprets dynamic pages, including backup files (.bak)

Injection Attacks

One of the most frequent and harmful web attacks is the injection attack. The top risk in the OWASP Top 10 Web Application Security Risks is injection vulnerability. The Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses list includes a number of injection attacks.

In an injection attack, an attacker feeds a program with improper input. An interpreter will process this input as part of a command or query. This in turn modifies how that software is run.

The huge attack surface of injection vulnerabilities, particularly those related to XSS and SQL Injection, makes them particularly terrifying. Additionally, injection attacks are a form of vulnerability that is well known. There are numerous tools that are readily available for free that enable even novice attackers to automatically exploit these vulnerabilities.

Various types of Injection attacks

Code injection – In this type of attack, the attacker injects application code written in the application programming language. This code may also be used to execute operating system commands with the privileges of the user running the web application. In more complex situations, the attacker might use other privilege-escalation flaws to compromise the entire web server.

Threats: Successful code injection attacks can compromise the entire system.

SQL Injection (SQLi) – SQL queries that can read or modify database data are injected by the attacker. Advanced SQL Injection attacks allow the attacker to write arbitrary files to the server and even run OS commands using SQL commands. This might compromise the entire system.

Threats: Authentication bypass in login pages, data loss, compromised data integrity

OS Command Injection – On the web server that hosts them, web applications occasionally need to execute a system command. If user input is not controlled and checked under these circumstances, a command injection may happen.

Command injections, as opposed to code injections, simply call on an understanding of the operating system by the attacker. Using the user’s privileges, the attacker then inserts a command into the system. The host system then carries out the command that was inserted.

Threats: Successful OS injection attacks can compromise the entire OS system

Cross-site Scripting – An attacker can deliver malicious code to a separate end user without having it validated or encoded whenever an application accepts user input inside the output it produces. These are chances for Cross-Site Scripting (XSS) attacks to introduce malicious scripts into reliable websites. During a Cross-Site Scripting attack, text with malicious code (mostly in JavaScript) is added to a web page. The code is run when an oblivious user accesses that website.

A string of text, for instance, might be appended to the URL. A user’s browser will run the code, creating a breach, if the application fails to validate it and allows it to pass.

An XSS attack can also be used to modify user settings, hijack user sessions, and steal cookie information. This could invite imitating and vandalism.

Threats: Website Defacement, account impersonation

Input Validation Attacks

Input validation assaults are a type of cyberattack where the attacker inserts malicious data that the target system can interpret and use to its advantage. Code, scripting, and command input are just a few of the input formats that input validation attacks might use. Buffer overflow, canonicalization, cross-site scripting (XSS), and SQL injection (SQLi) attacks are the most frequent types of input validation threats.

Brute Force Attack

A brute force attack is a hacking technique that makes use of trial and error to break encryption keys, passwords, and login credentials. It is a straightforward but effective strategy for getting unauthorized access to user accounts, company systems, and networks. Until they discover the proper login information, the hacker tries a variety of usernames and passwords, frequently utilizing a computer to test a wide range of combinations.

Automated tools are frequently used in a straightforward brute-force assault to try every possible password until the right input is found. This attack strategy is outdated yet remains efficient at breaking common passwords.

Types of brute-force attacks

Dictionary Attack – A dictionary attack is a fundamental type of brute force hacking in which the attacker chooses a target and then compares potential passwords to the user name of that person. Although the assault technique itself is not technically a brute force attack, it can be a key step in a malicious actor’s password cracking operation.

Hackers trawling through dictionaries changing words with special characters and numbers gave the phrase “dictionary attack” its name. Compared to more recent, more successful attack strategies, this form of attack is often time-consuming and has a lower likelihood of success.

Credentials stuffing – Users’ poor password etiquette makes them easy prey for credential stuffing. Attackers gather stolen username and password combinations and try them on different websites to see if they can access more user accounts. This strategy is effective if users re-use passwords for numerous accounts and social media profiles or utilize the same login and password combination.

Reverse Brute Force Attacks – An attacker starts a reverse brute force attack by using a known password, which is often found through a network breach. They utilize that password to browse through lists of millions of usernames in quest of a matching login credential. Attackers may also utilize a username database to look for a match by using a widely used weak password, such as “Password123456,” to search through.

Preventing brute force attacks

1. Limiting failed login attempts
2. Forcing complex passwords
3. Implementing Two-Factor Authentications
4. Implementing CAPTCHAs

XSS

Cross-site scripting or XSS is a type of injection attack in which a malicious threat actor inserts data, such as a malicious script, into content from trusted websites.

The injected malicious code is then included with dynamic content delivered to a victim’s (users) browser.

Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

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.

Types of XSS

1. Reflected XSS

Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data.

2. Stored XSS

Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all

3. DOM Based XSS

DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write).”

Successful XSS attacks can lead to:

• Pretending to be the victim user or impersonating them.
• Execute whatever operation that the user is capable of
• Read any data that the user is able to access.
• Perform virtual defacement of the web site.
• Inject trojan functionality into the web site.

XSS prevention:

Cross-site scripting prevention is sometimes simple, but it can also be challenging depending on the application’s sophistication and how it manages data that can be changed by the user.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

Strong input data validation – Apply a rigorous filter based on what is valid or expected input at the point where user input is received.

Encode Output Data– At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

Use appropriate response headers– To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

Content Security Policy– To lessen the severity of any remaining XSS vulnerabilities, you can employ Content Security Policy (CSP) as a last line of protection.

Source: owasp.org

CSRF

Cross-Site Request Forgery (CSRF) is an attack that compels a user who is currently logged in to a web application to perform undesirable actions.

An attacker can employ a little social engineering to persuade users of an online application to carry out their desired activities (for example, by delivering a link via email or chat). If the victim is a regular user, a successful CSRF attack can compel them to carry out state-changing operations like money transfers, email address changes, and other such tasks. The entire web application may be compromised by CSRF if the victim is an administrative account.

The purpose of a CSRF attack is to coerce the user into making a state-changing request. Examples comprise:
• Deleting a record.
• Submitting a transaction (such as funds transfer to the attackers account)
• Changing the users’ password.
• Sending a message not intended by the user.

How does it work

An end user can be deceived in a variety of ways to load information from or submit information to a web application.

To successfully launch this attack:

1. The attacker must build an exploit URL specific to the users website
2. The attacker must also deceive the user into clicking the exploit URL
3. The user needs to have an active session with the website.

CSRF prevention methods which will NOT work

1. Only accepting POST requests rather than GET
2. Using a secret cookie in the form
3. Multi-step transactions for any sensitive operations
4. HTTPS for communication

Defense mechanisms against CSRF attacks

1. Using CSRF tokens – A CSRF token is a one-of-a-kind, confidential, and unpredictably produced value that is shared with the client by the server-side application. The client must provide the appropriate CSRF token in the request when attempting to carry out a sensitive operation, such as submitting a form. This makes it incredibly challenging for an attacker to create a legitimate request on the victim’s behalf.
2. HTTP Referer header validation – Some applications utilize the HTTP Referer header to check whether the request came from their own domain in an effort to fight against CSRF attacks. Generally speaking, this is less efficient than CSRF token validation.
3. Using SameSite Cookies – A browser security feature called SameSite detects if cookies from one website are included in requests coming from another. The appropriate SameSite constraints may prevent an attacker from initiating these actions cross-site because requests to execute sensitive actions normally require an authenticated session cookie.

Buffer overflow

A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra data – which has to go somewhere – can overflow into adjacent buffers, corrupting or overwriting the valid data held in them.

Attackers may conduct buffer overflow attacks for a number of reasons, including overwriting crucial code or data to cause the program to crash, inserting malicious code to be executed by the program, or changing crucial values to alter the program’s execution flow.

Types of Buffer Overflow Attacks

There are several techniques to carry out a buffer overflow attack, however some of the more typical ones are as follows:

1. Stack-Based Buffer Overflow: Buffer overflow attacks frequently target the program stack, which houses important control flow information for an application (such as function return pointers). By overwriting a return pointer, the program may jump to attacker-controlled data and run that data as code, giving the attacker access to the application’s permissions.
2. Format string attack: When an application treats input as a command or improperly validates input, a format string exploit occurs. This gives the attacker the ability to run code, extract data from the stack, or crash the application by causing segmentation faults. This can lead to fresh behaviors that endanger the system’s stability and security.
3. Heap-Based Buffer Overflow: The heap of the program is used to allocate memory on the fly to variables whose sizes are not specified during program compilation. A buffer overflow vulnerability can be used by an attacker to flood the system heap and erase crucial application data.

Defenses against Buffer Overflow

1. Enabling Runtime Memory Protection: Buffer overflow protections like Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and Structured Exception Handling Overwrite Protection are usually built-in to most systems. Attacks utilizing buffer overflows become significantly more challenging when these safeguards are enabled.
2. Executing Input Validation: Programs that make assumptions about user-provided input without validating those assumptions are vulnerable to buffer overflow attacks. Buffer overflows can be prevented by measuring the length of the data or by only copying a specific number of bytes to a memory address.
3. Memory-Safe Languages usage: Buffer overflows happen in computer languages with fixed-size variables and no memory protections, hence memory-safe languages should be used instead. Buffer overflows are difficult or impossible to occur when other programming languages like Python, Java, or C# are used.
4. Preventing use of Vulnerable Functions: In C/C++, functions like gets, scanf, and strcpy are susceptible to buffer overflows. The safe versions of these functions should be used correctly to avoid buffer overflow issues.

Directory browsing/Directory Indexing

A web security flaw called directory traversal (sometimes called file path traversal) enables an attacker to access any files on the server hosting an application. This could comprise critical operating system files, back-end system login information, and application code and data. An attacker may occasionally be able to write to any file on the server, which would give them the ability to change application data or behavior and ultimately gain complete control of the server.

Example

Think about a shopping app that shows pictures of available products. Images can be rendered using HTML in the following ways:

<img src="/renderImage?file=110.png">

The contents of the provided file are returned by the renderImage URL, which accepts a filename parameter. The actual image files are kept on disk at the address /var/www/images/. The application adds the requested filename to this base directory in order to return a picture, and then utilizes a filesystem API to read the file’s contents. The application reads from the following file location in the aforementioned scenario:

/var/www/images/110.png

In order to access any file from the server’s filesystem, an attacker can request the following URL because the program doesn’t protect against directory traversal attacks:

https://website-name.com/renderImage?file=../../../etc/passwd

This causes the application to read from the following file path:

/var/www/images/../../../etc/passwd

Within a file path, the sequence../ is acceptable and denotes a level-up in the directory hierarchy. The file that is really read is: The three successive../ sequences step up from /var/www/images/ to the filesystem root.
/etc/passwd

Defenses against directory traversal

1. Validate user input – The user input should be verified by the application before processing it. The validation should, ideally, compare to a whitelist of authorized values. If the needed functionality prevents that, then the validation should ensure that the input only contains content that is allowed, such as only alphanumeric characters.
2. Using Indexes – Indexes are more secure to employ in URLs than bare file names. Because an index does not offer a hacker immediate access to the file, as the raw file name does, it adds an additional layer of abstraction between the hacker and the files.

Parameter Tampering

The Web Parameter Tampering attack is based on changing application data, such as permissions, cost and quantity of goods, etc., by manipulating parameters that are transferred between client and server.

This information is typically used to improve the operation and control of an application and is stored in cookies, hidden form fields, or URL Query Strings.

This type of attack can be performed by a malicious user who wants to exploit the application for their own benefit, or an attacker who wishes to attack a third-person using a Man-in-the-middle attack.

Examples of parameter tampering attacks include:

1. URL parameters manipulation
2. HTML Hidden fields data manipulation
3. HTML form GET and POST data manipulation by tools

Defenses against Parameter Tampering:

1. Validate input data for type and range
2. Avoid storing sensitive data in hidden HTML form fields

Also Read: Attack Techniques-Advanced, Attack Techniques Section