Reading Time: 5 minutes

What is Remote Code Execution?

Remote code execution, also known as code injection, is one of the most common ways hackers compromise a website. This term encompasses multiple techniques which have one aspect in common. The attacker passes off their code as legitimate in the server's eyes, using a data submission method typically reserved for regular users.

Being hacked is one of the largest problems for any server administrator. It can grind your business to a halt, expose customer data and most importantly, damage a business's reputation depending on the extent of the damage. If you know what to look for, there are several ways you can protect your website against attacks.

What are the Different Types of Remote Code Execution?

SQL injection

Let’s look over a few common example of remote code execution. Many of these vulnerabilities take advantage of how SQL statements are constructed. When creating an application that reads usernames from a database, developers may be tempted to use code like this to search for a particular username:

SELECT * FROM users WHERE name = 'username'

What is the problem with that query, you may ask?

Any visitor, even those with malicious intentions, can enter a username. For example, they could enter ' OR '1'='1' --, resulting in a query which executes a sql statement that looks like this.

SELECT * FROM users WHERE name = '' OR '1'='1' --'

Now, supposing our application then searches through the database for usernames and selects the fields where the name is blank. When the number 1 is equal to 1, the second part is always true. This will end up providing every single username within the database.

Data leaks like this are not the only concern with SQL injection. Potential attackers could send multiple commands to your database, which possibly deletes or overwrites data. 

Cross-Site Scripting

Cross-site scripting is another remote code execution vulnerability that affects visitors, instead of servers. In a webpage, content and code are rendered in the same way. The browser can tell code apart because it is wrapped in <script> tags. This means that without proper filtering, an attacker can add malicious code to anywhere they’re allowed to add text. This would include fields like a comment box, search bar, or even a display name and the browser will run this code. 

Cross-site scripting would not be a major problem if it only was executed within the attacker’s browser. But, when it is made public such as a comment box, it will also affect any visitors that see that content. With the ability to execute any remote code, the attacker can steal passwords or impersonate other users. This video shows a step-by-step breakdown of one such attack, which affected Twitter’s TweetDeck platform several years ago. 

Directory Traversal

This kind of attack is not aimed at the application itself, or even at visitors. The primary target here is the website itself. This vulnerability relies on the way files are stored on your server's file system. 

Typically, data is stored inside a directory such as /home/user/public_html. Scripts inside this directory can access files using a relative path, such as wp-admin/index.php to refer to /home/user/public_html/wp-admin/index.php. If scripts are configured to access files outside their current directory, they can accomplish this adding a "../", which refers to the directory above the current one. For example, this directory pattern /home/user/public_html/../ is the same as /home/user/

When scripts are allowed to upload or read from a custom filename, attackers can direct your application to traverse directories with a name like ../../../../../../../../../etc/passwd. Without security measures like input filtering, this would end up giving them access to core files on the server. 

Preventing Remote Code Execution?

All the above information is not meant to cause fear or intimidate. It is however intended to stress the importance of having robust security measures in place. These remote code execution attacks can be stopped or mitigated by simply being aware of and preparing for them in advance. We should always anticipate and know how our server handles user-provided information. 

The best way to stay secure from a remote code execution vulnerability is to have multiple layers of defense. Even if one layer were to fail, we would still be protected. Here are some of the most common steps to take to prevent these types of attacks.

1. Validate User Input

The first place to prevent this type of vulnerability is where the user interacts with your application. The easiest method is to filter and remove any undesired characters. Another option is to preserve the content by escaping it. 

Escaping is the process by which we tell the computer to take something which looks like code and treat it as regular text instead of actual code. From example, a <script> tag noted previously should be replaced by "&lt;script&gt;". This way, the web browser knows it should display the less-than "&lt; and greater than "&gt; symbols at those locations, without actually treating the entire string as code. The result will be invisible to the user.

2. Use Established Software

Escaping works excellent as a first line of defense, but there are other ways code can be interpreted by the browser or server beyond script tags. Trying to keep track of them all will get very complicated, very fast. Luckily, developers have given thought to this problem. Using a reputable and trusted Content Management System or CMS, such as WordPress, provides solutions for us. This is why it is essential to keep software up-to-date. If a vulnerability is discovered, developers work around-the-clock to patch any newly discovered weaknesses. This includes both themes and any plugins used.

If we use a custom CMS application, we can stay safe from SQL injection attacks using parameterized queries. This type of query tells the application in advance what type of query we are going to run. It can then recognize and remove extra commands which may try to be inserted. Instead, it sends the original query, without the added string.

Here’s what our example from above would look like using a parameterized query:

$query=”SELECT * FROM users WHERE name = ?”
$results=$query.execute(“ ' OR '1'='1' --”)

This time, the database handles ' OR '1'='1' correctly. It sees this query as a string of text, and realizes that there’s no user associated with that name.

3. The Principle of Least Privilege

In rare cases, a 0-day vulnerability may arise that neither you nor the CMS developers are aware of. We can still limit the power of attackers by setting smart rules about what our application can do. For example, if we are designing an application that only reads from a database, it is unnecessary to give the app permission to write or delete records. This way, even if an attacker were to attempt to compromise a script, they encounter an error. 

Another area where the principle of least privilege is useful is within PHP functions. These are a popular target for attackers online. Powerful functions that may not be necessary for your application, such as exec() (which runs code passed as text) or ini_set() (which lets you change PHP settings from within a script), can be disabled to prevent them from being used by attackers.

This idea not only applies to server-side code but can also secure the public-facing section of your website.

Content-Security-Policy is an HTTP header used by modern browsers to determine which content they’re allowed to load on your site. By sending headers from our web server or application, we can specify the script types that can run and what locations. This tactic prevents attackers from injecting and using their scripts. 

You can also prevent cookies from being read by scripts or sent on requests to other sites by setting them with the HttpOnly or SameSite=Strict attributes. Even in the worst-case scenario where an attacker’s code ends up running on your website, this will prevent them from accessing your user’s authentication cookies, significantly limiting the damage they can make.

Liquid Web Security Products Can Help!

It’s normal to feel a bit overwhelmed when learning about all the threats lurking out there. Luckily, we are here to help. Our Managed hosting products put the administration of your website in the hands of our experts. Simultaneously, our Server Protection and Vulnerability Scanning add-ons give you extra peace of mind if you’d still rather be leading your server administration.

We pride ourselves on being The Most Helpful Humans In Hosting™!

Our knowledgeable Solutions or Experienced Hosting advisors are always available to show you how you can take advantage of these techniques today!

We are available 24 hours a day, 7 days a week 365 days a year, via our ticketing systems at support@liquidweb.com, by phone (at 800-580-4986) or via a LiveChat or whatever method you prefer.

We work hard for you so you can relax.

Avatar for Isaac Noboa

About the Author: Isaac Noboa

Former support technician, budding software developer, and general tinkerer. If there's one thing Isaac enjoys more than understanding how systems work, it's helping others do the same.

Latest Articles

Blocking IP or whitelisting IP addresses with UFW

Read Article

CentOS Linux 7 end of life migrations

Read Article

Use ChatGPT to diagnose and resolve server issues

Read Article

What is SDDC VMware?

Read Article

Best authentication practices for email senders

Read Article