Injection Theory - Revision history

Jeff Williams at 02:18, 28 March 2016

2016-03-28T02:18:33Z

Jeff Williams at 02:07, 28 March 2016

2016-03-28T02:07:42Z

Jeff Williams at 17:35, 21 June 2013

2013-06-21T17:35:12Z

Jeff Williams at 12:15, 17 September 2012

2012-09-17T12:15:57Z

Jeff Williams at 23:18, 16 September 2012

2012-09-16T23:18:54Z

Jmanico at 19:51, 10 September 2012

2012-09-10T19:51:39Z

Jmanico at 19:50, 10 September 2012

2012-09-10T19:50:41Z

Jmanico at 19:50, 10 September 2012

2012-09-10T19:50:22Z

Jmanico at 19:50, 10 September 2012

2012-09-10T19:50:10Z

Jmanico: Created page with "== 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 ..."

2012-09-10T19:42:37Z

Created page with "== 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 ..."

New page

== 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 [[Searching for Code in J2EE/Java|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.

Traditionally, [[Data Validation|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|defense in depth]] and use '''escaping''' as described below as the primary defense.

== Escaping (aka Output Encoding) ==

"[http://www.w3.org/TR/charmod/#sec-Escaping 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 [http://www.w3.org/TR/charmod/#sec-Digital 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 [http://www.w3.org/TR/charmod/#sec-Encodings 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.

== Injection Theory ==

[[Injection Flaws|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like <div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this <div>data < script>alert("attack")</script> context</div>.

XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is easily the worst mashup of code and data of all time, as there are so many possible places to put code and so many different valid encodings. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).

To really understand what's going on with XSS, you have to consider injection into the hierarchical structure of the [http://www.w3schools.com/HTMLDOM/default.asp 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:The most common way is to close the current context and start a new code context. For example, this is what you do when you close an HTML attribute with a "> and start a new <script> tag. This attack closes the original context (going up in the hierarchy) and then starts a new tag that will allow script code to execute. Remember that you may be able to skip many layers up in the hierarchy when trying to break out of your current context. For example, a </script> tag may be able to terminate a script block even if it is injected inside a quoted string inside a method call inside the script. This happens because the HTML parser runs before the JavaScript parser.

;Injecting DOWN:The less common way to perform XSS injection is to introduce a code subcontext without closing the current context. For example, if the attacker is able to change <img src="...UNTRUSTED DATA HERE..." /> into < img src="javascript:alert(document.cookie)" /> they do not have to break out of the HTML attribute context. Instead, they introduce a subcontext that allows scripting within the src attribute (in this case a javascript url). Another example is the expression() functionality in CSS properties. Even though you may not be able to escape a quoted CSS property to inject up, you may be able to introduce something like xss:expression(document.write(document.cookie)) without ever leaving the current context.

There's also the possibility of injecting directly in the current context. For example, if you take untrusted input and put it directly into a JavaScript context. While insane, accepting code from an attacker is more common than you might think in modern applications. Generally it is impossible to secure untrusted code with escaping (or anything else). If you do this, your application is just a conduit for attacker code to get running in your users' browsers.

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.

@@ Line 39: / Line 39: @@
 == Parsers ==
 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 ==

← Older revision		Revision as of 02:07, 28 March 2016
Line 97:		Line 97:
	== Author ==		== Author ==

−	[[User:Jeff Williams]] : jeff.williams[at]~~aspectsecurity~~.com	+	[[User:Jeff Williams]] : jeff.williams[at]contrastsecurity.com

@@ Line 1: / Line 1: @@
-[[Injection Flaws|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.
+[[Injection Flaws|Injection]] is an attacker's attempt to send data to an application in a way that will change the meaning of commands being sent to an interpreter.  For example, the most common example is SQL injection, where an attacker sends "101 OR 1=1" instead of just "101".  When included in a SQL query, this data changes the meaning to return ALL records instead of just one.  There are lots of interpreters in the typical web environment, such as SQL, LDAP, Operating System, XPath, XQuery, Expression Language, and many more.  Anything with a "command interface" that combines data into a command is susceptible.  Even XSS is really just a form of HTML injection.
 =Why Injection Happens to Good Developers=
@@ Line 13: / Line 15: @@
 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
+As untrusted data flows through an application, it is frequently split into parts, combined with safe data, transformed, validated, and encoded in a variety of ways. A single piece of data could go through dozens of these steps before it gets to an interpreter.  This makes identifying injection problems very difficult.  Tools have a difficult time tracing the entire data flow and understanding exactly what data can run the gauntlet and what cannot.
 == Injection Context ==

@@ Line 1: / Line 1: @@
-[[Injection Flaws|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 loss of control of a browser, application, or server.
+[[Injection Flaws|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.
 == Untrusted Data ==
@@ Line 8: / Line 12: @@
 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.
 == Injection Context ==
@@ Line 29: / Line 36: @@
 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.
 == Injection into References ==
@@ Line 53: / Line 64: @@
-== Injection with Multiple Parsers ==
+== Injection with Multiple Nested Parsers ==
 XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is easily the worst mashup of code and data of all time, as there are so many possible places to put code and so many different valid encodings. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).

@@ Line 1: / Line 1: @@
-[[Injection Flaws|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like &lt;div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this &lt;div>data &lt; script>alert("attack")</script> context</div>.
+[[Injection Flaws|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 loss of control of a browser, application, or server.
-XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is easily the worst mashup of code and data of all time, as there are so many possible places to put code and so many different valid encodings. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).
+== Untrusted Data ==
 To really understand what's going on with XSS, you have to consider injection into the hierarchical structure of the [http://www.w3schools.com/HTMLDOM/default.asp 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:
@@ Line 13: / Line 52: @@
 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.
-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 [[Searching for Code in J2EE/Java|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.
+== Injection with Multiple Parsers ==
-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.
+== Validation ==
 Traditionally, [[Data Validation|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|defense in depth]] and use '''escaping''' as described below as the primary defense.
 == Escaping (aka Output Encoding) ==
@@ Line 33: / Line 85: @@
 == Author ==
-Jeffe' Williams : jeff[at]aspectsecurity.com
+[[User:Jeff Williams]] : jeff.williams[at]aspectsecurity.com

← Older revision		Revision as of 19:51, 10 September 2012
Line 30:		Line 30:

	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.		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.
		+
		+	== Author ==
		+
		+	Jeffe' Williams : jeff[at]aspectsecurity.com

← Older revision		Revision as of 19:50, 10 September 2012
Line 12:		Line 12:

	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.		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.
−

	== Untrusted Data ==		== Untrusted Data ==

← Older revision		Revision as of 19:50, 10 September 2012
Line 1:		Line 1:
−	~~== Injection Theory ==~~
−
	[[Injection Flaws\|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like <div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this <div>data < script>alert("attack")</script> context</div>.		[[Injection Flaws\|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like <div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this <div>data < script>alert("attack")</script> context</div>.