Security and JavaScript

Learning Objectives By the end of this lecture, you should be able to: Describe what is meant by JavaScript’s same-origin security policy Explain using an example how a Cross-Domain Scripting attack might work

Security and JavaScript One of the most important considerations for the people who developed the JavaScript language was the issue of security. As a programming (okay, ‘scripting’) language, there is quite a bit of power available to the skilled developer. For this reason, the standards group charged with creating JS standards required that the language adhere to certain security parameters. Arguably, the two most important security considerations in web scripting involve files and browser windows. Files: JavaScript does not allow the programmer to open up files on a user’s computer unless given explicit permission to do so. Windows: Another important standard is that JavaScript does not allow one browser window to access a different window. Also note that each tab in a browser is considered to be a different window. This will be discussed further when we touch on the “Same-Origin” security policy next.

JavaScript’s “Same-Origin” Security policy Imagine that you have Amazon.com open in one tab , and are about to finalize a purchase an expensive piece of stereo equipment. Before confirming your purchase, you open a new tab where a quick Google search shows a site you've never heard of offering a 1-hour flash sale on the same item. Turns out, though, that the "sale" page is, in fact, a malicious site that has script embedded in it. The programmer of that site uses scripting code to access your Amazon.com window. The programmer allows the Amazon window to go ahead and finalize your purchase. However, the site also changes the shipping address to a location in Slovenia. For good measure, they tack on a few additional items, and, as an afterthought, a new boat. This scenario might indeed be possible to the clever programmer were it not for JavaScript’s “same origin” security policy. This policy ensures that JavaScript disallow communication between windows that have different domains, protocols or ports. Therefore, since the Amazon window is on the domain ‘amazon.com’, and the malicious site is ‘badstuffhere.si’, scripts originating in the latter would be unable to access the Amazon window.

“Same-Origin” Security policy Ensures that there is no communication via script between pages that have different domains, protocols or ports. Protects against snooping from one domain on another domain. Even within the pages residing in same domain there are limitations. For example, if your domain is: http://www.somecompany.com , then any JavaScript running on your page would not be allowed to communicate with any of the following: http://othercompany.com  Different domain altogether https://www.somecompany.com  Different protocol (https) http://www.somecompany.com:8080  Different port (default is 80) http://other.somecompany.com  Different host There are techniques for allowing pages within the same domain to communicate with each other, provided that the server is configured to allow it.

Cross-Domain Communication The JavaScript standard does allow for some communication to span domains. For example, the <img> tag is allowed to access certain resources from other domains. This is why a student on a server in the ‘depaul.edu’ domain can have an image tag that looks like this: <img src=“http://www.someStrangeSite.com/images/firetruck.jpg”>

Cross-Site Scripting (“XSS”) Attacks XSS attacks are a classic JavaScript vulnerability in which malicious script is injected in such a way that it fools the victim site into believing that the script is local, and may therefore be trusted and executed. These attacks bypass the same-origin policy because browsers trust all of the code that shows up on a page as being a legitimate part of that page. So if a malicious programmer has a way of injecting code into a naïve or ‘unsanitised’ page, then real-damage may occur. Cross-site scripting is a major issue that any competent JavaScript programmer will be attuned to. Example: Suppose you have a text field asking the user for their name. Your script then outputs: “You’re name is “ followed by the information the user entered. Now imagine that the user entered for their “name”: <script>alert(navigator.userAgent)</script> "Sanitising" Input: The above example demonstrates a situation in which the user’s input is not properly “sanitised”. It is very important to take all free-text input from the user and ensure that there are no characters or symbols that should not be there. We will discuss techniques for sanitising user-input when we talk about Regular Expressions. See: script_injection.htm

Content Security Policy The W3C maintains an ongoing response to JavaScript’s security vulnerabilities. One of the most active defenses being moderated by the W3C comes in the form of the ‘Content Security Policy’ or ‘CSP’. A link to the discussion and whitepaper of the CSP standard can be found here: https://w3c.github.io/webappsec/specs/content-security-policy/