Monday, May 12, 2014

Web Application Security & Non-Hacking Tools & Techniques

Below are major threat categories. We'll study here different tools and techniques to prevent such attacks.
  1. Cross Site Scripting(XSS) & HTML Injection 
  2. Cross site request Forgeries(CSRF)
  3. Session Hijacking
  4. Injection
    • SQL Injection
    • HTML Injection
    • HTTP header injection
    • Mail-header injection
    • OS command injection
  5. Sensitive Data Handling
  6. Phishing Attack
  7. Click-Jacking
  8. Directory Traversal
  9. Race Condition
  10. Access Control
  11. Encryption
  12. Programming
  13. Input Validation

1). Cross Site Scripting(XSS):

Cross-site scripting (XSS) vulnerabilities occur when:
  • Untrusted data enters a web application, typically from a web request.
  • The web application dynamically generates a web page that contains this untrusted data.
  • During page generation, the application does not prevent the data from containing ontent that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
  • A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
  • Three Types of XSS:
    • Type 1: Reflected XSS (or Non-Persistent) - The server reads data directly from the HTTP request and reflects it back in the HTTP response.
    • Type 2: Stored XSS (or Persistent) - The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content.
    • Type 0: DOM-Based XSS - In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection.

Security Solution:
  1. No HTML tag should be allowed as input data
    • ASP.NET Razor Views are HTML Encoded by default (also ASP.NET MVC 4)
    • For aggressive stripping use Microsoft AntiXSS library
    • Use HTML.Encode <%: %> provided by ASP.Net MVC for output
  2. All inputs should be HTML escaped
    • Prevent HTML tags in inputs by default, globally. (To turn it off - ValidateInput=false / AllowHTML) (ASP.NET MVC 4)
    • Use Microsoft Anti-Cross Site Scripting Library (AntiXSS) and set it as default HTML encoder.
    • Use AntiXSS Sanitizer object to call GetSafeHtml or GetSafeHtmlFragment before saving HTML data to the database
  3. All attributes should be put  in double quote parentheses
    • Use inbuilt HTML5 and CSS3 validation provided by Visual Studio.
  4. Ensure no Script tag is included in the input value
  5. Specify the charset  to Content Type on HTTP response header
    • Modify web.config code on IIS with following to specify charset and content-type as (name="Content-Type" value="text/html; charset='UTF-8'" )
  6. Use HttpOnly attribute to the cookie
    • Set HTTPOnly attribute as following:
  7. Invalidate all unnecessary HTTP methods, like TRACE, DELete etc
      • IIS 7 by default PUT, DELETE are not enabled.
      • Otherwise Deny TRACE by configuring IIS request filtering -> HTTP Verb -> Deny TRACE"

    2). Cross site request Forgeries(CSRF):

    CSRF vulnerabilities occur when:
    • When attacker tricks the victim into submitting a malicious request by inheriting the identity and privileges of the victim to perform an undesired function on the victim's behalf. 
    A successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

    Security Solution:
    1. In ASP.NET MVC:
      • Client Side:
        • Protect HTML form by using Html.AntiForgeryToken() inside the form. 
          • @using(Html.BeginForm()) {
          • @Html.AntiForgeryToken()
          •  -- Rest of the form goes here.
          • }
        • This will render something like the following
          • form action="/UserProfile/Edit" method="post" 
          • input name="__RequestVerificationToken" type="hidden" value="B0aG+O+Bi/5..." 
          • -- rest of form goes here --
          • /form
        • Using Html.AntiForgeryToken() will also give visitor a cookie whose name begins with __RequestVerificationToken.
        • This cookie will contain the same random value as the corresponding hidden field. This value remains constant throughout the visitor’s browsing session and every request to server
      • Server Side:
        • Validate incoming form submissions by adding the [ValidateAntiForgeryToken] attribute to the target action method. Here’s an example:
          • [ValidateAntiForgeryToken]
          • public ActionResult Edit(string email, string hobby)
          • {
          • // Rest of code unchanged
          • }
        • This authorization filter ensure checking that the incoming request has a Request.Form entry called __RequestVerificationToken.
        • And also ensure checking the request comes with a cookie of the corresponding name, and that their (I.e. Form field and Cookie) random values match.
          • If not, it throws an exception (saying “a required anti-forgery token was not supplied or was invalid.”) and blocks the request.
          • Else, request is pass thru and response is returned
        • Note: The MVC Framework’s antiforgery system has a few other handy features:
          • Antiforgery cookie’s name has a suffix that varies according to the name of your application’s virtual directory. This prevents unrelated applications from accidentally interfering with one another.
          • Html.AntiForgeryToken() accepts optional path and domain parameters; these are standard HTTP cookie parameters that control which URLs are allowed to see the cookie. 
            • For example, unless you specifically set a path value, the antiforgery cookie will be visible to all applications hosted on your domain (for most applications, this behavior is fine).
          • __RequestVerificationToken hidden field value contains a random component (matching the one in the cookie), but that’s not all. 
          • If the user is logged in, then the hidden field value will also contain their user name (obtainedfrom HttpContext.User.Identity.Name and then encrypted).
          • [ValidateAntiForgeryToken] checks that this matches the logged-in user. This adds protection in the unlikely scenario where an attacker can somehow write (but not read) cookies on your domain to a victim’s browser and tries to reuse a token generated for a different user

    Hope this helps.

    Arun Manglick

    No comments:

    Post a Comment