This paper briefly describes several common classes of coding error generally encountered when auditing web applications running on the Active Server Pages (ASP) platform.

The paper is broken down into three broad sections, each of which addresses several common coding problems. The following is a list of the common errors that are discussed in this document, divided into three broad categories. The remainder of the document deals with each of these problems in turn. Any ASP code samples assume that the default language is VBScript, but all of the points apply equally to JavaScript. Equally, all occurrences of the SQL language assume that Microsoft SQL Server is being used as the back - end database.

Free Ebook on ASP Programming : Writing Secure ASP Scripts.pdf

Predictability and secure management of state

Web applications typically requite some way of maintaining the 'state' of a user's interaction with the application. This can manifest itself in a number of ways, and if handled poorly, is open to abuse by attackers.

Poor randomness
Applications generally have some requirement for randomness. The application may have to generate its own session identifiers, for example, or it might have to create some kind of random password.

Most 'random' number generators build into languages and libraries are based upon arithmetic 'pseudo' random number generators. A problem frequently exhibited by these generators is that they issue repeating sequences. Another common problem is that of seeding with predictable data, such as a tick count, an IP address or hostname.......more

An attacker is very likely to be able to guess the time at the server, even to millisecond resolution; often it is contained in web responses. The ICMP timestamp request is another method of obtaining the time at the server.

Predictable session identifiers
Some applications use monotonically increasing session identifiers (i.e. the first id is 1, the second 2 and so on). Some applications use the primary key of a table in a database; again, this is extremely weak and quite easy to guess, given a single valid identifier.

The reason why predictable session identifiers must be avoided is that knowledge of the session id typically grants access to the application. Once a user has passed the 'authentication' phase of an application, the session identifier is the only way the application has of verifying who is who.

Consequently, if an attacker can guess the session id of a user who is currently authenticated with the application, they will be able to interact with the application as though they were that user.

Session state manipulation bugs
This is a subtle class of problem that exploits the manipulation of the state of an application

Top