Injection is an attack that attempts to invoke an interpreter or change the meaning of commands sent to an interpreter. Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server.
- 1 Why Injection Happens to Good Developers
- 2 DEFENSES
Why Injection Happens to Good Developers
Injection can be complex. The subtleties of data flow, parsers, contexts, capabilities, and escaping are overwhelming even for security specialists. In the following sections we will outline these topics to make it clear how injection can happen in a variety of different technologies.
First we need to consider the vehicle for injection attacks -- untrusted data.
Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, untrusted data is input that can be manipulated to contain a web attack payload. The OWASP Code Review Guide has a decent list of methods that return untrusted data in various languages, but you should be careful about your own methods as well.
Untrusted data should always be treated as though it contains an attack. That means you should not send it anywhere without taking steps to make sure that any attacks are detected and neutralized. As applications get more and more interconnected, the likelihood of a buried attack being decoded or executed by a downstream interpreter increases rapidly.
TBD: Data Flow
When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the injection context. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.
Consider a few of the types of commands and documents that might allow for injection...
- SQL queries
- LDAP queries
- Operating system command interpreters
- Any program invocation
- XML documents
- HTML documents
- JSON structures
- HTTP headers
- File paths
- A variety of expresson languages
In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.
TBD. Describe different types of parsers, tokens (particularly control characters), BNF.
Injection into References
TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)
Injection into Commands
TBD. Recursive descent or LALR parsers.
Injecting in Hierarchical Documents
To really understand what's going on with XSS, you have to consider injection into the hierarchical structure of the HTML DOM. Given a place to insert data into an HTML document (that is, a place where a developer has allowed untrusted data to be included in the DOM), there are two ways to inject code:
- Injecting UP
- Injecting DOWN
The rules in this document have been designed to prevent both UP and DOWN varieties of XSS injection. To prevent injecting up, you must escape the characters that would allow you to close the current context and start a new one. To prevent attacks that jump up several levels in the DOM hierarchy, you must also escape all the characters that are significant in all enclosing contexts. To prevent injecting down, you must escape any characters that can be used to introduce a new sub-context within the current context.
Injection with Multiple Nested Parsers
Traditionally, input validation has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?
While input validation is important and should always be performed, it is not a complete solution for injection attacks. It's better to think of input validation as defense in depth and use escaping as described below as the primary defense.
Using Safe Interfaces
TBD - parameterized interfaces with strong typing
Escaping (aka Output Encoding)
"Escaping" is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. There are lots of different types of escaping, sometimes confusingly called output "encoding." Some of these techniques define a special "escape" character, and other techniques have a more sophisticated syntax that involves several characters.
Do not confuse output escaping with the notion of Unicode character encoding, which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does not defuse attacks. However, if there are misunderstandings about the intended charset between the server and browser, it may cause unintended characters to be communicated, possibly enabling XSS attacks. This is why it is still important to specify the Unicode character encoding (charset), such as UTF-8, for all communications.
Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.
User:Jeff Williams : jeff.williams[at]aspectsecurity.com