Viewstate lies at the heart of PRADO. Viewstate represents data that can be used to restore pages to the state that is last seen by end users before making the current request. By default, PRADO uses hidden fields to store viewstate information.
It is extremely important to ensure that viewstate is not tampered by end users. Without protection, malicious users may inject harmful code into viewstate and unwanted instructions may be performed when page state is being restored on server side.
To prevent viewstate from being tampered, PRADO enforces viewstate HMAC (Keyed-Hashing for Message Authentication) check before restoring viewstate. Such a check can detect if the viewstate has been tampered or not by end users. Should the viewstate is modified, PRADO will stop restoring the viewstate and return an error message.
HMAC check requires a private key that should be secret to end users. Developers can either manually specify a key or let PRADO automatically generate a key. Manually specified key is useful when the application runs on a server farm. To do so, configure TSecurityManager in application configuration,
ValidationKey="my private key" />
HMAC check does not prevent end users from reading the viewstate content. An added security measure is to encrypt the viewstate information so that end users cannot decipher it. To enable viewstate encryption, set the EnableStateEncryption of pages to true. This can be done in page configurations or in page code. Note, encrypting viewstate may degrade the application performance. A better strategy is to store viewstate on the server side, rather than the default hidden field.
Cross Site Scripting Prevention
One of the most important measures to prevent XSS attacks is to check user input before displaying them. One can do HTML-encoding with the user input to achieve this goal. However, in some situations, HTML-encoding may not be preferable because it disables all HTML tags.
PRADO incorporates the work of HTMLPurifier 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.
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: email@example.com'.
In such a situation user input must be checked to avoid possible injection.
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.
There are several countermeasures to prevent cookies from being attacked.
- An application can use SSL to create a secure communication channel and only pass the authentication cookie over an HTTPS connection. Attackers are thus unable to decipher the contents in the transferred cookies.
- Expire sessions appropriately, including all cookies and session tokens, to reduce the likelihood of being attacked.
- Prevent cross-site scripting (XSS) which causes arbitrary code to run in a user's browser and expose his cookies.
- Validate cookie data and detect if they are altered.
PRADO implements a cookie validation scheme that prevents cookies from being modified. In particular, it does HMAC check for the cookie values if cookie validation is enable.
Cookie validation is disabled by default. To enable it, configure the THttpRequest module as follows,
<module id="request" class="THttpRequest" EnableCookieValidation="true" />
To make use of cookie validation scheme provided by PRADO, you also need to retrieve cookies through the Cookies collection of THttpRequest by using the following PHP statements,
foreach($this->Request->Cookies as $cookie)
// $cookie is of type THttpCookie
To send cookie data encoded with validation information, create new THttpCookie objects and add them to the Cookies collection of THttpResponse,
To avoid the possibility of identity theft through some variants of XSS attacks, THttpSession should always be configured to enforce HttpOnly setting on session cookie.
The HttpOnly setting is disabled by default. To enable it, configure the THttpSession module as follows,
<module id="session" class="THttpSession" Cookie.HttpOnly="true" >