This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Category:Encoding"
From OWASP
| Line 1: | Line 1: | ||
| − | + | {{Template:Countermeasure}} | |
| − | [[Category: | + | ==Description== |
| + | |||
| + | Encoding, closely related to [[Escaping]] is a powerful mechanism to help protect against many types of attack, especially [[:Category:Injection Attack|injection attacks]] and [[XSS]]. Essentially, encoding involves translating special characters into some equivalent that is no longer significant in the target interpreter. So, for example, using HTML entity encoding before sending untrusted data into a browser will protect against many forms of [[XSS]]. | ||
| + | |||
| + | Considerations: | ||
| + | |||
| + | ; What interpreter? | ||
| + | : To encode properly, you need to know what interpreters the data might end up in. For example, if the data is going into a SQL interpreter, you should consider encoding based on syntax of the SQL engine you are using. | ||
| + | |||
| + | ; What characters? Complete? | ||
| + | : You want to make sure that you encode all the characters that might cause a problem, so the best approach is to use a positive encoding scheme, where all characters except a minimal '''known good''' set are encoded. | ||
| + | |||
| + | ; What encoding scheme? | ||
| + | : There are dozens of ways to encode characters and many interpreters allow multiple forms of a single significant character. For a browser, HTML entity encoding is a good way to prevent script injection, but URL encoding or Unicode encoding (%xx) will not prevent scripts from running. Be sure to use the appropriate encoding scheme for the target interpreter. | ||
| + | |||
| + | ; Double encoding and decoding? | ||
| + | : Be careful not to double encode your data. In some cases, doubly encoding data can inadvertently introduce special characters in the final output. Also, be aware that some processors may automatically undo your encoding. There is some evidence that XML processors are decoding HTML entity encoding, thus reintroducing potential [[XSS]] problems. | ||
| + | |||
| + | |||
| + | |||
| + | See the [[:Category:OWASP Encoding Project]] for more information. | ||
| + | |||
| + | ==Examples== | ||
| + | |||
| + | ==Related Threats== | ||
| + | |||
| + | ==Related Attacks== | ||
| + | |||
| + | ==Related Vulnerabilities== | ||
| + | |||
| + | ==Related Countermeasures== | ||
| + | * [[Input Validation]] | ||
Revision as of 15:14, 28 November 2006
This is a countermeasure. To view all countermeasures, please see the Countermeasure Category page.
Description
Encoding, closely related to Escaping is a powerful mechanism to help protect against many types of attack, especially injection attacks and XSS. Essentially, encoding involves translating special characters into some equivalent that is no longer significant in the target interpreter. So, for example, using HTML entity encoding before sending untrusted data into a browser will protect against many forms of XSS.
Considerations:
- What interpreter?
- To encode properly, you need to know what interpreters the data might end up in. For example, if the data is going into a SQL interpreter, you should consider encoding based on syntax of the SQL engine you are using.
- What characters? Complete?
- You want to make sure that you encode all the characters that might cause a problem, so the best approach is to use a positive encoding scheme, where all characters except a minimal known good set are encoded.
- What encoding scheme?
- There are dozens of ways to encode characters and many interpreters allow multiple forms of a single significant character. For a browser, HTML entity encoding is a good way to prevent script injection, but URL encoding or Unicode encoding (%xx) will not prevent scripts from running. Be sure to use the appropriate encoding scheme for the target interpreter.
- Double encoding and decoding?
- Be careful not to double encode your data. In some cases, doubly encoding data can inadvertently introduce special characters in the final output. Also, be aware that some processors may automatically undo your encoding. There is some evidence that XML processors are decoding HTML entity encoding, thus reintroducing potential XSS problems.
See the Category:OWASP Encoding Project for more information.
Examples
Related Threats
Related Attacks
Related Vulnerabilities
Related Countermeasures
Pages in category "Encoding"
The following 2 pages are in this category, out of 2 total.
