2 pagine in totale: <<Indietro 1 [2]
Data Protection API
DPAPI (Data Protection Application Programming Intefaces) un'altra novità ghiotta.
Si tratta di API che permettono di implementare particolari funzionalità di protezione per le applicazioni.
Perchè funzioni, si utilizza un tool, che serve primariamente per trasferire nel registry alcuni parametri di configurazione e criptarli.
L'unico utente del sistema in grado di accesso, tramite ACL, è il Worker Process di ASP.NET.
Questo ha due effetti: da un alto aumenta la sicurezza (nessuno può accedere a certi dati di configurazione), dall'altro allontana il deployment XCopy: sarà necessario intervenire manualmente, non basterà più copiare i files.
I punti in cui le DPAPI lavorano sono i tag di configurazione processModel , identity e sessionState per quanto riguarda la configurazione con SQL Server.
Cross Site Scripting addio!
Gli attacchi di tipo CSS, da non confondere con i fogli di stile, sono una piaga molto diffusa, ad esempio in alcuni forum che lasciano passare troppi dati all'utente.
Il risultato è che volendo si può inserire codice maligno in grado di fare submit di form o altro, con il vantaggio di girare nel dominio di partenza, che si considera sicuro.
E' un po' simile agli attacchi di tipo SQL injection, dove però la vittima è il database (anche se i risultati possono essere gli stessi).
La buona notizia è che ASP.NET 1.1 non accetta più codice nei campi delle form, generando un Exception specifica in caso l'utente tenti di inviare questo genere di dati.
E' attivo di default, e lo si può configurare sulla base di applicazioni/server, all'interno del web.config/machine.config:
<pages validateRequest="true">oppure sulla base di ogni singola pagina, con:
<%@ Page ValidateRequest="true"%>True ovviamente abilita la funzionalità (già lo è di default), false la blocca qualora abbiate bisogno di inserire questo genere di codice in web form.
altre migliorie alla sicurezza
Se ASP.NET 1.0 può girare su un domain controller con qualche problema, per ASP.NET 1.1 se ne sconsiglia vivamente l'uso. Funzionerà, ma non è garantito che lo faccia.
Infine, il session state service, il protagonista del primo bug di ASP.NET, accetta chiamate solo dal server locale, rifiutando di default quelle dell'esterno. Il comportamento è comunque forzabile dal registry, ma rappresenta un'altra garanzia di sicurezza, visto che il servizio non sarà disponibile all'esterno, di default.
La piattaforma migliore per l'hosting
L'ho sentito ripetere così tante volte, che forse mi sono convinto anche io. Ed è probabilmente vero se usato con IIS 6.
Il dev team punta a rendere ASP.NET la piattaforma migliore per l'hosting, non solo per housing o comunque server propri.
L'ambizione sarà certamente più semplice da raggiungere con la 2.0 (c'è tempo per lavorare), ma la 1.1 non pecca di novità in questo senso.
Per prima cosa, ci sono due livelli in cui si potrà far girare l'applicazione: full trust e quindi con permessi maggiori, e minimal , con soli diritti di esecuzione.
In più, ci sono delle API per lo shotdown di un app Domain che dovesse risultare bloccata. Ciò permetterà di riavviare il solo App Domain e non l'intero worker process, qualora qualcosa non andasse per il verso giusto.
Inoltre, il worker process non consumerà risorse se non utilizzato (come fa ora, anche se in minima parte) ma sarà automaticamente scaricato dalla memoria. Con la 1.0 rimane con un'occupazione minima, ma rimane comunque togliendo risorse ad altri processi del server.
Ancora meglio con IIS 6
Ciò che abbiamo detto in precedenza vale ancora di più se il web server con cui lavora ASP.NET 1.1 è IIS 6.
Per i distratti, ricordo che IIS 6 sarà disponibile con Windows Server 2003, in uscita a metà Aprile di quest'anno.
E' un web server completamente riscritto, secure by default e con un'archiettura fault-tolerant. Ho avuto modo di seguire uno speech a cura dei Security e Riability Manager di IIS 6 e mi hanno impressionato. Avevo già buttato un occhio e provato IIS 6, ma farsi spiegare da chi l'ha fatto i punti in cui hanno operato è qualcosa di davvero unico. Probabilmente torneremo nel dettaglio con un articolo apposta sull'argomento, visto che esula dai temi di questo articolo.
Ad ogni modo, con IIS 6 e ASP.NET sarà possibile bloccare banda e connessioni, avere un riciclo del wp ogni 3 ore, in modo da non consumare risorse, configurare opzioni in maniera migliore, ed impostare un limite su CPU e memoria che l'App Domain può utilizzare. Il tutto relativamente ad ASP.NET, non ad IIS in quanto tale.
Torniamo per un attimo su IIS 6 e sulla sua archiettura. In un mio precedente articoli di introduzione al .NET Framework potete leggere alcune cose sulla nuova architettura, in particolare sull'implementazione di http.sys (nella kernel area) e della cache associata (sempre nella kernel area).
Come è normale attendersi, la V1.1 fa uso di questa cache nella kernel area per i propri meccanismi di cache.
Questo vuol dire essenzialmente che pagine che usano la direttiva OutputCache saranno mantenute in questa porzione di memoria, che ha un accesso rapidissimo e che le rende in pratica del tutto simili alle richieste di file HTML statici: non cambia nulla!
In questo modo, senza cambiare API tra l'altro, non è necessario più uno switching di context tra user e kernerl area (necessario con IIS 5) perchè la cache di IIS 6 lavora ad un livello superiore, nella kernel area per l'appunto.
Sempre a proposito di OutputCache, è stato migliorato il comportamento relativo al caching di User Controls.
Attraverso la proprietà shared, che accetta un booleano, è possibile indicare al motore di condividere quella stessa istanza di User Controls in cache in tutta l'applicazione. Basta che l'ID di dichiarazione sia identico.
Conclusioni
Come si può notare, dunque, il lavoro maggiore è stato fatto sul bux fixing (e questo si vede poco) e sulla sicurezza (ed in questo caso è più tangibile).
In particolare, la cosa che mi fa davvero piacere è l'integrazione molto spinta con IIS 6 (che è un gioiellino a prescindere) e le nuove security features aggiunte.
Vale la pena passare ad ASP.NET 1.1? Certo! Già solo il sistema di recycling del worker process vale il passaggio. Ed ovviamente il resto non è da meno.
Infine, segnalo l'uscita degli ASP.NET Starter Kits , delle nuove applicazioni per ora in beta, a cui potete dare un'occhio per imparare a sviluppare in maniera migliore con ASP.NET.
Approfondimenti
- Per scaricare il .NET Framework 1.1 beta 2 da MSDN
- Informazioni tecniche sull'architettura di IIS6
- ASP.NET Starter Kits
2 pagine in totale: <<Indietro 1 [2]
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
