Skip to content

CSRF & XSS

Cross-Site Request Forgery (CSRF)

  • in Cross-Site Request Forgery attack, attacker sends a cross-domain forged request, on behalf of the victim, from attacker's website to targeted website

  • if targeted website does not implement countermeasures, it cannot distinguish between authentic message and one originating from another domain

  • CSRF requires victim has an active session with target website while visiting attacker's website

  • attacker crafts a request to target server with selected querystring or post data to carry out the attack → without countermeasures the target server will not distinguish the origin of this request

  • can use GET or POST:

  • attacker can make a GET request in iframe or image etc.

  • attacker can make a POST request by scripting

  • many developers lack understanding of CSRF vulnerabilities and thus have implemented no countermeasures to protect against it

  • possible countermeasures:

    • using referer header: identifies the origin domain of the request; however referer may not be available due to privacy concerns

    • cookies SameSite attribute: there are two policies, strict and lax, where strict policy will not include cookies in cross-site requests; and lax will only attach cookies on top-level (browser?) navigations

    • secret token - server provides a secret token accessible only by its own pages, and requests to server include this token to indicate request is from same domain.

Cross-Site Scripting (XSS)

  • type of code injection attack involving attacker, victim, and target website where attacker injects code to victim's browser through target website → victim's browser will execute this injected code with victim's privileges

  • there are two XSS attack categories: non-persistent/reflected and persistent.

  • non-persistent/reflected attack:

    • reflection refers to website behavior of displaying user input back to user

    • if input is not sanitized before render, it may include injected code and be reflected back to user

    • example: injecting script into querystring and that script running on page load

  • persistent attack:

    • attacker sends data to target website and it is stored in persistent storage

    • if website loads the data without sanitizing it, the injected code may run in the context of the website without being distinguishable from authentic code

  • XSS worm - self-propagating version of XSS attack → injected code needs to replicate itself which can be either through external source or by copying itself dynamically

  • quine program = non-empty computer program which takes no input and produces a copy of its own source code as its only output. The standard terms for these programs in the computability theory and computer science literature are self-replicating programs, self-reproducing programs, and self-copying programs

  • countermeasures:

    • removing code from input:

      • filter code from user inputs: writing a good filter is challenging, <script/> is not the only tag to allow code → use well-vetted filters

      • encode all tags &lt; to disable input from executing

      • consider combining multiple approaches

    • apply strategies to separate data from code during development stage

      • use content-security policy (CSP) to disallow inline javascript (CSP also applies to video, audio, images):
      1
        Content-Security-Policy : script-src ' self'
      • use CSP to ensure linked JavaScript is from a trustworthy domain

    • trusted inline js can bypass CSP using a nonce value that enables only specific inline script blocks to execute but disables all others (nonce value is generated dynamically and changes)

       1
 2
 3
 4
 5
 6
 7
 8
 9
10
      // in response header:
Content-Security-Policy : script-src ' nonce-34fo3er92d'

<script nonce=34fo3er92d> 
// I can run
</script>

<script nonce=3efsdfsdff>
// cannot run
</script>