Encryption != Protection
Something that should be obvious, yet isn't always.
We'll use a relatively concrete example, without naming names or giving out links. Because while Encryption does not equal Protection, Encryption not equaling Protection plus scandalous leaks can equal very bad things. 
In any case:
Let's say you want want to pass some sensitive data from one site to another (in particular I'm thinking about single-sign on solutions, where a login persists between sites). In order to keep the information "safe" over the wires, you encrypt it (on the server, of course). I'll pseudo-code this so it's language agnostic for y'all:
-
function Encrypt data
-
return theData Encrypted
-
end function
-
-
function WriteUserLink
-
Write( <a href="http://othersite.com/page/?user=bob&password={Encrypt( bobspassword )}&todo=update">Click here</a> )
-
end function
Somewhere on your page, you call the "WriteUserLink" function which outputs a link to do something to the user, encrypting the password along the way*. Now, no-one will be able to see the plain text password if they happen to sniff the request or look over the users shoulder.
Hopefully you see the problem.
The scenario above is would be put in place where authentication on one site needs to carry through to another site (eg: a single sign on solution). When transferring a user between the two sites, the username/password combination is passed through, the password encrypted.
Well, my friends, you've just left the barn doors wide open.
Why? Because, in the scenario, anyone who grabs the url can now login as the user in question, simply by copy-and-pasting the url into their own browser. Depending upon the abilities given through the site, the nefarious agent may now be able to change the account password, and would then have complete control of the users account.
At the very least, use form (POST) variables - while they're visible in the request, they're not visible in the URL. A somewhat better approach would be to drop a cookie on the second domain from the initial site, with a fully encrypted payload. From there, the page on the second domain could read the cookie. Still not 100%, but way less transparent. Alternatively, if you have really sensitive data, a better idea might be to authenticate the user a second time on the other site - it's a slightly worse user experience, but virtually eliminates the possibility of the authentication data being picked up in between.
I'd love to offer more (and better) solutions - they're definitely out there (I am definitely not inventing the wheel on this one). I'll follow up on this post as I think/discover more about it...For the time being, just think carefully about how you implement things like this.
And keep your barn doors closed. Ahem.
* Please note: I am absolutely not advocating sending a username/password combination via querystring...this is just an example.
Binary Code » We Are All Worthy of “Dude, WTF?” wrote:
[…] My first year working at Chum, almost all I did for that year was refactor the existing VB code base. It was a brutal code-base, so nasty that Jay and I practically shared daily wtf?’s, err…, well, daily. Unquestionably the three of us improved those systems by many orders of magnitude. And yet I’m certain that every now and then Jay and Jonathan come across some of my old code that today makes them think “dude, wtf?”. […]
Posted on 26-Mar-07 at 4:31 pm | Permalink