If you want to keep your web app secure, you need to be aware of three typical injection vulnerabilities: SQL injection, OS injection, and LDAP injection. It could mean the difference between your application being secure or not if you don’t yet understand how they operate, how to prevent them, or what they actually signify. Continue reading to find out more about these three weaknesses, how they operate, and how to guard against them.
For those who are not know, injection vulnerabilities are a particularly risky kind of attack. Injection attacks are characterized by injecting code that is interpreted on the website or application that is being attacked, allowing malicious activities and searches to be done, and, in the worst scenario, escalation privileges to seize control and steal sensitive information.
Attackers typically exploit a website or application that has been inadequately coded (albeit occasionally, we developers are aware that we are not being particularly careful). and thus makes it possible for an attacker to run commands or searches with harmful intent.
There are quite a few different kinds of injections, but we will concentrate on the three most significant ones:
- SQL Injection
- OS Injection
- LDAP Injection
1. SQL Injection
Because it involves the database we have connected to the application or website, a Structured Query Language Injection (or, for friends, SQL injection) is the most prevalent and serious injection assault.
With this kind of vulnerability, the attacker can access sensitive and private data by running SQL queries without authorization. Given that the majority of businesses lack adequate protection to fend off these kinds of attacks, it is crucial to understand how they originate and how to stop them.
How do you stop it?
Utilizing an ORM is one of the greatest methods to prevent this (Object Relational Mapper). An ORM enables us to convert our application’s objects into a suitable format so they may be saved in any kind of database. By doing this, we can save any SQL query and use it for every database operation (such as read, write, delete or update).
I advise utilizing Entity Framework for.NET.
The use of parameterized queries rather than direct queries is the second simplest method of preventing SQL injections. These parameterized queries are those where the values are passed using parameters of the SQL type.
var sql = @”Update [User] SET FirstName = @FirstName WHERE Id = @Id”;
context.Database.ExecuteSqlCommand(
sql,
new SqlParameter(“@FirstName”, firstname),
new SqlParameter(“@Id”, id));
Not recommended is contacting SQL strings anywhere in the code. Dynamic SQL is what is used in this.
Additionally, using an ORM still has the potential to be done accidentally, as OWASP cautions us in their cheatsheet series, thus they advise carefully verifying any components that might be weak. Let’s look at an OWASP illustration:
string strQry = “SELECT * FROM Users WHERE UserName='” + txtUser.Text + “‘ AND Password='”
+ txtPassword.Text + “‘”;
EXEC strQry // SQL Injection vulnerability!
Always attempt to connect to the database using a user who has the bare minimum of permissions. A user shouldn’t have write permissions if they won’t be writing to the database. Simple but powerful.
2. OS Injection
It has many different names (OS Command Injection or simply Command Injection). This kind of attack uses weak software to execute (inject) commands into the operating system by taking advantage of the absence of input validation.
The risk of this attack stems from the attacker’s ability to use commands to access private data, change system components, or even elevate administrator rights to start SSH connections or activate backdoors.
I’ll use a straightforward example:
Consider a scenario in which a user interacts with an application that requires a value input At first, the programme opens without issues, and so far nothing unusual (aside from the user’s lack of design knowledge).
Imagine, however, that the user also wants access to the application, website, or software, in addition to creating a cool logo. In this situation, contacting the malicious command with the original one is simple. For instance:
mspaint && echo "pwned"
As we can see, the user is able to run additional commands, and there is already a place where privileges can be escalated. Of course, if the application is susceptible to this kind of injections and is running with administrator privileges for some reason.
How to avoid it?
Verifying user input is the first step to preventing this. What manner? There are numerous methods:
- If there are commands involved, make a whitelist of permitted commands and see if the one the user input is on it. If not, don’t carry it out.
- In a similar vein, you can solely include the instructions that shouldn’t be run in a blacklist.
- When it comes to arguments, just like with commands, a list of permitted arguments must be defined.
- Verify the permitted characters. You shouldn’t let special characters in Regular Expressions if, for instance, the user is supposed to provide a name.
Example of special characters:
! \ ` < > $ | & ; In .NET we can use System.Diagnostics.Process.Start for this. Let’s see the OWASP example in its cheatsheetseries:
var process = new System.Diagnostics.Process();
var startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.FileName = “validatedCommand”;
startInfo.Arguments = “validatedArg1 validatedArg2 validatedArg3”;
process.StartInfo = startInfo; process.Start();
Even though there is a way to stop OS injection attacks with this, complete security is still not guaranteed.
Another approach is to send the data encoded (for instance, in Base64), which the application will then decode.
3. LDAP Injection
The least frequent of the three injection kinds is the Lightweight Directory Access Protocol Injection (LDAP Injection), yet it’s no less harmful. Because LDAP access resembles database access, particularly in web applications, it is somewhat comparable to SQL injection.
The primary distinction between these two sorts of attacks is that, while LDAP injection targets the user validation system, SQL injection targets the SQL server. It would then be possible for the attacker to manipulate users, change their rights, add new users, or even get access to other LDAP domain machines or zones.
OWASP LDAP attack prevention identifies the following as the primary causes of this vulnerability:
• LDAP query interfaces lacking safer, parameterized versions
• LDAP is frequently used to authenticate users to systems.
How do you stop it?
Escape from all variables is the main defense against these attacks. You must escape characters both in the DN (Distinguished Name) and the Search Filter, on the one hand.
Here’s a DN example:
cn=Juan España, ou=Cybersecurity Department, dc=dotnetsafer, dc=com
According to Ldapwiki, there are a few characters in this situation that are regarded as exceptional. They are as follows:
• Comma,
• Backslash character \
• Pound sign #
• Plus sign +
• Less than symbol< • Greater than symbol>
• Semicolon ;
• Double quote ”
• Equal sign =
Despite being allowed in DN, we must escape these characters by using the backslash ().
Ldapwiki: DN Escape Values is a good resource to consult if you want to learn more about the various character kinds and whether you should escape or not.
Microsoft, of course, has the answer for us with System.Web.Security for.NET.
Encoding strings with AntiXss’s primary function is to stop LDAP attacks (it is also used to prevent XSS attacks).