Command Injection

• Command injection is where your application handles underlying operating system commands and the attacker bypasses this to execute malicious OS commands. Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

Please note that This attack differs from Code Injection, in that code injection allows the attacker to add their own code that is then executed by the application. In Command Injection, the attacker extends the default functionality of the application, which execute system commands, without the necessity of injecting code.

• Command Injection looks like this: image explain.
  • That’s all that is required for an attacker to gain full access to your system. In such a case all of your data could be stolen, modified, or deleted. Not code that you want to be responsible for writing! So how does an attacker leverage this code? Since the user is able to provide user_supplied_path they could do this:
  • This gives the attacker full access to the details of your database.
• If your application has to execute commands in the underlying operating system, there are several methods in Ruby: exec(command), syscall(command), system(command) and command. You will have to be especially careful with these functions if the user may enter the whole command, or a part of it. This is because in most shells, you can execute another command at the end of the first one, concatenating them with a semicolon (;) or a vertical bar (|).
• Ruby offers a function called eval which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.
• When using ImageMagick to manipulate images, Rails makes a shell call and passes command line arguments to an executable. If those arguments come from a user-supplied source, they could be crafted to cause ImageMagick to use excessive CPU or time.
• What are the Possible Risks? - The likeliest scenario is a denial of service attack, where the user causes ImageMagick to consume enough CPU or memory resources to bog down the server. It’s also possible to delete or overwrite files by passing in additional options to ImageMagick.

What can I do against ImageMagick Command Injection in Rails? When you’re dealing with a list of known parameters, as here, it’s easiest to validate user input against a regex or set of known secure responses. The Dragonfly library, for example, does a good job of checking user arguments (e.g. resize requests) to make sure they’re safe:

`RESIZE_GEOMETRY = /\\A\\d*x\\d*[><%^!]?\\z|\\A\\d+@\\z/ # e.g. '300x200!'`

demo

• A countermeasure is to use the system(command, parameters) method which passes command line parameters safely.
  • system("/bin/echo","hello; rm *")

  • prints "hello; rm *" and does not delete files

• To safely protect from Command Injection, call your command by breaking each piece into a seperate string. Here’s an example:
  • system("ls -a -l -@ -1 #{path}") #No
  • system("ls", "-a", "-l", "-@", "-1", path) #Yes

CSS Injection

• CSS Injection happens when a malicious party is able to alter your webpage by making use of user-defined styles. If your Rails application allows users to define a color which is then served back through CSS using a view:

  <div style="background: <%= user.background_color %>;">

  Then a user could supply a value which alters the page layout or content. A major risk of CSS injection is abuse of the content directive to rewrite a page’s content. Additionally, if a user is able to edit the style of forms seen by others, they could trick those users into putting personal data in the public.

• CSS Injection is explained best by the well-known MySpace Samy worm. This worm automatically sent a friend request to Samy (the attacker) simply by visiting his profile. Within several hours he had over 1 million friend requests, which created so much traffic that MySpace went offline. The following is a technical explanation of that worm.

  • MySpace blocked many tags, but allowed CSS. So the worm's author put JavaScript into CSS like this: <div style="background:url('javascript:alert(1)')">
  • So the payload is in the style attribute. But there are no quotes allowed in the payload, because single and double quotes have already been used. But JavaScript has a handy eval() function which executes any string as code.
  • The eval() function is a nightmare for restricted list input filters, as it allows the style attribute to hide the word "innerHTML":
  • The next problem was MySpace filtering the word "javascript", so the author used "java<NEWLINE>script" to get around this:
  • Another problem for the worm's author was the CSRF security tokens. Without them he couldn't send a friend request over POST. He got around it by sending a GET to the page right before adding a user and parsing the result for the CSRF token.

• This example, again, showed that a restricted list filter is never complete. However, as custom CSS in web applications is a quite rare feature, it may be hard to find a good permitted CSS filter. If you want to allow custom colors or images, you can allow the user to choose them and build the CSS in the web application. Use Rails' sanitize() method as a model for a permitted CSS filter, if you really need one.

• The easiest way to prevent injection attacks is to validate user-provided values. Instead of giving end users the ability to set their own values, you can also give users a pre-defined list which you’ve already validated.

AJAX Injection

• Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a traditional (i.e., “pre-web”) application. Since AJAX is still a new technology, there are many security issues that have not yet been fully researched.

• AJAX uses the XMLHttpRequest(XHR) object for all communication with a server-side application, frequently a web service. A client sends a request to a specific URL on the same server as the original page and can receive any kind of reply from the server. In the case of accessing an AJAX page on a non-SSL connection, the subsequent XMLHttpRequest calls are also not SSL encrypted. Hence, the login data is traversing the wire in clear text. Using secure HTTPS/SSL channels, which the modern day browsers support, is the easiest way to prevent such attacks from happening. XMLHttpRequest(XHR) objects retrieve the information of all the servers on the web. This could lead to various other attacks such as SQL Injection, Cross Site Scripting (XSS), etc.

• Countermeasures - CLIENT SIDE

  • Use .innerText instead of .innerHtml¶

  The use of .innerText will prevent most XSS problems as it will automatically encode the text.

  • Don't use eval

  eval() function is evil, never use it. Needing to use eval usually indicates a problem in your design.

  • Canonicalize data to consumer (read: encode before use)

  When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep its logical meaning. Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved.

  • Don't rely on client logic for security

  Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic.

  • Don't rely on client business logic

  Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly.

  • Avoid writing serialization code

  This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality.

  • Avoid building XML or JSON dynamically

  Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library or safe JSON or XML library to make attributes and element data safe.

  • Never transmit secrets to the client

  Anything the client knows the user will also know, so keep all that secret stuff on the server please.

  • Don't perform encryption in client side code

  Use TLS/SSL and encrypt on the server!

  • Don't perform security impacting logic on client side

  This is the overall one that gets me out of trouble in case I missed something :)

• Countermeasures - SERVER Side

  • Use CSRF Protection

  We will learn more in the CSRF section! (Next section)

  • Protect against JSON Hijacking for Older Browsers

    • ALWAYS RETURN JSON WITH AN OBJECT ON THE OUTSIDE

    Always have the outside primitive be an object for JSON strings:

    • Exploitable: [{"object": "inside an array"}]
    • Not exploitable: {"object": "not inside an array"}
    • Also not exploitable: {"result": [{"object": "inside an array"}]}

  • Avoid writing serialization code Server Side

  Remember ref vs. value types! Look for an existing library that has been reviewed.

  • Services can be called by users directly

  Even though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!).

  • Avoid building XML or JSON by hand, use the framework

  Use the framework and be safe, do it by hand and have security issues.

  • Use JSON And XML Schema for Webservices

  You need to use a third-party library to validate web services.