Safety of Raising Exception

rubyonrails-talk
1

Let's say I have a url like

/controller/method/id?some_param=whatever

if I put some_param into an exception, such as

raise MyException, "I don't like the value #{some_param}"

or

log("I don't like the value #{some_param}")

I'm trying to inject filesystem calls into the raised exception. I'm seeing some application failures, but haven't quite got it refined. However, it implies to me that it is having some effect on the application.

This seems to me the filesystem equivalent of SQL injection, but I don't see it listed anywhere.

2

Does this mean you're passing some_param to a system call? I guess the proper term for that would be "code injection" (http:// en.wikipedia.org/wiki/Code_injection).

You should escape some_param somehow before passing it to a call on the command line. If you could paste some example code of what you're doing, we could probably provide pointers on how to make it safe...

3

Sure, here's an example using log, and one using exceptions:

Assuming there is a parameter klass, which is used as the class for lookup:

/controller/method/id?klass=Blog

def list begin   raise SecurityError, "Class not found: #{params[:klass]}" if !params[:klass].legal_class? ... rescue => e   log.error("Cannot find class #{params[:klass]} #{params[:id]})   raise end

4

Sorry I'm a little lost. Nothing in that snippet seems like code injection unless #legal_class? is implemented insecurely. Or unless it's hiding in the ...

Care to reveal a bit more?

5

Really I'm concerned about the two lines:

raise SecurityError, "Class not found: #{params[:klass]}" log.error("Cannot find class #{params[:klass]} #{params[:id]})

where a user could pass code through the url parameters, and code injection occurs on the two message types.

I need to clean up my code, and then send an example. If you see any problems with the above, let me know.

6

There is nothing wrong with those two lines. Code injection is only an issue if you actually treat what the user gave you as code. In this case you're just telling ruby to dump strings. Ruby doesn't execute the contents in any way. There's very little security concern.

If you're unconvinced, then you can dump out the inspected versions of the strings. Most non-ASCII characters will show up as escaped octets:

  log.error("Cannot find class #{params[:klass].inspect} #{params[:id].inspect}")

7

Ah. So the reason SQL injection occurs in :conditions=>"something=#{params[:something]}" because the SQL command is dependent on a string. I wasn't clear on the distinction between the two evaluation contexts that are obviously safe, and the SQL injection example.

Thanks for the great help!