UriMapper in Windows Phone

In un precedente post su Estensibilità ricerca in Windows Phone 7 , un UriMapper è stato utilizzato per tradurre l'URI lancio invocato da ricerca Bing in un MappedUri, in questo caso, una pagina all'interno dell'applicazione Windows Phone.In questo articolo andremo a vedere come utilizzare una UriMapper per aiutare a strutturare e navigare all'interno dell'applicazione Windows Phone. Come un ripasso, ecco il UriMapper abbiamo definito nel App.xaml, e come è stato collegato al PhoneApplicationFrame nel file App.xaml.cs. 

App.xaml
<Application.Resources>
    <uriMapper:UriMapper x:Key="UriMapper">
            <UriMapper: UriMapping Uri = "/ SearchExtras"
                            MappedUri = "/ MainPage.xaml" />
    </ UriMapper: UriMapper>
</ Application.Resources>

App.xaml.cs
RootFrame = new PhoneApplicationFrame () {
                                UriMapper = Risorse ["UriMapper"] come UriMapper
                            };

Stiamo per iniziare cambiando il UriMapping al seguente:

<uriMapper:UriMapping Uri="/{Page}" MappedUri="/{Page}Page.xaml" />

Questa mappatura sarà tradurre qualsiasi URI che inizia con "/" aggiungendo il suffisso "Page.xaml". Ciò presuppone che tutte le pagine all'interno della nostra applicazione si chiuderà con "Page.xaml", ma significa che invece di navigare a "/ SecondPage.xaml", si può invece navigare solo "/ secondo".

Questo diventa utile se in seguito si decide che tutte le nostre pagine saranno in una cartella denominata "Pagine". In precedenza, avrebbe dovuto cercare attraverso l'intera applicazione alla ricerca di qualsiasi Naviga metodi e modificare l'URI per includere il prefisso "/ Pagine". Utilizzando UriMapping, tutto quello che dovete fare è cambiare la mappatura di includere il prefisso.

<uriMapper:UriMapping Uri="/{Page}" MappedUri="/Pages/{Page}Page.xaml" />

Come applicazione di Windows Phone cresce, si può decidere di rompere la vostra applicazione fino in assembly separati. In questo caso, è possibile ancora utilizzare un UriMapping per individuare la pagina a cui l'utente sta navigando. Per esempio, la mappatura seguenti individuare il MySatellitePage.xaml, che è in un assembly denominato Satellite:

<UriMapper: UriMapping Uri = "/ MySatellite" 
                      MappedUri = "/ satellite; componente / Pages / MySatellitePage.xaml" />

Deep linking
Un altro luogo dove l'uso di un UriMapping è importante è quando si utilizza il deep linking al fine di indirizzare gli utenti a una posizione specifica all'interno dell'applicazione. Questo può essere da un Tile Live (come determinato dal URI specificato durante la creazione della piastrella), o da una notifica Toast (l'elemento Param determina l'URI all'interno dell'applicazione per essere navigato a quando l'utente seleziona il brindisi).

L'approccio più semplice è di utilizzare l'URI della pagina che si desidera avviare (per esempio, "/ MyLaunchPage.xaml").Tuttavia, questo introduce un forte accoppiamento tra la struttura delle applicazioni e le notifiche inviate dal server. Invece, si può aggiungere un UriMapping simile al seguente, che mappa un URI "/ Toast" attraverso la pagina di lancio:

<UriMapper: UriMapping Uri = "/ Toast" 
                      MappedUri = "/ MyLaunchPage.xaml" />

Ora, se abbiamo bisogno di cambiare la struttura dell'applicazione, possiamo farlo facilmente aggiornando la mappatura. Senza la UriMapping avremmo dovuto aggiornare sia l'applicazione Windows Phone e il codice del server, e garantire che sono entrambi aggiornati allo stesso tempo - un compito quasi impossibile.

Noterete che non abbiamo specificato alcun parametro query in qualsiasi mapping dichiarato. Questo perché ci vengono mappati automaticamente di fronte alla URI al MappedUri. Nel caso del UriMapping scorso, per esempio, un URI "/ Toast? CustomerId = 1234" avranno mappato "/ MyLaunchPage.xaml? CustomerId = 1234".

Ho dimostrato un certo numero di scenari in cui una UriMapper può essere utilizzato per migliorare la navigazione e la struttura della vostra applicazione Windows Phone. Imparare ad usare questo potente strumento, e sarete scrivere codice più efficiente prima di conoscerla.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla

Sessione ASP.NET con Google e hijacking ELMAH

Amo ELMAH - questo è uno quelle librerie che è sia bella nella sua semplicità, ma potente in quello che ti permette di fare. Combinano la potenza di ELMAH con la comodità di NuGet e si può essere installato e funzionante con l'errore assolutamente inestimabile registrazione e la gestione letteralmente in un paio di minuti.

Eppure, come dice il vecchio adagio, con un grande potere derivano grandi responsabilità e se non sei responsabile di come si implementano ELMAH, sei anche solo un paio di minuti di distanza dal fare il dirottamento di sessione della vostra applicazione ASP.NET - e molti altri exploit - molto, molto facile. Cosa c'è di più, le applicazioni vulnerabili sono solo una semplice ricerca su Google di distanza. Lasciatemi dimostrare.

Aggiornamento: Voglio mettere in chiaro proprio sulla parte anteriore che il fuori della configurazione casella ELMAH non fa nulla di quello che stai per leggere possibile. E 'solo quando ELMAH è configurato per esporre i log in remoto e non adeguatamente protetto che le cose vanno male.

La proposta di valore ELMAH

Alcuni retroscena primo; ELMAH è l'errore di registrazione Moduli e gestori scritto dal molto intelligente Atif Aziz ed è molto popolare. Quanto è popolare? E 'attualmente il pacchetto 14 più scaricato da NuGet :

Ciò significa che al momento della scrittura, ci sono stati 42.429 download della biblioteca.

Ho il sospetto che la popolarità ha molto a che fare con quanto sia semplice da implementare. Prima di tutto, è possibile aggiungere ELMAH per la vostra applicazione ASP.NET, senza ricompilare, è solo una questione di alcune voci web.config e compresa la biblioteca ELMAH.

In secondo luogo, è molto facile per registrare gli errori di una serie di diversi meccanismi di stoccaggio permanente tra cui il default in memoria negozio e per SQL Server (fra gli altri) per la longevità un po 'di più. Una volta che il web.config è impostato, succede solo automagicamente .

In terzo luogo, è molto semplice da configurare ELMAH a fuoco è spento una e-mail quando qualcosa va storto. Non c'è niente come essere in grado di contattare in realtà un utente con un "Ehi, vedo che avevi un problema" messaggio cinque minuti dopo che hanno avuto problemi. La gente ama questo genere di proattività!

In quarto luogo, è molto facile per recuperare le voci di registro, è sufficiente staccare, per il percorso / elmah.axd delle app che invoca un gestore bel po 'di tirare fuori i messaggi recenti di qualunque repository che stai usando.

E, infine, registra ELMAH sono cose molto, molto utile in loro per aiutare realmente risolvere il problema. Ma a quanto pare, hanno anche roba molto, molto utile in loro per aiutare i cattivi rompere l'applicazione che ci porta allo scopo del post di oggi.

Hacker-friendly info in ELMAH

Cominciamo approfondire i dettagli di ciò che ELMAH ci dà, o in questo caso oggi, quello che dà l'hacker. Ecco un esempio di ciò che esce da tale gestore elmah.axd:

In realtà, si può vedere questo per lei oltre a http://isnot.asafaweb.com/elmah.axd

Questo luogo particolare è quello che uso come banco di prova per ASafaWeb e le suevolutamente insicuro (più su quello a breve). Ciò che vedete nell'immagine sopra è una richiesta per il percorso "/ blah.aspx" che non esiste quindi è causando un HTTP 404 "NOT FOUND", che viene catturato da ELMAH. Fin qui, tutto bene.

Drill-down in tale errore, vedremo una traccia dello stack che comincia a rivelare l'implementazione interna del codice in cui è verificato l'errore. Tenete a mente questo è totalmente indipendente dalla configurazione personalizzata errori della app, è possibile attivare e specificare un valore predefinito reindirizzamento a una pagina di errore e ELMAH sarà ancora log di quello che vedete qui sotto - che è la bellezza di esso!

Ora scorri verso il basso un po 'e raggiungere l'interessante sezione - variabili del server:

Ho evidenziato due sezioni qui e voglio fare riferimento ad essi dal basso verso l'alto:

1. La variabile "AUTH_USER" è impostata su "admin". Questo è il nome dell'utente autenticato quando è verificato l'errore. In altre parole, sappiamo che era l'amministratore connesso in quel momento.
2. Il cookie ". ASPXAUTH". Nel caso in cui questo non sia già noto, uno sguardo attraverso il mio post su OWASP Top 10 per gli sviluppatori NET parte 9:. insufficiente protezione Transport Layer

Leggi il post? A destra, così ora avrete una buona idea di dove sta andando questo post -. ASPXAUTH il cookie viene utilizzato per mantenere lo stato di un utente autenticato quando il sito web utilizza il provider di appartenenze ASP.NET per l'autenticazione.

Identificazione di un obiettivo

Il punto cruciale di questo exploit centri intorno al fatto che molte persone non sono adeguatamente proteggere i registri ELMAH sul loro sito e che è facilmente rilevabile. In effetti è così facile da scoprire, è solo una questione di una semplice ricerca su Google perinurl: elmahtr.axd ASPXAUTH

Oh ragazzi, questo è un sacco di risultati - 11.000 pagine di registro non protetti ELMAH ! con informazioni cookie di autenticazione Sostituire la "ASPXAUTH" criteri di "Log di errore per" che appare nella parte superiore di ogni risorsa elmah.axd e il risultato è attualmente 192.000. Ouch! Certo, alcuni di questi sono risultati per il sito stesso e alcuni sono semplicemente pagine circa ELMAH ma in qualunque modo si taglia, ci sono un enormenumero di siti di mettere i loro privati ​​esposti al pubblico!

Questo è il vostro classico Googledork o in altre parole, una ricerca con cura artigianale che si trasforma fino risultati relativi alla configurazione negligente. Tenete presente anche che questo è ovviamente solo i risultati accessibili al pubblico, che Google ha indicizzato, quanti altri siti sono là fuori esponendo i loro registri ELMAH che semplicemente non sono state indicizzate? Dopo tutto, elmah.axd normalmente non è una risorsa pubblicizzati; Google deve sapere che è lì e richiedere esplicitamente la risorsa per l'indicizzazione.

Sfruttando il sito

Ora per la cosa interessante - sfruttando le informazioni di cui sopra di sfruttare effettivamente il sito. Lasciatemi dipingere uno scenario che mette la facilità e la praticità di questo nel contesto:

Indossando il cappello di hacker male, ho appena fatto la ricerca di Google e identificato sopra il sito che voglio sfruttare. Posso vedere dai log che il cookie ASPAUTH viene catturato quindi so che autenticazione basata su form è in uso o in altre parole, il sito ha qualcosa che si vuole proteggere. Da questa ricerca da solo c'è un buon cambiamento che ho potuto trovare un token valido ASPXAUTH da utilizzare nel mio esercizio dirottamento.

Ma cosa succede se il registro è solo utilizzando le impostazioni predefinite in memoria di storage ed è stato recentemente lavata? Oppure non ci sono errori di recente con un cookie ASPAUTH che è ancora valido? Nessun problema, solo un po 'di ingegneria sociale è necessario per contribuire a generare un nuovo messaggio di errore. Trovare informazioni di contatto per il proprietario del sito è di solito semplice, proviamo un messaggio come questo (sto assumendo @ asafaweb è il bersaglio):

L'inserimento del carattere "<" nell'URL causerà la convalida della richiesta al fuoco - tutto il resto del messaggio è solo destinato a costruire un senso di urgenza (il messaggio) e di legittimità (il dominio dell'URL). Ora, naturalmente, l'utente deve essere autenticato al fine di ottenere un nuovo cookie ASPAUTH, ma è probabile che sono o già registrati o si utilizza una lunga durata di timeout per salvarle la registrazione di nuovo in Anche se non sono, un messaggio allo stesso modo artigianale con un link ad una pagina di amministrazione potrebbe facilmente prendere cura di questo.

Ora è solo una questione di guardare l'attaccante ELMAH fino a una voce del registro nuovo appare. Il cookie auth sarà simile a questa:

.ASPXAUTH=3C886BA2344099338361C921C846EAF4E02F2A88E5E7EDE6838705928F7BB7C6FF469D35FEB1532C44B81DB38F200DEE08B6ED0E6121B945C659E932D8CE8B69FFF09E7B59DBE4820873DBD7891DD6B6BC4A486F35A2F99849017A6C72D9C6A44517D9AFDC731B3A3C55596E79732806F7DDDF9F

Con la nostra cappello degli hacker, andiamo ora prendere questo valore e creare un nuovo cookie con il nome e il valore dall'alto. Questo diventa molto semplice con una estensione del browser come modificare questo cookie :

Potete vedere il "Log In" testo dietro la finestra di cookie in modo questo browser non è sicuramente autenticato prima di aggiungere il cookie. Ma se l'hacker invia il cookie e aggiorna la pagina:

E ci avete - l'hacker è loggato come amministratore! Questo non dare loro l'amministratore la password , ma li fa tutti i diritti di utente admin . A seconda del sistema, questo può dare loro i diritti per visualizzare o creare altri account, gestire i permessi, visualizzare i dati finanziari, ecc ecc Usate la vostra immaginazione.

Ma aspettate - c'è di più

Un registro pubblicamente esposto ELMAH è abbastanza grave vulnerabilità di business saggio. Non c'è solo il rischio di dirottamento di sessione come spiegato qui, ad esempio, c'è il rischio di rivelare la struttura interna del database semplicemente cercando SqlException :

O come su un mucchio di istruzioni SQL - questo è proprio quello che si vuole ottenere un inizio grande testa su un attacco di iniezione:

E che dire semplicemente cercando "password" - non hai nemmeno bisogno di guardare oltre la finestra di ricerca su alcuni di questi:

Vuoi trovare siti che utilizzano una particolare libreria in cui una zero-day è stato appena scoperto? E questo è assolutamente, positivamente solo un esempio - sono solo la raccolta di una biblioteca popolare che non sarebbero normalmente individuabile semplicemente la consultazione del sito:

Ma naturalmente non è solo sulla ricerca di errori esistenti che potrebbero essere di interesse, una volta che un attaccante sa che un sito è di esporre i log ELMAH possono poi andare a cercare tutta una serie di altri attacchi e ottenere un feedback immediato su quello che sta succedendo internamente! Come conveniente è quello?!

Ma c'è anche tutta una serie di altri piccoli frammenti che possono venire in valore per i malvagi, URL di riferimento, percorso fisico del sito sul server, percorso fisico del sito sulla macchina dove è stato compilato (spesso macchina dello sviluppatore) , i nomi ei valori di tutti i cookies, l'indirizzo IP dei visitatori del sito e così via e così via. I registri ELMAH sono un vero e proprio tesoro di informazioni.

La protezione contro questo attacco

Questo è in realtà solo un semplice caso di controlli di accesso o in OWASP parlare, Errore di limitazione dell'accesso URL . Questo non è - e mi veramente sottolinearlo - non è una vulnerabilità di ELMAH .

Nel caso in cui i provider di appartenenze e di ruolo sono in uso, la correzione è nulla di più complesso di una semplice voce di autorizzazione in web.config:

< location path = " elmah.axd " >
  < system.web >
    < autorizzazione >
      < permettere ruolo = " Admin " />
      < negare utenti = " * " />
    </ autorizzazione >
  </ system.web >
</ location >

Ecco, niente di più. Quelle 192.000 siti dalla ricerca Googledork non hanno questo! Ognuno di questi siti è facilmente vulnerabile agli attacchi di cui sopra. Sono anche esponendo tracce dello stack interno e le variabili del server che possono portare ad attacchi di altre nature. Questa è una grave vulnerabilità di configurazione seria.

Oh, e nel caso in cui non è già evidente, protezione livello di trasporto non fa assolutamente nulla per mitigare questo rischio, significa solo un attaccante in grado di caricare i vostri dati di log sensibili tramite una connessione criptata:)

Un aiuto da ASafaWeb

In tutta onestà a quelli con i registri ELMAH pubblicamente di fronte, questo è davvero facile da sbagliare. La facilità di implementazione offre ELMAH lo rende potente e potenzialmente vulnerabili allo stesso tempo. Nel fatto che spesso la storia con NET in generale;. Caratteristiche come gli errori personalizzati e tracce dello stack può essere facilmente esposto interamente per caso.

Il mese scorso ho lanciato ASafaWeb con l'intento di fornire uno strumento gratuito per verificare facilmente per ASP.NET vulnerabilità di configurazione relativi. Oggi sono felice di aggiungere anche una scansione per l'accessibilità al pubblico di ELMAH.

Sono molto attenti a eventuali scansioni aggiungo a ASafaWeb. Di solito questo significa un'ulteriore richiesta HTTP (come è il caso della scansione ELMAH), e questi sono piccoli esercizi molto costoso in termini di durata si aggiunge a una scansione. Ma nel caso di ELMAH, la prevalenza della biblioteca combinata con l'enorme numero di siti insicuri e la facilità di implementazione rende un buon candidato da aggiungere.

Ecco come funziona: il sito ASafaWeb ti permette di collegare sia un URL (questo può essere un qualsiasi URL accessibili al pubblico) o in alternativa, eseguire una scansione contro il sito di esempio di cui ho parlato sopra e hanno evidenziato di seguito:

Quando la scansione funziona, ci sono una serie di richieste HTTP al fine di testare i vari aspetti della sicurezza del sito. ASafaWeb si mostra ciò che le specifiche richieste sono state poi lo stato di ogni singola scansione. A volte più di una richiesta HTTP viene utilizzato per una scansione o una singola richiesta può essere riutilizzato attraverso scansioni multiple:

Cliccando sul fallimento "ELMAH log" scan salta poi noi in fondo alla pagina per i dettagli della scansione incluso il percorso con la vulnerabilità e come risolvere il problema (essenzialmente le informazioni nel post precedente):

Si può collegare direttamente nel profondo la scansione del sito di prova , se volete vederlo in azione ora.

Riassunto

Nel caso in cui non ho fatto perfettamente chiaro le prime volte, questo non è un difetto in ELMAH, in realtà penso che sia uno strumento fantastico e lo uso molto in ASafaWeb:https://asafaweb.com/elmah.axd

Ops, non è possibile accedere a tale però, è possibile?! E questo è davvero il punto che sto facendo - ELMAH può essere implementato in modo sicuro e sopra tutto c'è alcun modo una raccomandazione non usarlo. Ma per favore, per favore, applicare un po 'di diligenza dovuta e bloccarlo in modo corretto.

Se si fanno scoprire i registri ELMAH erano pubblicamente visibili poi decidere di bloccare giù, c'è ancora il rischio reale che hanno già indicizzati e le versioni cache sono ancora disponibili, in effetti ho visto più volte quando si ricerca per questo post. Se siete in questo campo, si vuole prendere una buona occhiata a cosa c'è nel vostro (ora sicura) i registri ELMAH e considerare quali informazioni possono essere state esposte ed è ora ricercabili attraverso vari motori di ricerca (ricordate, non è solo Google) .

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla

Ha la patch hash DoS stato installato sul vostro sito? Controllare adesso con ASafaWeb!

Già nel settembre dello scorso anno abbiamo visto l'emergere della vulnerabilità imbottitura oracolo che improvvisamente ha un sacco di sviluppatori ASP.NET molto nervoso. La preoccupazione reale con questa vulnerabilità è che in realtà non era molto che si possa fare a livello di codice al di là di un paio di modifiche poco - quello che era realmente necessario era per le patch per avere installato sul server e veloce .

Il problema allora era che, beh, non si poteva sempre fidarti del tuo fornitore di hosting .Hosting provider prendere tutti i tipi di forme diverse; server aziendali gestite da gruppi IT, macchine dedicate con gli host dedicato, condiviso co-affittato macchine e ora sempre più spesso, le soluzioni cloud based. Ma una cosa è rimasta costante e che è stato che la patch di Microsoft ha subito rilasciato necessario per ottenere sulla macchina.

Allora ho parlato sul mio blog su come rilevare a distanza i patch. Ma quello che non parlavaera che avevo scritto un app per automatizzare questo controllo. Come molti con la responsabilità di una serie di siti, ero troppo occupati a fare le cose che sono patchati per ottenere quel piccolo pezzo di software in una forma adatta per la condivisione. Oggi le cose sono un po 'diversa ...

Benvenuti ASafaWeb (di nuovo)

Ho introdotto ASafaWeb al mondo solo poche settimane fa. L'obiettivo era creare una molto semplice, molto facile consumo e gratuito strumento che permetterebbe di eseguire la scansione alla ricerca di vulnerabilità di configurazione di ASP.NET e aiutare ad educare gli sviluppatori. Ciò che non ho detto fino ad ora è che ASafaWeb ha le sue origini ai tempi vulnerabilità oracolo imbottitura, i concetti che ho usato per automatizzare le scansioni allora sono stati riutilizzati e, mentre la base di codice è tutto nuovo, lo scopo rimane.

Che cosa questo significa per la situazione hash DoS è che è stato molto semplice per aggiungere una scansione per la vulnerabilità di ASafaWeb. Si prega di notare che questa non è una scansione che sfrutta la vulnerabilità , piuttosto è una scansione che verifica la presenza della patch di Microsoft. Più su quello a breve, cerchiamo di ricapitolare in fretta su ciò che questa situazione hash DoS è tutto per primo.

Di fondo: qual è l'hash DoS e perché dovrebbe interessarti?

Questo è in realtà un attacco semplice ed elegante piccolo con conseguenze potenzialmente gravi. Il modo migliore per capire veramente di cosa si sta per vedere il video qui sotto diAlessandro Klink e Julian Zeri dal Chaos Communication Congress di Berlino all'inizio di questa settimana:

Comprendere tutto questo? Bene! No? Ecco il tl; versione dr:

Una tabella hash è una struttura dati che associa chiavi a valori. E 'una struttura particolarmente efficiente di dati ed è d'uso comune attraverso molti linguaggi di programmazione. Questa struttura dati è utilizzato in ASP.NET per memorizzare i parametri ricevuti in una richiesta POST (quello che avevamo normalmente pensiamo come "dati del modulo"). Fin qui, tutto bene.

Il problema è però che quando due o più stringhe sono hash, c'è il potenziale per creare ciò che è indicato come un collisione hash che significa semplicemente i due ingressi discreti valori sia finire con lo stesso valore hash. Questo da solo non è un grosso problema e non ci sono meccanismi integrato nel framework come ASP.NET per gestire questo scenario quando si verifica.

Ma il vero problema è che se si creano collisioni abbastanza hash dai parametri di forma abbastanza allora la CPU va, bene, un po 'di noci. Come i dadi? Questi due scivoli dai ragazziriassumere quanto pochi sono i dati necessari da inviare al fine di mantenere un sacco di CPU troppo occupato a fare altro:

Ora, il problema è che una volta che le CPU sono troppo occupati a fare qualsiasi lavoro legittimo, è effettivamente un attacco denial of service o "DoS". In termini semplici, il vostro sito è farcito, ma semplicemente non risponde più.

Ma il vero problema è che sfruttando questa vulnerabilità è morto semplice , tutto quello che dovete fare è inviare i dati del modulo diritto di un sito vulnerabile. C'è già un esempio molto semplice di come sfruttare questa contro PHP qui . In questo esempio, ci sono 65.536 valori forma (beh in realtà, sono solo nomi senza alcun valore), quindi non stiamo parlando di piccoli numeri qui. Questo è ciò che stiamo cercando:

• EzEzEzEzEzEzEzEz =
• & EzEzEzEzEzEzEzFY =
• & EzEzEzEzEzEzEzG8 =
• & EzEzEzEzEzEzEzH% 17 =
• ...

Sarebbe un gioco da ragazzi per costruire una richiesta HTTP in questo modo quindi è una vulnerabilità molto facilmente sfruttato davvero.

Patch di Microsoft

Alessandro e Giuliano effettivamente rivelato la vulnerabilità a Microsoft il 29 novembre, ben prima della loro presentazione. Fortunatamente c'è stato abbastanza tempo per una patch per essere preparato ed è ora disponibile come parte del Microsoft Security Bulletin MS11-100 , insieme a un paio di altri pezzi.

Nel video qui sopra, è suggerito che le tecniche di mitigazione potrebbe includere modifiche al comportamento di hashing, l'applicazione di un limite ai cicli della CPU richiesta potrebbe consumare e limitando il numero di parametri che possono essere inviati ad una pagina. E 'quest'ultimo che Microsoft ha implementato nel loro patch.

Testing della patch

Ciò che Microsoft ha fatto è impostare il limite di variabili forma in una richiesta POST a 1.000. Non più di questo e si sta andando ad un errore che sembra proprio così:

Beh in realtà, si dovrebbe avere errori personalizzati configurato correttamente in modo che i visitatori non vedere un errore come questo. Lo schermo di cui sopra è dal sito di prova volutamente insicuro per ASafaWeb a isnot.asafaweb.com e ho appena postato 1.001 variabili forma ad esso. Questo sito gira su AppHarbor che in maniera molto efficienteapplicata questa patch entro poche ore è stato rilasciato.

Il modo in cui il test per la patch funziona è che i messaggi ASafaWeb semplicemente una richiesta con 1.001 nomi in sequenza incrementando forma variabile in questo modo:

• 0 =
• & 1 =
• & 2 =
• & 3 =
• ... Tutta la strada fino a "& 1000 ="

Questo non è destinato a provocare una collisione hash! Questo è molto importante come il gol con ASafaWeb è sempre stato quello di bel gioco con i siti la scansione. Questa richiesta è semplicemente destinato a vedere se il sito processi felicemente la richiesta o se si genera un errore. Come messaggi di errore possono prendere tutte le forme e le forme e può essere restituito entro un successo codice di stato HTTP (a 200), ASafaWeb sta cercando di vedere che la risposta di questa richiesta è diversa da quella risposta da una semplice richiesta GET alla stessa pagina.

Prima che le risposte vengono confrontati, un po 'di pulizia va avanti per eliminare le differenze biologiche avrai da legittime richieste successive alla stessa pagina (ad esempio pubblicità diversa, Stati Vista, ID di forma, ecc) Questo è lo stesso processo utilizzato di test per la convalida delle richieste di applicazioni web forme e ha dimostrato di essere abbastanza affidabile, anche se non infallibile.

Riassunto

Ho cercato di girare intorno a questa scansione piuttosto in fretta perché so le persone sono ansiose e vogliono testare i loro siti. Ho assorbito il più possibile da Alessandro e Giuliano, Microsoft e il flusso infinito di tweet comunità e credo che le informazioni di cui sopra - e il test ASafaWeb scan - è accurato. Ho anche provato un sacco di siti che conosco o fare o non hanno installato la patch ed i risultati della scansione sono stati coerenti con lo stato delle patch note. Ma, come sempre, se sbaglio in un punto qualsiasi, per favore fatemelo sapere, così posso fare le cose sul binario giusto.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla

5 lezioni di sicurezza web per gentile concessione di Stratfor

Proprio quando si comincia a pensare che abbiamo visto fuori l'ultima delle violazioni importanti della sicurezza per il 2011, giorno di Natale ci porta un whopper finale per l'anno:Stratfor . Molto è già stato detto sul motivo per cui potrebbe essere stato violato e che potrebbero (o non potrebbe ) l'hanno fatto, ma resta il fatto che ora ci sono decine di migliaia di password dei clienti ei dettagli della carta di credito galleggiante in tutto il web.Ah, ea quanto pare circa 5 milioni di email interne pronto per essere rilasciato.

Allora cosa facciamo prendere da questo sito come costruttori? Il senno di poi ci dà una buona occasione di riflessione mentre guardiamo le ricadute svolgersi dalla violazione ultima grande dell'anno. Vorrei condividere le 5 lezioni sto prendendo alla larga da questo.

1. Ci non ha bisogno di essere un motivo per voi di essere hackerato

Il movimento hactivism intero, come eticamente discutibile che sia, almeno ha qualcheragione per essere razionale. Visa è stato attaccato dopo che sospendere i pagamenti a WikiLeaks. HB Gary è stato abbattuto dopo sostenendo che avevano infiltrato anonimo e avrebbe rivelato le identità dei membri '. A torto oa ragione, questi incidenti hanno motivazioni al di là di furtarelli puro.

Ma Stratfor? Nessun motivo sembra essere presente e, mentre essi forniscono servizi relativi alla sicurezza, non sembrano essere coinvolti in una qualsiasi delle tante attività che normalmente attirano le ire della comunità hacktiviste. A differenza di molte violazioni precedenti, non c'è stato alcun "Siamo perché si è riusciti a [inserire qui i motivi]" informativa.

Indietro nel mese di settembre ho scritto su ASafaWeb Gootkit attaccare , un progetto su cui stavo lavorando, che era agli albori in quel momento. Il punto è semplicemente che solo di essere sul web è motivo sufficiente per essere attaccato indiscriminatamente . Bot automatici non me ne frega niente che cosa il vostro sito, avranno un andare verso di voi e se qualche debolezza sono trovati, è possibile essere che ci sia un essere umano all'altro capo pronto a passo le cose su una tacca. Questo è tutto il motivo per cui hanno bisogno.

2. L'abuso finanziarie dei vostri clienti si estenderà lungo e lontano

Dopo la breccia, gli attaccanti inizia con le carte di credito dei clienti 'a fare donazioni . C'è un elemento di Robin Hood su questo - assumendo che comodamente trascurare il fatto che molti titolari di carta semplicemente segnalare la transazione come fraudolente e hanno invertito la carica - ma il bit veramente interessante doveva ancora venire. Messaggi come questo ha iniziato popping up molto rapidamente dopo i dati della carta sono state pubblicate on-line:

E simili su Twitter :

Questa conto su di autori? Chissà, avrebbe potuto essere chiunque, tutte le carte di credito sono ora disponibili per il mondo a vedere proprio qui . L'entità degli abusi è limitata soltanto alla diligenza del titolare della carta (la velocità con cui si annulla) e l'istituzione finanziaria (la loro capacità di identificare le attività fraudolente). tl, dr - questo sta facendo un sacco di clienti molto, molto infelice come l'abuso finanziario si estende ben oltre la semplice gli hacker .

3. Altri servizi online ai vostri clienti 'sarà compromessa

All'inizio di quest'anno ho scritto perché la progettazione della sicurezza la vostra applicazione potrebbe influenzare le vendite di bacche di Acai . In questo post ho parlato l'alta prevalenza di riutilizzo delle password, come evidenziato dalla violazione Gawker e perché il compromesso di un sito comporta di conseguenza, il compromesso dei conti su molti altri.

Poi intorno alla metà dell 'anno ho fatto una breve analisi la password Sony e ha trovato un evento incredibilmente alto di riutilizzo delle password attraverso indirizzi di posta elettronica comune a entrambi Sony e Gawker:

Quindi è una sorpresa che uno sguardo molto veloce al conti Stratfor riferimenti incrociati con precedenza violato fonti credenziali sta mostrando riutilizzo delle password ancora di più?Qui ci sono solo una manciata di esempi in cui le violazioni precedenti avevo in archivio abbinato con i conti da Stratfor:

Che cosa significa è semplicemente questa: perché Stratfor non protegge adeguatamente le credenziali dei loro clienti 'e perché molti di tali credenziali riutilizzo dei clienti, è estremamente probabile che gli altri servizi connessi non sarà superato di conseguenza . E 'anche molto probabile che la colpa di ciò sarà diretto a Stratfor.

4. Gli hash delle password senza sale sono una sottile patina di sicurezza

Ora sappiamo che le password erano memorizzate come cliente diretto hash MD5, non c'era l'uso di sali. Secondo il comunicato Pastebin , il 54% dei conti erano facilmente violata utilizzando un attacco di dizionario con la lista delle password UNIQPAS . Una volta che hai 30 milioni le password del mondo reale, hash e confrontando questi a un database violato diventa un evento abbastanza semplice.

Tornato in parte 7 della mia serie sulla OWASP Top 10 per sviluppatori. NET dimemorizzazione di dati crittografici insicuro , mi ha mostrato quanto facilmente gli hash delle password da sola caduta di un attacco di forza bruta e ora stiamo vedendo questo (di nuovo) allo stato selvatico. Intendiamoci, ho anche mostrato come sia facile creare un sale crittograficamente casuale e per questo qualsiasi sito web a tutti oggi non farebbe questo, e tanto meno uno la natura della Stratfor, è oltre me.

Così la linea di fondo è questo: se le password semplicemente hash, si potrebbe semplicemente non di fastidio a tutti , e questo è a prescindere dalla algoritmo di hash utilizzato. L'unica cosa di risparmiare da un attacco di forza bruta è semplice se gli utenti di creare forti password uniche - che come ho mostrato nell'analisi di Sony, che quasi mai!

5. La biancheria sporca software andrà in onda pubblicamente

In un momento o un altro, tutti finiscono con alcuni scheletri nell'armadio software. Se dalle nostre volontà o pressioni da parte degli altri, prendiamo alcune scorciatoie e fare qualche compromesso. A volte ci chiameremo "debito tecnica", altre volte ci guarderemo indietro e chiedersi perché non sapevamo meglio in quel momento.

Una volta che sei stato veramente bene e di proprietà in Stratfor / Sony / Gawker stile, che la biancheria sporca sta per diventare molto, molto pubblico. Stratfor ha fatto un certo numero di cose fondamentalmente stupidi nella loro progettazione di siti web e le pratiche sono ora in mostra per il mondo a vedere. Utilizzando MD5 come algoritmo di hashing, di cattivo gusto. Nessun sali utilizzati; temerario. Memorizzazione di carte di credito in chiaro; addirittura negligente.

Quindi è necessario porsi questa domanda: se un sito web che è stato coinvolto in edificio è stato spogliato e messo a parte esposti al pubblico, sarei in grado di stare con orgoglio dal mio codice? Oppure sarei battere in ritirata precipitosa e rapidamente la rimozione Stratfor (o equivalente) dal mio CV?

Riassunto

Questo non era destinato ad essere un Stratfor-bashing post, piuttosto è un'opportunità per vedere il destino che attende coloro che non prendono sul serio la sicurezza web. Chiamatelo un controllo di realtà veloce, se vuoi.

Quindi, con questo fresco nella mente, come pure i vostri siti aderire alla sicurezza rischi identificati in pubblicazioni come la OWASP Top 10 ? Sei memorizzare i dati dei clienti sensibili in chiaro? Sei semplicemente l'hashing delle password, senza sale, a prescindere l'algoritmo usato? O solo leggermente peggio, si archiviano le password in chiaro?

Se puoi rispondere "sì" a tutto questo allora è il momento migliore per avere un serio pensare di investire un po 'di tempo ottenere il vostro ordine in casa. Sollevare con il tuo capo, chat per il tuo CIO / CSO, parlare a chi ci ascolta, perché se siete nella stessa barca, come Stratfor e si ottiene di proprietà, c'è una reale possibilità è buono il tuo mondo cambierà in ogni sorta di sgradevole modi letteralmente dall'oggi al domani.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla