Come costruire (e come non costruire) una funzione sicura "ricordati di me"

Ecco lo scenario - un utente accede al tuo sito web, torna domani e ... deve eseguire nuovamente il login.L'idea del "ricordati di me" - e diciamocelo, tutti abbiamo visto questo prima - è che il loro stato autenticato viene mantenuto al di là del campo di applicazione immediata di utilizzo. Che cosa questo significa è che si può chiudere il browser, spegnere il PC poi tornare domani o la prossima settimana o il mese prossimo o comunque molto più tardi si determina è un lasso di tempo ragionevole e il sito lo sa ancora chi sono e li offre tutte le stesse caratteristiche che avevano quando hanno lasciato.

Sto parlando di questo ragazzo poco qui:

Sembra facile, vero? Può essere, ma come vedrete non è inoltre raro fare un pasticcio assoluto di esso e anche quando non lo fanno bene, c'è una fila di persone pronte a dirvi come si è, infatti, non abbastanza giusto . Cominciamo con il proprio roba sbagliata e lavorare da lì.

Anti-modelli

Questo sembra ovvio, no? Voglio dire l'attuazione di una funzione di "ricordati di me" è abbastanza fondamentale, non è il genere di cose facilmente ottenuto sbagliato, no? Pare di no.

Vorrei condividere due anti-pattern e vedremo i problemi con loro prima di parlare di come farlo nel modo giusto. Il primo esempio viene fornito per gentile concessione di Black & Decker, che sarebbe la stessa B & D di recente ho scritto in sicurezza è difficile, l'insicurezza è facile . Ecco l'idea quando si effettua il login:

Questo è tutto abbastanza standard, il bit interessante viene dopo l'accesso Diamo uno sguardo ai biscotti:

Questo è abbastanza impressionante serie di biscotti, ma è quelli evidenziati che sono veramente interessanti. Questi cookies non otterranno impostare se non si seleziona la casella "Ricordami" così la loro funzione è puramente password potrebbero tornare in seguito. Il mio indirizzo e-mail è abbastanza chiaramente in là, ma che non è la mia parola d'ordine, invece sembra essere una sorta di fortezza impenetrabile di crittografia ... appendere - che è la codifica Base64! La cosa di codifica Base64 è che è perfettamente completato da Base64 di codifica che significa che si può staccare, per un posto comebase64decode.org e fare questo:

Ora, non tutti usano Base64 come mezzo di "crittografia" (sì, alcune persone veramente fare questo ), e in effetti si tratta di un modo perfettamente legittimo di rappresentare i dati in un formato ASCII, la vera storia qui però è che questa è la mia password seduto lì nel mio browser in testo normale. Vi chiederete - perché questo è un problema? E 'nel proprio browser, giusto? In che modo un utente malintenzionato ottiene?

Ho intenzione di parlare di due modi molto semplici e il primo si riferisce al collegamento in precedenza circa l'insicurezza essere facile. Black & Decker erano esposti i registri ELMAH e in quei registri di stato ogni eccezione non gestita server interno, da qualche parte a nord di 50.000 di loro al momento ho riferito a loro. Quando ELMAH registra un'eccezione si registra anche tutte le intestazioni di richiesta che significa che i cookie sono registrati. Che si combinano con l'enorme numero di eccezioni non gestite essere generate dal sistema e ora avete un tesoro di credenziali utente. Sì, dovrebbero avere assicurato il loro log ELMAH correttamente per cominciare, ma si tratta di un buon esempio di come si può essere facilmente annullata da una semplice configurazione errata.

Ecco un altro:

Questo è Aussie Agricoltori diretto ed è una abbastanza tipico log vedendo in forma. Facciamo il login, dirgli di "ricordati di me", poi dare un'occhiata ai biscotti:

Oddio, di nuovo stesso problema, ma senza alcuna codifica Base64. In realtà questo è particolarmente grave perché si può fare cose come questa:

XSS tuo biscotto JSON? Certo! L'altra peculiarità è che cambiando la password non cambia il cookie in modo da tornare al sito in seguito e si tenta di accedere in voi con quello vecchio. Oops.

Aussie Gli agricoltori diretti non hanno esposto i registri ELMAH (essendo sorta di PHP aiuta in questo!) Ma hanno altri rischi, quali XSS (per inciso, questo è stato divulgato in modo responsabile e il rischio sommariamente respinto - più volte). L'altra cosa su entrambi i siti di cui sopra è che quei biscotti che tengono le password non vengono contrassegnati come HttpOnly, si può vedere questo nella seconda colonna da destra nelle liste dei cookie. Che cosa questo significa è che lo script client può accedere a quei biscotti che significa che se si può ottenere un pezzo di XSS sul sito - così come è possibile sul sito Agricoltori australiano - è possibile rubare i cookie contenenti le password se è possibile ottenere un cliente di caricare il carico utile XSS (e ci sono molti modi per farlo). L'attributo HttpOnly manca è sciatto per conto di entrambi i siti, ma il nocciolo della questione è la memorizzazione delle password nei cookies che poi li rende vulnerabili tramite altre sviste.

C'è una ragione di più di fondamentale importanza perché entrambe queste pratiche sono negligenti, che stanno proteggendo le credenziali dei clienti utilizzati su altri siti. Ogni volta che un cliente che utilizza la funzione "ricordati di me" su uno dei siti di cui sopra fa una richiesta, c'è una buona possibilità che stanno inviando il nome utente e la password per la posta elettronica, il loro eBay o la propria banca attraverso il filo, a volte in pianura testo, a volte accessibile tramite script client, sempre seduto lì non protetto nel browser. password riutilizzo è dilagante e mentre quei dannati gli utenti dovrebbero prendere qualche sanguinosa responsabilità (sto parafrasando qui!), noi - come sviluppatori - dobbiamoriconoscere che siamo protezione molto più di nostro sito quando gestiamo credenziali.

Così che dovrebbe stabilire se vi sia un vero e proprio fraintendimento di come la funzione "ricordati di me" dovrebbe essere costruito, andiamo ora passare sulle buone pratiche.

Una implementazione di riferimento del campione

Uno dei mantra si sente spesso nel mondo della sicurezza è "non rotolare il proprio - utilizzare ciò che è già stato dimostrato di essere robusto". Questo è molto spesso applicato alla crittografia e schemi di autenticazione, ma in questo caso si può estendere questo per la caratteristica "ricordati di me", al fine di iniziare con una buona implementazione di riferimento prima di approfondire i dettagli.

In un nuovo sito Web ASP.NET MVC 4 provisioning con Visual Studio 2012 si ottiene questo diritto fuori dalla scatola:

Altri quadri hanno altri modi standard di implementazione di questa funzione, ma questo è un compito facile per me fare riferimento. Quando abbiamo Login con i campi come sopra (cioè non chiedendole di ricordarsi di me), risultati di autenticazione riusciti nel seguente biscotto da restituire:

path = /; HttpOnly

Questo è semplicemente un cookie di autenticazione e nel mondo senza stato che è HTTP è l'unico piccolo pezzo di dati che lega tutte le richieste altrimenti del tutto indipendenti da una persona insieme.Ogni volta che questo unico-a-me cookie viene inviato, il sito web sa che sono io e che ho già autenticato. Lo possiamo vedere po 'più chiaramente quando lo guardiamo nella raccolta Cookies di Chrome:

Per inciso, il secondo cookie è un token antifalsificazione per prevenire attacchi CSRF e non ha nulla a che vedere con il nostro stato autenticato. Oltre a questo, non ci sono altri biscotti.

Vediamo ora il login e chiedere al sito di ricordare me, ecco la risposta di biscotto:

expires = Tue, 02-Jul-2013 00:27:05 GMT; path = /; HttpOnly

Aha - si vede che?! Si diventa più chiaro quando lo vedi suddiviso in Chrome:

Ora abbiamo una scadenza del cookie, che è di 48 ore da oggi al contrario di non avere scadenza del cookie che significa che verrà scartata quando il browser viene chiuso. Diamo uno sguardo più da vicino a questo.

Guardando auth cookie di scadenza

Questo è in realtà un ridicolmente facile costruire la sicurezza ed è solo alla luce degli esempi precedenti che mi piacerebbe anche pensare che vale la pena scrivere, ma qui siamo. In questa implementazione, il "Remember Me" si riduce semplicemente a quando il cookie di autenticazione scade, perché quello che stai facendo veramente qui è il controllo per quanto tempo si desidera che qualcuno a rimanere connesso per, è così semplice.

Nel precedente esempio, il default ASP.NET di utilizzare un cookie di sessione o in altre parole, un cookie che non ha una data di scadenza esplicita e sarà quindi forzatamente scade quando il browser viene chiuso. Questo è un approccio, un altro è impostare esplicitamente un breve periodo di scadenza in modo che, anche se il browser viene lasciata aperta l'utente verrà automaticamente disconnesso dopo un periodo di tempo. Naturalmente è anche possibile controllare questo comportamento sul server e si può anche tenere estendere la durata di un cookie di autenticazione se il sistema viene utilizzato attivamente dal server aumentando la data di scadenza sulla risposta.

Ricordando qualcuno può essere semplice come mantenere vivo il cookie auth. Quanto tempo dovrebbe essere mantenuto in vita per? L'esempio sopra il default è due giorni che è probabilmente un po 'corto per molti usi legittimi della funzione (anche se è facilmente configurabile in ASP.NET), prova a Facebook e anche se avrai i cookie che durano per un anno. Durata inferiore significa meno rischi ma più inconveniente, durata maggiore rende più facile per l'utente, ma aumenta la finestra di potenziale attacco. Diamo un'occhiata a questo rischio in modo più dettagliato.

Sfruttando stato di autenticazione di lunga durata

Mentre non si dispone dell'autenticazione, la sessione non può essere dirottato. Lo so, roba perspicace!Ma sul serio, prendere un caso come Aussie Agricoltori diretto di cui sopra; che cookie scadrà tra sei mesi e combinato con il fatto che non è contrassegnato come HTTP solo e che non hanno difetti XSS nel sito c'è ora una mezza finestra anno in cui solo a seguito di una link potrebbe causare me a consegnare inavvertitamente le mie credenziali per un attaccante. Se questo periodo è stato, diciamo, un mese sì, avrei ancora alcuni gravi difetti nel loro design, ma poi la finestra di opportunità per un attaccante è stato appena tagliato.

D'altra parte, Black & Decker ha un breve periodo di scadenza di una settimana rispetto così nel loro caso con i registri ELMAH a vista, sì, ci fu una serie di brutti errori da parte loro, ma a meno che qualcuno si era connesso con il "ricordati di me" casella evidenziata nella scorsa settimana e ha causato un'eccezione non gestita, le credenziali non sarebbero stati messi in mostra pubblica. Ok, se siete sul sito per cominciare c'è una buona possibilità che stai già effettuato l'accesso (almeno rispetto al caso di agricoltori in cui non si dovrebbe andare consapevolmente nessuna parte nei pressi del sito di perdere la tua password), ma si può vedere come tale profilo di rischio cambia con il periodo di scadenza dei cookie.

Naturalmente alla base di tutto questo è che il cookie auth deve essere attentamente tutelato; attributi HttpOnly e sicuro sono un must assoluto. Tutte le minacce classiche dirottamento restano pertinenti, ma poi di nuovo, ma si sezionare i questa funzione si sta andando a finire con una dipendenza biscotto quindi si sta andando ad avere bisogno di guardare molto, molto attentamente quei biscotti.

In definitiva si tratta di un compromesso che ha bisogno di prendere in considerazione fattori come il valore di un attaccante di dati dell'utente sul sito, la barriera che non viene autenticato pone a un utente di ritorno e il profilo di sicurezza del resto del sito. Per esempio, Facebook ha alcuni dati molto utili di carattere sociale e gli utenti si aspettano un basso attrito (anche senza processo-attrito) al ritorno, più che hanno fatto enormi investimenti nel loro profilo di sicurezza. Aussie Farmer'S, d'altra parte, contiene i dati di identificazione personale degli utenti più informazioni finanziarie al tempo stesso un servizio che le persone si aspettano per l'autenticazione (servizi di pagamento) hanno ancora una scarsa conoscenza di importanti concetti di sicurezza. Sono profili di rischio molto differenti e che dovrebbero essere molto diverse strategie di scadenza del cookie auth.

Rafforzare l'approccio

Ci saranno persone che guardano l'approccio cookie di autenticazione e roteare gli occhi in preda alla disperazione. La cosa di sicurezza è che c'è sempre un modo migliore a seconda del tempo / denaro / complessità che sei disposto ad aggiungere e c'è anche sempre qualcuno pronto a dirti che hai sbagliato!Utilizzando il cookie auth scadenza come punto di partenza, diamo un'occhiata ad alcuni possibili modi di rafforzare l'approccio.

Un argomento contro la lunga scadenza del cookie auth è che stanno efficacemente mantenendo l'utente autenticato e al rischio di attacchi come CSRF o clickjacking. Ovviamente l'applicazione deve esporre altri rischi in ordine per un utente malintenzionato di sfruttare la lunga durata dei cookie, ma l'intera difesa in profondità l'argomento viene in su di nuovo. Un'alternativa è quella di avere un biscotto dedicato calettata contro l'utente che dopo convalida l'autenticità di esso con il server, possono poi avviare una nuova sessione autenticata il loro ritorno. La sessione originale può quindi scadere rapidamente, il trucco è quello di ripristinare una nuova quando l'utente torna con il "ricordati di me" cookie dedicata e comprende alcuni convalida supplementare nel processo.

Un modo per fornire un'ulteriore convalida è includendo l'indirizzo IP dell'utente / user agent / altro segno distintivo del "ricordati di me" cookie. La logica è che questo offre una certa difesa contro dirottamento del cookie. Il problema, naturalmente, è che ci sono casi in cui tali cambiamenti uso legittimo. Nel mondo mobile, in particolare, non è raro per tornare a un sito con un IP diverso. Anche nel mondo delle connessioni fisiche non si può necessariamente fare affidamento su l'ISP fornisce un indirizzo IP statico. Per quanto riguarda gli interpreti, con browser come Chrome e Firefox l'aggiornamento a quello che sembra come ogni altro giorno, a meno che non sei un po 'selettivi su ciò che gli attributi della stringa user agent che stai memorizzare e confrontare che sta per essere un approccio rischioso. Le stesse difese intorno utilizzando attributi utente e uniche per aggiungere sicurezza sono spesso discussi nel contesto di sessione e cookie auth e mentre sono sicuro che ci sono casi di utilizzo validi per questo (torna al settore bancario di nuovo), non posso dire di ' ve effettivamente visto nel luogo in uno qualsiasi dei siti che ho provato prima. C'è probabilmente una buona ragione per questo ...

A mitigazione più pragmatico è quello di separare ancora il cookie auth da un "ricordati di me" cookie dedicato e utilizzare quest'ultimo per ri-autenticare l'utente , ma imporre alcune restrizioni . La realtà è che il processo di persistenza dello stato automaticamente autenticato di qualcuno - attraverso qualsiasi mezzo - introduce compromessi al modello di sicurezza. A mitigazione potrebbe essere quella di richiedere un utente automaticamente ri-autenticato per fornire espressamente le proprie credenziali di nuovo prima di visualizzare alcune categorie di dati o l'esecuzione di determinate attività. Questo non è inaudito anche al di fuori del campo di applicazione del "ricordati di me", si potrebbe vedere che durante l'esecuzione di attività di alto valore, come il bonifico bancario. In questo caso, stiamo dicendo che l'utente autenticato è più a rischio perché c'è più probabilità che non sono chi dicono di essere (cioè qualcun altro si è seduto al PC ed efficace highjacked una sessione).

L'altra tempra possiamo applicare a questo approccio è di assicurare che il cookie utilizzato per ricordare all'utente viene resettato dopo che è stata utilizzata. Questo significa anche invalidarla sul lato server in modo ci deve essere sia l'unicità e la persistenza del valore del cookie, ad esempio un nonce persisteva sia nel database e il cookie. Questo ha il vantaggio di garantire che, se il cookie viene ottenuto da un utente malintenzionato ha ha solo un unico ambito l'uso - e questo è se l'utente non può utilizzare legittimamente prima di loro. C'è un po 'di buona articolo qui che parla di alcune mitigazioni a questo modello e di nuovo, ci sono casi d'uso in cui questo può essere utile, ma che si sta per investire ulteriore sforzo costruirlo e ci sono casi in cui sarà utenti legittimi disagi (cioè cercando di ricordare te sullo stesso sito su più PC).

L'ultima cosa degna di nota è che gli stessi principi di gestione degli account che devono essere considerati per le sessioni autenticate attivi sono rilevanti nel "ricordati di me" contesto. Ad esempio, sono più sessioni autenticate contemporaneamente consentite da quello utente? Se l'utente cambia la password ti è scollegare le altre sessioni? Può un amministratore di terminare la sessione autenticata? Ci sono tutti i tipi di problemi che vengono in su che sono in realtà parte della discussione su come sessioni autenticate sono verificati e gestiti, la discussione qui è solo su come ripristinare quello.

Quando non si deve permettere "ricordati di me"? (E alcune alternative intermedia)

A volte semplicemente non ha senso per consentire a un utente autenticato di rimanere autenticato per lunghi periodi di tempo. Bancario, ad esempio, è il caso d'uso stereotipato per quando si desidera forzare una nuova autenticazione al più presto possibile in quanto i rischi sono troppo significativi per lasciare le sessioni del browser non utilizzati autenticate in giro il posto.

Ma vi è in realtà un po 'di terra di mezzo che può essere presa qui:

Questo non è del tutto quello che sembra - quando si torna dopo una sessione scaduta, dove lei ha chiesto al sito di "Remember Me", otterrete questo:

Ho non offuscato il nome utente, il nome utente come appare sopra le stelle sono memorizzati in un cookie che dura per tre mesi insieme ad alcuni altri dati che identificano inevitabilmente l'utente.Francamente, non vedo un sacco di valore in questo, ricordando il nome utente di solito non è il problema!

Ma, inoltre, non deve essere tutto o niente, non c'è via di mezzo. Ad esempio, il punto che ho fatto in precedenza su ri-autenticare prima di processi chiave vengono eseguite se la sessione fosse stata ripresa da una funzione di "ricordati di me". E 'un po' il meglio dei due mondi.

In conclusione ...

Questa è una di quelle caratteristiche che sembra una buona idea, al momento (e talvolta lo è) e di solito è molto facile da ottenere, almeno sufficientemente giusto per ogni uso. Francamente, è ancora un po 'sconcertante come sbagliato i due esempi precedenti si sono particolarmente se si considera che sarebbe stato sufficiente per estendere semplicemente la durata del cookie che già hanno!

L'altro punto di togliere da questo post di là solo la meccanica della funzione "ricordati di me": così la sicurezza è un multi-tiered, bestia come interdipendenti. Potreste essere in grado di cavarsela con le credenziali in cookie di per sé, ma che si combinano con la situazione ELMAH o mancanti solo HTTP attributi e difetti XSS e improvvisamente un sciocche seppur pratica relativamente innocuo diventa un rischio serio. Di che si trattava "difesa in profondità" di nuovo?!

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java

Video: "Hack Yourself First" e altri suggerimenti di sicurezza per gli sviluppatori web

Un po 'di tempo fa ho scritto su Hacking se stessi prima e dettagliato un sacco di modi diversi per gli sviluppatori a cercare i rischi nelle loro applicazioni, si spera prima attaccanti li trovano prima. Sono molto entusiasta di questo approccio e credo che gli sviluppatori hanno bisogno di affinare le capacità di cyber-reato al fine di comprendere correttamente - e proteggere le loro applicazioni da - rischi sul web. C'è un mucchio di più contenuti provenienti da me in questo senso in una varietà di formati e oggi è un video di libera discussione su SSW TV .

Questi ragazzi fanno un po 'di ottimi video su vari argomenti di sviluppo che si trovano sul loro sito web gratis, tra cui anche il mio gruppo di utenti discorso sulla Protezione delle applicazioni web dalla tirannia del male con OWASP registrato lo scorso anno (di fatto a piedi attraverso la OWASP Top 10 per ASP.NET). Il video di oggi è una chat con SSW di Damian Brady e tocchiamo un mucchio di diverse problematiche legate al web, ASP.NET e la sicurezza in generale. Si tratta di un casual, discussione senza copione che contiene spera alcune informazioni utili per lo sviluppatore attento alla sicurezza.

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java

L'inutilità di sicurezza che è l'incorporazione di forme d'accesso sicure all'interno di pagine non sicure

Ho scritto un mucchio di contenuti intorno HTTPS ultimamente e la registrazione di video per dimostrare la facilità con cui le implementazioni insicure di SSL può essere rotto. Ad esempio, vi è stato il pezzo su cui non si può fidare loghi SSL , allora come caricando moduli di login su HTTP, ma annuncio a HTTPS è inutile e, più recentemente, perché quei avvertimenti contenuto misto significa guadagni facili per gli attaccanti sul layer di trasporto . Tutti questi implicano dimostrazioni di lavoro contro i siti reali che proprio non riesce quasi mai HTTPS.

L'esempio di oggi è su ciò che accade quando una pagina di login viene caricato in modo sicuro, anche se incorporato in una pagina non sicura.Questo è un comune di sicurezza anti-modello e vedrete che in molti siti. L'esempio nel video è da conto alla rovescia in Nuova Zelanda , ma ancora una volta, ci sono innumerevoli altri là fuori. Date un'occhiata al video e poi tornerò a come ho montato l'attacco:

Ha senso? In breve, non si può mai fidare della componente HTTP della comunicazione e senza la possibilità di vedere l'URL nel browser caricato su un indirizzo HTTPS con un certificato valido , l'implementazione SSL è quasi inutile.

La meccanica di come ho dimostrato attacchi contro l'uso insufficiente delle SSL comporta l'uso di script di Fiddler . Molti di voi potrebbero già avere familiarità con Fiddler , l'opzione di scripting ci dà la capacità di manipolare il traffico non crittografato sul filo proprio come un utente malintenzionato potrebbe in qualsiasi punto della rete di comunicazione. Chiaramente un attaccante, diciamo un ISP o l'esecuzione di un hotspot wireless canaglia non sarebbe in esecuzione Fiddler, ma la meccanica di manipolazione richieste e risposte è simile ad altri strumenti.

In questo esempio ho semplicemente aggiunto il seguente script in caso OnBeforeResponse:

se ( oSession . HostnameIs ( "www.countdown.co.nz" ) && oSession . PathAndQuery == "/" ) { 
    / / Rimuovere qualsiasi compressione o 
    

    

    Modificare il percorso di login 
    


    Impostare il corpo di risposta al mutato stringa corpo 
    oSession . utilSetResponseBody ( obody ); 
}

In altre parole, quando viene caricata la pagina iniziale è sufficiente sostituire il link al form di login da quello originale per uno dell'attaccante che sembra la stessa. Lavoro fatto.

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java

Scansione di errori di configurazione della sicurezza dinamica con OnCheckin e ASafaWeb

Ecco la cosa per la sicurezza - non si può semplicemente "farlo" per passare poi. Cosa voglio dire con questo è che è un processo continuo e pensare che hai solo bisogno di implementare solo alcuni standard di codifica sicure o eseguire la scansione del sito web una volta prima di andare a vivere lascia un grande grande buco nel vostro processo.

Per esempio, l'altro giorno ho scritto su come l'insicurezza è facile in cui ho parlato di come Black and Decker erano esposti i registri ELMAH. Questo è il più piccolo di errori di configurazione che può facilmente accadere in qualsiasi momento, ma voleva dire che si è conclusa con le credenziali da una parte significativa della loro base di clienti accessibile al pubblico - ahi! Ok, questo ha coinvolto anche la memorizzazione delle password semplici testi in cookie al fine di facilitare la funzione "ricordati di me" (no, davvero), ma il punto è a quanto sia stato facile per fare un semplice cambiamento che soffiava un buco enorme nel fianco il loro profilo di sicurezza.

Questo mi porta al punto del post: errori di configurazione della sicurezza avviene ed è necessario iniziare la ricerca di esso botto dopo aver pubblicato il sito. Esposto ELMAH log è una cosa ma errata configurazione semplici modifiche di protezione si può rovinare il rilascio di un sito Web ASP.NET vanno ben al di là di quello; errori personalizzati, il rintracciamento, la convalida richiesta e il modo in cui i cookie sono configurati per citarne solo alcuni. Ognuno di questi può essere configurato in modo da lasciare un sito vulnerabile letteralmente in pochi secondi.

Per l'ultimo paio di anni ho fornito un servizio per rilevare questi problemi in un luogo vivo - ASafaWeb .La proposta di valore di ASafaWeb è sempre stata che su richiesta, è possibile eseguire la scansione del sito web in diretta ASP.NET e sarà riferire su questi errori di configurazione. Ora sono molto felice di condividere come ASafaWeb è stato integrato nel OnCheckin (da un'idea di Doug Rathbone ) per fornire la distribuzione continua di siti web ASP.NET come servizio basato su cloud.

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java

Parlando con Scott Hanselman su honeypot, ananas e SSL

Per molti di voi, Scott Hanselman avrà bisogno di presentazioni ed è un volto molto familiare, la voce e scrittore. Tra le tante cose buone che Scott fa per sostenere la comunità di sviluppo web (e che non sono solo le persone di Microsoft o), è anche l'uomo dietro la Hanselminutes podcast di cui sono stato molto felice di unirsi a lui sul recente. In realtà questo rimane uno dei pochissimi podcast dove ho effettivamente ascoltare ogni episodio - a prescindere dalla rilevanza diretta per me - semplicemente perché è consegnato in un modo così professionale e so che ho intenzione di imparare qualcosa ogni volta.

Il podcast va sotto il titolo Sei sicuro? Gli honeypot WiFi, ananas e SSL con Troy Hunt , che è abbastanza auto-esplicativo. Come dice il titolo, abbiamo per lo più discutere i rischi presentati utilizzando wifi pubblico più l'importanza di HTTPS per quelli di noi che stanno costruendo applicazioni web. Vorrei condividere un certo materiale supplementare che ho sia toccato in quel discorso o saranno di pertinenza di ascoltatori interessati:

1. SSL non è sulla crittografia
2. OWASP Top 10 per gli sviluppatori NET parte 9:. Insufficiente Transport layer di protezione
3. 5 modi per implementare HTTPS in modo insufficiente (e la perdita di dati sensibili)
4. Proprio form di login messaggi a HTTPS, ma hai sprecata quando lo hai caricato su HTTP
5. Guida ai principianti di rottura sito web di sicurezza con niente di più che un ananas
6. Ananas Sorpresa! Mescolando i dispositivi di fiducia con subdolo Wi-Fi a # wdc13

C'è molto più contenuti collegati sotto di quelli, ma questo è un buon punto di partenza. Spero che ti piace il podcast!

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla - Corsi asp.net - Corso Java

Il fantasma che i codici: come anonimato è uccidendo la tua carriera di programmazione

Egli si nasconde in silenzio nel buio emerge solo a sfornare brevemente alcuni tag durante le ore lavorative. Non ha volto, nessun nome, nessun record. La sua unica arma è la sua parola. Egli è:

Questo non è il lavoro di fantasia, questi fantasmi a piedi in mezzo a noi, integrandosi perfettamente nel loro ambiente finché un giorno emergono, alla ricerca di un lavoro da qualche altra parte. E quando lo fanno, potenziali datori di lavoro cerca per loro e ... non può essere trovato. Ovunque.

Sì, il "Ghost Who Codici" è reale e si può anche essere uno di loro senza rendersi conto di quello che sta facendo per la tua carriera. Ma non è troppo tardi - si può ancora emergere dal buio ombra, ma deve essere fatto subito, non è qualcosa per ritardare.

Su Internet, nessuno sa che sei un cane (o un programmatore)

Il fumetto classico realizzato alla luce del fatto che Internet vi offre la possibilità di creare la propria identità, si può pretendere di essere chiunque (o altro) che si desidera. Un curriculum non è molto diverso, e questo è al centro di ciò che vuole ottenere a; CV in cui sono presentati i reclami, ma perché il candidato è un fantasma metaforico non esiste alcuna traccia di loro - non prova di loro - ovunque sul web. Forse questa è una cosa che ci si aspetta quando l'assunzione, per esempio, una battaglia di Gettysburg storico, ma è non è qualcosa che ci si aspetta quando assumere qualcuno in alta tecnologia online centro di un mondo che è l'industria del software.

Ecco di cosa sto parlando: un CV arriva e naturalmente si tratta di un conto incandescente di tutte le cose meravigliose che l'individuo ha fatto nel corso degli anni tra cui la loro grande esperienza in una vasta gamma di tecnologie e versioni. Ma è la loro versione della storia e, naturalmente, hanno abbellito le cose, per migliorare la loro negoziabilità o perché sono inconsciamente incompetenti (che non è destinato ad essere un commento dispregiativo, "tu non sai quello che non so"). Così come un datore di lavoro coscienzioso potenziale si cercano maggiori informazioni a sostegno della grande ricchezza di conoscenze del candidato promette di portare voi:

Si guarda per il loro profilo LinkedIn. C'è o non è uno o è una copia del CV e non riflette alcuna appartenenza al gruppo, le discussioni tra pari, specializzazioni, i collegamenti o qualsiasi tipo di coinvolgimento con la comunità del software.

E allora cercate un profilo di Stack Overflow. Nessuna fortuna lì, ci sono senza fare domande e senza risposte date. Non ho contribuito conoscenza né hanno cercata in qualsiasi attivo modo.

Forse hanno solo come mettere al canale Microsoft e hanno un profilo sano MSDN per la stessa ragione? Difficilmente.

Che ne dici di un account GitHub o la partecipazione in altre open source? No, niente neanche lì.

Forse un account Twitter o pubblico pagina Facebook per dimostrare il tipo di informazioni che ritengono rilevante in condivisione o addirittura contiene solo alcune delle loro intuizioni più spiritoso al punto e virgola rispetto al dibattito infuria punto e virgola non? Nope.

Ci potrebbe anche essere un account Disqus evidenziando il loro accordo (o meno) con una qualsiasi delle centinaia di migliaia di pezzi utili di materiale software di sviluppo del motore commento accompagna? Nessuna possibilità.

Un blog? Lascia perdere.

Ho intenzione di andare su un arto qui e dire questo: se questo si è, si potrebbe uccidere le vostre prospettive di carriera, perché dipinge un quadro molto sfavorevole. Vi spiego perché.

Gli sviluppatori di provata efficacia lasciare una traccia cartacea

Scott Hanselman li chiama gli sviluppatori di materia oscura , che costituiscono una parte significativa dell'universo ! eppure non li vedi nel suo solito modo affabile, Scott sottolinea che questi ragazzi sono probabilmente felici ottenere il lavoro fatto con il loro ASP.NET 1.1 e punzonatura quando l'orologio scandisce il passare del tempo a casa prima di fare una veloce ritirata, assumedly a qualche forma di non-programmatore basato sulle attività.

Va bene, ma queste non sono le persone con la passione. Sono anche lontano dalla più produttiva (si può immaginare non generici, nessuna pagina moduli web master, non MVC, nessun ORM, ecc) e non sta andando ad essere l'introduzione di ogni innovazione o contribuire molto per migliorare l'ambiente in cui lavorare in là forse di essere in buona compagnia.

Ma uno dei più grandi carenze con questo pubblico è che si sta lavorando in un vuoto. Che cosa succede quando vengono perplessi su qualcosa?Tutti si perplesso su qualcosa e di solito non è un fatto strano, la domanda è, che cosa succede quando lo fai? Chi sa riconoscere sono bloccati presto e entrare in contatto con la comunità per il supporto levate in piedi una significativamente migliore possibilità non solo di ottenere il problema risolto presto, ma probabilmente sempre fatto meglio pure. Naturalmente questo poi lascia una traccia cartacea per artisti del calibro di overflow dello stack.

Al contrario, è uno sviluppatore mai contribuire? Io direi che è ragionevole supporre che il 99% dei programmatori entrare in contatto con la comunità online per prendere informazioni quando sono bloccati (diciamocelo, Google è la prima tappa quando questo accade), ma il numero di restituire il favore? Queste comunità funzionare solo perché abbastanza persone sono disposte a dedicare competenze gratuitamente, cosa dice quando qualcuno non è disposto a farlo pur beneficiando del lavoro gratuito degli altri? Non sto dicendo che diventare Jon Skeet , ma andiamo, forse rispondere alla domanda strana, effettuare una modifica o lasciare un commento per migliorare il valore dei contenuti per gli sviluppatori futuri colleghi.

Quindi, che cosa dire di sviluppatori che non hanno questa traccia cartacea? Beh in primo luogo, sono quasi certamente passare più tempo sbattendo la testa contro il muro cercando di risolvere i problemi di quello che dovrebbero essere. Sono, inoltre, non indiscutibilmente con gli strumenti a loro disposizione in modo efficace - che stanno lavorando in modo meno efficiente di quanto necessario. Si potrebbe ragionevolmente estendere questo modo più insulare di lavorare oltre la semplice Q & A e, sono queste le persone attivamente alla ricerca di altri modi per migliorare le loro pratiche di sviluppo? Stanno seguendo quello che sta succedendo nel settore e portare questi miglioramenti in ufficio con loro?

"I migliori programmatori sono fino a 28 volte migliori dei peggiori programmatori"

Questo è da fatti ed errori di Ingegneria del Software , ed è estremamente importante per i datori di lavoro perché fa una grande differenza per il valore del loro investimento. E non fare errore su di esso, i dipendenti sono investimenti. Potrai leggere cose simili in The Mythical Man-Monthquando si parla di un gruppo di sviluppatori esperti:

Nel giro di questo gruppo i rapporti tra le prestazioni migliori e peggiori media di circa 10:1 sulle misure di produttività e un incredibile 5:01 sulla velocità del programma e le misure dello spazio!

Immagina che - essere in grado di ottenere un aumento del 5 o 10 volte il vostro investimento sviluppatore solo perché hai scelto la persona giusta! Ma non avete intenzione di ottenere che con gli sviluppatori che lavorano nel loro bozzolo proprio piccolo, almeno non da coloro che lavorano con le moderne tecnologie che si stanno evolvendo rapidamente. Questa è la proposta di valore molto importante per i datori di lavoro ed è per questo impegnata, acceso sviluppatori che sanno come sfruttare al massimo le risorse a loro disposizione sono così preziosi e quelli che non lo fanno, beh, non così tanto.

Molto è stato scritto sul processo di intervista programmatore, Joel Spolsky ha un pezzo eccellente su La Guida di Guerrilla Intervistare che è sempre un buon punto di partenza. Tutto questo è di cercare di estirpare il minore autore - quelli che sono del 10% o del 20% più efficace il loro acceso coetanei - e raggiungere la "crema". Tecniche di colloquio sono grandi, ma ci sono anche quelli che tenterà di "gioco" loro nella misura più ampia possibile. Io stesso ho ricordi di molti anni fa, di tutto quello che ho potuto diligentemente memorizzazione da alcuni libri di programmazione di grandi dimensioni in modo da poter ripetere questa conoscenza testualmente nelle interviste il giorno seguente.

Immaginate ora di essere in grado di avere qualcuno dire: "Ecco il mio repository GitHub pubblici, andare a dare un'occhiata". Supponendo che ci sia abbastanza in là per eliminare gli sviluppatori inserire la copia (e si può dimostrare che abbastanza facilmente), si aggiunge una dinamica meraviglioso per un colloquio. Si può effettivamente parlare di codifica pratiche nel contesto del lavoro vero e proprio! Diventa una discussione molto meno filosofica e in particolare una volta che c'è un po 'di storia anche lì che consente di godere di Insight non si può ottenere da discussioni o addirittura seduti il candidato verso il basso per una codifica test (e diciamocelo, quelle sono sempre un po 'stressante per il dev poveri).

Formazione? Grande, ma che cosa hai fatto in realtà?

Se venivo operato avrei voluto essere dannatamente sicuro che il chirurgo aveva alcune qualifiche gravi. Quando ho saltare su un aereo che voglio sapere il pilota è stato strenuamente testato, e molto di recente a questo. Ma quando assumo un codificatore il singolo fattore più importante è quello che hanno effettivamente conseguito e che posso verificare al di là del sentito dire che è un CV (o nella migliore delle ipotesi, un punto di riferimento). Gradi generici in discipline informatiche connesse dare assolutamente alcuna garanzia che qualcuno è uno sviluppatore di prima qualità e certificazioni semplicemente dimostrare che qualcuno è in grado di passare un corso.

Molti sostengono che queste cose aprire porte che altrimenti non sarebbero stati aperti senza di loro. Certo che dipende da chi sta aprendo la porta e quanto l'accento è posto sul lavoro burocratico a fronte di un track record verificabile. A mio avviso - e penso in modo abbastanza - che tanto più che il "vecchio guardia" mossa e quelle responsabili per l'assunzione sono sempre più della generazione internet, la messa a fuoco sta diventando un molto più pratico, basato sull'evidenza uno. Non potevamo davvero fare questo, anche un decennio fa. Possiamo ora.

Intendiamoci, niente di tutto questo è per dire non andare e di perseguire certificazioni istruzione terziaria o di guadagno, possono anche aiutare a sviluppare le abilità che è possibile utilizzare per fare effettivamente qualcosa . Ma fare in modo che "qualcosa" è in realtà fatto.

Ci è stato a lungo l'enigma tra quelli nelle fasi iniziali della loro carriera per quanto riguarda il modo in cui diventare occupabili senza avere un track record. L'istruzione era l'unica cosa che poteva contenere fino a una qualche forma di garanzia che non erano del tutto incompetenti. Questo non è più il caso - ora abbiamo tutti i canali citati in precedenza e francamente se qualcuno esce di tre anni più di istruzione terziaria in una disciplina di programmazione senza un profilo di Stack Overflow o un account GitHub o una scia di social media di Tech Talk, cosa mai ti hanno fatto?

Ma non tutto è perduto ...

Niente di tutto questo può mai importanti per te. L'utente non può essere messo in una posizione in cui sei o alla ricerca di un lavoro o sono in competizione con coloro che non sono fantasmi. Forse. Forse.

Ora, naturalmente, nulla di tutto questo significa che lo Spirito Chi Codici è disoccupato, lontano da esso, ma quando vengono messe accanto a qualcuno che sulla carta è uguale , tranne che hanno questa storia ricca e verificabili in modo indipendente dei contributi di impegno e di comunità poi c'è nessuna concorrenza. Che cosa significa è che non hanno altro che la loro parola su cui basare l'intera premessa del rapporto di lavoro e convincente come questo può essere, non è più sufficiente.

Ma la buona notizia è che se si vuole uscire dall'ombra è morto facile da iniziare e grandi cose possono accadere in tempi brevi. Prendere Iris Classon , dare un'occhiata a ciò che ha raggiunto in un breve 18 mesi. Non e '18 mesi di un programmatore esperto di tentare di costruire alcuni complimenti pubblici, questo è di 18 mesi che va da alcuna esperienza di programmazione a tutti a migliaia di seguaci, gli impegni di lingua multiple e la partecipazione in alcuni davvero ben considerati programmi. Che la dice lunga a un potenziale datore di lavoro che un CV di fantasia o su carta qualifiche non lo farà mai.

In definitiva, la mancanza completa di profilo pubblico non rende qualcuno un programmatore male. D'altra parte, un curriculum ricco di impegnarsi con la comunità, ponendo domande, dimostrando entusiasmo e partecipazione attiva nel settore vi consente di partire sanguinosa testa sulle i fantasmi.

Nota: Non mi è sfuggita che chi commenterà sono, per definizione, non i fantasmi mi riferisco! Coloro che commentare a nome dei fantasmi ulteriormente servire a mettersi là fuori sul facilmente rilevabile, pubblico cronologia :)

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla

Fantasie Facebook: Premere piace e digitare il numero 1 e vedere cosa succede per l'immagine!

Ho visto alcuni di questi in giro ora, di solito con foto diverse, con una sorta di mistero:

La promessa implicita è di qualcosa di interessante accade una volta che hai cliccato sul pulsante mi piace e digitato il numero 1. C'era uno con una ragazza attraente e un quadrato sovrapposto sopra la sua spalla facendo il giro un po 'di tempo fa, troppo. Ho visto gli altri in cui le istruzioni sono più esplicite in termini di parole o frasi da digitare.

Ecco una buona domanda: che cosa di solito succede quando si piace e commentare qualcosa in Facebook? I numeri continuano a crescere (e si può vedere che sono già considerevole) e viene pubblicato sul tuo muro. Nulla di magico in questo e c'è sicuramente accadendo nulla di eccitante per le persone che rientrano in fila dietro le centinaia di migliaia prima di loro che sono già da aspettarsi seguito le istruzioni.

Allora qual è il rialzo per il manifesto originale della foto? Popolarità via piace e commenti. C'è una scienza dietro a tutto questo e dei volumi di certo grandi Mi piace, commenti e azioni è vantaggioso per percepito popolarità. Non è dannoso, in quanto non sta andando a servire malware o addebito sulla carta di credito, ma che implicitamente annunciare ai tuoi seguaci che sei ingenuo!

Oh, e quel buco grosso freakin 'nel terreno? E 'l'unica cosa in questa immagine, che è in realtà legittimo .

Corso Visual Studio - Corso asp.net
Corso C# - Corso PHP - Corso Joomla