1. CHAPTER 7 Unexpected Input

2. INTRODUCTION What is Unexpected Input? Something (normally user-supplied data) that is unexpected happen to an application to circumvent security restrictions. Why Unexpected Input is dangerous? It can be resulting three classes of attack: 1. Buffer Overflow If the data submitted more than the application expects, the application may not gracefully handle the surplus data. C and C++ are the examples.

3. INTRODUCTION 2. System Functions The data is directly used to modify how a system function behaves. System function include running other applications. 3. Logic Alteration The data is crafted in such a way as to modify how the application’s logic handles it. This type of situation include altering SQL queries.

4. COMMON SITUATIONS There are some common situations that involving unexpected input or data: HTTP/HTML The biggest mistake application make is relying on the HTTP referer header as a method of security. The referer header contains the address of referring page and supplied by the client at the client options, that means it is trivial to spoof. The second mistake is the dependency on HTML form limitations.

5. COMMON SITUATIONS SQL Queries In SQL Queries, including user submitted data within SQL queries make it possible for an attacker to include extra commands to be executed by the database. Disguising the Obvious In signature matching, an attacker take a known “bad” signature (an actual virus or an attack signature) and disguise it in such a manner that the application is fooled into not recognizing it.

6. FINDING VULNERABILITIES There are some techniques that can be used to determine an application vulnerabilities: Black-Boxing (try and error) A few tactics can be kept in mind: 1. Use intuition on what the application is doing, such as, is the application accepting e-commerce order? 2. Run the full interactive process from start to finish at least once. 3. Try to intentionally cause an error to see if the application alerts to an error.

7. FINDING VULNERABILITIES Use the Source Starting with system functions and trace back will allow us to efficiently audit the application in order to find a situation where the application can be exploited by unexpected data. Application Authentication The popular method is to give a large random session or authentication key whose key space is large enough to thwart brute-forcing efforts. The key must prove to be truly; any predictably will result in increased chances of an attacker guessing a valid session key.

8. PROTECTION Filtering Bad Data The best way to combat unexpected data is to filter the data to what is expected: 1. Deleting or removing unwanted characters from data. Every languages has their own way of filtering. 2. Protecting SQL Queries The common method used is called quoting - just making sure that submitted data is properly contained within a set of quotes and there are no renegades quotes contained within the data itself.

9. PROTECTION 3. Silently Removing versus Alerting on Bad Data Silently removing means delete automatically and alerting means delete manually. 4. Invalid Input Function Centralizing a common function to be used to report invalid data will make it easier to monitor unexpected data. 5. Token Substitution This is the trick where we substitute a token (typically a large random session key) which is used to correlate sensitive.

10. SAFETY FEATURES Available Safety Features Various programming languages and applications have features that allow us to reduce or minimize the risks of vulnerabilities. PHP PHP includes a “safe mode” configuration option that limits the uses of PHP’s system functions. Perl Perl has a “taint mode”. When running in taint mode, Perl will warn of situations where application directly pass user data into certain commands.