[Nitro] Security problems

Aleksi Niemela Aleksi.Niemela at cs.helsinki.fi
Sat Nov 12 05:54:30 EST 2005


James Britt wrote:

>Emmanuel Piperakis wrote:
>  
>
>>>Dear devs,
>>>
>>>I am wondering if anyone has found (or can find) any security problems
>>>with Nitro. Moreover, If anyone can suggest any common security
>>>measures that could be wrapped in a controller helper/aspect I would
>>>like to know. Even urls for (authoritive) articles regarding web site
>>>security would be helpful.
>>>      
>>>
>>I am not sure if this can be done already, but I would like the path to be 
>>hidden. I would like to show only the main page URI. I think it is a 
>>security problem if a user sees things like http://myhost.com/project/1
>>
>>The users might type /2 by himself...
>>    
>>
>
>I see that as a feature, not a bug.
>
>  
>
I might even add that in the case when action 'project' is activated and 
it needs to make authorization the usual cases are:

1) check if current user (with possible other conditions, like 
time/frequency what not) is allowed to access the action
2) check if current user is also coming through a path of ulrs which 
allows him to do it

Usually 1) is quite easy to add as a checking if-clause to the beginning 
of the action, albeit those tend to grow and get more complex to the 
level it's much nicer to abstract them away.

Case 2) is harder. There are at least three ways around. Consider 
application where you're doing checkout through path

    fill in billing information -> confirm billing -> review bought 
items -> complete transaction through message "you're done"

Usually fill in stores information to the database to current order. 
Step 2 sends out the bill and changes order status to 'billed'. Step 3 
shows billed items again and step 4 marks the whole transaction completed.

People could write url 1 and click ok, then skip 2 by typing new url for 
step 3, clicking there ok and move on to page 4 to get transaction 
completed. In badly designed system they would accomplish this but at 
step 4 before marking the transaction 'completed' we need a bit more 
complex logic to check if we're really done.

2.1) One way is to check all the parameters that should have been set so 
far.
2.2) Another way is to store allowed next (and previous) pages to 
persistency, and check we're within those as actions start up.
2.3) Third way is to pass extra state in url as a parameter, a checksum 
which needs to match.

Web application framework like Wee only supports third way, to the 
extent it's the only parameter send ever. Therefore for user to cheat he 
must come up with random checksum to proceed to the next page and he has 
no room to bypass the action. Skipping pages is not possible. But it is 
possible to jump backwards and then forwards (up to the point where he 
was) at will. These possibilities can be limited by specifying certain 
path to be transactional, allowing only one way traversal.

----------

Aside these issues I'm more worried there are some built-in ways for 
users to execute Ruby code written by them, or examine current state of 
the interpreter and variables within. I'm also a bit worried current 
implementation doesn't detect (or attack) sql injection through nice 
tricks users may apply.

Also performance related attacks are currently not avoided at all, I 
guess. So basic "instead of this normal action run action_quick when 
load > 0.8 or >5 concurrent actions" would be nice. It would enable one 
to activate more caching or simplify contents in order to keep up even 
minimum level of service.

    - Aleksi




More information about the Nitro-general mailing list