Cross-Site Scripting

Cross-site scripting, also known as XSS, is a specialized version of an HTML injection attack. XSS vulnerability enables an attacker to execute script in the user's browser. By running with the identity of the user on the Web site, this script can hijack the user's session, attempt to deface Web sites, insert hostile content, conduct phishing attacks, or even take control of the user's browser.

·   Encode output by using the Anti-XSS library. This library is available from the CodePlex Web site at http://www.codeplex.com/AntiXSS.

·   Perform input validation by using the ValidateRequest attribute.

·   In addition, the SDL also recommends the following two defense-in-depth practices:

1.   Do not use the JavaScript eval() function of any similar functions that can evaluate and execute a string as though it was script code.

2.   Do not set the domain property of a document to the top-level domain of the Web site.

Open Redirects

An open redirect, also known as a cross-site redirect or XSR, enables an attacker to redirect a user request to an arbitrary site through a URL on your Web site. Attackers could use this for phishing attacks, spam, and serving malicious software (also called malware).

·   Verify all redirections against a list of allowed URLs.

Cross-Site Request Forgery

A cross-site request forgery attack, or XSRF, forces the browser for a logged-on user to send a request to a vulnerable Web application. The vulnerable Web application performs the request with the identity of the user.

·   Set the ViewStateUserKey property on pages accessed by an authenticated user.

·   Alternatively, use a custom-built dynamic canary library (described below).

JS/JSON Hijacking

JavaScript (JS) or JavaScript object notation (JSON) hijacking enables an attacker to read a JavaScript or JSON response from another site. Web sites typically return personally identifiable information (PII) about users in JSON responses, so this attack could allow an attacker to steal users’ PII just by visiting the attacker’s Web site. When the vulnerable Web site receives the request, it runs the script with the identity of the user.

·   Use a custom-built dynamic canary library.

·   As a defense-in-depth option, consider returning PII in JSON responses only to POST requests.

Note: The option of using ViewStateUserKey or a custom-built dynamic canary library warrants a little more explanation. Some teams at Microsoft do not use the ViewState property of a page for several reasons. This means that the corresponding pages cannot set the ViewStateUserKey property either. Consequently, these teams have built a library with application-level logic that incorporates anti-forgery validation tokens, referred to as canaries. A canary is an unpredictable, unguessable string of characters that the Windows Live Web applications can validate. A canary has a short period of time during which it is valid. A method in the library generates a canary, inserts the canary into the page, and then verifies that subsequent HTTP requests include the same canary. This challenge response sequence is similar to the ViewStateUserKey functionality.