Introduction

Throughout this book we discuss a wide variety of threats and security risks. But none of these threats is as serious as when an attacker goes straight for the heart and directly attacks your application code. Many developers have faced the somber reality that their code is insecure; that some hacker broke in using nothing other than a flaw found in the Web application itself. By manipulating program input, attackers can often trick the server into revealing customer data, or allowing access to unauthorized files or execution of program code on the server itself. Indeed, insecure code is the source of countless intrusions.

The risks of insecure code are great for several reasons:

• There are so many different ways to exploit insecure code.

• There is no need to obtain a password because the code is already _running in the context of an authenticated user.

• The attacker gains access to anything that the Web application can access, which usually includes sensitive user data.

• Most Web applications are not properly configured to detect and prevent these types of attacks.

Every week, security researchers flood mailing lists such as BugTraq and VulnWatch with discoveries of security flaws in commercial or widely available Web-based applications. While many programmers are finally learning the skills to avoid insecure code, there seems to be a never-ending supply of programmers who put users at risk because they don t filter the input coming into their application.

Here are some common threats caused by poor input filtering:

• SQL injection