RETURN $ecure;

Just another rant about a remotely possible scenario. Earlier this week I had forgotten the password to the control panel of one of my sites. I went to recover the password and found out to my dismay, that you can use domains to actually change the password. I was curious so I put my domain in. I found out that my password was instantly changed to jibberish. This normally wouldn’t be a huge deal, but this host’s master ftp/sql/etc accounts are based off this same password, so if you used them for anything…they now are totally non-functional until you change your password and the scripts that use it. The password change form declares that I can’t use previous passwords(DO THEY KEEP A LOG!?). So, I can’t simply change it back and have all my stuff working again. That would be a weird DoS, eh? Write a script to automate this process and eat up all of the victims common passwords, while needing them to change a bunch of config files all the time. Sure, they can prevent it from simply creating alternate accounts for ftp and whatnot, but it’s still weird.

There was some talk on the WASC mailing list about CSRF recently, specifically with how to defeat tokens/nonce-based defenses. I have wanted to write about this for awhile but haven’t had the time. A quick rundown of the threads; people simply claimed that using XSS and other attacks to perform CSRF was the way to defeat tokens. Which while true, is also not specifically just CSRF. I’m a bit on the line here. I believe CSRF is a totally separate problem from everything else and simple tokens and captcha-like devices(not current image captchas, mind you; as per they blow.) are enough to defend against CSRF.

The real issue are other attack vectors that enable a malicious user to perform CSRF regardless of the tokens. XSS-enabled CSRF is the most common problem in this area. Forcing the user to do an arbitrary action is almost a non-issue to complete since it can be so easy. I mentioned this before during the HackerSafe era on sla.ckers and DarkReading, what matters at the end of the day is total site integrity.  Although you likely won’t ever reach 100% security, every little drop makes a big difference and further compromises the otherwise secure remainder.

On a slightly related note, I do have a few ideas to help — at the least slow down or; stop CSRF abusing worms. A site could implement an IDS-like system that would watch important site features/actions. If the activity of say, the logout button; increases dramatically, then you either have a large loss of user base for some other reason which is an issue into itself or there is a somewhat benign worm annoying your users. Or perhaps for repeatable actions(sending private messages within the site), an ‘impact’-like value that would increase each time it is done in rapid succession. If a user reaches a certain value, they are either spamming and/or propagating a worm and you should at least temporarily block the feature in question while you fix the issue.

Anyways, enough ranting! Keep an eye out. I’ll be releasing some semi-interesting stuff on worm history and future progression with specific regards to propagation and reach.