September 2010 Archives

I am writing this, because at this time it seems that twitter is vulnerable to the simplest of CSRF attacks. If you know what a CSRF is and how to avoid it on your code, you will probably not learn anything new, but you may have valuable input.

CSRF simply put stands for "Cross site request forgery". What that means is that some other website told your browser to do a request that would cause an undesirable action at the attacked website.

For example, consider the image tag:
<img src="" alt="you've been hacked!" >

While I don't use twitter, and I don't know the exact variables needed to send a CSRF, this is basically all a CSRF needs. If you happen to be logged into twitter, this code would cause your browser to try to retrieve an image at "" including all the browser cookies that would tell twitter that you are logged in, as well as post the 'hello world' to your twitter feed.

CSRF is simple to execute, but also relatively simple to prevent too. To avoid the worm type of CSRF right now, just forcing the user's id to be passed in as well, and to match the userid in the browser cookie would prevent all the current worm problems.

However If I didn't like you, and sent you an email sending you to a webpage that had the following image tag, I would still get you to post the 'hello world' message:
<img src="" alt="you've been hacked!" >

The best way to prevent CSRF is to include a 'nonce'. A nonce is just a simple random number id that your server remembers and requires before a post is allowed. 

CPAN is not much help at this time, I only found one module for CGI::Application that mentioned CSRF. . There were several others that mentioned nonces, but none appeared to be something that could be simply plugged into a web application.

How you remember a nonce between drawing the webpage and receiving the submission is left as an exercise for the reader at this time, but depending on your application, storing a nonce in the database attached to the user's record (one per user) would work, but would of course increase the writes to your database. One way to minimize writing load on your server is only to update the nonce each time the user posts new data to the application.This way you only update the nonce when already writing to the database, and can reject the submission if the nonce doesn't properly come back to the webserver via the form submission.

This however does not prevent Cross Site Scripting attacks (CSS). One of the most infamous of CSS scripters overcame several nonce mechanisms using javascript and AJAX to retrieve the required information.


C programmers

While I have nothing against C, or C developers, it hurts to program in a Perl App, when a C developer has been present:

if ( exists $self->[kCLASS_NDX]->{$class} )
at the top of the file there are a bunch of constants declared, instead of some oo:
if ( exists $self->class_index($class))
Or even just using perl constructs::
if ( exists $self->{'kCLASS_NDX'}->{$class} )

That really is the same thing as they wanted to begin with isn't it? It just hurts to look at this code.

Happy Labor day!

Frozen Perl planning has officially started. I need to get the sponsorship documents ready for everyone else to use, but we are well on our way now.

About this Archive

This page is an archive of entries from September 2010 listed from newest to oldest.

August 2010 is the previous archive.

October 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.