“You may be running nonfree programs on your computer every day without realizing it—through your web browser.” Richard Stallman

Cross-Site Scripting (XSS).

XSS is a web-based attack performed on vulnerable web applications.

Malicious content is delivered to users using JavaScript.

These attacks can be used to steal authorization credentials (i.e. passwords) or hijack existing sessions. This way they can be used for identity theft or misuse. Thus, the victim is the user and not the application.

They work because the same browser is used for different web sites (i.e. banking and looking at cats) and this way it tears down security borders between these sites. Same Origin Policy is only of limited use in these cases.

Example: inclusion of third party scripts into a web site. This can be external Javascript libraries, tracking code like code analytics, buttons for social networks or advertisement. This included code is out of the control of the original web site but still has full access to the site inside the browser and can thus read information from it, fill in forms or read their content, navigate the user to different sites, press like buttons, inject advertisements or malware etc.

Apart from that Javascript can be used to fingerprint the browser in a more detailed way which might be a problem especially when trying to be anonymous.

It should not be possible to access files on the local machine (at least not without notification) but with attacks like DNS rebinding it can be possible to read the contents from intranet web sites and forward these information to the attacker.

Beware of Cross-Site Scripting (XSS) vulnerability

  • validate input early (in backend) and strip or reject bad values.
  • apply proper escaping/quoting just before using/outputting a value.

Avoid form validation in Javascript.

Never trust the client

Even CSS can be a risk if generated on the fly, because it, too, can contain scripts.

Using val() to read values from the page is not a reliable source.

Flash objects pose security risks.

Also be sure to always send the right Content-Type headers.

These are just the most basic rules to avoid the typical injection attacks. These are also the things that most frequently go wrong.

Cross-Site Request Forgery (CSRF)

Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.

The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.

The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

<iframe src="//www.yoursite.com/%3Ca%20href%3D"http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789">http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=..." >

Upon loading that iframe, my browser will send that request to examplebank.com, which my browser has already logged in as me. The request will be processed and send $1,500.00 to account 123456789.

Beware of AJAX request loads external scripts dynamically.

Dynamic JavaScript constructs that are difficult to analyze without interpreting the program, or is loaded along with scripts that use such constructs. These constructs are: –using the eval function, –calling methods with the square bracket notation, –using any other construct than a string literal with certain methods (Obj.write, Obj.createElement, …).

The program GNU LibreJS detects nonfree, nontrivial JavaScript in pages you visit, and blocks it. LibreJS is included in IceCat, and available as an add-on for Firefox.