Check, please
I often find fields that do not perform data validation on input. This is a gold mine for buffer overflow and SQL injection attackers. During testing, I'll open notepad and create a 500+ character string, then cut and paste it into the password field. If the system doesn't limit the input string, many systems will hang or crash.
Then I'll test for validation rules by embedding a condition that always evaluates to true (e.g., "OR 'x'='x'") and append it into the password field. A lot of systems can be manipulated to allow unauthorised access because of the way the SQL statements have been constructed -- appending an "OR TRUE" conditional fools the system into allowing unauthorised access. Here's a sample SQL statement that could be manipulated: Select userid, passwd from USERS where userid = :uid_entered and passwd = pwd_entered
Assume that the user entered admin into the userid field and password "OR 'x'='x'" into the password field. The SQL statement would expound this as "select userid, passwd from USERS where userid=admin and passwd=password OR 'x'='x'. This is probably not what the designer was expecting.
The keys are under the welcome mat
I am also amazed at how many times I see system accounts used to perform pre-validation logons to application databases. Many Web apps store user credentials (i.e., userids and passwords) in its own application database. Because you must logon to the database in order to validate the credentials, systems usually handle validation using what I call a "pre-validation logon account"; for example, the system logs in as "admin/admin" and validates that there is a user and password in the database matching what the user input on the screen.
Notably, every pre-validation logon account that I've encountered has always been an "admin" type account with extensive privileges within the application. What makes this an even riskier practice is that in order for the Web application to have visibility to passwords for these accounts, they are usually either stored in a text file housed in the Webroot or embedded directly in the start page. Either way, a malicious user can get to the password very easily. This practice is a lot like hiding house keys under the welcome mat, or a spare set of car keys on top of the visor. It's a big mistake that makes it easy to break into a Web-based application.
