Shawndouglas: Added further reading

2016-08-10T22:32:50Z

Added further reading

← Older revision		Revision as of 22:32, 10 August 2016
Line 4:		Line 4:

	===To prevent this type of attack===		===To prevent this type of attack===
	* Thoroughly filter/escape any untrusted content		* Thoroughly filter/escape any untrusted content.
	* If the allowed character set for certain input fields is limited, check that the input is valid before using it		* If the allowed character set for certain input fields is limited, check that the input is valid before using it.
	* If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted		* If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted.
	* If you are sure, but there is no '''real''' need to treat it as trusted, treat it as untrusted		* If you are sure, but there is no '''real''' need to treat it as trusted, treat it as untrusted.
	* The request URL (e.g. in environment variables) is untrusted		* The request URL (e.g. in environment variables) is untrusted.
	* Data coming from HTTP headers is untrusted		* Data coming from HTTP headers is untrusted.
	** Referer		** Referer
	** X-Forwarded-For		** X-Forwarded-For
	** Cookies		** Cookies
	** Server name (!)		** Server name (!)
	* All POST and GET data is untrusted		* All POST and GET data is untrusted.
	** ~~includes~~ non-user-modifiable input fields like select		** Includes non-user-modifiable input fields like select
	* All content validation is to be done server side		* All content validation is to be done server side.

	===Rationale===		===Rationale===
Line 24:		Line 24:

	An attacker is not constrained by the constraints a browser puts on him. Just because an input field is specified with <code>maxlength=20</code> does not mean that an attacker cannot craft a request with 200 KB of data. The same goes for any JavaScript based constraints.		An attacker is not constrained by the constraints a browser puts on him. Just because an input field is specified with <code>maxlength=20</code> does not mean that an attacker cannot craft a request with 200 KB of data. The same goes for any JavaScript based constraints.

			==Further reading==
			* [[wikipedia:Secure input and output handling\|Secure input and output handling]]
			* [[wikipedia:Trust boundary\|Trust boundary]]

	==Notes==		==Notes==
	The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/(Un)trusted_input the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license.		The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/(Un)trusted_input the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license.

Shawndouglas: Created as needed.

2016-08-10T21:03:42Z

Created as needed.

New page

{{TOC right}}
==(Un)trusted input==
All user input is to be considered untrusted. Seemingly “trusted/safe” input, like some $_SERVER variables in PHP, can be easily manipulated by attackers.

===To prevent this type of attack===
* Thoroughly filter/escape any untrusted content
* If the allowed character set for certain input fields is limited, check that the input is valid before using it
* If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted
* If you are sure, but there is no '''real''' need to treat it as trusted, treat it as untrusted
* The request URL (e.g. in environment variables) is untrusted
* Data coming from HTTP headers is untrusted
** Referer
** X-Forwarded-For
** Cookies
** Server name (!)
* All POST and GET data is untrusted
** includes non-user-modifiable input fields like select
* All content validation is to be done server side

===Rationale===
Escaping or filtering “trusted” input that should not contain any characters that require escaping will only give you a negligible performance penalty, but you will be on the safe side if the input turns out to be untrusted.

Validating input data using a character whitelist can avoid attacks using unexpected characters (null bytes, UTF-8, control characters used as delimiters in internal representations etc.). Ensure your validation is not too strict, for example you will need to allow both UTF-8 and characters like ' in person name fields.

An attacker is not constrained by the constraints a browser puts on him. Just because an input field is specified with <code>maxlength=20</code> does not mean that an attacker cannot craft a request with 200 KB of data. The same goes for any JavaScript based constraints.

==Notes==
The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/(Un)trusted_input the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license.

LII:Web Application Security Guide/(Un)trusted input - Revision history

Shawndouglas: Added further reading

Shawndouglas: Created as needed.