Stress testing your protected pages
Posted by rick April 19, 2006 @ 08:13 PM
David came up with a quick tip for anyone stress testing protected pages with a stateless tester, such as siege.
- Log in with your browser
- View the cookies and find the session id (Firefox has a handy cookie search tool)
- Prepend the queries with ?_session_id=YOURSESSIONID
Now, any requests made will be as though they came from your account.
Do you have any other handy tips for stress testing your Rails applications?

As stated in the Agile Web Development with Rails book on page 475, you can fetch pages with a session id as cookie using ab with the option -C “_session_id=YOURSESSIONID”.
Shouldn’t secure web applications at least check the user agent string before it accepts a sessionid from a different IP?
Certainly not. The session id is a (presumably) secret value that is hard to guess, while the agent string is a (possibly) public value that is easy to guess.
I can’t think of any plausible threat model that is addressed by your suggestion. Did you have something specific in mind?
Brandt,
Probably something like this: http://www.imperva.com/application_defense_center/glossary/session_hijacking.html
I had the same thought when I saw this hint.
If this functionality is already in rails it wouldn’t be a far stretch to support users without cookies by putting the session ID in the query string, would it?
I agree with Sammy and Nico, as it is what I originally thought as well. Is there any way to turn this feature off?
I’ve actually been getting ready for a set of ruby/rails stress tests to help justify it as a capable solution. I’ve been using railsbench (http://railsbench.rubyforge.org/) to get a baseline for the differing OSs, and figure out where our prototype slows down. The big frustration there is railsbench’s lack of support for POST.
Besides that, I’m planning on using apache flood for the harder hitting tests. Using the XML configuration is a bit obtuse, but it lets me reflect the actual load from a community of users far more accurately than alot of test platforms. I forgot about siege, I’ll need to take a look at it again.
Now if only I didn’t look like a fool fighting with rails for mssql 2000 support. gragh.
if you mind about session hightjacking you could retrieve the client ip in a before_filter, store it in the session itself and invalidate the session if the ip changes later on.
this will at least prevent cookie theft from another machine.
best protection for your cookies akaik is to use https.
i think you mean ‘append’ and not ‘prepend’??
The Macromedia Flash 8 FileReference.upload() function uploads files by sending a multipart POST request to the server. Unfortunately, there is a bug that prevents Firefox cookies from being sent along with the request, so a different Session is created. I’m having my Flash code use ExternalInterface to call a Javascript function on the page with the Flash movie. The JS function returns the _session_id from the user’s cookie, which Flash then uses to append to the request it sends to the server when uploading a file (as described in this post). However, it seems that in certain situations (mine being one of them) Rails and the Ruby CGI class fail to use the correct Session as passed in through the params. This is described at http://dev.rubyonrails.org/ticket/210 and there is a patch which doesn’t apply to my situation (as I cannot modify the form that Flash sends to the server, to include a hidden field with _session_id). Is there some (ugly and hackish) way that I can switch to the appropriate Session manually, once I have the correct Session ID?
Any answer to Kaveh? I know this is hijacking the thread a little bit, but I’ve spent too many hours today trying to solve a very similar problem (except mine’s from a Java applet perspective and not Flash).