From 4e92e78b70299854205294ee43f056bda619e4db Mon Sep 17 00:00:00 2001 From: "ctrlaltca@gmail.com" <> Date: Mon, 26 Mar 2012 10:10:51 +0000 Subject: added some documentation for the changes introduced to fix #391 --- demos/quickstart/protected/pages/Advanced/Security.page | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'demos/quickstart/protected/pages/Advanced') diff --git a/demos/quickstart/protected/pages/Advanced/Security.page b/demos/quickstart/protected/pages/Advanced/Security.page index c3d0b511..226d7e49 100644 --- a/demos/quickstart/protected/pages/Advanced/Security.page +++ b/demos/quickstart/protected/pages/Advanced/Security.page @@ -36,7 +36,17 @@ One of the most important measures to prevent XSS attacks is to check user input

PRADO incorporates the work of SafeHTML and provides developers with a useful component called TSafeHtml. By enclosing content within a TSafeHtml component tag, the enclosed content are ensured to be safe to end users. In addition, the commonly used TTextBox has a SafeText property which contains user input that are ensured to be safe if displayed directly to end users.

- +

+With the broad use of active controls and more generally of AJAX-enabled controls using Javascript to transfer data between the server and the client, it's common to see attackers target javascript itself as a vector to inject malicious code. +

+

+Imagine a validator that uses an ajax callback to check user input from a textbox and returns an error message including the user input, example: 'The email address is not valid: test@example.com'. +In such a situation user input must be checked to avoid possible injection. +

+

+The classic xss check involves checking for html tags inside the message and encode them; but since the message gets sent back to the client inside a javascript block, it needs to be encoded again to avoid any possible javascript escaping. +By default PRADO encodes all variables sent clientside inside a javascript block to avoid any user-generated input from injecting malicious javascript code. +

Cookie Attack Prevention

Protecting cookies from being attacked is of extreme important, as session IDs are commonly stored in cookies. If one gets hold of a session ID, he essentially owns all relevant session information. -- cgit v1.2.3