Security

Limitare le info che si danno all'utente in caso di errore

Gian Maria Ricci — Mon, 25 Aug 2008 15:57:55 GMT

Ho trovato un link: http://www.stupidcubicle.com/ dovrebbe contenere materiale per geek :), il problema è che quando ci vado trovo questo Ok, è vero che da queste informazioni non si ricava nulla, ma fare vedere gli spezzoni di codice a tutti è un bug di sicurezza. L'utente non sviluppatore dovrebbe vedere una semplice pagina di scuse tipo "Sorry, the application has encountered an error", loggare l'errore tipo con elmah, e non far vedere a nessuno il codice che c'è dietro. A livello di security dare un messaggio di errore cosi dettagliato è una cattiva pratica. alk.

Mamma mia quanto odio queste cose

Gian Maria Ricci — Tue, 27 Nov 2007 13:48:07 GMT

Debbo usare un programma che gestisce un hardware, il fornitore da un tool ma peccato che dica questo We are happy to inform that ***** works normally under Windows Vista, however, the UAC (User Access Control) will need to be disabled. A new version will be released later on, which will work under Windows Vista with UAC enabled. Perchè debbono essere felici??? Debbo disabilitare la UAC per poter lavorare con il loro prodotto??? Ma la sicurezza cosa è un opzione?? Sono felici di dirmi che ora posso lavorare con il loro prodotto al costo di un sistema più insicuro..mamma mia..... Alk.

Login sicura

Gian Maria Ricci — Sat, 27 Oct 2007 09:43:44 GMT

In un precedente post ho parlato di come cifrare una stringa in javascript con RSA ora è arrivato il momento di mostrare un utilizzo pratico di questa tecnica. Il controllo login standard di asp.net 2.0 è infatti poco sicuro perché spedisce la password dell'utente in chiaro e quindi dovrebbe essere sempre utilizzato in contesto https. Purtroppo per hosting a "poco prezzo" ma in generale se non si ha a disposizione https, sarebbe comunque doveroso non far girare per la rete le credenziali dell'utente in chiaro. Per fare questo si procede in questo modo, ecco come si presenta la pagina di login. <script language="javascript" src="RSA/BigInt.js" type="text/javascript"></script> <script language="javascript" src="RSA/Barrett.js" type="text/javascript"></script> <script language="javascript" src="RSA/RSA.js" type="text/javascript"></script> <script language="javascript" type="text/javascript"> function EncryptPassword() { var EncExponent = document.getElementById("encryptionExponent").value; var DecExponent = ""; var EncModulus= document.getElementById("modulus").value; setMaxDigits(130); key = new RSAKeyPair(EncExponent, DecExponent, EncModulus); document.getElementById("EncryptedPassword").value = encryptedString(key, document.getElementById("Login1$Password").value); document.getElementById("Login1$Password").value = "*********"; } </script>... <asp:Login ID="Login1" runat="server" OnAuthenticate="OnLoggingIn" OnLoggedIn="OnLoggedIn"> </asp:Login> <asp:HiddenField ID="encryptionExponent" runat="server" /> <asp:HiddenField ID="modulus" runat="server" /> <asp:HiddenField ID="EncryptedPassword" runat="server" /> Come si può vedere si importano i file js che implementano l'algoritmo RSA, poi si crea una semplice funzione che genera una nuova chiave crittografica dalla chiave pubblica mantenuta negli hiddenfield encryptionExponent e modulus, con questa chiave pubblica si può cifrare il contenuto della textbox password, e sostituire al suo contenuto una bella serie di asterischi, la password cifrata viene invece messa in un hiddenfield chiamato EncryptedPassword. Il code behind è altrettanto semplice e può essere consultato nell'esempio accluso. Nell'evento load viene generato un nuovo RsaCryptoServiceProvider, esportata la sua parte pubblica, inserita negli appositi ridde field ed infine messo in sessione if (!IsPostBack) { RSACryptoServiceProvider provider = new RSACryptoServiceProvider(); RSAParameters publicKey = provider.ExportParameters(true); encryptionExponent.Value = BitConverter.ToString(publicKey.Exponent).Replace("-", ""); modulus.Value = BitConverter.ToString(publicKey.Modulus).Replace("-", ""); Session["key"] = provider; } L'altro evento degno di nota è invece l'OnLoggingIn del controllo login, dove bisogna fare la decrittazione della password e l'autenticazione. public void OnLoggingIn(Object sender, AuthenticateEventArgs e) { TextBox userTextBox = (TextBox) Login1.FindControl("UserName"); String password = DecryptPassword(); e.Authenticated = Membership.ValidateUser(userTextBox.Text, password);} Come si può vedere non si fa altro che decrittare e delegare il tutto alla ValidateUser della membership, il gioco è cosi fatto. Alk. (Scarica l'esempio)

Controllare prima di fare :D

Gian Maria Ricci — Wed, 24 Oct 2007 09:13:10 GMT

Se vi interessa cifrare stringhe da Javascript in RSA da passare al codice lato server questo posto potrà esservi utile. (Clicca per leggere)

Alk.

L’avvento

Gian Maria Ricci — Thu, 18 Oct 2007 08:53:15 GMT

Il mondo è veramente cambiato, egli verrà su un debugger di fuoco e brucerà i bug con i suoi infiniti poteri, nessun buco di sicurezza potrà tollerare il suo sguardo. Egli ha creato il mondo dall'assembly e nel momento del giudizio i giusti cammineranno assieme a lui verso il Codice promesso. Alk.

Validare gli input dell’utente seconda parte

Gian Maria Ricci — Wed, 10 Oct 2007 15:03:50 GMT

Seconda parte del post su come validare gli input dell'utente. In questa parte si mostra come utilizzare Castle.Winsor per gestire il file di configurazione dove memorizzare le regole di validazione. Alk.

Validare sempre gli input dell’utente

Gian Maria Ricci — Tue, 09 Oct 2007 09:55:44 GMT

In questi giorni mi sto dilettando un po di sicurezza, ieri ho postato un tip su come cifrare la querystring, oggi volevo postare una semplice tecnica per fare validazione custom dei parametri in querystring e post. La tecnica non è nulla di eccezionale, ma può essere interessante. (clicca per leggere) Alk.