How to remediate "OS command injection" findings in application penetration testing

Dear all,

We would like to ask your experts advice on how to remediate one of the findings in our application penetration testing: "OS command injection". Here is the details of the findings:

OS command injection

Operating system command injection vulnerabilities arise when an application incorporates user-controllable data into a command that is processed by a shell command interpreter. If the user data is not strictly validated, an attacker can use shell metacharacters to modify the command that is executed, and inject arbitrary further commands that will be executed by the server.

OS command injection vulnerabilities are usually very serious and may lead to compromise of the server hosting the application, or of the application's own data and functionality. It may also be possible to use the server as a platform for attacks against other systems. The exact potential for exploitation depends upon the security context in which the command is executed, and the privileges that this context has regarding sensitive resources on the server.

Hope you can help us resolve the issues.

Thanks and best regards,
Edna BrimonIT ManagerAsked:
Who is Participating?
btanConnect With a Mentor Exec ConsultantCommented:
All injection flaws are input-validation errors. We need to find all input streams into the application. This can be from a user’s browser, CLI or "thick" client but also from upstream processes that “feed” our application. The quick wins is to sanitise all the inputs by validating against (1) blacklisted injection pattern or (2) whitelisted inputs.

(1) Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected. Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks.

(2) Only short alphanumeric strings should be accepted. If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Rule of thumb is use stringent whitelists that limit the character set based on the expected value of the parameter in the request.

Overall, you can check out 3 main tips
Rule #1 (Perform proper input validation):
Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

Rule #2 (Use a safe API):
The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

Rule #3 (Contextually escape user data):
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
You will want to make certain that any areas in the application that accept user input (Forms for registering a user account, data input, etc) are designed in a way that prevents an attempt to "inject" commands to the Server by entering a string of text that is essentially a shell-based command. A quick but simplified version of this type of attack is entering "format c:" in a web form somewhere. If the application is not designed to reject that command or is designed to interface with the OS in a way that the form input is directly processed through the command shell, entering that command would allow a remote attacker to format the c: drive (This example doesn't really work, but explains what the attack can do).

The solution here is to add error checking or regular expression checks against any data that is received from a user. For example, blocking the use of special characters (!@#$%^(&, etc) with a regex or boolean expression against the input data would prevent the majority of injection attacks, since those types of attacks often rely on special characters. If a PenTest report showed this, the actions you need to take depend on the type of pen test. If an active attacker pen test was done and this is in your report, it means the attacker was able to execute shell-based code through the application's forms. If the pen test was an automated vulnerability scan, this may just be a warning that is part of every report. You'll want to get with the company that performed the test to determine the exact nature of this reported vulnerability, but also make sure that your app's forms are designed to prevent shell commands from being entered.
David Johnson, CD, MVPConnect With a Mentor OwnerCommented:
there is the infamous user 'drop table'
btanExec ConsultantCommented:
for author advice
btanExec ConsultantCommented:
For consideration since no further inputs received.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.