Mario Heiderich

Web application firewalls and client-side filters

Web application firewalls (WAFs) are commonly used to detect (and sometimes block) Web attacks. Many commercial WAFs are available, along with several freely available (usually open source) alternatives. WAFs can be difficult to customize for a particular application, making it difficult to run them in “whitelisting mode.” It is common to find WAFs deployed in “blacklisting mode,” making them more vulnerable to bypasses and targeted attacks. Most open source WAFs have a publicly accessible demo application showing the effectiveness of their filtering, and sometimes the WAFs administrative interface as well. Spending some time with the administrative interfaces and/or bypassing the built-in filters is a great way to practice many of the techniques. After some practice, security penetration testers can learn to recognize the general strengths and weaknesses of WAFs, which can help them to hone their Web application attack skills. Different types of filtering devices can be used to protect Web applications. Both WAFs and client-side filters have filtering limitations which an attacker can exploit. Putting together many of the ideas and techniques, users can see how a variety of filters can be bypassed and attacked. These attacks range from abusing cross-site scripting, which results in universal cross-site scripting, to performing denial-of-service attacks against poorly constructed regular expressions.

JavaScript and VBScript

JavaScript is a very dynamic and expressive language and even though it is loosely typed, it has very powerful features. This chapter explains how to use JavaScripts features in unusual ways to obfuscate a code. Some background on JavaScript and a couple of simple examples to help understand the obfuscation performed later in the chapter are provided. The process of encoding script in various browsers is discussed. This chapter explores the uses of JavaScript and various obfuscation techniques. Understanding how languages work enables users to take full advantage of their features and produce truly unreadable code. The best way to learn a language is to obfuscate and de-obfuscate; both practices require an in-depth knowledge of the syntax. This chapter also provides practical understanding of why the code works. Hidden features and unintentional hacks can lead to some amazing results.

Chapter 4 – Nonalphanumeric JavaScript

Publisher Summary nThis chapter discusses nonalphanumeric code and how to create and execute them. In JavaScript, objects usually return a string form of their contents when concatenated with another string. In addition, type coercion can produce number-based strings without specifically using numerical characters. The loosely typed nature of JavaScript also helps produce characters that strongly typed languages would find very difficult to produce. We often refer to JavaScript as the language of hackers because of its surprising syntax and flexibility. One of the most basic forms of nonalphanumeric code in JavaScript involves the use of inflix operators to acquire numbers. Numbers are the basic requirement for producing code, as string indexes require a position in the string. The great thing about nonalphanumeric code is that one can learn the innermost workings of the language.

Chapter 6 – PHP

Publisher Summary nThis chapter discusses how PHP can be used to create obfuscated code and discovers the features for creating unreadable snippets. It also discusses the history of the language and how it evolved from a small collection of useful scripts to a powerful object-oriented programming (OOP) language. There are countless ways to execute PHP code as soon as PHP has been installed. One of the most common and easiest-to-use configurations is known as LAMP, which stands for Linux, Apache, MySQL, and PHP. It covers basic and advanced string obfuscation patterns, elaborates how to access and cast superglobals, and explores several ways to execute code with eval() and beyond. In real-life situations, the possibility to use filters and streams for inclusions are particularly interesting, since many Web applications are vulnerable against local file inclusions, which can be easily turned into actual remote code executions with these techniques, while at the same time making detection and forensics extremely hard to accomplish. PHP is not very cooperative here, and it contains a lot of possibilities for creating code that is unreadable but still works. PHP contains far more quirks, bugs, and vulnerabilities which can be useful during an attack to unveil and manipulate data and execute code. PHP 6 might introduce a whole new array of issues and new obfuscation techniques.

Chapter 2 – HTML

Publisher Summary nThis chapter discusses HTML (HyperText Markup Language), the markup language for structuring Web pages. Mastering HTML from a security point of view—in terms of both attack and defense—is complicated and requires almost encyclopedic knowledge. This chapter attempts to provide hat knowledge. In addition to discussing the HTML family and its hidden gems for attackers and trapdoors for defenders, this chapter sheds some light on the differences between the different HTML standards and their actual implementations. The history and basic elements of HTML and markup languages are discussed to get a better understanding of how and where to obfuscate. Some ways to obfuscate markup include execution of JavaScript, the obfuscation of a URL, or even a DoS attack against the client rendering the markup. Markup and HTML are difficult to parse and secure, and the user agents make this task difficult by allowing crazy combinations of characters, attributes, and tags to execute JavaScript. HTML is usually part of an attack against Web applications; although it is called a “markup language,” it is very powerful and should be treated with respect.

Chapter 7 – SQL

Publisher Summary nStructured Query Language (SQL) is one of the most common languages today for directly interacting with databases and comparable systems. Most Web applications providing interactive content use databases and are usually fueled by database management systems (DBMSs) such as MySQL, PostgreSQL, or Oracle, all of which are capable of understanding queries in SQL. The usual usage pattern is easy to describe. In most cases, the Web application receives user input requesting a certain amount of data specified by certain filters and constraints. SQL injection, and especially SQL obfuscation, is not always just a way to attack the database and Web server. Another, often-underestimated aspect of SQL obfuscation in connection with even un-exploitable SQL injection vulnerabilities is the fact that the encodings understood by the various DBMSs are not part of the feature set of common client-side cross-site scripting defense mechanisms such as NoScript and the IE8 cross-site scripting filter. Most Web application frameworks deliver decent protection against SQL injection attacks. Nevertheless, this range of attack techniques will not dramatically lose relevance, since many developers still write their SQL queries themselves, use concatenation, and thereby are likely to destroy any protective mechanisms provided by the frameworks and other mechanisms. The rise of client-side databases will be a breath of fresh air for SQL injection techniques and thereby obfuscation as well.

Chapter 5 – CSS

Publisher Summary nCascading Style Sheets (CSS) is a language that defines the presentation of a document. CSS can also be used with most markup languages, including XUL and SVG, and with practically any XML document that supports style sheets. CSS has been a fundamental part of the Web stack for the past couple of years, and like other technologies, it presents several security challenges. This chapter discusses how the extra functionality given to CSS, such as the ability to read the visited state of a page, CSS expressions, CSS attribute selectors, and UI appearance manipulation, can be used to affect the privacy and security of information. A variety of CSS based attacks are reviewed and a couple of syntax bugs that may allow users to obfuscate attacks at a higher level of complexity are discussed. The process of how several types of attack vectors, which may not require the use of JavaScript or any other scripting language, are created. CSS syntax and parsing rules are also different from JavaScript and HTML, in that CSS combines the passive security origin but with elements that can define the origin as the CSS hosting site (as in HTML). And with its very permissive parsing and the cross-domain nature of remote style sheets, CSS also allows information leakage and cross-browser parsing compatibility problems that introduce security vulnerabilities. It is important to note that CSS3 is still a work in progress, and some elements may change.

Mitigating bypasses and attacks

This chapter discusses best practices for securing Web applications and pinpoints common mistakes developers tend to make in this regard. This is interesting knowledge for both developers and attackers who have no development background, and thus often do not know how Web developers think and work. This is often half the battle in terms of finding Web application bugs in a more efficient manner. Experienced penetration testers and attackers often just have to see a particular feature to know that it is vulnerable—or is likely to be vulnerable. General code injections—cross-site scripting attacks as well as code injections and similar attacks—are discussed. This chapter discusses techniques with which the users should be able to create a client-side sandbox that takes setter assignments into account. This is useful for client-side malware analysis, as it would allow one to execute the code but prevent actual DOM manipulation while still monitoring what has been assigned. If an untrusted code is to be handled and included on the Web site, perhaps accepting code from the user or online advertisements, this chapter gives the users the groundwork and the knowledge to create users own system or implement one correctly. Programmers who test and break their own code produce better-quality code that is more secure than programmers who do not.