لطفا منتظر باشید ...
Chapter 5: Filtering User Input
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 Manipulating user input to construct SQL statements that execute on the database server
Directory traversal Accessing files outside the bounds of the Web application by manipulating input with directory traversal characters. This is also known as the double dot attack.
Server-side code access Revealing the content of server-side code or configuration files by manipulating input to disguise the true file extension
File system access Manipulating input to read, write, or delete protected files on disk
Denial of service Causing the application to consume system resources excessively or to stop functioning altogether
Information leakage Intentionally sending invalid input to produce error messages with information that may facilitate an attack
Cross site scripting Injecting HTML or script commands, causing the Web application to attack other users
Command injection Injecting special shell metacharacters or otherwise manipulating input to cause the server to run code of the attacker’s choice
Buffer overflows Overwriting a buffer by sending more data than a buffer can handle, resulting in the application crashing or executing code of the attacker’s choice
Despite the wide variety of input injection attacks, Web developers have one great advantage: these attacks are completely preventable through careful input filtering and smart coding practices.
