Server-side errors in ASP
You would have hoped that Classic ASP was a long-dead dinosaur, but not so. Recently, I have been working on a large website written mainly in Classic ASP (VBScript) and I’ve been getting to grips with some of the absolutely atrocious code that I’ve seen.
There is a lot of database interaction on the site, and a lot of the server-side SQL is written in a way that basically invites injection attacks. As well as that, database connections are arbitrarily unclosed and input is mainly unchecked. This is code that I would have been comfortable with 10 years ago, when people on the web were more trustworthy.
In order to get around some of these problems, some code was inserted at a later date to force ASP to carry on processing after an error. This was mainly put in to stop errors from showing up on a production site. However, the side effect is that when there is a fatal error, processing carries on infinitely, or rather until the time hits the timeout. When a lot of these happen at the same time, the server can easily be slowed down, and in fact this was a problem we experienced recently with an attempted denial of service attack.
At the moment, I am working on migrating a lot of SQL code to use parameters which fixes a lot of the errors, such as type checking, quotes and prevention of injection attacks. As well as this, the cloaking code has been taken out, and instead we have a 500 error page which sends an email with the error. At least with this, users gets to see a meaningful error and we get to know what happened without the server going down.
As a result, we initially received a massive number of error messages which would have otherwise been hidden. I spent a lot of my time rummaging around legacy code fixing these errors, which consisted mainly of variables not being declared before being used and form input being too long or of the wrong type. However, these errors have now died down and it’s good to know that we now have a site which has less errors and better performance.