1. Security and JavaScript

2. 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

3. Security and JavaScript Perhaps the most important consideration for the people who developed the JavaScript language, is 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. Perhaps the two most important considerations 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. “Same-Origin” Policy: Another very 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.

4. 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. Unfortunately, that page is, in fact, a malicious site that has script embedded in it. The malicious programmer accesses your Amazon.com window. The site goes ahead and finalizes your purchase, but then changes the 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 requires that JavaScript does not allow communication via script 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.

5. “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 none of the following sites would be allowed to communicate with each other via JavaScript: – 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.

6. Cross-Domain Communication The JavaScript standard does allow for some communication to span domains. For example, the 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:

7. 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 skilled JavaScript programmers must 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”: alert(navigator.userAgent) This is an example 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

8. 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/