Posts Tagged ‘xss’

ASP.NET and input validation against XSS

Friday, September 5th, 2008

The today’s topic is XSS under ASP.NET and how validation filters and request filters works and are applied under ASP.NET.

The Microsoft .NET framework comes with a request validation feature, configurable by the ValidateRequest setting. ValidateRequest has been a feature of ASP.NET since version 1.1. This feature consists of a series of filters, designed to prevent classic web input validation attacks such as HTML injection and XSS (Cross-site Scripting).

Procheckup describe how bypass ValidateRequest in a whitepaper.

On the other side, some ASP.NET controls offers by default automatic html encoding, a great resource when you are reviewing your code for possible Cross-Site Scripting (XSS) or double encoding problems is this table that list all ASP.NET control and which property offers html, script or url encoding.

Le vulnerabilita` XSS sono sottovalutate

Monday, November 19th, 2007

Vi racconto una storiella accaduta circa un paio di settimane fa.

Come spesso accade qualcuno incolla un link in una delle chat che frequento, io ci clicco sopra e mi trovo un sito di uno dei maggiori partiti politici italiani, con un form che richiede l’inserimento di dati personali per la registrazione a una sottoscrizione.
Non menzionero` ne il partito politico ne a cosa serviva quella sottoscrizione, ho visto che proprio ieri lo hanno fatto altri, quindi lascio a loro gloria e fama sulle riviste patinate.ieri

La cosa attira la mia attenzione, do` una rapida occhiata ai sorgenti html della pagina, [snip], e noto che il modulo di registrazione non valida assolutamente nulla.

Non soltanto gli sviluppatori di tale sito si fidano ciecamente dell’input immesso da un utente, ma si fidano anche ciecamente della sua lealta`. Esatto, perche` non soltanto la form di immissione dei dati non valida la loro natura, ma non valida nemmeno il voto, e` infatti possibile effettuare innumerevoli volte la sottoscrizione, di fatto invalidando la consistenza di tale sottiscrizione, che prevede una registrazione per ogni persona fisica.

Quindi e` possibile far le peggior cose con tale sito, in particolare:

  1. Falsare i risultati della sottoscrizione
  2. Inserire dell’input malformato, cioe` non previsto dagli sviluppatori, al fine di mettere l’applicazione web in uno stato non previsto o di riuscire ad iniettare del codice

Notate come il punto 2 puo` portare a tutta una serie di problematiche di sicurezza, chiamate ad esempio html injection, sql injection, XSS.

E infatti secondo voi, un sito sviluppato da programmatori che fanno il solito, tipico, classico errore di fidarsi dell’utente, sara` sicuro?

Guarda caso noto proprio tutta una serie di vulnerabilita` XSS, molto gravi per la sicurezza del sito e dei suoi utenti.

Di solito quando trovo questo tipo di vulnerabilita`, nell’ottica di una responsible disclosure, prima avverto i gestori concedendo un tempo ragionevole per tappare la falla, e poi rendo pubblica la vulnerabilita`.

Cosi faccio spedendo una mail ai gestori del sito.

Un bel po’ di giorni dopo, evidentemente queste persone il week end non lavorano nemmeno per le problematiche di sicurezza, ricevo una risposta di questo tipo:
"La ringraziamo per la segnalazione, abbiamo verificato quello che lei dice e ci e` stato confermato il fatto dai nostri sistemisti, che dicono che il sistema e` sicuro e che anche in presenza di XSS non sarebbe pericoloso. Grazie bla bla yadda yadda"
Eh?! Ma scherziamo?
Riassumendo in poche righe buttate giu a getto, quale e` l’impatto di una vulnerabilita` di tipo XSS:

  • La privacy: Può trasmettere dati privati dell’utente, tracciare le sue abitudine, trafugare la history
  • Autenticazione: furto di credenziali, furto del password manager
  • Integrità: Può alterare il sito visitato, redirigere l’utente ad un altro sito, visualizzare siti di terze parti o parti di esso, praticamente un paradiso per il phishing
  • Disponibilità: causare DoS
  • Attaco all’utente: Exploitation del browser e sue estensioni
  • Attacco alla lan dell’utente

Ora io non direi che anche in presenza di vulnerabilita` XSS un sito puo` essere considerato in sicurezza, perche` minaccia sia le sicurezze degli utenti che lo visitano, sia la sicurezza e la reputazione del sito.

Che dire… Io ho segnalato il fatto, i sistemisti hanno affermato che non e` una minaccia per la sicurezza.
Bene, sapanno fare il loro mestiere, o almeno glielo auguro, perche` proprio ieri leggevo di una persona che ha fatto 100000 (si, cento mila) sottoscrizioni in due minuti, e spero, per loro, che nessuno si pensi di utilizzare una di quelle vulnerabilita` per visualizzare il sito del partito politico opposto in vece del sito vero.

La mancanza di cultura, e` un problema del mondo moderno, la non coscienza della propria ignoranza, anche.
In certi mestieri questo puo` essere letale.

Rails Security: Secure your Ruby on Rails web application

Saturday, July 14th, 2007

Ruby on Rails is a great Ruby framework for rapid development of web applications.
But default Rails comes with some (in)security features that must be hardened and fixed.
And a lot of the how to and tutorials in internet that publish the sponsor “websites in 5 minutes” help people to write insecure code.
Some examples:
File permission: default Rails cames with leak permission, all can read DB config and all can read and write log files.
Sessions: session does not expire server side
Validate input: the input must be properly validated to avoid sql injection and xss
Escape output: rember to use html_escape if you display user input data
Here is some links to secure your Rails installation and secure your web application from sql injections, xss and other stuff.

Links: