CIS 4615 meeting -*- Outline -*-

* Web server related attacks (XSS, XSRF, and Response Splitting)

  Based on chapter 2 of the book: 24 Deadly Sins of Software Security
  by M. Howard, D. LeBlanc, and J. Viega (McGraw-Hill, 2010).

** example
*** type 1 attacks (non-persistent)
------------------------------------------
   CROSS-SITE SCRIPTING (XSS), TYPE 1

Idea:

 1. Design URL containing 

 2. Get user to click on that URL

 3. Web server puts the script on web page
    that is 

 4. The browser 




In JSP:
  <%= request.getParameter("Name") %>

In Ruby on Rails:

   <%= comment.body %>
------------------------------------------
      ... malicious script

      Q: How do you get step 2 to work?
      social engineering
      It helps to use a service like tinyurl.com or snurl.com
      to abbreviate the URL

      ... rendered by user's browser

      ... runs the malicous script

      Q: Why doesn't the attacker run the script themselves?
      To steal from the user
      To gain access to the user's browser's information (cookies, history)

      Q: What role does the web server play in this?
      It only has to reflect/echo the malicious script back to the user's
      browser in a web page it is rendering.
      It's *complicit*

      Q: What security service does this violate?
      Integrity!
      Serving up tainted inputs.

** severity
------------------------------------------
           SEVERITY OF XSS

Very common

Easy to find using a browser

------------------------------------------

** other types of xss attacks

*** type 2, persistent xss attacks
------------------------------------------
        STORED XSS ATTACKS (TYPE 2)

Like type 1, but the malicious query is

 1. Send input containing

 2. Get user to browse that web site

 3. Web server puts the script on web page
    that is 

 4. The browser runs the malicious script


------------------------------------------
       ... stored by the server

       ... malicious script to the server
           which stores it

       ... rendered on the user's browser

       Q: What kinds of web sites store user input and show it to others?
       Product reviews, feedback, newspaper comments, chats...

       Q: Is there social engineering necessary to make this work?
       No, user's may always look at that website.

*** response splitting
------------------------------------------
          RESPONSE SPLITTING

Puts malicous script in


In Ruby on Rails:

   redirect_to(url)
------------------------------------------
       ... HTTP headers, not in the body (like types 1 and 2)

        Q: What's the problem with the rails code?
        If url isn't trusted, could be an attack.

*** cross-site request forgery (XSRF)
------------------------------------------
    CROSS-SITE REQUEST FORGERY (XSRF)

Occurs when website designed to use 
  query strings in URLs to 



e.g., in email app:

  http://ex.com/request.php?create-new
  http://ex.com/request.php?read-NNN
  http://ex.com/request.php?delete-NNN


------------------------------------------
     ....represent requests by client

     Q: Why is that design a problem?
     Because if the attacker can get user to open web page containing
     such a URL, then it will be executed, e.g.,
         <img src="http://ex.com/request.php?delete-all/>



** prevention
*** xss prevention
------------------------------------------
         DETECTION (FOR XSS)

Code review:
   look for reading from a request object
   and 


Testing: set all inputs to a known


IBM Security AppScan
CAT.NET
------------------------------------------
        ... passing that request to a response object

        ... malicious value,
            then look for that value in the HTML rendered

            IBM's AppScan does static and dynamic analysis

------------------------------------------
           PREVENTION (FOR XSS)

Don't trust

Validate inputs


Encode output (HTML encoding or URL encoding)


Take CRLF out of input that goes into headers


Set a default character set:
<meta http-equiv="..." content="text/html";
    charset="ISO-8859-1" />
------------------------------------------
        ... user inputs

        Q: How could you validate inputs?
        Use regular expressions, or a parser.

        Q: Why does HTML or URL encoding help?
        It stops the input from looking like a script.

        Q: Why use a default character set?
        Harder for attacker to use certain escapes and tricks.

*** for xsrf
------------------------------------------
          PREVENTION (FOR XSRF)

 1. Use a secret value to authenticate
    the client to the server, and
    don't

 2. Give the session a timeout

 3. Use POST (instead of GET)


------------------------------------------
        ... store the secret value in the cookie!

        Q: What good does the timeout do?
        Makes it harder for the attacker.

        Q: Why use POST instead of GET?
        Makes it a bit harder to modify the requests.