venerdì 20 febbraio 2015

Visual Studio online Sprint 78: nuovo look Kanban Boards

In questo sprint, tavole Kanban ottenere un look spartano per consentire loro personalizzazione in futuro. Inoltre, più tester possono essere aggiunti a Visual Studio suite di test online.

By Michael Domingo2015/02/19

Un altro aggiornamento Visual Studio Online è disponibile, questa volta con miglioramenti tavole Kanban, e la possibilità di assegnare più utenti a testare suite.

"E 'probabile che prendere quattro o cinque giorni di tempo per aggiornare tutti gli account in modo da non essere sorpreso se non si vedono i cambiamenti nel vostro conto subito," Microsoft Technical Fellow Brian Harry bloggato annunciando la volata.

Le schede Kanban in Sprint 78 hanno un aspetto più semplificata, con le carte con uno sfondo bianco solido e di essere ridimensionata per essere leggermente più grande rispetto alla versione precedente. "Stiamo gettando le basi per ulteriori opzioni di personalizzazione sulle carte, tra cui ornamenti, altri campi e tag," Visual Studio online Program Manager Aaron Bjork, ha detto in una versione Web .

Le schede vengono anche con due nuove funzionalità: il supporto per l'aggiunta di nuove carte, e tutte le carte possono essere modificati direttamente; e uno Split Colonne caratteristica che è più chiara su carte come sono spostati da una persona all'altra.

Visual Studio online rende anche più facile per gli sviluppatori di aggiungere più tester di una suite di test. Ma non è solo un semplice aumento del numero. Invece, c'è qualche automazione in modo che, come tester sono aggiunti attraverso un clic di una finestra di dialogo, gli utenti vengono informati tramite una e-mail contenente un link ad una prova assegnata.

Una nota a parte, la settimana scorsa Harry blogged circa un anteprima di una nuova funzionalità di ricerca di codice per Visual Studio Online. La funzionalità è limitata a coloro che chiedono e sarà disponibile solo per un numero limitato di account. Più informazioni qui .

giovedì 5 febbraio 2015

Introduzione Fundamentals AngularJS protezione a Pluralsight

Se devo essere onesto, ho sempre trovato un po 'insolito per arrivare a questa domanda:

"Come faccio a rendere sicuro il mio applicazioni angolari?"

Voglio dire, angolare è solo JavaScript che viene eseguito nel client e alcune direttive HTML. Ok, è molto buono JavaScript e non intendo banalizzare il quadro in alcun modo, ma tutto il lavoro sporco di sicurezza deve ancora accadere sul server. Angolare farà nulla per l'iniezione SQL o la vostra mancanza di controlli di accesso alle risorse del server o di qualsiasi delle altre cose di sicurezza davvero brutto che tende ad andare male in applicazioni web. Eppure la domanda continuava e più ci pensava, più si rendeva senso mettere la sicurezza angolare in prospettiva. Quindi ho fatto questo corso Pluralsight :

Angolari Fundamentals JS sicurezza

Il fatto molto solo che gli sviluppatori continuavano a chiedere per la sicurezza angolare era una motivazione sufficiente per fare un corso di esso. Mi spiego come ho avvicinai a lui.

Inizia ottenere la vostra testa intorno ad esso
Spesso mi chiedo se la domanda di sicurezza angolare viene da coloro che sono forse più recente per lo sviluppo web e il cui mondo centri più in giro angolare come un prodotto piuttosto che dove si inserisce nel più ampio ecosistema web app. Ad esempio, come ben sintonia sono sviluppatori al fatto che è facile solo per prendere angolare fuori dal quadro del tutto e inviare richieste direttamente alla API sul server? Alcune persone potrebbero fanno beffe l'affermazione che non è ampiamente compreso, ma credetemi, è comunemente perso. In realtà questa è una delle cose che mi concentro sul mio Hack Your primo corso API ed è una mentalità particolarmente diffuso nel mondo di applicazioni mobili.

Una delle prime cose che faccio nel corso è molto chiaramente client segmento di rete da server. Chiaramente angolare è una tecnologia lato puramente client in modo che vive nel mondo del DOM, ha a che fare con le cose come site scripting e beneficia di difese, come solo i cookie sicuri e HTTP croce. Non sta andando per aiutarvi a proteggere stack di rete o server e spendere un po 'di tempo che delinea i rischi discreti e le difese non in termini di come devono essere affrontati indipendentemente dal client.

Questa è una delle cose che la gente spesso si affacciano nella progettazione dei loro app, siano essi angolare altro:

Graphic su ciò che si può controllare (solo il server)

E 'un problema di assunzione di fiducia - "Ho costruito questa Javascript e sarà sempre utilizzare quella volevo a" - ed è un presupposto pericoloso. Come ho detto prima, si può sempre sostituire il client per qualcos'altro (anche solo CURL) e si può sempre manipolare il traffico sul filo, anche se è inviato tramite HTTPS e si possiede il client. Il server è dove il vero resilienza deve essere e uno dei punti chiave che faccio molto presto è semplicemente questo: assumere sempre il client è compromesso!

Questo aiuta con il modo di pensare su angolare, next up è come iniziare a rompere pezzi di applicazioni integrate con esso.

Lavorare con i controlli di sicurezza sul server
Molto di questo si riduce a come le applicazioni vengano autenticati e quindi autorizzare le richieste di risorse del server. Alcune di queste è la stessa con applicazioni web costruite nel modo più "tradizionale", dove un muro di messaggi HTML al server, scarica dal DOM e poi afferra un nuovo muro di HTML. Ma un sacco di si differenzia anche quando si passa a richieste asincrone leggeri progettati per manipolare solo il DOM.

Identità persistenza, per esempio, assume improvvisamente una forma nuova o almeno può fare. Normalmente avremmo buttiamo un cookie di autenticazione nel browser su login e tutte le successive richieste sarebbe auth'd in virtù di quel cookie implicitamente di essere inviato. Ma i cookie non sono "RESTful" (potete leggere alcune delle mie opinioni sulla RESTfulnes qui ) e la vista di richieste API è che in genere devono essere inviate tramite token portatore invece. Ora che non è difficile da fare e ha un certo numero di vantaggi rispetto cookie comunque (CSRF difesa, per esempio), ma avete ancora a persistere sul DOM scarico. Alcuni mettono in un cookie e quindi orchestrare è il recupero tramite JavaScript in modo che possa essere aggiunto alle richieste API, ma ora il cookie non possono essere contrassegnati come HTTP solo quindi è vulnerabile a rischi di qualsiasi XSS. Ci sono altri modi, ma questo dà un senso di quel tipo di problemi affronto nel corso.

Una cosa da sottolineare è che io non vado in "Questo è esattamente come implementare questa end to end in angolare e [inserire preferito framework lato server qui]". Si tratta di un corso di agnostico piattaforma server, cioè è altrettanto relent di ASP.NET in quanto è PHP o Nodo o qualunque sia il vostro gusto preferito di roba che esegue sul server è. Questo è lo stesso approccio che ho preso con altri corsi come Hack Yourself First e sicuro Gestione Account Fundamentals e ho trovato che la larghezza piuttosto che la profondità funziona bene per questo stile, naturalmente. Quello che faccio concentro su è però comportamenti l'applicazione deve dimostrare in modo da passare attraverso entrambi anti-modelli e buone pratiche, spiegando loro rispettivi insidie ​​e meriti. C'è anche una applicazione di esempio che viene utilizzato nel corso ed è pubblico per le persone a giocare con più a awesomeplaces.troyhunt.com e tra l'altro, che è costruito su ASP.NET MVC e utilizzando API Web.

C'è un sacco di altre cose nel modulo sui controlli di sicurezza del server, ma è il modulo successivo che ho il sospetto che turbare più di un paio di sviluppatori angolari là fuori ...

Problemi di sicurezza comuni sul lato client
Cominciamo dal crogiolarsi nel caldo bagliore di questo brillantezza :

Commenti HTML rivelare account admin la password

Sai cosa c'è di sbagliato in questo. Io so cosa c'è di sbagliato in questo. Heck, anche il dev che ha scritto probabilmente sa che cosa c'è che non va, ma qui è in tutto il suo splendore. Chiaramente questo non è angolare, ma illustra un punto molto importante - nulla inviato al cliente è osservabile da parte di coloro che lo ricevono! Lo so, chi avrebbe mai thunk esso, ma è un punto importante in angolare perché fa un sacco di lavoro del server normalmente in una applicazione più tradizionale. Tutto quello che lega modello e orchestrazione di chiamate di servizio e di carico dei modelli è ora esposti al pubblico. Quando si invia un controller verso il cliente in un file di script e contiene riferimenti a quella fabbrica "nascosto" admin che poi chiama in un servizio per gestire gli utenti, questo è adesso Informazioni pubblico.

In caso di trasmettere queste informazioni al client pre-auth? Questa è una delle cose che discuto nel corso e naturalmente con forza parlare di proteggere i servizi che sono "nascosti" dal cliente. Mostrando le cose giuste alle persone giuste e fiduciosa al browser di prendere quelle decisioni per voi è meraviglioso in una AJAX'y, sorta di risposta di strada, ma niente di tutto questo nega il punto precedente - non si controlla il client.

Naturalmente anche guardare in altri attacchi che avvengono nel browser e quindi le cose come il rischio di XSS e come angolare codifica output maniglie (in realtà è piuttosto intelligente), il ruolo di biscotti e di quelli sicuri e HTTP solo gli attributi e poi un po 'su CSRF come bene. Come si è visto, angolare ha un bel modo pulito di aiutare a ottenere i tuoi gettoni anti-falsificazione sotto controllo e questo è qualcosa copro nel modulo successivo ...

Sicurezza costruisce all'interno AngularJS
Nel corso, faccio notare che la documentazione di sicurezza angolare è, beh, un po 'scarsa:

La pagina di documentazione di sicurezza angolare

Questo è tutto. Questo è l'intera pagina. C'è un collegamento fuori per ngCsp ma questo è tutto. Ora si può capire perché questa domanda su come proteggere angolare continua ad emergere!

Ma c'è in realtà una certa sicurezza molto ordinato costruisce in angolare. Ad esempio, ho detto qualche magia CSRF in precedenza: se si dispone di un cookie chiamato "XSRF-TOKEN" allora angolare converte automaticamente in un intestazione di richiesta personalizzata denominata "X-XSRF-TOKEN" e inviarlo a qualsiasi richiesta invocata tramite il $ servizio http dove il vostro quadro preferito del server può quindi validare il token e farlo magia anti-contraffazione.

Un altro trucco è il modulo ngSanitize (tutti al di fuori dell'America, fare notare l'ortografia, non succede molto altrimenti!). Questo cambia l'approccio di angolare per la codifica in uscita e implementa una whitelist di gettoni HTML consentiti mentre nudo tutto il resto fuori. Ora francamente, sanificazione è sempre un po 'di un pantano, ma angolare fa fare piuttosto un bel attuazione di esso.

Poi c'è il pieno "si è ora da soli" per quanto riguarda la codifica di uscita, che è quello di trasformare totalmente fuori escape contestuale rigorosa e solo la fiducia che tutti i dati che si collega in tale contesto è sicuro. E 'la "è il tuo piede" approccio e mi mostra come buono come angolare è, si può ancora rovinare tutto piuttosto male.

A proposito, indovinate cosa succede quando metti i dati non attendibili da input dell'utente in un modello reso sul lato server? Diciamo che non è piacevole e mi dimostrano perché questo è uno dei pochi pezzi di orientamento Google in realtà messo in quella pagina di sicurezza angolare sopra.

Il mio approccio a questo modulo e in effetti l'intero corso - come è con i miei altri - è questo: mostrare alla gente come rompere le loro cose. Far loro capire che cosa può andare storto e sperimentare in prima persona, perché a meno che siano realmente impegnati nei rischi associati a questi modelli, è molto difficile per loro di acquistare nello sforzo che è necessario per difendere le loro applicazioni.

Si tratta di un corso angolare che non si tratta di angolare
Originariamente, io non avevo intenzione di fare di questo un corso angolare. Invece, stavo per fare un corso più generico che applicato allo stesso modo a angolare come fa, per esempio, Backbone o Ember. Il mio pensiero era che l'attuazione della biblioteca lato client non era il punto, piuttosto era più di circa la comprensione dove i rischi giacciono in un'applicazione che si muove molto logica nel browser. Questa è ancora la mia visione delle cose e in questo senso, i primi quattro moduli del corso sono rilevanti indipendentemente dal vostro quadro Thing.JS preferito. Ma chiaramente angolare ha un enorme impulso al momento ed è finito per essere semplicemente un modo più ampio rilevante di descrivere il corso.

Detto questo, l'ultimo modulo sopra descritto è tutto angolare. Sembra specificamente accesso quello che abbiamo avuto modo, nel quadro e come utilizzare e cattivo uso di esso. Spero che questo dà il corso della massima utilità possibile.

Perché up slip sicurezza sono ovunque
Come ho iniziato la registrazione al corso, ho caricato il sito angolare e ...

Il sito angolare con contenuto misto

Contenuto misto. Bugger. Questo è il browser web di Google caricamento del sito web per framework di Google e mostrando gli avvisi di Google che parti della pagina sono insicuri. Hanno praticamente proprio stack end-to-end, ma ancora qui, questo è scivolato in. Non è un grosso rischio per la sicurezza, ma simboli di avvertimento tendono ad essere il genere di cose che non vuoi sul tuo sito web del prodotto!

Si tratta quasi certamente di una svista e va a illustrare molto di quello che parlo in corso, vale a dire che è facile ottenere questa roba sbagliata. Un piccolo rischio XSS, per esempio, in combinazione con un biscotto accessibile in script client (che è piuttosto comune in applicazioni angolari) e ci si va - sessioni dirottato!

In chiusura ...
Il corso dovrebbe arrivare a chiunque la costruzione di riflessione angolare su cui il quadro si inserisce nel più ampio panorama della sicurezza in un modo che ti aiutano a capire i rischi. Mette angolari - e altri JS quadri - in prospettiva e rende molto chiaro ciò che è e ciò che non è quando si tratta di sicurezza. Angolare è molte cose meravigliose, ma fornisce un semplice piccolo pezzo del quadro di sicurezza in un sito angolare.

Infine, per chi non conosce Pluralsight, si tratta di un modello di servizio di abbonamento con costi dando il via a $ 29 / m e che vi dà accesso a vicino a 4.000 corsi su un mucchio di argomenti di sviluppo e di un gruppo di informatici quelli pro e creative pure. Come autore, ricevo una royalty in base a quanto il mio contenuto è guardato e posso solo fare ciò che è che faccio perché i miei corsi ottengono occhi su di loro. Quindi, se siete in angolare o la sicurezza in generale, controllare i miei corsi Pluralsight e mi aiuta a mantenere il contenuto in arrivo!