C#

Semplice è bello :) Ref Out ?

Rosalba Fiore — Sat, 24 May 2008 15:47:35 GMT

Quando affrontai per la prima volta come studentessa autodidatta il passaggio di tipi per riferimento mediante out e ref li trovai impegnativi, sinceramente visto che non li capivo mi demoralizzai un pò, solo all'inizio però

Oggi mi è capitato di leggere direttamente da MSDN Evitare parametri out di seguito riporto fedelmete alcuni passaggi:

"Il passaggio di tipi per riferimento (mediante out o ref) richiede esperienza con i puntatori, conoscenza delle differenze tra tipi di valore e tipi di riferimento, nonché conoscenza dei metodi con più valori restituiti. La differenza tra parametri out e ref spesso non è compresa."

"Sebbene i valori restituiti siano comuni e ampiamente utilizzati, l'applicazione corretta dei parametri out e ref richiede competenze in progettazione intermedia e codifica. I progettisti di librerie che progettano per un pubblico generico non possono prevedere che gli utenti utilizzino in modo professionale i parametri out o ref."

Però cassarli completamente mi sembra esagerato, semplicemente utilizziamoli quando è il caso. Non a caso l'articolo si trova nella sezione "Avvisi di Progettazione".

Provando la beta 3 di Safari

Rosalba Fiore — Fri, 04 Jan 2008 11:13:34 GMT

Insomma passano tanti ma tanti minuti aspettando di poter inserire name and password per un portale SharePoint con Safari x Windows, talmente tanti che dopo un pò si lascia perdere....

E' ancora in beta dunque c'è margine di miglioramento, capiamoci non che io sia una fanatica di Apple però vedere cose nuove e/o diverse fa sempre bene

Rosa' un articolo chiaro su lambda expression, Linq?

Rosalba Fiore — Tue, 24 Jul 2007 03:28:00 GMT

Le specifiche:

Facile da leggere, non troppo lungo e con esempi di codice

Eccovi accontentati, di Anson Horton, che tanto per la cronaca è Program Manager in Microsoft da quasi sei anni, lavora nel team di C# fin dalla fondazione. L'articolo dal titolo impegnativo ma scorrevole:

"L'evoluzione di LINQ e l'impatto sulla progettazione di C#"

Per leggerlo seguite questo link

Ieri Cobol ed oggi..

Rosalba Fiore — Thu, 19 Jul 2007 22:58:00 GMT

Mentre ieri parlavo di cose che hanno fatto storia, oggi qualche cosa su cosa si profila all'orizzonte,

direttamente dai laboratori di Microsoft Reaserch (c'è l'area People se volete vedere i volti di chi ci lavora) maggiori news ed il blog di riferimento di Don Syme.

Chissà che ruolo avrà in futuro nella nostra vita di sviluppatori!!! Avrà uno sviluppo, a distanza di tanti anni ne parleremo/useremo ancora come il Cobol ed il Fortran?

Per ora io ancora non mi pronuncio :) però la voce su Wiki esiste già:

"F# (pronounced F sharp) is a functional and object oriented programming language for the Microsoft .NET platform. A strength of F# is its setting within .NET. A key design aim is seamless .NET interoperability, both via direct use of .NET APIs from F# and authorship of natural .NET components in F#. Consequently, the main F# libraries are the .NET libraries themselves (e.g. DirectX, Windows Forms, and ASP.NET, as well as alternatives like Gtk#). A Visual Studio plugin provides a graphical development environment, including features such as background type-checking with feedback under the mouse, which is extremely helpful for those unfamiliar with type inference.

F# is developed by Microsoft Research, and has a core language that is similar to that of the Caml language: both are members of the ML programming language family.

F# also provides a standard library of its own, designed to be largely compatible with the OCaml standard library. Since the two languages also share a common language subset, it can thus be quite practical to compile a single codebase with both. This enables core Caml code to be ported to the .NET world, and core F# code to run with OCaml. Maintaining this basic compatibility is one of the primary goals of the project.

As a research project, F# demonstrates how .NET enables interoperability between different programming paradigms. It showcases a set of extensions to .NET's intermediate language IL, called ILX, which demonstrate how a strict curried functional language may be compiled efficiently."

fonte: Wikipedia

[70-340] In principio era tutto unmanaged

Rosalba Fiore — Wed, 30 May 2007 07:02:00 GMT

Non sempre possimo utilizzare l'ultima novità anzi.. i compotenti COM, Win32 DLL sono ancora molto diffusi, pensiamo solo al se si tratta di continuare a migliore prodotti di livello enterprise, in questi casi non sempre si può ripartire da zero.

Quali sono i problemi di sicurezza in questi casi?

la CAS in questo caso non ci aiuta, il codice unmanaged ad essa sfugge
nel codice che andiamo ad utilizzare effettivamente può esserci scritto di tutto e tanto per fare un esempio possiamo anche incorrere nel buffer overruns (detto anche buffer overflow)
sono unsigned, quindi facilmente rimpiazzabili con cose non proprio buone e giuste

Le regole principali da seguire in questi casi sono:

validare l'input e l'output che viene passato o ottenuto da una libreria unmanaged
verificare che il "chiamato" sia integro, ad esempio calcolando l'hash e verificandolo col precedente ad ogni chiamata
nel caso di DLL specificar il path assoluto e non relativo utilizzando DLLImport Attibute, che tra le altre cose si occupa di:

•LoadLibrary (carica la dll in memoria) – Free (scarica la dll)

•GetProcAddress (ottiene un puntatore alla funzione richiesta)

•Marshalling (mapping e passaggio parametri)

Però se utilizziamo il path assoluto dobbiamo ricordarci che ci potrebbero essere problemi relativamente l'hash con nuovi update del compotente

Quindi invece di:

using System.Runtime.InteropServices;

[DllImport("user32.dll")]

Abbiamo:

using System.Runtime.InteropServices;

[DllImport(@"C:\windods\system32\user32.dll");

E su tutto ricordasi.. per far funzionare la nostra applicazione l'utilizzatore non deve necessariamante avere i privilegi dell'amministratore... ovvero ricordarsi della regola dei privilegi minimi !

[70-340] La sicurezza dei web services

Rosalba Fiore — Mon, 21 May 2007 09:05:00 GMT

Una delle cose che più mi ha entusiasmato dei web services è la loro estrema praticità. Quando si creano più applicazioni che hanno delle funzionalità comuni si possono inscatolare in un web services e lo sviluppo è sicuramente più celere.

Quello che però alle volte sfugge è "una delle sue maggiori virtù, SOAP tanto per capirci, è anche il suo tallone d'achille per la sicurezza".

Perchè sicurezza e cosa ci interessa in buona sostanza:

l'identità del client
messaggio valido ed integro durante la trasmissione
privacy della comunicazione

In questa faq riportata da Lorenzo a suo tempo si trovano molte informazioni sul mondo WSE ovvero quello che ci viene in soccorso in questi casi. Per ulteriori informazioni su SOAP,WSLD e Web Services vi consiglio questo suo articolo ....ed immaginate che nel 2001 già parlava di XAML.

Ma che cosa è WSE? WSE = Web Services Enhancements ossia un tool per utilizzare la WS-Security con Asp.Net, dove per WS intendiamo Web Services Security Language ovvero uno standard per aggiungere l'autenticazione, firma e la criptazione alla comunicazione SOAP dei Web Services.

Ma WS è un set di definizioni e complessi algoritmi per risolvere i tre punti indicati? No, è uno standard.

Descrive una serie di schema per la descrizione di SOAP:Header che aggiungono informazioni ai messaggi SOAP, tanto per farcene un'idea date un occhio allo schema http://schemas.xmlsoap.org/ws/2002/07/secext/

Per capire meglio di cosa stiamo parlando conviene prima dare uno sguardo a XML Schema for WS-SecurityPolicy.

Ma come fa il client ad autenticarsi? Ci sono tre modalità, elenchiamone due:

il client utilizza una trusting authority centralizzata e poi chiama il server
il server si proccupa di ottenere il token per il client

Quello che a noi ora interessa e cosa accade nel wsse. Supponiamo di utilizzare un X.509

<wsse: Security

xmlns:wsse=http://schemas.xmlsoap.org.org/ws/2002/12/secext

<wsse:BinarySecurityToken

ValueType="wsee:X509v3"

EncodingType="wsse:Base64Binary">

Idjfai......

</wsse:BinarySecurityToken>

</wsse: Security>

Se utilizzassimo i ticket Kerberos dovremmo sostituire con ValueType="wsee:Kerberosv5ST"

Per maggiori informazioni sull'interoperabilità di WS tutte le news le trovate su ws-i .

Ma WSE nel nostro Visual Studio dove si trova? Non è già "compreso" occorre scaricarlo all'indirizzo http://msdn2.microsoft.com/it-it/webservices/aa740641(en-us).aspx in questo post facciamo riferimento alla vesione 2.0.

Le classi più importanti:

WebServicesClientProtocol
SoapContext
Security
UsernameToken
X509SecurityToken

Mentre i namespace sono:

Microsoft.WebServices2
Microsoft.Web.Services2.Security.Token

Ma prima d'attentrari, magari nel prossimo post su cosa sono e come si usano, vediamo per concludere come si aggiunge la potenza di WSE ad un nostro progetto:

installiamo WSE scegliendo l'opzione add-in
apriamo/creiamo un progetto VS
tasto destro sul progetto e scegliamo WSE Setting 2.0
selezioniamo Permetti WSW per questo progetto

E cosa posso dire adesso....io studio ancora per un pò prima d'andare a dormire magari riesco a vedere anche qualcosa in televisone, ed a voi "Buona settimana".

[70-340] RSA

Rosalba Fiore — Fri, 18 May 2007 10:12:00 GMT

In questo post non mi soffermerò sulla crittografia asimmetrica, ricordo solo che il principio ha una solida base matematica che lo giustifica. Il primo e più famoso algoritmo è l'RSA dalle iniziali di Ron Rivest, Adi Shamir e Len Adleman del MIT. Storicamente prima di essere brevettato dal MIT fu ideato dal matematico britannico Clifford Cocks (piccola nota a margine.. le scoperte matematiche pure non possono essere brevettate sono considerate patrimonio dell'umanità..) quindi io lo chiamerei CRSA...

La classe del .Net che si occupa di tutte queste problematiche è l'AsymmetricAlgorithm e della quale ne abbiamo due implementazioni:

RSACryptoServiceProvider: q uesta è proprio l'implementazione dell'algoritmo RSA. Ha alcune proprietà caratteristiche che si occupano del get e del set:
- PersistKeyInCsp
- UseMachineKeyStore
DSACryptoServiceProvider

Tra i metodi della RSACryptoServiceProvider c'è la FromXmlString che ci permette d'importare la key pair da una stringa XML.

Bello l'XML ma Microsoft ci avvisa che:

"Mantenere una stringa XML contenente una chiave privata in una posizione non protetta è una minaccia alla protezione. La protezione dell'applicazione può essere compromessa se una terza parte non autorizzata può accedere alla chiave privata. Per mantenere una chiave privata in modo sicuro, utilizzare un contenitore di chiavi protetto. Per ulteriori informazioni sul mantenimento delle chiavi private in un contenitore di chiavi, vedere Procedura: archiviare chiavi asimmetriche in un contenitore di chiavi"

Ma come "inviamo al mondo" la nostra chiave pubblica ...

RSACryptoServiceProvider mrsa=new RSACryptoServiceProvider();

RSAParameters publicKey=mrsa.ExportParameters(false);

(nota abbiamo il FromXmlString ci sarà anche contrario... certo

RSACryptoServiceProvider.ToXmlString(true);)

Rapidamente vediamo ( i dettagli nella procedura indicata sopra) che una volta create le chivi private occorre aggiungere:

un oggetto CspParameters
specificare la proprietà CspParameters.KeyContainerName
passare al RSACryptoServiceProvider il CspParameters creato
e settare a true la proprietà PersistKeyInCsp dell'istanza del RSACryptoServiceProvider

Vista l'ora vado a dormire ...la prossima volta vedremo qualcosa sul data padding

[70-340] Strong Name e GAC

Rosalba Fiore — Wed, 09 May 2007 10:11:00 GMT

Sospendendo un attimo la CAS, affrontiamo insieme il discorso dello strong name e dalla GAC.

Io ho un nome ed un cognome così anche i nostri assembly, anzi loro hanno molte più informazioni oltre il nome hanno:

la versione
la cultura
public key
digital signature

Tutto questo torna utile anche dal punto della sicurezza e capiremo dopo il perchè. Prima di tutto come gli diamo la public key e la digital signature? Semplice a dirsi sn.exe (strong name tool). Ed a farsi?

Ma ancor prima dove si trova:

C:\Programmi\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin

Passaggi:

generiamo l'snk: dal prompt dei comandi di VS.Net 2003 per creare un file .snk dobbiamo di nome "chiavi.snk"

scrivere sn -k chiavi.snk

viene generato e salvato nella directory corrente

associamolo alla nostra .dll: questo lo facciamo nell'Assembly.Info

[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile(@"..\..\chiave.snk")]

verifichiamo che abbiamo fatto bene:

scrivere sn -v "C:\IlPercorso\Esempio.dll"

Se ci restituisce una cosa del genere utilità nome sicuro di Microsoft vuol dire che abbiamo fatto bene, altrimenti :)

Ora ditemi voi una volta che ho assegnato tutte queste cose è più difficile utilizzare in modo improprio o "impersonare" il nostro assembly? Direi proprio di sì.

I parametri del tool sn sono tutti qui

Vediamo ora qualcosa sulla GAC (Global Assembly Cache)...

Nel bene e nel male una delle cose che a seconda dei casi può essere considerata un beno o un male è l'AVANTI AVANTI ossia wizard etc. Certo automatizzare l'installazione delle nostre soluzioni è una gran bella comodità delle applicazioni create col .NET framework ma se il nostro scopo è quello di lavorare in sicurezza? Meglio utilizzare la GAC che sta lì proprio per questo. Se installiamo un assembly in esso più applicazioni possono utilizzarlo. Immaginiamo domani di fare una release di update? E' più comodo modificare UNA cosa in UN posto SOLO che cambiare lo stesso assembly in tutte le cartelle. Bello, bellissimo ma vediamo come si procede.

Allora i metodi sono:

automaticamente :
- windows installer
- chiamando direttamente le APIs
- da linea di comando utilizzando un batch file ed la GacUtil
manualmente:
- col .Net Framework Configuration tool
- da linea di comando
- windows explorer

Windows Explorer

Vista l'ora vediamo prima come si fa con la windows explorer: basta aprire una cartella o windows explorer e nella barra dell'indirizzo %windir%\assembly e grazie a SHFusion.dll vediamo tutti i nostri assembly che risiedono nella GAC.. ed ora? Un bel copia ed incolla del nostro assembly :)

Complichiamo un pò le cose ed utilizziamo il Configuration tool

Configuration Tool

E' lo stesso di cui parlavo ieri dunque ricordiamo Start-Pannello di Controllo- Strumenti d'amministrazione - .Net Configuration1.1

tasto destro su Cache Assembly ed aggiungiamo il nostro assembly

Per gli altri magari domani... continuo a studiare ma non penso di riuscire a postare prima delle 24.. dunque a domani :)

Ps. Maggiori informazioni sull'esame 70-340: Implementing Security for Applications with Microsoft Visual C# .NET qui

[70-340] Questo sì e questo no con la CAS

Rosalba Fiore — Wed, 09 May 2007 06:56:00 GMT

Oggi pomeriggio lo dedico tutto alla preparazione dell'esame quindi mano mano posto un pò di cose.

Allora ritorniamo alla CAS Declarations... ok ma che scriviamo?

Ad esempio in C#

[assembly:RegistryPermission(SecurityAction.RequestMinumun,Read=@"HKEY_LOCAL_MACHINE\Software")]

[assembly:FileIOPermissionAttibute(SecurityAction.RequestMinimun Read=@"C:\boot.ini")]

In sostanza i tipi di permessi dichiarativi degli assembly sono:

SecurityAction.RequestMinimun (permessi che deve soddisfare per l'esecuzione se il nostro assembly non soddisfa questi viene lanciata un'eccezione)
SecurityAction.RequestOptional (non abbiamo eccezione)
SecurityAcrion.RequestRefuse (non abbiamo eccezione)

Vediamo un modo carino di utilizzare la SecurityAction

[FileIOPermission(SecurityAction.Deny,All=@"C:\PostdiUgi\")]
[WebPermission(SecurityAction.PermitOnly, ConnectPattern=@"http://www\.postdiugi\.it/.*)]

Secondo voi che succederà?

Comunque tutto questo è statico e se volessimo generare qualcosa dinamicamente come ad esempio l'indirizzo web? Occorre ritornare alle Imperatively Limit Permissios?

Quindi la seconda diventa

Regex connectPattern=new Regex(@"http://www\.postdiugi\.it/.*);

WebPermission webPerm=new WebPermission(NetworkAccess.Connect,connectPattern);

webPerm.PermitOnly();

...

A più tardi!

[70-340] CAS e la pagina 5 di Google

Rosalba Fiore — Mon, 07 May 2007 06:00:00 GMT

Ripassando per l'esame ho provato a fare una piccola ricerca su Google, inserisco la parola CAS e mi è toccato spulciare fino a pagina 5 per iniziare a vedere qualche cosa d'attinente per il resto club alpini, società di costruzioni etc. ovviamente totalmente differente il risultato se inserisco Code Access Security.

L'argomento è talmente interessante che merita un post e dunque.. vediamo cosa posso aggiungere dopo le slide di Santini e Rialdi che per fortuna sono ancora disponibili per il download.

Prima d'attentrarci nei meandri dell'argomento in un mio vecchio post indicavo un articolo su msdn che spiegava il perchè è saggio utilizzare i privilegi minimi.

Quando vogliamo restringere la pericolisità del "danno" di un'applicazione i principali strumenti sono l'utilizzo sapiente della RBS e la CAS. Se per il codice unmanaged la scelta obbligata è la prima per il codice manged utilizzando sapientemente la CAS è possibile granulare correttamente cosa il nostro codice può fare ma anche cosa l'utente può fargli fare.

Il meccanismo utilizzato è quello dell"evidence" ossia un set d'informazioni che identificano con tutta una serie d'informazioni un assembly. Le informazioni spaziano dalla directory nella quale esso si trova (application directory), strong name, all'hash queste ed altre informazioni sono membri della System.Security.Policy. Comunque le evidence sono di due tipi le host (es. origine:directory, Url o sito) e le assembly, queste ultime sono del tipo customer user o definite dal developer. Sulle slide che ho ricordato prima trovate riferimenti alla code group ed ai permessi.

Ci potremmo chiedere se la CAS sostituisce l'operating system securitity? La risposta è NO essa si pone come uno strato su di essa, dunque è un complemento e non un suo sostituto.

Ok, tutto questo è bello ma come faccio a sapere se un assembly è attendibile e come si configurano i permessi? Sempre utilizzando .Net Configuration tool si utilizza il nodo CRITERI DI PROTEZIONE RUNTIME

Valutare l'assembly: facciamo clic col tasto destro su di esso e scegliamo Valuta Assembly seguendo passo passo il wizard vedremo i permessi che esso ha;
Nuovi permessi ed assegnazione: E per aggiungerne? Prima cosa dobbiamo decidere a che livello vogliamo impostarli enterprise, computer, user (il primo si applica a tutta la rete, il secondo a tutte le applicazioni sul PC, il secondo all'utente singolo) Es. presi da mania di grandezza supponiamo di voler creare un nuovo set di permessi che porta il nostro nome per tutta la rete, quindi scegliamo il nodo Enterprise e poi Set di Autorizzazioni, seguendo passo passo la procedura impostiamo prima il nome del set in questo caso "Autorizzazioni di Rosalba" e poi che tipo di autorizzazione dobbiamo dare (dns, internet, contatore di prestazioni, stampa in corso etc etc) e per ciascuna le proprietà. Al termine vedremo sotto le altre (Full Trust, Execution etc) anche quella che abbiamo appena creato. A questo punto come l'assegniamo? Sempre nel nodo Enterprise scegliamo Gruppi di Codice, All Code dunque tasto destro e poi Nuovo, dunque creiamo un nuovo gruppo di codice e specifichiamo il tipo di condizione per il gruppo di codice (le evidence dette prima ed anche un livello personalizzato mediante XML da scrivere o da importare) dunque gli assegniamo il set di autorizzazioni dunque "Autorizzazioni di Rosalba" e poi fine. Ora mi ridimensiono pure io!

Questa è la strada facile se vogliamo/dobbiamo utilizzare caspol.exe i parametri sono effettivamente un pò tanti da postare dunque vi rimando a questo in italiano di MSDN

Piccola nota fino ad ora ho utilizzato solo Windows XP PRO, dunque le prove le potete fare tranquillamente anche se non avete Windows Server 2003.

Ma se poi ciò che è previsto dalla CAS non permette alla nostra applicazione? In questo caso ricorriamo alla CAS Assmbly Declarations.

Le ragioni:

gli amministratori utilizzando il tool Permview possono analizzare i permessi che l'assembly richiede, dunque grazie ai metadati può risparmiarsi di leggere pagine e pagine della documentazione che accompagna la nostra applicazione
le risorse utlizzare saranno solo quelle che la nostra applicazione ha il permesso di utilizzare, e l'amministratore capirà dall'eccezione lanciata che cosa è successo sempre che ci siamo ricordati di utilizzare la SecurityAction.RequestMinimum
un attacco alla nostra applicazione non provoca grossi danni essendo essa in una piccola sandbox
sappiamo esattamente i permessi che essa richiede poichè ogni volta che dobbiamo aggiungere una doppiamo dichiararla con SecurityAction.RequestOptional altrimenti viene trovata un'eccezione di tipo System.Security.Policy.PolicyException.

Il resto...magari la prossima volta oggi è domenica mi un pò di riposo.