views:

169

answers:

3

I'm implementing a Rails application in which users will be able to store snippets of code for later reference. I'm planning to use Markdown for text entry and will probably use the wmd markdown editor. (The very one Stackoverflow uses.)

I'm a little concerned about the idea of people entering code into the edit box. From what I understand, there's a danger of entering SQL that could screw up my DB, or of entering JavaScript that would get run later and do mischief.

Ordinarily, Rails has functionality to guard against this, but am I in a special situation here because my users will be encouraged to enter snippets of code?

Are there any extra precautions I should be aware of?

+5  A: 

Just sanitize your DB entries and you'll be ok. Rails does that by default now. You just have to use the framework correctly. Check this out for more informations: http://wiki.rubyonrails.org/howtos/security/sql_injection

DO THIS:

Project.find(:all, :conditions => ["name = ?", params[:name]])
# or
Project.find(:all, :conditions => {:name => params[:name]})

NOT THIS:

Project.find(:all, :conditions => "name = '#{params[:name]}'")

You also have to prevent XSS attacks by going

<%=h possible_harmful_text %>

For reference:

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include client-side scripts. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Vulnerabilities of this kind have been exploited to craft powerful phishing attacks and browser exploits. Cross-site scripting carried out on websites were roughly 80% of all documented security vulnerabilities as of 2007. Often during an attack "everything looks fine" to the end-user who may be subject to unauthorized access, theft of sensitive data, and financial loss. (via wikipedia)

and of course

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.[1] (via wikipedia)

marcgg
From Wikipedia, I take it? ;)
Lucas Jones
Yes of course ^^ I'll add the reference right now
marcgg
+3  A: 

You're not in a special situation because users will be encouraged to enter snippets of code. People can enter snippets of code in fields where they're not encouraged to. Basically, you should always be "extra careful". Don't trust user input.

Logan Capaldo
+2  A: 

You're actually in a safer position in accepting code samples rather than allowing actual code. By that I mean, e.g. Stack Overflow lets me enter actual HTML to control my post.

Allowing actual code is much more dangerous, because you'll be evaluating that code. In the Stack Overflow example, the site is actually evaluating input markup like <a href="http://example.com/"&gt;link&lt;/a&gt; -- which means it needs to be on the lookout for onclick handlers, etc. Thorough sanitization is much tougher than simply escaping.

So as long as you're not evaluating anything, you're in the same boat as any other site that accepts text input. Stick to the standard data input principles -- e.g. escape any and all input immediately before writing it anywhere -- and you'll be fine.

Aseem Kishore