Script Language Injection

What is a script language injection?

A script language injection is a flaw mostly present in the web. Script language injection occurs when a programming language uses user input to execute code without filtering it. This vulnerability is similar to the OS command injection but differs in the way that it is executed.

Let’s take the diagram of a command injection:

In this example, the server will execute a command on the operating system that hosts it, so commands specific to different shells can be injected.

 

Now let’s look at the script language injection:

Here, the server itself executes a command specific to the language it uses.

An attacker must then use language-specific functions.

However, most of the languages used on a server can interact with the operating system, so the risks are similar to the OS command injection.

However, when command injection is only located on the server side, a script language injection can be performed on the client side if the javascript used allows it.

Impact of a Script Language Injection

 

The script language injections have the following impacts:

 

OS Command Injection

Script injections allow to perform command injections with functions like system() which executes a command on the OS. 

See Command Injection article for more information.

 

SQL Injection

If the victim server uses a database, it is then possible to perform SQL injections and have risks like you’ll find in the SQL Injection article.

 

Cross Site Scripting (XSS)

When a script language injection vulnerability is located on the client side, the application becomes vulnerable to reflected XSS, the consequences of which can be multiple. Find them in our Cross Site Scripting article.

 

How can a hacker inject code?

  1. One client side and one server side vulnerable

To illustrate a script language injection attack, I will use the example of a web application containing 2 vulnerabilities: one located on the client and one located on the server side.

It is advisable to have followed the articles on command injections and Cross Site Scripting in order to understand what a command is and how a reflected XSS works.

The vulnerable website helps you to train on math, a “Generate” button displays a random equation and a form to be completed.

  1. Exploiting server-side Script Language Injection

On the form, Loris, the hacker, will try to enter a Shell order.

It ends up with a PHP error message.

It then understands that its input is processed by the eval function, a function for executing PHP code in a PHP program.

In order to be able to execute Shell commands, it will then transform its input into:

The system function will allow to execute any Shell command, and the code executed by the server will then look like this:

By doing an ls, Loris sees a file named “routes.txt”,

Using cat on it, Loris ends up with all the paths available on the website, including “/{endpoint_name}” which is not visible on the web page.

  1. Exploiting client-side script language injection

By going on it, Loris finds a classic page.

Looking at the HTML code, he notices a <script> section calling the eval function, working similar to the eval function in PHP but with Javascript code. This function seems to use a parameter in the URL.

It is therefore possible to make a browser execute javascript code thanks to a parameter in the URL.

By using code to redirect an administrator’s cookies to his server with ‘document.cookie’, Loris would then have access to an account with elevated privileges.

Therefore, it only needs to build its code for a reflected XSS:


Then he places it in the “value” parameter of the URL.

Finally, using a bit of social engineering, he just has to send an email to a site administrator.

 

What are the protection mechanisms against script language injection attacks?

To protect against script language injection attacks, the recommendations for other injections apply:

  • Filter all user entries.
  • Allow only certain values to restrict a user’s scope of action to the maximum.

However, script language injection attacks are very dangerous and can lead to huge consequences.

Moreover, such functions are usually easily replaceable.

It is therefore preferable never to use a function that executes code entered for the user.

How to protect yourself from script language injection attacks with R&S®Cloud Protector?

 

R&S®Cloud Protector allows to protect web applications thanks to its syntax engine which allows it to detect the grammar of the different languages used on the server side: PHP, Java etc…

In this example, R&S®Cloud Protector will find 2 malicious pattern: « if () { } » et « system() ; » and give them a score.

If the final score is higher than the authorized limit, the request will be blocked and the user will be redirected to another page.

Request your 14 days free trial

It takes only 60 seconds to protect your websites and applications.
What are you waiting for?