Securing a Server against Web Application scanners

Treat all data as hostile

No data should ever be inserted into a database, echoed to a user, or manipulated in any way until it has passed a rigorous set of validation tests. At each test, make your functions verify good data rather than to try to cull bad data. This may mean that valid but unforeseen data will be rejected, but this is better than invalid data being let through because it was encoded in an unforeseen way. Only after the data has been verified as completely benign should it be used in any fashion. Verify all data on the server, not on the client; Client checks can be easily spoofed.

Example of verifying good data rather than culling bad:

In the below example, modified from Writing Secure Code, the function checks to see if the error is access denied and if access is denied then goes ahead to lock down the system and report back to the user. (Howard & LeBlanc 30)

bool IsAccessAllowed(Error myError){
   if (myError == ERROR_ACCESS_DENIED){
      //security check failed
      // Inform user user that access is denied
      return false ;
   }
   else {
      //Everything Must be fine....
      //Perform Task
      return true ;
   }
}

At first glance this looks fine because it does it's job perfectly when expected input is received, however what happens when another error is returned, such as ERROR_NOT_ENOUGH_MEMORY? The function should be rewritten as such:

bool IsAccessAllowed(Error myError){
   if (myError == NO_ERROR){
      //Everything is fine
      //Perform Task
      return true ;
   }
   else {
      //security check failed
      // Inform user user that access is denied
      return false ;
   }
}

Example of dangerous data:

Type	Attack String	Clean String
Cross Site Scripting	<script>alert(document.location)</script> also: <object><applet><form> tags should be removed	&lt;script&gt;alert(document.location)&lt;/script&gt;
SQL injection	‘ DROP TABLE OrderDetail;	Use SQL variables in stored procedures, never build query string directly from user input
Canonicalization Issues	MyLongFile.txt MyLongFile.txt. MyLong~1.txt MyLongFile.txt::$DATA	Require OS to resolve all file permissions
Hex Encoded	%74%68%69%73%46%69%6C%65%2E%74%78%74	MyLongFile.txt
Path Traversal	../../MyLongFile.txt	Require OS to resolve all file permissions

Using built in functions to verify and clean data

The system has many great functions built in to help you clean the data to make sure it will not harm the system. All filenames should be verified though the operating system to decide on permissions and path traversal. Any information echoed back to the user should be HTML-encoded, meaning all interesting characters translated to their ASCII representation.

<<Previous

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Next>>

Provided by: Security Innovation, The Application Security Company