All posts in Security

Last week two security researchers, Thai Duong and Juliano Rizzo, have discovered a bug in the default encryption mechanism used to protect the cookies normally used to implement Forms Authentication in ASP.NET.

Using their tool (the Padding Oracle Exploit Tool or POET), they can repeatedly modify an ASP.NET Forms Authentication cookie encrypted using AES and, by examining the errors returned, determine the Machine Key used to encrypt the cookie. The process is claimed to be 100 percent reliable and takes between 30 and 50 minutes for any site.

Everyone immediately focused on the bug not mentioning what is commonly known as good practice and applied to every production site by any decent software developer “Never expose your production server errors (exceptions) to the client” failing to do so exposes your server to a number of threats not only the one described in the above security vulnerability.

There are several ways you could achieve that and Scott Gu mentions the easiest one in his blog post. An other way you could hide errors from your clients is by handling the Application_Error event in the web app’s Global.asax like this

void Application_Error(object sender, EventArgs e)
    Exception ex = Server.GetLastError();

                //Log any way you feel like

  catch (Exception ex){	}

The Microsoft Anti-Cross Site Scripting library is an encoding library designed to protect ASP.NET applications from cross-site scripting (XSS) attacks. This library differs from other encoding libraries in that it uses the the principle of inclusions technique to provide a high degree of protection against XSS attacks.

For those of you that build Web Applications this is a library that should always be used.

Recently I came to realize the real threat spammers pose to the Internet community. After trying for two days (30 hours) to find out why a web application, that was up to recently flawless, was not responding on a non deterministic basis, I discovered (the hard way) that it had been exploited by spammers, in order to send their emails. Sending thousands of emails each day the spammers have actually accomplished a DOS (Denial of service) attack on it.

So what’s the lessons learned here…

a)      Design your web applications having security always (I don’t know if I’m emphasizing “always” enough) in mind. Don’t rely on software or third party infrastructure to secure your application.

b)      Provide only the required by the spec. set of services to the users as it is more than certain that they will be targeted by malicious users.

c)       Don’t rely on third party components to be secure. Test them you’re self before using them in your application.

d)      ALWAYS enable logging for your web applications.

e)      When an application you built fails for reasons you can’t figure out, check the web server’s logs. The information you’ll get might help you find the problem even faster than debugging (if that’s even possible).

I could go on and on with advice, but I think I got the most important ones. Hope this helps the next guy that will fall into similar kind of problem…

P.S. Now that I mentioned spam, I’m starting to get really annoyed with the number of spam I receive each day. It’s not only the waste of my time (My Outlook spam filter actually saves me from having to go through the trouble of handling spam) but of bandwidth as well. I’m thinking of removing my email address from my site. Does anyone have any suggestions?

Continuing my Vista setup and exploration, I begun installing all the software and components I used in order to develop software. Most of the MSI installation packages (including Microsoft’s CAB) though failed to complete under Vista.
It seems that some kind of privileged action needed in order to complete the installation, which is probably write access to the program files directory in order to write an InstallerState file is not allowed not even when the executable is running under an administrative account. The error message says that “Access to the path c:program filesprogramprogramInstall.InstallState is denied (P.S not event the administrator can change the access rights). The installation completes successfully though when a different installation path is specified (e.g. C:Program).
Ok it’s nice to protect the OS from various things that could damage it but from the experienced user’s perspective it gets really frustrating having to confirm every administrative action through a dialog or not allowing write access to the Program Files folder.