Common Software Vulnerabilities

Buffer Overflow Attacks

What Are They?

Like a flooding river, a buffer overflow has the potential to cause significant damage. To understand why, let’s begin at the source of the problem. In low-level languages that access and write memory, a part of this memory stays allocated for temporary data that needs to be saved during run-time. This part of memory is called a buffer. A buffer overflow happens when the data that needs to be saved exceeds the allocated memory space in the buffer.

Examples of a Buffer Overflow

As you can see in the image to the right, memory is made of different parts. Between the stack and the heap, there is a buffer area, which allows both to grow during run time. If we look at a stack in detail, we can see different sections:

Function: The calling function written by the developer
Parameters: The parameters needed by the function
Return: Tells the program what to do after it has executed the function
Basepointer: Marks the start of a function stack frame
Buffer: The allocated space for data

Types of Buffer Overflow

Stack Overflow: This involves overflowing a buffer on the call stack, as described above.
Heap Overflow: Same as stack overflow, but it takes place in an open memory pool.
Integer Overflow: An arithmetic operation results in an integer too large for its integer type.
Integer Overflow: Unicode characters are inserted into an input that expects ASCII characters.

Preventing Buffer Overflow Attacks

Avoid C/C++, these programming languages are prone to buffer overflow.
Address space layout randomization.
Enhance the security of executable programs by detecting buffer overflows on stack-allocated variables.
Mark memory regions as non-executable.
Avoid standard library functions that are not bounds checked, such as gets, scanf and strcpy.
Scan your code for buffer overflow vulnerabilities.

Code Injection Attacks

What Are They?

Code injection is a general term for a type of software vulnerability where unvalidated input is evaluated by an application. It is fairly common on web applications that rely on user input through forms that lack appropriate input/output data validation. This flaw can be exploited by attackers by injecting malicious into the application, which will then be executed by the server-side interpreter for that language.

Consequences of code injection can be dire:

Data loss
Data corruption
Lack of accountability
Denial of access

Types of Code Injections

SQL Injection
Cross-site Scripting
PHP Object Injection
Remote File Injection (file inclusion vulnerability)
Format Specifier Injection (format string attack)

Preventing Code Injection Attacks

Validate and sanitize inputs — accept only a limited set of values.
Use a SAST solution.
Give the account the database calls run under only limited privileges.
Avoid vulnerable evaluation constructs.

Cross-Site Scripting Attacks

What Is Cross-Site Scripting?

According to OWASP Top 10, XSS is the second-most prevalent issue found in the majority of web applications. By using XSS, attackers can bypass the Same Origin Policy (SOP) in a vulnerable application by entering malicious code that is mistakenly interpreted as user input. This can be done with technologies like VBScript, ActiveX, Flash, and even CSS, but JavaScript attacks are the most common.

XSS differs from SQL because it does not target the database of web applications; it mostly limits itself to their front end.
These attacks can be non-persistent, persistent, and DOM-based. The consequences of XSS attacks can be very damaging, especially when combined with social engineering.
Websites or web interfaces can become corrupted and unsafe. Cookies and authentication information can be stolen, leading to identity theft. By hacking a vulnerable company website, attackers can gain control of the company’s computer clients.

Examples of Cross-Site Scripting Attacks

Cookie Theft
Website Damage
Phishing
Keylogging
Client Access

Preventing Cross-Site Scripting Attacks

Specify which tags are designed as “safe” in the HTML documents created by user inputs.
Encode the data on output.
Use Content Security Policy (CSP).
Use a Static Application Security Testing solution.

The Dangers of SQL Injection Attacks

What Are They?

From November 2017 to March 2019, 65% of web application attacks worldwide used SQL injection (SQLi). So it’s no surprise that injection attacks were named as the number one threat to web applications by the Open Web Application Security Project (OWASP).

If you’re wondering why SQLi attacks are so frequent, it’s because web forms that use SQL queries to retrieve data are common. From login pages to search queries, online order forms, and more, these web forms are often connected to databases with potentially valuable information such as personal data and financial records.

By targeting web forms, attackers can bypass other types of security, such as firewalls and endpoint defenses. The knowledge needed to conduct an injection attack is readily available online.

Attackers use SQLi to extract data, such as passwords and credit card information. They can add, modify, or delete records in the database, perform database operations such as changing credentials or dropping entire tables, and more. Any database that uses Structured Query Language (SQL) is vulnerable to SQLi, including Microsoft SQL Server, Oracle, MySQL, PostgreSQL, and MongoDB.

Preventing SQL Injection Attacks

Avoid constructing dynamic queries.
Use stored procedures and call them using canonical syntax.
Sanitize user data by removing special characters and reserved words.
Suppress database error messages to avoid revealing details.
Limit application user permissions.
Use a SAST solution.

Common Vulnerabilities