Web Application Security : Solutions

4 Solutions
 

4.1 Some Ideas

There are a number of ideas to fix this two security problems. The basic approach is to create a library of ASP functions which can be used without much hassle. The advantage of this is that it can be used very easily. But it’s not the best way, because you need to think of it every time you read some request. The one and only place where you forget to use this functions might be the door for an attacker. The other major disadvantage is that this requires a system for code sharing to ensure that every Web application uses current functions.

        Combined with the ASP functions it’s possible to create a checker tool that reads the source files on the server and tries to detect the parameters which aren’t checked. This could even be automated using command line options and/or a configuration file.

        Another idea that floated around in my head was to create an ISAPI filter, so that you don’t have to rewrite the applications. This would be a great advantage, but it has some disadvantaged. The most serious problem is the fact that in the ISAPI filter you can’t know whether to protect this query against SQL injection
or cross-site scripting. As we have seen, both need different filtering. It might be possible to solve this using some configuration files. I have decided not to dig into this for the moment, because it would be quite time consuming.

       As I find the idea of the checker tool very sexy I decided to implement the ASP
functions and a checker tool.


4.2 ASP Functions

          Appendix A shows the code for an include file that provides the necessary functions to protect against XSS and SQL injection. cHtml protects against cross-site scripting using the approach 1 (see section 1.1). The functions starting with the letter“n” (you guessed it, “n” stands for “new”) are equivalents for the corresponding VBScript function, e.g. CInt or CStr.

4.3 Checker Tool

        When using the ASP functions it’s crucial that they are used every time when you process request data. The one single request where you forget that can be the wide open door for an attacker.
        I created a prototype of such a checker tool. The idea is to get a list of the vulnerable files so that they can be fixed. It is written in Perl because Perl is great for rapid development and provides great string functions. It is also available for the Microsoft Windows platforms.

4.3.1 Algorithm
    1. Find statement which reads request data
    2. Does the data get sanitized using one of the ASP functions?
    3. If no, mark the line as vulnerable
    4. Continue until end of file
The code is presented in appendix C.
 

4.4 Configuration Changes
        There are some configuration changes that can be done to restrict the attackers when exploiting SQL injection bugs. First you can tell IIS not to give detailed error messages when an error occurs. So it gets a lot harder, though by far not impossible. Additionally you should remove all extended stored procedures. With
them it’s possible to harm the whole system. For example with xp cmdshell it’s possible to add users, delete files, put files on the server,