Declaration: This article is compiled and translated by Bypass for security research and learning purposes only.

Article source: medium.com/bugbountywr…

How to write secure code? Protect yourself from injection attacks!

I’ve been working on this issue for months, trying to understand what makes code vulnerable, and now I’ve received this simple answer – bad programming habits. This may seem obvious now, but a large portion of the programming community remains in the dark about this fact.

Understand the problem!

I mean penetration testing and having a dedicated team responsible for building the security of an application is amazing and always commendable, but it’s not affordable for everyone. Big companies can brag about their security practices, how they have teams working 24/7 to keep customer data secure, but so can those without the resources.

One of the biggest reasons we have vulnerable code in our most important applications — banking, airline, online shopping — is programmers.

That last line is sure to offend a lot of people, and let me say I didn’t mean to bash one community. I’m not going to do this because it’s not their fault, in the current age of programming, code execution times need to be as low as possible, and it’s totally understandable that they skip these parts to enhance their code.

So, I started taking notes that help programmers write safe code. I’ll try to cover the different types of attacks as well as the small adjustments programmers make to keep their code safe so that their organizations don’t have to pay again to keep their applications safe. I think I’ve had enough for today, so let’s cut to the chase.

Let’s dig!

Let me start with my definition injection and why it happens. An attacker entering malicious payloads can trick the interpreter into executing unexpected commands or accessing unauthorized data. Injection defects occur because untrusted data is sent directly to the interpreter as part of a command or query without the payload being checked or cleaned up causing all problems.

In this article, I’ll cover three different types of injection attacks and methods that you can use to prevent them:

1. SQL injection

This type of attack occurs primarily when an attacker adds a single quote (‘) to the end of a statement, adding OR to the total number of truth values following the statement. In simple terms, the SQL payload looks like this

Prime, or 1 = 1 minusCopy the code

The above statement added to the query can help an attacker gain access to the full database. To give you a better understanding of the following query, it will provide an attacker with the entire database.

SELECT * FROM Users WHERE UserName ='Aditya'OR 1 = 1--
Copy the code

Take a look at the code below and try to figure out if it is vulnerable to SQL injection attacks.

If you think the code above is safe, be sure to read on.

The reason the code is insecure is because the values entered by the attacker are passed directly as parameters. As long as the expected values are entered, but the user’s input may contain % 1 $TM, % 1 $te, and % 1 $tY format specifiers, you’re fine.

If the attacker passes in the value % 1 $tm for args [0], the result will be as follows.

05 Do not match! Hint: It was released on the 23rd of the month. // 05 is the month that users need to know to verify themselves.Copy the code

You can see that the program itself will come out the same month as the credit card expiration date.

To avoid this attack, the following code may be useful.

The only difference between the two codes is that in the first code, the value entered by the attacker is passed directly to the program, whereas in the second code, instead of passing the value, we print it out directly, rendering the whole attack useless.

Preventing SQL injection attacks should involve input validation. We must check the values entered by the user, and we must always assume that these values are not trusted, that they may harm the application.

We have to use parameterized queries with bound variables and clean up the user-entered values.

Parameterize and sanitize code

In the image above, we can see how passed values are cleaned up first before being used by the code.

2. Command injection

This is one of the most dangerous types of injection attacks and is still prevalent in today’s scenarios and doesn’t get much attention. This attack exploits a vulnerability that allows an attacker to enter and execute commands that the application does not expect.

Let me share with you an example that shows a basic implementation of a command injection attack.

In the image above, we observe that there is a text box where we need to enter the hostname/IP and the details about the IP address will be retrieved and presented to us.

The entire application seems simple enough, but it is susceptible to code injection. To understand we first need to figure out how the application works, then we can try to figure it out and then we can understand how code injection works.

When we enter the hostname/IP, the application actually calls the terminal and displays the output to us from there. The people who work with terminals they know that we can use ampersand in terminals to pass two different commands at the same time.

Thus, the figure above shows exactly how code injection works. To avoid this attack, the application needs to perform path validation (normalization followed by absolute path checking), and the application also needs to perform input validation and enumerate the commands it allows the user to enter and execute.

Enumeration {dir, CD, CLS}Copy the code

3. The JSON injection

This is an important injection attack, and the frequent use of apis in applications has increased in recent years. JSON injection works when we inject the payload into the PASSED JSON query as the API issues request and response queries.

The example is easy to understand. The application has a drop-down menu from which you need to select a PenTest tool option, and the application will show you the details of the PenTest tool you selected.

So let’s try to understand how this application works. Let’s open the burp-Suite and intercept the request made by the application.

 

So in the image above, we can see that the ToolId is being sent in the request query, and we add the payload to the ToolId to check if it is reflected to us in the response query.

We did receive the payload that we injected in the request query, so we can be sure that our injection attack will pass. Let’s execute the attack payload and verify that the attack is effective.

Seeing the response we received earlier, let’s pass this value to get the cookie value.

"}}); Alerts (in document.cookie); //Copy the code

Before passing the value in the parameter, we urL-encode it to avoid any special character constraints that may have been placed.

We can clearly see that the cookie value has been returned to us in the alert box, confirming that the attack has passed.

We need to examine how the attack actually looks in the browser and display the cookie details as needed.

The most effective way to prevent JSON injection attacks is to perform coding techniques on JavaScript. OWASP also provides a JSON fungicide that can be used for string validation.

String someValidation = JsonSanitizer. Sanitize (myJsonString);Copy the code

moral

The most important thing we can do to prevent injection attacks from occurring is to believe that any and all input from the client side could be an attack. Most programmers take it for granted that user input will not harm the application that causes most of the bugs in the application. Each input from the user must be sanitized, and the input must be validated prior to application use. Values entered by the user must not be passed directly to the program.

If programmers remember these things, they can surely defend against most injection attacks.