What is a Command Injection?
A command injection is an exploit of a system weakness to gain access to the system for the purpose of executing malicious code, harvesting user data, and engaging in other activities. While there is a potential for a command injection to be benign in nature, usually it is not, and it can present a significant security threat. There are a number of workarounds designed to prevent this activity in computer systems.
One of the most common points of vulnerability for a command injection is a form, either on a web page or in a computer system. Forms allow people to input data and are then processed by the system. If there are no constraints on the type of data entered into the form, it is possible for people to input computer code that the system will read and execute. Forms on webpages may also convert the input to display to other users, exposing other people to code as well; for example, someone could leave a malicious script in the comments on a website.
When the code executes, it may do things like providing people with access to the backend of a computer system, including administrative access, and could also plant viruses and malware on a computer system. Command injections may be designed to spread themselves, as infected computers interact with uninfected computers over a network. They can spread very rapidly and may cause substantial damage along the way.
One way to avoid a command injection is to design forms and other inputs in a way designed to restrict what people can enter. On Internet comments, for example, there would likely be no legitimate reason for users to enter scripts, and the comment form could simply reject script, while still allowing HTML for markup and styling. Likewise, in a computer program, the input forms could refuse inputs of certain characters, preventing people from executing code in the form.
The potential risk presented by the command injection was first noted in the 1990s. Numerous designers have tackled the problem and come up with various ways to prevent or stop command injection attacks. Hackers have also attempted to develop their own workarounds, developing new and creative ways to execute code through weak points in a computer system. Some people develop new techniques out of purely academic interest and occasionally wreak havoc by accident when their research escapes into the wild, so to speak.
@allenJo - You are correct that they wouldn’t be able to guess. But they could deploy a virus or malware that would issue an OS command injection to get a list of tables in your table and email that information back to the host.
That’s one workaround. Another workaround is that the hacker may in fact work for your company or may have once worked there. In that case, they already know where the goods are. That’s why you have to constantly be alert; you almost have to have a SQL injection scanner that works around the clock to block execution commands from external inputs. That’s the only way to be permanently secure in my opinion.
@NathanG - Yeah, we were taught to be on guard against a SQL injection attack. What you’ve described is one approach to preventing such an attack. It should be pointed out however that executing such an attack requires knowledge of the underlying database structure.
In the example you gave, how would the hacker know you had a table called Accounts? He might be able to assume that you did, since it’s a fairly common table name for account information.
If he were guessing, he would no doubt get lucky. To foil his luck, then, you have to change your table names. This is a design decision that needs to be done from the start, as you are building your database.
Give each table a name that is slightly different than what you would expect, even if means a slight alteration like calling your Accounts table “xrzAccountInfo.” That way, the hacker couldn’t guess (within a reasonable time frame).
When I was studying computer security we learned about the SQL injection attacks, which are the most common form of command injections. SQL is structured query language and it is the querying language use to query underlying databases. The problem is that it can also be used to alter the data in those databases too.
So for example, let’s say someone is taken to your contact form, and instead of entering his message, he enters “DROP table Accounts,” which basically deletes your Accounts table. If the form “executes” that query, your Accounts table is gone forever.
How do you prevent against this? Well as the article points out you can add code in your form to prevent it from executing SQL. That way everything entered in the contact page is treated as a message, not a command to be executed.
Post your comments