In the security research world, getting Rickrolled has become a global epidemic. If you've been to any of the recent conferences, you're sure to have been Rickrolled at least once... if you were fortunate enough to be at ToorCon Seattle, then you got Rickrolled about 300 times by Dan Kaminsky.
This is a light hearted post, as I'm in a great mood after having just proposed to my long time girlfriend this weekend (she said yes, thank God!), and I just couldn't help but laugh about this one.
Marcin Wielgoszewski introduced me to Jeff Williams of Aspect Security (he also is heavy into OWASP contribution) who passed me an attack against a piece of code that de-morses morse code. Basically, Jeff crafted a morse code version of a cross-site scripting attack that will redirect the victim to a wonderful Rickroll. As the application de-morses the message, it of course get's rendered as HTML... geez.
In case you don't speak fluent morse, that basically translates into a redirect to a tinyurl site, which again redirects you to the youtube rickroll video.
I'd be re-missed if I didn't lurch into my consultant talk here and talk about the necessity to do proper input validation and output sanitization... oh, and while I'm at it, don't home roll your own input/output validation techniques... there's tons of good APIs out there that you can either get, or are already built into the language you are using. In fact, Jeff Williams has been involved in putting together a great one called the Enterprise Security API (ESAPI). Everyone seems to understand that using home-grown encryption is bad, when is everyone going to realize that using home-grown validation is bad?
Rolling your own encryption is to encraption as
Rolling your own input/output validation is to _______