+91 20 24210201/301 info@genex.co.in

Web Security Vulnerabilities Prevention Cheat Sheet

Cross Site Scripting (XSS):

XSS is an attack in which script is maliciously injected into a user’s browsing session, generally without the user’s knowledge. These types of attacks have become quite familiar to many people because of incidents in which a large social networking site was struck and its users had messages posted they didn’t authorize. If an attacker posts malicious script that he can cause the browser to execute, this script is executed in the context of the victim’s session, essentially enabling the attacker to do anything he wants to the DOM—including showing fake login dialogs or stealing cookies. Such an attack could even install an HTML key logger on the current page to continually send input from that window to a remote site.
How Do You Prevent XSS?
  1. Ensure all of your output is HTML-encoded.
  2. Don’t allow user-supplied text to end up in any HTML element attribute string.
  3. Prevent the use of Internet Explorer 6 by your application by checking Request.Browser
  4. Know your control’s behavior and whether it HTML encodes its output. If it doesn’t, encode the data going to the control.
  5. Use the Microsoft Anti-Cross Site Scripting Library (AntiXSS) and set it as your default HTML encoder.
  6. Use the AntiXSS Sanitizer object (this library is a separate download and is addressed later in this article) to call GetSafeHtml or GetSafeHtmlFragment before saving HTML data to the database; don’t encode the data before saving.
  7. For Web Forms, don’t set EnableRequestValidation=false in your Web pages. Unfortunately, most user group postings on the Web advise disabling this setting if there’s an error. The setting is there for a reason and will stop the request if the character combination “
  8. Use the HttpOnly cookie option : This prevents client-side scripts from accessing a cookie from the document.cookie property.
  9. Use the innerText Property Instead of innerHTML:
    If you use the innerHTML property to build a page and the HTML is based on potentially untrusted input, you must use HtmlEncode to make it safe. To avoid having to remember to do this, use innerText instead. The innerText property renders content safe and ensures that scripts are not executed. (e.g. ,
    and etc.)

Cross-Site Request Forgery (CSRF):

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf). CSRF is an attack that occurs when someone takes advantage of the trust between your browser and a Web site to execute a command using the innocent user’s session.
How Do You Prevent CSRF?
Cross-Site Request Forgery (CSRF) is an attack where a malicious site sends a request to a vulnerable site where the user is currently logged in.
  1. ViewStateUserKey = Session.SessionID then viewstate will act as a form token.
  2. Protect SessionID using Hashing and Encryption.
  3. Use SSL to prevent sniffing of SessionID and ViewState
  4. Either create a BasePage and add the following code in that and check ViewState for forms and inherit all the pages from this base page. 
ASP.NET has an option to maintain your ViewState. The ViewState indicates the status of a page when submitted to the server. The status is defined through a hidden field placed on each page with a control. Viewstate can be used as a CSRF defense, as it is difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF. 
To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event).

Injection Flaws:

Step 1: Use ASP.NET Request Validation
Step 2: Constrain Input
  • Use server-side input validation: Use client-side validation in addition to server-side validation to reduce round trips to the server and to improve the user experience.
  • Validate length, range, format and type: Make sure that any input meets your guidelines for known good input.
  • Use strong data typing: Assign numeric values to numeric data types such as Integer or Double. Assign string values to string data types. Assign dates to the Date Time data type.
For Web form applications that obtain input through server controls, use the ASP.NET validator controls to constrain the input. For other sources of input data, such as query strings, cookies, and HTTP headers, constrain input by using the Regex class from the System.Text.RegularExpressions namespace.
  • To allow restricted HTML input:
    • Disable ASP.NET request validation by the adding the ValidateRequest="false" attribute to the @ Page directive.
    • Encode the string input with the HtmlEncode method.
    • Use a String Builder and call its Replace method to selectively remove the encoding on the HTML elements that you want to permit.
  • Validate Query String/Cookie Values
    • Validate query string/cookie values for length, range, format, and type.
  • Validate File and URL Paths
    • If your application has to accept input file names, file paths, or URL paths, you need to validate that the path is in the correct format and that it points to a valid location within the context of your application.
  • Validating File Paths
    • If you must accept file names as input, use the full name of the file by using System.IO.Path.GetFileName.
    • If you must accept file paths as input, use the full file path by using System.IO.Path.GetFullPath.
Using MapPath to Prevent Cross Application Mapping.
If you use MapPath to map a supplied virtual path to a physical path on the server, use the overload of Request.MapPath that accepts a bool parameter so that you can prevent cross-application mapping.
Step 3: Encode Unsafe Output
If you write text output to a Web page, encode it using HttpUtility.HtmlEncode. Do this if the text came from user input, a database, or a local file.

  • Use HtmlEncode to Encode Unsafe Output.
  • Use UrlEncode to Encode Unsafe URLs
Step 4: Use Command Parameters for SQL Queries
Use strongly typed Parameterized Queries, such as SqlCommand with SqlParameter or an ORM like Hibernate.

Information Leakage & Improper Error Handling:

Verify that ASP.NET Errors Are Not Returned to the Client.

You can use the element to configure custom, generic error messages that should be returned to the client in the event of an application exception condition.


Broken Authentication & Session Management

Broken Authentication and Session Management attacks are anonymous attacks generated to try and retrieve passwords, user IDs, account details and other information. For example, a webmaster running an online forum or participating in a social network is extremely prone to these types of incidents.
These attacks normally begin when the attacker impersonates the target by relying on information they’ve gathered from other users on the same platform. By doing so, the attacker can ask for (and often receive) valuable information which can in turn lead to account hijacking, identity theft and other critical issues.

Insecure Cryptographic Storage

Many web applications do not properly protect sensitive data, such as credit cards, tax ids, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
  1. Encrypted any sensitive data that will be stored long term.
  2. Insure that only authorized users can access decrypted copies of the data.
  3. Insure that a strong encryption algorithm is used. (Approved public algorithms such as AES, RSA public key cryptography, for hashing use SHA-256 or better. Do not use weak algorithms, such as MD5 or SHA1.)
  4. Only use widely accepted implementations of cryptographic algorithms rather than implementing an algorithm on your own. 

Comments (0)

Post a comment

Maximum 250 alphanumerals only