1) Prevention of remote code execution

2) Avoiding SQL injection

Prevention of remote code execution

Remote code execution, also known as Arbitrary Code Execution, refers to the act of executing code on the server remotely by an attacker. This attack is usually a result of poor and improper coding practices. Attackers typically execute this attack not to steal confidential data but to demonstrate their ability to breach your security. Identifying this vulnerability during testing may be challenging, but it often surfaces during source code reviews. It is important to note that exploiting this vulnerability can lead to a complete compromise of the system with the same privileges as the web server itself.

How to prevent remote code execution

To prevent remote code execution, ensure that your code adheres to the boundaries of your data buffers. Enable range checking or similar run-time checks in compilers. By doing so, the compiler will generate code that validates whether an array index value falls within the range before accessing the corresponding memory location in the array. It is vital not to trust the user’s description of their data. Always assume that any information provided will be corrupted. Strings may not be properly terminated, arrays may not be appropriately sized, and structures may be missing components. Packets may be oversized or incomplete.

SQL injection

SQL injection is one of the most common attacks in the web industry. It is a code injection technique used to exploit data-driven applications. In this attack, the attacker inserts SQL statements into an entry field in a form, intending for these statements to be executed. Such attacks can result in data loss and the compromise of sensitive information. Malicious users can inject SQL commands into an SQL statement via web page input, thereby altering the SQL statement and compromising the security of a web application.

SQL Injection Based on 1=1 is Always True

This is a common method of SQL injection. Let’s examine an example. Suppose the original purpose of the code was to create an SQL statement to select a user with a given user id. In an attack scenario, the user inputs the following:

Userid 105 or 1=1

The attacker would utilize the following code line:

SELECT *

FROM Users

WHERE UserId = 105 or 1=1

As 1=1 is always true, the system would display the Users table to the attacker. Another SQL Injection example can be seen below.

SELECT UserId, Name, Password

FROM Users

WHERE UserId = 105 or 1=1

SQL Injection Based on “”=”” is Always True

This is another form of SQL injection attack. Consider the following login prompt. To log in, a user must provide a username and password.

When a customer enters the username and password, the corresponding server code is generated as shown below.

uName = getRequestString(“UserName”);

uPass = getRequestString(“UserPass”);

sql = “SELECT * FROM Users WHERE Name='” + uName + “‘ AND Pass='” + uPass + “‘”

By inserting ” or “”=” into either the username or password text box, a hacker could gain access to usernames and passwords from the database. The server code would generate a valid SQL statement like this:

SELECT *

FROM Users

WHERE Name =”” or “”=”” AND Pass =”” or “”=””

As this SQL query is always true, the attacker would successfully log into the website.

SQL Injection Based on Batched SQL Statements

Many databases support batched SQL statements separated by semicolons, which attackers misuse to carry out SQL injection attacks.

Example: SELECT * FROM Users; DROP TABLE table1

This code would display the Users table and then delete table1.

Now let’s examine the following code to understand how this attack is implemented.

txtUserId = getRequestString(“UserId”);

txtSQL = “SELECT * FROM Users WHERE UserId = ” + txtUserId;

Suppose the attacker enters the following line in the text field to insert the user id:

105; DROP TABLE Suppliers

This would result in the following SQL code:

SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers

How to Prevent SQL Injection

To prevent SQL injection attacks, follow the measures outlined below.

1) Use parameterized queries.

2) Implement stored procedures.

3) Properly escape all user-supplied input.

Use Parameterized Queries

In this approach, the developer defines the SQL code first and then passes each parameter to the query separately. This differentiation between code and data allows the database to treat the supplied input from the user appropriately, regardless of its content.

Implement Stored Procedures

While stored procedures are not always completely safe from SQL injection attacks, certain programming constructs within them can have the same effect as parameter queries when implemented securely.

Properly Escape All User-Supplied Input

When other preventive measures fail, implementing this method can be effective. However, this technique is highly dependent on the database used. It involves escaping the user’s input before incorporating it into a query. Each DBMS supports specific character escaping schemes for different query types. By properly escaping all user-supplied input according to the escaping scheme specified for the database, the input will not be mistaken for developer-written SQL code.

If you require further assistance, please contact our support department.