• Prime prove tecniche per Content Security Policy di Firefox

    firefox_logo.jpg

    Mozilla Foundation ha presentato una prima demo del suo nuovo Content Security Policy detto anche “CSP”.

    Si tratta di un meccanismo che ha lo scopo di prevenire gli attacchi di tipo cross-site scripting (XSS).

    In particolare CSP consente ai Web administrator di inviare uno speciale header:

    X-Content-Security-Policy: allow 'self'

    che è in grado di informare il browser su quali domini dovrebbe accettare come sorgente fidata per codice e script vari.

    Alcuni attacchi di tipo XSS sfruttano le vulnerabilità presenti nelle applicazioni Web che consentono di eseguire codice JavaScript nel browser con i permessi dei domini fidati.

    Grazie invece a CSP, il browser eseguirà unicamente script che hanno origine da domini inseriti all’interno della whitelist: tutto il resto verrà bloccato.

    Questo consentirà di definire dei veri e propri “script server” da dove verranno recuperati gli script poi eseguiti.

    Non sarà quindi più possibile fare script injection all’interno di file HTML.

    CSP funziona unicamente in una versione apposita del browser. A questo scopo è stata “confezionata” una Preview Build di Firefox che supporti questa funzionalità.

    Nonostante sia possibile effettuare i primi test è ancora troppo presto per un giudizio finale visto che la release in questione non supporta ancora tutte le specifiche previste.

    È stata messa online una speciale pagina Web dove è possibile testare e verificare il corretto funzionamento di CSP.

    Brandon Sterne, Security Program Manager di Mozilla, spera di ricevere al più presto le prime impressioni su questa versione “speciale” di Firefox.

    Tags:

    Se vuoi aggiornamenti su Prime prove tecniche per Content Security Policy di Firefox inserisci la tua e-mail nel box qui sotto:


    Ho letto e acconsento l'informativa sulla privacy

    Si No

    Acconsento al trattamento dei dati personali di cui al punto 3 dell'informativa sulla privacy

    Si No

    Commenti

    1. emmebì dice:

      Come gli antivirus su firma, questo bloccherà solo gli script da url blacklisted.

      E’ la direzione giusta?

    2. No lo scopo è di consentire solo script da url nella whitelist ;-)
      Mi sembra senza dubbio una buona soluzione per cominciare, anche se con tutta probabilità compariranno metodi per bypassare questa funzionalità o sfruttarla a vantaggio dell’attaccante.
      Penso ad esempio alla possibilità di intercettare e forgiare questo nuovo header a proprio piacimento per far “considerare” sicura una sorgente script malevole.

    3. lij dice:

      Ma la nuova navigazione a schede quando verrà introdotta?? se n’è parlato tanto e poi?? e questa funzionalità di sicurezza da che versione? speriamo entrambe vengano introdotte alla 3.6

    4. emmebì dice:

      Beh è il browser ad interpretare quell’header. Posta l’assenza di script iniettati (cioè se questo CSP funziona bene), non vedo come sia possibile modificarlo, se non per lo stesso programmatore del prog.Web o via bug di FF stesso..

      Per il mio post, intendo dire che non è per nulla noto a priori quali siano le sorgenti di script fidate (sia per approcci black- che white-) e quali meno..

      Approccio white. E’ come il miglior amico che ti tradisce: credi di esser al sicuro e poi te la prendi…

      Al contrario, approccio black- : (l’universo-quelli di cui non mi fido) = quelli di cui mi fido?? No.

      In sintesi, per me serve a poco questa cosa..

    5. @lij: Per CSP mi sa che si dovrà aspettare dopo la 3.6, anche perchè dalla roadmap questa minor release è prevista a breve.
      Per il discorso navigazione a schede, se intendi la modalità dei processi separati stile Chrome ci sarà da aspettare fino alla 4.

      @emmebi: per il discorso dell’header è pur vero che gli attacchi MITM ci hanno abituato a tutto :-) non escludo quindi che si possa forgiare un finto header partendo da quello che sta inviando il server verso il client. Poi sul discorso blacklist e whitelist son d’accordo con te che certamente non sono la soluzione finale ai problemi, pero’ un aiuto in più in questo caso lo possono dare. Personalmente sono più favorevole laddove sia possibile alle whitelist.

    6. emmebì dice:

      @Massimo,

      nel caso si sia in presenza di MiM mi preoccuperei di ben altro che inclusioni js/modifica HTML.. Che poi, cmq, in contesti SSL sarebbe quasi-impossibile.

    7. emmebì dice:

      P.S. Concordo con te che le whitelist sono evidentemente più stringenti. Ma ben più “dolorose” da seguire, per puri paranoici insomma, se fatte a livello “globale”. Qui credo sia il programmatore stesso a deciderele (?)

    Commenta

    Your email address will not be published. Required fields are marked *