[Nitro] Security problems
Aleksi.Niemela at cs.helsinki.fi
Sat Nov 12 05:54:30 EST 2005
James Britt wrote:
>Emmanuel Piperakis wrote:
>>>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
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.
More information about the Nitro-general