When a user loads a web page to the browser, any JavaScript code can be executed on his or her computer. This may cause security issues.
Browser vendors had to work out a balance between providing powerful client-side APIs and at the same time solutions that are safe for users. They strive to prevent users from being exposed to malicious code that could lead to theft or corruption of their data.
To protect users against malicious software and various types of abuses some APIs were restricted or entirely disabled.
Access to user’s resources
Access to local file system restrictions
One of the fundamental security policies prohibits JavaScript scripts included on web pages from having access to the files on user computer. The assumption is that JavaScript scripts do not have access to local file system. If they have access, any web page that you load could steal or destroy your files.
JavaScript scripts in web browsers are run in “sandbox” environment that isolates them from direct access to the operating system. Scripts have access to the current document and related documents but do not have access to local file system.
JavaScript cannot write and update files, and cannot list directories. This prevent users against data deletion and against infection by viruses.
The only way that JavaScript script can read the local file is explicitly select a file by the user by using the browser’s built-in dialog (FileReader API).
Note that for security reason the value of FileUpload element cannot be set. This prevents sending any files to the server without the consent of the user.
Be aware that some browsers may have security holes and the sandbox may not work as per the assumptions.
Networking restrictions
Client-side JavaScript does not have general-purpose networking capabilities. JavaScript scripts handle HTTP protocol. However JavaScript does not have access to the operating system’s networking layer.
Memory access restrictions
JavaScript has no access to the memory space. JavaScript objects are stored in memory but there is no direct access to memory in JavaScript. It is handled by JavaScript engines.
Opening and closing windows
JavaScript has the ability to open browser windows. However, to prevent abuse of pop-up windows most browsers restrict this feature. It can be done only in response to an user event like mouse click.
JavaScript script can close browser window. But this is limited to the windows that were opened by the script itself.
The same origin policy
The same origin policy prevents scripts loaded from one website from reading or setting properties of a document loaded from a different website.
This applies for example if the web page contains <iframe> or when it opens a new window. JavaScript script can read and set only the properties of windows and documents that have the same origin as the document that includes the script.
Origin
The origin of a document is specified by the protocol, host and and port of the URL address from which the document was loaded. Two documents have the same origin if they are loaded from URLs with the same protocol, host and port.
Note that the origin of the script itself is not important. Important is the origin of the document in which the script is included.
JavaScript script can open a new window and load a document from different origin. It can close the window but it cannot read the content of that document.
The same origin policy applies also to HTTP requests via XMLHttpRequest object. HTTP communication is allowed with the web server from which the document including the JavaScript script was loaded. It is not allowed to communicate scripts with other web servers.
The same origin policy prevent from stealing sensitive data. Without this restriction a malicious script could open a new window in order to cause the user to use it for browsing websites. Then malicious script could track user’s activities, read content of that window and send collected information to its own server.
Relaxing the same origin policy
Sometimes the same origin policy may be problematic, for example for websites which use subdomains. To support interactions between subdomains of the same website you can use the domain property of the Document object. By default the domain property contains the hostname of the server from which the document was loaded. It can be set to a suffix of current domain. For example if current value of the domain is “app.example.org”, it can be set to “example.org”. Scripts from two subdomains that have set the same domain property may cooperate with each other.
The same origin policy may be also relaxed for HTTP communication. It is done through technique called Cross-Origin Resource Sharing (CORS). CORS uses additional HTTP header Access-Control-Allow-Origin. It allows servers to use that header and specify the list of servers (or use a wildcard to give access to all servers) which may request a given resource.
For example a script contained in a document that has http://example.com origin sends a request to http://website.com. Server on domain http://website.com responses with the “Access-Control-Allow-Origin: *” header. It means that resource can be accessed by any domain and web browser allows to access it.
Browser plugins
Web browsers allow instal plugins that are software components adding new features to standard functionalities (eg. Flash player, video players, Java applets, ActiveX controls). JavaScript provides an interface to handle these plugins. Plugins like Java applets and ActiveX controls have access to low level features. They may have security holes. Attackers can use JavaScript to exploit these flaws and run malicious code on user’s computer.
Cross-Site Scripting
Cross-Site Scripting (XSS) is type of web applications vulnerability, in which an attacker injects HTML or JavaScript code into web pages viewed by other users.
Web page is vulnerable to XSS attack when:
– data is added to the web application from an untrusted source, most often through web request,
– web page content is generated dynamically and bases on sent by user data without validating it against malicious code.
XSS attacks can be reflected or permanent.
XSS attack is reflected when data provided in the web request is used immediately by server-side script to display a web page with result to an attacked user without properly sanitizing the request. This happens usually when user is tricked to click a malicious link with harmful data in query parameters or submit a crafted form.
XSS attack is permanent when injected code is permanently stored on the target server, mainly in the database. Then each time when a victim requests a given resource, it receive malicious code.
The way to prevent XSS attacks is to sanitize any untrusted data. Any dangerous code should be removed. Escape (encode) HTML tags and HTML attributes, JavaScript, CSS and URLs before inserting untrusted data.
Reply