martedì 18 settembre 2012

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:
@ Troyhunt problema con il compagno di asafaweb registrazione - 1Password utilizzato per generare 20char e ho ottenuto un errore di 'bastardo' - gestito un pw meno sicuro ok
Bugger. Naturalmente ciò che stava accadendo in realtà è abbastanza chiaro, non vi resta che provare a cambiare la password per "<script>":
Richiesta convalida sparare sul campo password,
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

martedì 4 settembre 2012

Fissaggio DoS hash buona e giusta (e la rottura ASafaWeb)


Ricorda DoS hash ? Questo è stato molto intelligente che attacco ma altrettanto brutto piccolo che significa che se si formatta i parametri in un juuuuust richiesta palo destro si potrebbe abbattere un sito Web ASP.NET con una semplice richiesta singola. Bugger.
Questo fatto per una piuttosto sgradevole periodo di Natale e Capodanno per un certo numero di persone a Microsoft così come gli amministratori di sistema di tutto il mondo.Microsoft ha rilasciato un rapido il bollettino MS11-100 critica patch o in altre parole, la stop-cosa-tu sei-fare-e-install-it-RIGHT-NOW patch.
Ma non era davvero una patch di per sé, in quanto non è stato risolto la vulnerabilità sottostante, che era legato a collisioni hash. Invece, si è fermato a un utente malintenzionato di pubblicare più di 1.000 parametri del modulo a un sito web in modo pensare di più come una difesa preventiva, piuttosto che una correzione.
Ho anche avuto un po 'di punta in questo periodo perché volevo arrivare ASafaWeb scansione per la presenza della patch. Spesso gli sviluppatori non hanno visibilità diretta sul livello di patch delle infrastrutture sono in esecuzione su così ho voluto un mezzo di auto-valutazione. E 'stato troppo facile - tutto quello che dovevo fare era inviare 1.001 parametri di modulo e se il sito ha restituito un errore, la patch è stata installata. Se non avesse allora significava la richiesta è stata in fase di elaborazione e la patch non era presente. C'erano un paio di colpi di scena (come l'oggetto di richiesta la necessità di accedere in un app MVC per farlo funzionare), ma per la maggior parte, tutto è andato liscio.
Ora Microsoft ha fatto e rotto il mio scan - e non potrei essere più felice. Oggi ho eseguito tutti i miei test di integrazione ASafaWeb che controlla i risultati della scansione contro un certo numero di siti e di colpo la mia prova contro il sito ASafaWeb deliberatamente insicuro prova a notasafaweb.apphb.com stava fallendo. Mi riferisco alla prova di unità formale stava fallendo, perché prevede l'hash DoS scansione di passare (l'infrastruttura AppHarbor che gira su è stato patchato molto rapidamente), ma per qualche motivo l'hash DoS scansione è stata ora fallendo.
L'altra componente del test di integrazione che stava fallendo era che si attendeva la versione di ASP.NET del sito web per essere 4.0.30319.272 ancora stava tornando come 4.0.30319.17929. Questo è il numero di versione si torna in fondo una traccia dello stack e comprende l'ultimo segmento di cifre (la versione restituito nella X-aspnet-Version intestazione non). Coincidenza? Io credo di no, ed ecco perché:
Hashtable e Dictionary nel 4,5 utilizzare randomizzato algoritmo hash se si utilizza StringComparer.
Questa è una notizia molto buona perché quello che Levi sta dicendo è che l'implementazione sottostante hash è stato risolto quindi non c'è più bisogno di smettere di eccessivi posti i parametri del modulo nella loro tracce. Buon per l'ecosistema ASP.NET, non così buono per le prove ASafaWeb!
Che cosa questo significa è che ora rilevare il rischio di hash DoS è più difficile, molto più difficile. Ma non è impossibile e mi piacerebbe condividere il processo che ho appena implementato in ASafaWeb. Il motivo principale che voglio condividere questo è che mi piacerebbe che la gente fare dei buchi in essa e dimmi dove può essere migliorato.
Il fatto è che ora ci sono molte condizioni che devono essere valutati e anche in questo caso, ci sono molte circostanze che porteranno a risultati inconcludenti. Eppure, ecco cosa sta succedendo:
Albero decisionale per la rilevazione di hash protezione DoS
Qui ci sono alcune ipotesi fondamentali che non possono essere immediatamente chiaro:
  1. ASP.NET 4.5 è sicuro. Una volta che vediamo la versione 4.0.30319.17929 presentare sappiamo che la protezione hash DoS è integrato direttamente nel nucleo. Il problema è che si può solo rilevare questo se una traccia dello stack può essere causato o da un gestore Trace.axd accesso.
  2. ASP.NET 4 su IIS 8 è sicuro. Questo è semplicemente a causa del punto precedente;. NET 4,5 fornito con IIS 8. , Mentre altri 4 contro 4.5 non può essere rilevato dalla intestazione di risposta da solo, 4.x può essere come può la versione di IIS (a meno che non sono stati deliberatamente offuscato).
L'obiettivo è quello di cercare di minimizzare i risultati che rientrano nella categoria "inconcludenti", nessun rischio è grande, il rischio è grande anche confermato (almeno dal punto di vista di precisione), ma ci sono ancora molte situazioni che provocano un risultato inconcludente . Per esempio:
  1. Non conoscendo la versione di. NET il sito è in esecuzione e non essere in grado di causare un errore inviando vars forma troppi.
  2. Non ricevendo una risposta valida quando si postano le vars modulo ("metodo non consentito" risposta, timeout, risposta vuota, ecc)
  3. Il sito non è moduli web e la pubblicazione dei vars non causa un errore (potrebbe essere MVC e l'oggetto della richiesta è in uso)
Probabilmente ci sono altri che dovrebbero prendere in considerazione o potrebbe applicarsi per migliorare il sistema e mi piacerebbe sentire questo feedback. Se si conosce il modo per aggirare ASP.NET e può vedere i fori o miglioramenti in questo, per favore fatemi sapere. Per ora, l'approccio di cui sopra è stato implementato quindi sentitevi liberi di andare e provare a asafaweb.com .