Scriptorama.nl

Een werknemer van Mozilla heeft een nieuwe voorstel uit gebracht dat het gevaar van Cross Site Scripting (XSS) en Cross Site Request Forgery (CSRF) moet beperken. Het voorstel beschrijft namelijk manieren om op te geven welke hosts / domeinen bijv. Javascript mogen aanleveren of juist een bepaald request mogen uitvoeren. Mocht er een situatie voorkomen waarbij een van deze regels doorbroken zou worden (bijv: een niet toegestane host probeert request uit te voeren), dan kan de site ook een URL opgeven waarnaar een rapport gestuurd moet worden.

Site Security Policy provides a way to greatly reduce or altogether eliminate a website's attack surface for Cross-Site Scripting. With proper Site Security Policy in place, a successful XSS attack will require the attacker to have control over the contents of white-listed script source files. No longer will XSS attacks which rely on echoing script into page contents be effective. Further, if a site knows it never want to have JavaScript executing in its pages, it can simply globally disable JavaScript and not have to worry about script injection attacks against its users with supporting browsers.

Site Security Policy also provides a simple way for a website to prevent Cross-Site Request Forgery against its sensitive resources. A comprehensive CSRF protection mechanism, such as form token checking, can be complicated to implement and difficult to integrate into an existing web application. Such a mechanism may even be subject to its own security bugs. Even a properly implemented CSRF-protection-token system will not stand up in an environment with XSS bugs. Web sites facing these challenges can utilize Site Security Policy to harden themselves against attack and achieve a higher level of confidence in the security of their systems with an added layer of security. Websites will be able to fully control who can request resources from outside the site and what remote locations should be reachable by content from within the site.

Het voorstel is compleet met voorbeelden van syntax en zelfs een Firefox Addon waarin het voorgestelde reeds is geimplementeerd. Wat denk jij, zou een dergelijke beveiliging vanuit de browser helpen, of moet de focus toch meer bij de ontwikkelaars blijven liggen?

Lees het hele voorstel »

Het zal wel een beetje een koude dag in de hel zijn, maar de volgende versie van Firefox, Firefox 3.0, zal een feature bevatten die zijn oorsprong kent uit Microsoft Internet Explorer: HttpOnly cookies. Een HttpOnly cookie krijgt een flag mee welke de browser vertelt dat dit cookie niet uitgelezen mag worden door Javascript:

If Internet Explorer 6.0 SP1 (available in Microsoft Windows® XP SP1 and at the
Windows Update Site) detects a cookie marked HttpOnly and some client side
script code, such as JavaScript, attempts to read the cookie (document.cookie,
for example), Internet Explorer returns an empty string, thus preventing the
attack by preventing the malicious code in the XSS attack from sending the data
back to a malicious site. Of course, the cookie is passed to and from the
originating server as normal; the browser using script code just can't read it.
A cookie is set on the client with an HTTP response header. The following shows
the syntax used in this header:

Set-Cookie: <name>=<value>[; <name>=<value>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

Kortom, als een stuk Javascript een HttpOnly cookie probeert uit te lezen krijgt deze simpelweg een lege string terug. Door bijvoorbeeld session cookies als HttpOnly cookie te versturen zorg je er voor dat de impact van een mogelijk cross-site-scripting probleem binnen je site een stuk minder wordt -> de aanvaller kan met een HttpOnly session cookie nooit het sessie ID opvragen en daar vervolgens vervelende dingen mee te doen. Uiteraard is dit niet een oplossing voor cross-site-scripting maar meer een soort veiligheidsnet voor de keren dat het wel voorkomt.

PHP bevat sinds versie 5.2 ook ondersteuning voor HttpOnly cookies, doormiddel van het 7e (!) argument aan SetCookie():

Tevens kun je met de setting session.cookie_httponly aangeven dat de session cookie ook als HttpOnly cookie verstuurd moet worden. Heb je nog geen PHP 5.2, dan kun je met een header() aanroep natuurlijk zelf een cookie zetten met de HttpOnly flag:

Voor HttpOnly session cookies zul je echter moeten upgraden naar PHP 5.2

Zoals we al schreven bij de release van PHP 5.2.1 was Stefan Esser van plan om in maart een Month Of PHP Bugs (MOPB) te houden net zoals deze ook al eens gehouden werd voor Apple software (MOAP). Maart is inmiddels begonnen en Stefan Esser is dan ook meteen los gegaan en heeft al niet minder dan 5 advisories vrijgegeven:

• MOPB-01 - PHP 4 Userland ZVAL Reference Counter Overflow Vulnerability In PHP 4 userland code is able to overflow the internal 16bit zval reference counter by creating many references to a variable. This leads to an exploitable double dtor condition.
• MOPB-02 - PHP Executor Deep Recursion Stack Overflow A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash.
• MOPB-03 - PHP Variable Destructor Deep Recursion Stack Overflow The destruction of deeply nested PHP arrays will exhaust all available stack which leads to remotely triggerable crashes.
• MOPB-04 - PHP 4 unserialize() ZVAL Reference Counter Overflow During unserialisation of user supplied data that contains a lot of references to a variable the internal 16bit zval reference counter can overflow. This leads to an exploitable double dtor condition.
• MOPB-05 - PHP unserialize() 64 bit Array Creation Denial of Service Vulnerability Deserialisation of malformed PHP arrays from within unserialize() might result in a tight endless loop exhausting CPU ressources on 64bit systems.

Deze problemen zijn wel serieus maar gelukkig niet allemaal unpatched. Sommige problemen zijn reeds opgelost in de meest recente versies van PHP, terwijl andere alleen in PHP4 een probleem zijn. In andere gevallen zijn de problemen te omzeilen door Stefan Esser's Suhosin extensie te gebruiken.

Met de eerste advisories een Proof-of-Concept exploits beschikbaar wordt het interessant om te zien hoe de PHP ontwikkelaars gaan reageren op de claims van Esser. Ondanks de wat moeizame relaties tussen Stefan Esser en de PHP group lijkt het mij dat de PHP group het zich niet kan veroorloven om niet te reageren op deze zaken. Zeker met de mogelijke exploits die bijv. door MOPB-04 worden beschreven.

In ander nieuws: PHP 4.4.6 is vrijgegeven met een oplossing voor een crash in 4.4.5 dat kon ontstaan wanneer je sessies en register_globals gebruikte.

In dit artikeltje keken we naar een paar standaard dingen die vaak fout gaan bij mensen die met PHP beginnen. In deze korte toevoeging kijken we even naar wat variabelen in $_SERVER en hoe je die zou moeten gebruiken.

(more...)

Kwam dit vandaag tegen op FeedHouse. Het is een uitleg van een veiligheids probleem dat recentelijk in Google's GMail werd gevonden. Het probleem in GMail is (natuurlijk) inmiddels opgelost, maar het is desondanks een interessante uitleg.

[WEB SECURITY] Advanced Web Attacks using Gmail

AJAX brengt een nieuwe webexperience, maar mogelijk ook een hele nieuwe buslading aan veiligheids problemen waar je rekening mee moet houden :)

In de posting die ik laatst deed over de nieuwe versies van PHP 4 en 5 schreef ik over dat je (tot PHP 5.1.2) via het Session ID extra HTTP headers mee kon sturen en daarmee de nodige nare trucjes mee kon uithalen. In principe bestaat dit probleem ook in ander onderdeel van PHP, alleen, deze keer is het niet perse de schuld van PHP.

(more...)

Website-veiligheid is momenteel een hot-topic in PHP land. De nodige opensource pakketten zijn de laatste tijd negatief in het nieuws geweest in verband met beveiligingsproblemen. Daarom hier een paar tips waarmee je je eigen site wat veiliger kunt maken.

(more...)