lectures.alex.balgavy.eu

Lecture notes from university.
git clone git://git.alex.balgavy.eu/lectures.alex.balgavy.eu.git
Log | Files | Refs | Submodules

Lecture 11_ Web attacks on user.md (3968B)

      1 +++
      2 title = "Lecture 11: Web attacks on user"
      3 +++
      4 
      5 # Lecture 11: Web attacks on user
      6 ## Accessing user info
      7 User info can be accessed in many ways:
      8 - drive-by-download attacks let malicious server execute arbitrary commands on user's host
      9 - host under control of attacker can impersonate legitimate security-critical server
     10 - JS code can be injected in a page to steal critical info associated with web app (cross-site scripting)
     11 
     12 ### Cross-site scripting (XSS)
     13 Used to bypass JS's same origin policy.
     14 - reflected attacks
     15     - injected code reflected off web server, like in error message or search result
     16     - essentially in any response that includes some of input sent to server as part of request
     17     - for example, if server uses requested path in HTML of error page, you can embed `<script>` tags with JS in the requested path
     18 - stored attacks
     19     - injected code permanently stored on target servers, e.g. in database, forum, visitor log, comment field
     20     - two-step: first store the code as part of a message, then victim downloads and executes code when page containing attacker's input is viewed
     21 
     22 Preventing XSS:
     23 - every piece of data returned to the user that can be influenced by inputs *must be sanitized*
     24 - languages often provide routines for this
     25 - sanitization is different depending on where data is used
     26 - follow some rules:
     27     1. never insert untrusted data except in allowed locations
     28     2. HTML escape before inserting untrusted data into HTML element content
     29     3. attribute escape before inserting untrusted data into HTML common attributes
     30     4. JS escape before inserting untrusted data into HTML JS data values
     31     5. CSS escape before inserting untrusted data into HTML style property values
     32     6. URL escape before inserting untrusted data into HTML URL attributes
     33 - use `httponly` in cookie -- means cannot be accessed through client side script
     34 - [XSS prevention cheat sheet](http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet)
     35 
     36 ### Cross-site request forgery (CSRF/XSRF)
     37 Allows attacker to execute requests on behalf of victim.
     38 Embed a request in e.g. an image tag on a malicious page, like:
     39 
     40 ```html
     41 <img src="http://bank.com/transfer.php?amount=100000&dest=52345235" />
     42 ```
     43 
     44 It's a "confused deputy attack":
     45 - deputy == browser
     46 - confused so that it uses victim's authority to do what attacker says
     47 
     48 Preventing CSRF:
     49 - CSRF tokens:
     50     - HTML only:
     51         - web server embeds token (secret unique per request) in all HTML forms, verified on server side
     52         - every legit request will have it
     53         - token may be generated using any method ensuring unpredictability and uniqueness
     54     - Header-based for web apps with JS
     55         - on login, app sets cookie containing random token that remains for whole session
     56         - JS on client side reads value, copies into custom HTTP header sent with each transactional request
     57         - server validates presence
     58         - only JS running in same origin will be able to read the cookie
     59 
     60 ## HTTP response splitting
     61 Exploits fact that user provided data is in header of reply.
     62 
     63 For example, a redirect header includes the location.
     64 If that's added verbatim, the attacker might be able to add terminating CRLFs to build a second header.
     65 This poisons the web cache, associating the attacker-generated reply with the address.
     66 
     67 HTTP request smuggling is possible in a similar way.
     68 
     69 ## Language problems
     70 There are also language-specific vulnerabilities.
     71 PHP:
     72 - infers types, could lead to issues
     73 - people might do loose comparisons (`==`) instead of strict (`===`)
     74 
     75 Pyhon pickle
     76 - serialization library
     77 - pickle can handle arbitrary objects, including `subprocess.Popen`
     78     - can't do this directly in Python
     79     - but pickle allows pickling arbitrary objects with a `__reduce__` method returning string or tuple of callable and argument tuple
     80 - you can pickle a `subprocess.Popen` that calls a shell
     81 - if server unpickles header/body, you own it