From 2af72ba9636bec70046394c41744f89ce4572e35 Mon Sep 17 00:00:00 2001
From: Ilia Motornyi <elmot@vaadin.com>
Date: Thu, 3 Dec 2015 14:59:05 +0000
Subject: Revert "Merge branch 'documentation'"

This reverts commit f6874bde3d945c8b2d1b5c17ab50e2d0f1f8ff00.

Change-Id: I67ee1c30ba3e3bcc3c43a1dd2e73a822791514bf
---
 documentation/advanced/advanced-security.asciidoc | 56 -----------------------
 1 file changed, 56 deletions(-)
 delete mode 100644 documentation/advanced/advanced-security.asciidoc

(limited to 'documentation/advanced/advanced-security.asciidoc')

diff --git a/documentation/advanced/advanced-security.asciidoc b/documentation/advanced/advanced-security.asciidoc
deleted file mode 100644
index d3b0a5249c..0000000000
--- a/documentation/advanced/advanced-security.asciidoc
+++ /dev/null
@@ -1,56 +0,0 @@
----
-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]#++&lt;++# and [literal]#++&gt;++#, 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.
-
-
-
-
-- 
cgit v1.2.3