Permettete a XSS le password? Si dovrebbe!

Ci sono due principi di sicurezza che tengo caro, ma sono spesso controintuitivo:

1. Gli utenti dovrebbero essere in grado di creare qualsiasi password concepibile che desiderano - senza limiti!
2. Tutti gli input devono essere trattati come ostile e disinfettato correttamente contro una whitelist.

Questo è un consiglio controintuitivo, in quanto questo secondo punto è sempre statoparzialmente supportato nativamente dalla convalida delle richieste ASP.NET. Dico "in parte" perché non è l'ultima parola di convalida della richiesta e si dovrebbe sempre correttamente whitelist l'input ammissibile oltre alle difese quadro nativi. Detto questo, si dovrebbe sempre (almeno nella misura del possibile) lasciare abilitata la convalida delle richieste e, in passato sono stato critico di coloro che non lo fanno . E 'abbastanza importante che ho arrotolato un test per questo in ASafaWeb .

Tornando a questi principi essere controintuitivo, il mese scorso ho ricevuto un messaggio interessante da un sostenitore ASafaWeb amichevole:

Bugger. Naturalmente ciò che stava accadendo in realtà è abbastanza chiaro, non vi resta che provare a cambiare la password per "<script>":

Chiaramente questo è il mio ambiente di sviluppo dato il messaggio di errore interno, ma questo è esattamente ciò che stava accadendo sul sito pubblico troppo - la convalida della richiesta è stato respinto l'ingresso.

Allora, perché è necessario per questo un campo password? Beh in primo luogo, ASP.NET non fa discriminazioni; dati post è dati di invio e se contiene lo script potenzialmente dannoso poi è respinto. Ma perché dovrebbe ti preoccupi di un attacco XSS potenziale nel campo di una password? Voglio dire, non e 'come si sta andando mai a rendere a una pagina o e-mail, a destra (tosse, Tesco )? Naturalmente la prima cosa che dovrebbe accadere a una password quando si colpisce il server web è che dovrebbe essere crittograficamente hash e mai reso a qualsiasi contesto di output di nuovo. Mai.

Ai vecchi tempi, l'unico modo per consentire a XSS le password sarebbe stata quella di disattivare la richiesta di convalida nella pagina. Purtroppo questo significherebbe anche disabilitarlo su tutti gli altri campi, permettendo così XSS nel nome, indirizzo, numero di telefono e qualsiasi altro luogo lo sviluppatore non era esplicitamente whitelisting dati attendibili (che, purtroppo, è di solito in tutto il mondo). In realtà, la convalida delle richieste è stato spesso disattivata in tutto il sito che è sicuramente auspicabile.

Inserisci NET 4.5 e. due aggiunte molto fresco nuovo per richiedere la convalida :

1. Differita o la convalida "pigro": solo i dati che è in realtà accede è soggetta a convalida. Posta (o ottenere) un pezzo con nome casuale di dati e non verrà convalidato.
2. Non convalidato le richieste: non tutti i dati deve essere oggetto di richiesta di convalida e ora può essere selettivamente ignorato in diversi modi.

E 'questo secondo punto che significa che XSS nei campi della password è ormai una realtà, senza compromettere la sicurezza dei campi che si desidera ancora convalidato. Ci sono vari modi di attuazione della presente all'interno di ASP.NET MVC e non la convalida dei dati.

Per esempio, l'azione di controllo può essere diretto a convalidare l'input non:

[ HttpPost ]
[ ValidateInput ( true )]
 pubblico ActionResult ChangePassword ( ChangePasswordModel modello)

Che lavora per una modifica della password in cui normalmente solo tre password nei dati post (vecchio, nuovo, confermano che il nuovo), ma come al momento della registrazione?Se non si desidera disattivare la convalida della richiesta su tutti quei altri campi.

Fortunatamente possiamo solo scendere al livello di modello e disattivare la convalida su un attributo utilizzando l'annotazione AllowHtml dati:

[ AllowHtml ]
[ Required (ErrorMessage = "La password è necessaria" )]
[ StringLength (100, ErrorMessage = "La password deve essere di almeno {2} 
caratteri " , MinimumLength = 8)]
[ DataType ( DataType . password)]
[ Visualizza (Name = "Password" )]
 public string Password { ottenere ; set ;}

Ci sono poche altre opzioni disponibili per l'oggetto richiesta e (particolarmente utile per i web form), ma in realtà non si può ottenere molto più facile di questo nel mondo MVC - è sufficiente aggiungere i dati di annotazione per ogni attributo password.

Ciò è possibile solo con. NET 4.5 e che è una delle molte caratteristiche che posso ora sfruttare in ASafaWeb dopo recente aggiornamento del quadro e avendo AppHarbor sostegno che essendo precedenti adopter della nuova versione nel loro ambiente di hosting. Quindi, per gli utenti di ASafaWeb, impazzire con XSS in le password! Quanto a quelli di voi con pre-ASP.NET 4,5 siti, perché siete ancora limitando le mie opzioni per le password? :)

Edit (9 settembre): ho bisogno di chiarire questo un po 'meglio (buon promemoria del motivo per cui cerco di non correre i post sul blog!) - la ValidateInput e AllowHtml attributi utilizzati su azioni di controllo e le proprietà di classe è disponibile in MVC per un po' (pre. NET 4.5) e li troverete nella documentazione per la convalida delle richieste ASP.NET 4 .Cosa c'è di completamente nuovo per 4.5 è la possibilità di disabilitare selettivamente sulle proprietà richiesta individuale. La documentazione per la convalida delle richieste ASP.NET 4,5 dà una buona sintesi:

Request.Form [ "userinput" ]; / / Convalidato, errore se l'ingresso include markup

Request.Unvalidated ( "userinput" ); / / Validazione bypassato
 Request.Unvalidated () modulo [. "userinput" ]; / / Validazione bypassato

Request.QueryString [ "userPreference" ]; / / Convalidato
 Request.Unvalidated () QueryString [. "userPreference" ]; / / Validazione bypassato

Corso Visual Studio - Corsi Visual Studio

Corso .Net- Corso Dot.Net - Corso Vb.net

Corso C# - Corso PHP - Corso Joomla