If you are a developer, a couple of things are probably already clear to you without any further explanation – you should build all of your applications so that they are quick and always able to perform at the very best of their ability, your applications should also be available to the end-user 24/7, and they should also be secure. Security is one of the key aspects of any kind of application – without security, doors to your application(s) for a nefarious party are wide open. However, while many developers know about SQL injection, some attacks are just as dangerous, but overlooked. One of such attacks is Remote Code Execution, which is also frequently shortened to RCE.
What is RCE And When Does It Occur?
Remote Code Execution, or RCE for short, is a type of attack directed at web applications where a nefarious party (or an ethical hacker testing the web application for vulnerabilities) is allowed to execute code on a remote machine without physically having access to it – in other words, via the Internet.
Remote Code Execution attacks usually employ benign-looking functions in Linux utilizing them to do harm to a certain server of a web application.
The functions employed to do harm by attackers include, but are not limited to:
shell_exec()which allows an attacker to execute certain commands via a shell command and returns its output as a string value.
system()which executes a given Linux command or program and displays its output.
passthru()which can also be used to execute an external program and display the output.
eval()which evaluates a given string as PHP code.
RCE usually occurs when developers allow user input to be injected into a given input field (or sometimes a file) and executed. Making such a vulnerability available to exploit to attackers is pretty easy: when such a vulnerability is successfully exploited, a given web server can be (sometimes completely) compromised.
How To Protect Against RCE?
Now that we know what Remote Code Execution attacks are, it‘s time to learn how we can protect ourselves (and our web applications) from it. We are in luck here because protecting our web applications from Remote Code Execution attacks is pretty simple – a very quick and easy way to do that would be to never evaluate input supplied by a user by any command that can be used to cause harm to a web server (refer to the list of functions specified above.)
Protecting against the exploitation of such a vulnerability is indeed easy, but an often overlooked task. Protecting against RCE isn’t the only task you need to focus on, too – overlooking other flaws (SQL injection and the like) could land you in big trouble as well. To avoid being a target of attackers, consider employing the API possibilities offered by BreachDirectory to protect yourself and your employees, and after you’ve done that, learn from the data breaches that had already occurred in the past. Do that, and we will see you in the next one!