Sicurezza Web Publishing .
Nr. 35

19/02/2009
Sicurezza Web Publishing.

Supponiamo di dover mettere su web un'applicazione. Esistono molti modi per poterlo fare e ovviamente la scelta dipende da vari fattori quali ad esempio:

  • Tipo di dati
  • Tipo di applicazione
  • Operatività Richiesta
  • Ambito di utilizzo
  • Budget
  • Attrezzature già presenti e/o da acquistare

Fattori che a loro volta possono non essere definiti in modo così puntuale ma caratterizzati da incertezza (es. come si fa a stimare il livello di sicurezza di una applicazione : Ok le password e la loro crittografia, ma che resistenza può avere ad attacchi o usi impropri?).

In questo documento ho cercato di riportare i principi che sono propri di alcune delle soluzioni più comunemente adottate per pubblicazioni su web in ambito intranet ed internet : divisione application server - db server, reverse proxy, duplicazioni Inside/Dmz etc...

E' ovvio che queste sono solo delle linee guida che per essere efficaci devono essere contestualizzate al caso particolare. Riguardo a quest aspetto c'è da dire che se evidentemente l'hardening di un Apache è diverso dal quello di un IIS o di un Oracle valgono pressochè per qualunque software alcuni principi di base. Ovvero, premesso il fatto che particolari aggionamenti risolvono particolari bug (ma qui si deve sapere già quali bug combattere e a priori ciò è ovviamente complicato) criteri che valgono praticamente sempre per la messa in sicurezza di un sistema sono questi:

  • Far girare il processo con un utente con diritti minimi (mai root o administrator, comunque!);
  • Dare all'utente in questione il minimo di permessi a livello di filesystem sulle cartelle su cui opera (se non può eseguire programmi o salvare files i danni saranno limitati anche se sfruttando un exploit accede al filesystem);
  • Ridurre al minimo i banner passati (es. clausola ServerToken in Apache);
  • Utilizzare il passaggio dati in chiaro solo per contesti intranet. Utilizzare la crittografia solo quando effettivamente serve;
  • Loggare quanto più possibile e archiviare i log (attenzione anche agli aspetti di privacy);

Il documento è alla prima versione quindi non escludo ampliamenti e/o aggiornamenti nei prossimi post.

Questo sito è ottimizzato per la risoluzione 1024x768, testato su Internet Explorer 6 e Mozzilla Firefox 2.