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
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.
Memory access restrictions
Opening and closing windows
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.
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.
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.
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.