1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556 |
- ---
- title: Common Security Issues
- order: 8
- layout: page
- ---
-
- [[advanced.security]]
- = Common Security Issues
-
- [[advanced.security.sanitizing]]
- == Sanitizing User Input to Prevent Cross-Site Scripting
-
- You can put raw HTML content in many components, such as the [classname]#Label#
- and [classname]#CustomLayout#, as well as in tooltips and notifications. In such
- cases, you should make sure that if the content has any possibility to come from
- user input, you must make sure that the content is safe before displaying it.
- Otherwise, a malicious user can easily make a
- link:http://en.wikipedia.org/wiki/Cross-site_scripting[cross-site scripting
- attack] by injecting offensive JavaScript code in such components. See other
- sources for more information about cross-site scripting.
-
- Offensive code can easily be injected with [literal]#++<script>++# markup or in
- tag attributes as events, such as
- [parameter]#onLoad#.////
- TODO Consider an example, Alice, Bob,
- etc.
- ////
- Cross-site scripting vulnerabilities are browser dependent, depending on the
- situations in which different browsers execute scripting markup.
-
- Therefore, if the content created by one user is shown to other users, the
- content must be sanitized. There is no generic way to sanitize user input, as
- different applications can allow different kinds of input. Pruning (X)HTML tags
- out is somewhat simple, but some applications may need to allow (X)HTML content.
- It is therefore the responsibility of the application to sanitize the input.
-
- Character encoding can make sanitization more difficult, as offensive tags can
- be encoded so that they are not recognized by a sanitizer. This can be done, for
- example, with HTML character entities and with variable-width encodings such as
- UTF-8 or various CJK encodings, by abusing multiple representations of a
- character. Most trivially, you could input [literal]#++<++# and [literal]#++>++#
- with [literal]#++<++# and [literal]#++>++#, respectively. The input could
- also be malformed and the sanitizer must be able to interpret it exactly as the
- browser would, and different browsers can interpret malformed HTML and
- variable-width character encodings differently.
-
- Notice that the problem applies also to user input from a
- [classname]#RichTextArea# is transmitted as HTML from the browser to server-side
- and is not sanitized. As the entire purpose of the [classname]#RichTextArea#
- component is to allow input of formatted text, you can not just remove all HTML
- tags. Also many attributes, such as [parameter]#style#, should pass through the
- sanitization.
-
-
-
|