Scribd
Carica
98 visualizzazioni30 pagine

24 Deadly Sins of Software Security Programming Flaws and How To Fix Them (091 120) .En - It

Il documento descrive diverse vulnerabilità legate alla sicurezza del software come XSS, XSRF e response splitting. Vengono forniti esempi di codice per prevenire queste vulnerabilità in diversi linguaggi di programmazione tra cui PHP, Perl, ASP.NET e Ruby on Rails.

Caricato da

antonello laudato
Copyright
© © All Rights Reserved
Per noi i diritti sui contenuti sono una cosa seria. Se sospetti che questo contenuto sia tuo, rivendicalo qui.
Formati disponibili
Scarica in formato PDF, TXT o leggi online su Scribd
98 visualizzazioni30 pagine

24 Deadly Sins of Software Security Programming Flaws and How To Fix Them (091 120) .En - It

Il documento descrive diverse vulnerabilità legate alla sicurezza del software come XSS, XSRF e response splitting. Vengono forniti esempi di codice per prevenire queste vulnerabilità in diversi linguaggi di programmazione tra cui PHP, Perl, ASP.NET e Ruby on Rails.

Caricato da

antonello laudato
Copyright
© © All Rights Reserved
Per noi i diritti sui contenuti sono una cosa seria. Se sospetti che questo contenuto sia tuo, rivendicalo qui.
Formati disponibili
Scarica in formato PDF, TXT o leggi online su Scribd
Sei sulla pagina 1/ 30

Tradotto dal Inglese al Italiano - www.onlinedoctranslator.

com

52 24 peccati capitali della sicurezza del software

Restituisci EVAL_BODY_INCLUDE;
}
} altro {
restituisce EVAL_BODY_INCLUDE;
}
}

// *Incredibilmente* JSP non ha una funzione di codifica


HTML public static String codifica(String str) {
se (str == nullo)
restituire nullo;

StringBuffer s = new StringBuffer(); for (short i = 0; i <


str.length(); i++) {
char c = str.charAt(i); cambia
(c) {
caso '<':
s.append("<");break;
caso '>':
s.append(">");break;
caso '(':
s.append("(");break;
caso ')':
s.append(")");break;
caso '#':
s.append("#");break;
caso '&':
s.append("&");break;
caso '"':
s.append(""");break;
caso '\'':
s.append("'");break;
caso '%':
s.append("%");break;
caso '+':
s.append("+");break;
caso '-':
s.append("-");break;
predefinito:
s.append(c);
}
}
return s.toString();
}
}
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 53

E infine, ecco alcuni JSP di esempio che richiamano il codice del tag appena definito:

<%@ taglib uri="/tags/htmlencoder" prefix="htmlencoder"%> <head>

<title>Attenti, peccatori...</title> </head>

<html>
<body bgcolor="bianco">
<htmlencoder:htmlencode><script
type="javascript">BadStuff()</script></htmlencoder:htmlencode>
<htmlencoder:htmlencode>testin</htmlencoder:htmlencode> <script
type="badStuffNotWrapped()"></script>
</corpo>
</html>

Rimborso PHP (XSS)


Proprio come negli esempi precedenti, stai applicando entrambi i rimedi, controllando la validità e
quindi codificando in HTML l'output usando htmlentities():

<?php
$nome=$_GET['nome'];
if (asset($nome)) {
if (preg_match('/^\w{5,25}$/',$nome)) {
echo "Ciao, " . htmlentities($nome); } altro {

echo "Vattene!";
}
}
?>

Redenzione CGI (XSS)


Questa è la stessa idea degli esempi di codice precedenti: limitare l'input utilizzando
un'espressione regolare, quindi codificare in HTML l'output.

# !/usr/bin/perl
usa CGI;
usa HTML::Entità;
usare rigoroso;

my $cgi = nuovo CGI; print


CGI::header();
my $nome = $cgi->param('nome');
54 24 peccati capitali della sicurezza del software

if ($nome =~ /^\w{5,25}$/) {
print "Ciao, " . HTML::Entità::codifica($nome); } altro {

print "Vattene!";
}

Se non vuoi caricare, o non puoi caricare, HTML::Entites, puoi usare il seguente codice
per ottenere lo stesso risultato:

sub html_encode
mio $in = turno;
$in =~ s/&/&/g;
$in =~ s/</</g;
$in =~ s/>/>/g;
$in =~ s/\"/"/g;
$in =~ s/#/#/g;
$in =~ s/\(/(/g;
$in =~ s/\)/)/g;
$in =~ s/\'/'/g;
$in =~ s/\%/%/g;
$in =~ s/\+/+/g;
$in =~ s/\-/-/g;
ritorna $in;
}

mod_perl Redenzione (XSS)


Come tutto il codice precedente, questo esempio verifica che l'input sia valido e ben formato e, in caso
affermativo, codifica l'output.

# !/usr/bin/perl
usa Apache::Util;
usa Apache::Request;
usare rigoroso;
my $apr = Apache::Request->new(Apache->request); mio $nome
= $apr->param('nome');
$apr->content_type('text/html'); $apr-
>send_http_header;
if ($nome =~ /^\w{5,25}$/) {
$apr->print("Ciao, " . Apache::Util::html_encode($name)); } altro {

$apr->print("Vattene!");
}
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 55

FASI DI RISCATTO (XSRF)


Per il riscatto XSRF dovresti

1. Aggiungere un valore segreto alla sessione del client Web e del server Web; questo valore non
dovrebbe essere incluso nel cookie.

2. Aggiungere un timeout alla sessione.

3. Come meccanismo di difesa in profondità, utilizzare POST anziché GET.

Questo è il motivo per cui l'aggiunta di un timeout è importante, in quanto chiude la finestra di opportunità
dell'attaccante.
È interessante notare che questo è un tipo di vulnerabilità della sicurezza in cui la convalida dell'input non
aiuta perché tutto l'inputÈvalido. Inoltre, un bug XSS in qualsiasi punto del sito Web consentirà di aggirare
qualsiasi mitigazione XSRF.

Una nota sui timeout


È necessario aggiungere un timeout alla sessione per ridurre la finestra di opportunità dell'aggressore. Puoi
farlo impostando un timeout per il cookie o, in una sessione totalmente stateless, memorizzando un timeout
per il cookie o per i dati del modulo. È importante che i dati di timeout siano protetti utilizzando un codice di
autenticazione del messaggio (MAC); in caso contrario, un utente malintenzionato potrebbe essere in grado di
estendere il periodo di timeout.
Il codice C# seguente mostra come creare una funzione che genera la data e l'ora di scadenza e
aggiunge un MAC alla stringa risultante. Questa stringa potrebbe quindi essere aggiunta a un campo
nascosto.

stringa statica GetTimeOut(int min) {


DateTime timeout = DateTime.Now.AddMinutes(mins);
HMACSHA256 hmac = nuovo HMACSHA256(_key);
String mac = Convert.ToBase64String(
hmac.ComputeHash(
Encoding.UTF8.GetBytes(timeout.ToString())));
return "Timeout=" + timeout.ToUniversalTime() + "; " + mac;
}

Si noti che l'ora è rappresentata come ora UTC anziché come ora locale; questo renderà neutrale il
fuso orario del tuo codice. Infine, la chiave MAC, _key, è una variabile globale generata all'avvio
dell'applicazione.

Una nota su XSRF e POST rispetto a GET


È pratica comune mitigare le vulnerabilità XSRF utilizzando le richieste POST, che inseriscono i dati del
campo nel corpo HTML, piuttosto che le richieste GET, che inseriscono i dati del campo in una stringa di
query. L'uso di POST è comune perché in RFC 2616 il W3C stabilisce che i GET dovrebbero essere usati
solo per operazioni di lettura che non cambiano stato sul server back-end, in
56 24 peccati capitali della sicurezza del software

in altre parole, richieste idempotenti. Le richieste che modificano lo stato, ad esempio un'operazione che potrebbe
creare, aggiornare o eliminare dati, devono utilizzare un POST.
L'utilizzo di POST anziché GET può aiutare contro gli attacchi che utilizzano exploit in stile <img
src=xxx>, ma l'utilizzo di POST non interrompe l'attacco. Un utente malintenzionato può semplicemente
utilizzare un modulo HTML con JavaScript per montare l'attacco:

<form action="http://example.com/delete.php" method="post" name="nuke">


<input type="hidden" name="scelta" value="Elimina" /> </form>

<copione>
document.nuke.submit(); </
script>

Riscatto Ruby on Rails (XSRF)


Ruby on Rails rende anche molto facile aggiungere un valore segreto a una sessione HTTP:

class ApplicationController < ActionController::Base


protect_from_forgery :secret => generate_secret
FINE

Riscatto di Web Form ASP.NET (XSRF)


Il codice seguente mostra come associare una variabile di sessione casuale per contrastare gli attacchi
XSRF. Nota che la variabile è univoca per sessione per utente. Se vuoi davvero diventare hardcore, puoi
anche associare un timeout alle informazioni sulla sessione.

classe parziale pubblica _Default: System.Web.UI.Page {

protetto RNGCryptoServiceProvider _rng =


nuovo RNGCryptoServiceProvider();

protected void Page_Load(oggetto mittente, EventArgs e) {

lblUpdate.Text = "Impossibile effettuare l'ordine."; if


(Richiesta["elemento"] != null && Richiesta["qty"] != null) {

if (Richiesta["secToken"] != null &&


Session["secToken"] != null && Session["secToken"] ==
Richiesta["secToken"])
{
// Operazioni sul database ecc. per effettuare l'ordine
lblUpdate.Text = "Grazie per il tuo ordine.";
}
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 57

byte[] b = nuovo byte[32];


_rng.GetBytes(b);
secToken.Value = Convert.ToBase64String(b);
Session["secToken"] = secToken.Value;
}
}

Uso non draconiano della codifica HTML


La semplice codifica HTML di tutto l'output è un po' draconiana per alcuni siti web, perché alcuni
tag, come <i> e <b>, sono innocui. Per stemperare un po' le cose, considera la decodifica di
costrutti sicuri noti. Il seguente codice C# mostra un esempio di ciò che intendiamo, in quanto
"decodifica HTML" tag in corsivo, grassetto, paragrafo, enfasi e intestazione. Ma tieni presente
che l'espressione regolare è molto rigida e consente solo tag del seguente stile:

- Galletto di apertura

- Valori lunghi uno o due caratteri


- Galletto di chiusura

La ragione di ciò è che se consentiamo qualsiasi tag in grassetto (<b>), ad esempio, un utente malintenzionato
potrebbe essere in grado di aggiungere eventi onmouseover=nastyscript e chiaramente non lo vogliamo.

stringa r = Regex.Replace(s,
@"<(/?)(i|b|p|em|h\d{1})>", "<$1$2>",

RegexOptions.IgnoreCase);

Se utilizzi questo tipo di codice, è importante che tu imposti anche una code page, perché i
caratteri “<” e “>” potrebbero non essere validi in alcune code page.

MISURE EXTRA DIFENSIVE


È possibile aggiungere molti altri meccanismi difensivi al codice dell'applicazione del server Web nel
caso in cui si perda un bug XSS. Includono quanto segue:

Utilizza i cookie HttpOnly


Questo aiuta a proteggere alcuni clienti perché un cookie contrassegnato in questo modo non
può essere letto dal client utilizzando document.cookie. Diciamo "alcuni clienti" perché non tutti i
browser lo supportano oggi; le versioni attuali di Microsoft Internet Explorer e Firefox
supportano HttpOnly, ma Apple Safari no.
58 24 peccati capitali della sicurezza del software

Fare riferimento alla sezione "Altre risorse" alla fine di questo capitolo per ulteriori
informazioni. Puoi impostarlo in Visual Basic e ASP.NET con questa sintassi:

Dim cookie As New HttpCookie("LastVisit", DateTime.Now.ToString()) cookie.HttpOnly =


True
cookie.Name = "Roba"
Risposta.AppendCookie(cookie)

oppure, in ASP.NET usando C#:

HttpCookie cookie = new HttpCookie("LastVisit",


DateTime.Now.ToString());
cookie.HttpOnly = vero; cookie.Name =
"MyHttpOnlyCookie";
cookie.AppendCookie(myHttpOnlyCookie);

In JSP, puoi codificare in questo modo:

Cookie c = new Cookie("MyCookie","value; HttpOnly");


risposta.addCookie(c);

oppure, in PHP 5.2.0 e versioni successive:

sessione.cookie_httponly=1

O
setcookie("myCookie", $data, 0, "/", "www.example.com", 1, 1);

Avvolgi le proprietà dei tag con virgolette doppie


Piuttosto che usare <img src=qualcheinput>,usa <img src="qualcheinput">.Questo aiuta a sventare
alcuni attacchi che possono aggirare la codifica HTML.

Prendi in considerazione l'utilizzo di ASP.NET ViewStateUserKey


Impostazione delViewStateUserKeyLa proprietà può aiutare a prevenire il successo degli attacchi XSRF.
ViewStateUserKeyconsente di assegnare un identificatore alla variabile view-state per i singoli utenti in
modo che non possano utilizzare la variabile per generare un attacco. È possibile impostare questa
proprietà su qualsiasi valore di stringa, ad esempio un numero casuale durante l'applicazione
Pagina_Initfase:

override protetto OnInit(EventArgs e) {


base.OnInit(e);
byte[] b = nuovo byte[31];
nuovo RNGCryptoServiceProvider().GetBytes(b);
ViewStateUserKey = Convert.ToBase64String(b);
}
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 59

ViewStateUserKeynon è perfetto e dovrebbe essere considerato solo una tecnica di


difesa approfondita e non sostituisce un'applicazione mal progettata.

Prendi in considerazione l'utilizzo di ASP.NET ValidateRequest


Se usi ASP.NET, prendi in considerazione l'utilizzo diConvalidaRichiestaopzione di configurazione. È
abilitato per impostazione predefinita, ma ricontrolla se lo stai utilizzando. Questa opzione falliràAlcuni
richieste e risposte che contengono caratteri potenzialmente pericolosi. Tuttavia,ConvalidaRichiesta
non è affatto sicuro e non dovrebbe essere considerato affidabile, soprattutto quando vengono
scoperte nuove tecniche di offuscamento XSS. Se viene rilevato un problema da ASP.NET, il motore
genererà le seguenti informazioni sull'eccezione:

Dettagli eccezione: System.Web.HttpRequestValidationException: è stato rilevato un valore


Request.Form potenzialmente pericoloso dal client
(txtName="<script%00>avviso(1);...").
Descrizione: la convalida della richiesta ha rilevato un valore di input del client potenzialmente
pericoloso e l'elaborazione della richiesta è stata interrotta. Questo valore può indicare un
tentativo di compromettere la sicurezza dell'applicazione, ad esempio un attacco di scripting tra
siti. È possibile disabilitare la convalida della richiesta impostando validateRequest=false nella
direttiva Page o nella sezione di configurazione. Tuttavia, in questo caso si consiglia vivamente
che l'applicazione controlli esplicitamente tutti gli input.

Utilizzare la sicurezza del motore di runtime di sicurezza ASP.NET


Microsoft ha anche rilasciato uno strumento denominato Security Runtime Engine che codificherà
automaticamente l'output da oggetti ASP.NET come System.Web.UI.WebControls . Etichetta senza
modifiche al codice. Ulteriori informazioni sullo strumento sono disponibili all'indirizzo http://
blogs.msdn.com/securitytools.

Prendi in considerazione l'utilizzo di OWASP CSRFGuard


Le applicazioni Web basate su Java, come i servlet, dovrebbero esaminare il progetto CSRFGuard di
OWASP.

Usa Apache::TaintRequest
Il mod_perl di Apache offre Apache::TaintRequest per aiutare a rilevare quando l'input diventa output
senza essere prima convalidato. Fare riferimento alla sezione "Altre risorse" in questo capitolo per
ulteriori informazioni.

Usa UrlScan
UrlScan di Microsoft per Internet Information Server 5.0 consente di rilevare e rifiutare molte
classi di vulnerabilità XSS nel codice dell'applicazione Web.
60 24 peccati capitali della sicurezza del software

UrlScan non è necessario con Internet Information Server 6.0 e versioni successive (IIS) poiché IIS dispone di
funzionalità simili integrate. Per ulteriori informazioni, consultare la sezione "Altre risorse" in questo capitolo.

Imposta un set di caratteri predefinito


Imposta un set di caratteri per le tue pagine Web per aiutare a ridurre i tipi di fughe e trucchi di
canonizzazione disponibili per gli aggressori. È possibile impostare il set di caratteri per una pagina
Web, indipendentemente dall'ambiente di programmazione del server Web, aggiungendo questo
all'inizio delle pagine Web:

<meta http-equiv="Tipo di contenuto" content="text/html; charset=ISO-8859-1" />

ISO-8859-1, chiamato anche Latin-1, è una codifica di caratteri standard di 191 caratteri della
scrittura latina.
In ASP.NET puoi impostare globalmente la codepage per la tua applicazione web con quanto
segue:

<sistema.web>
<globalizzazione
requestEncoding="iso-8859-1"
responseEncoding="iso-8859-1"/> </
system.web>

Oppure per una singola pagina ASP.NET o un insieme di pagine, puoi utilizzare questo:

<%@ Pagina CodePage="28591"%>

In JSP, puoi usare una linea come questa nella parte superiore delle tue pagine web:

<%@ page contentType="text/html; charset=iso-8859-1"%>

ALTRE RISORSE
- “Segnalare vulnerabilità è per i coraggiosi”: http://
www.cerias.purdue.edu/site/blog/post/
reporting-vulnerabilities-is-for-the-brave/
- Common Weakness Enumeration (CWE) Software Assurance Metrics e valutazione degli
strumenti: http://cwe.mitre.org
- 2009 CWE/SANS Primi 25 errori di programmazione più pericolosi:
http://cwe.mitre.org/top25
- “Divide et impera: suddivisione della risposta HTTP, attacchi Web Cache
Poisoning e argomenti correlati”: www.securityfocus.com/archive/1/356293
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 61

- Progetto di sicurezza Ruby on Rails: http://www.rorsecurity.info/


- Scrittura di codice sicuro, seconda edizionedi Michael Howard e David C. LeBlanc (Microsoft
Press, 2002), capitolo 13, "Problemi di input specifici per il Web"

- Attenuazione degli script tra siti con cookie solo HTTP: http://
msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/
httponly_cookies.asp
- Convalida della richiesta: prevenzione degli attacchi di
script: www.asp.net/faq/requestvalidation.aspx

- mod_perl Apache::TaintRequest: www.modperlcookbook.org/code.html


- “Strumento di protezione UrlScan”: www.microsoft.com/technet/
security/tools/urlscan.mspx
- “Prevenire un attacco di scripting tra siti" di Anand K. Sharma:
www-106.ibm.com/developerworks/library/wa-secxss/ ?
ca=dgr-lnxw93PreventXSS
- “Ruba la cronologia del browser senza JavaScript”: http://ha.ckers.org/blog/20070228/
steal-browser-history-without-javascript/
- “Prevenzione degli attacchi di scripting cross-site” di Paul
Linder: www.perl.com/pub/a/2002/02/20/css.html
- “Avviso CERT CA-2000-02 Tag HTML dannosi incorporati nelle richieste Web del
client”: www.cert.org/advisories/CA-2000-02.html
- L'Open Web Application Security Project (OWASP): www.owasp.org
- “HTML Code Injection e Cross-Site Scripting” di Gunter Ollmann:
www.technicalinfo.net/papers/CSS.html
- Creazione di pagine e controlli ASP.NET sicuri: http://
msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/
html/THCMCh10.asp
- Comprensione della mitigazione dei contenuti dannosi per gli sviluppatori
Web: www.cert.org/tech_tips/malicious_code_mitigation.html

- Come prevenire i problemi di sicurezza degli script tra siti in CGI o ISAPI: http://
support.microsoft.com/default.aspx?scid=kb%3BEN-US%3BQ253165
- Come posso: prevenire un difetto di sicurezza di contraffazione di richieste tra siti in
un'applicazione ASP.NET? http://msdn.microsoft.com/en-us/security/bb977433.aspx

- “Falsificazioni di richieste cross-site: sfruttamento e prevenzione” di Zeller e


Felton: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
- Microsoft Anti-Cross Site Scripting Library V1.5: Protezione della pagina dei
segnalibri di Contoso: http://msdn.microsoft.com/en-us/library/aa973813.aspx
62 24 peccati capitali della sicurezza del software

- AntiXSS per Java: http://www.gdssecurity.com/l/b/2007/12/29/


antixss-for-java/
- XSS (Cross Site Scripting) Cheat Sheet Esp: per l'evasione del filtro:
http://ha.ckers.org/xss.html
- WebGoat e WebScarab: http://www.owasp.org/index.php/
Category:OWASP_Project
- Ricettario sui test di sicurezza Webdi Paco Hope e Ben Walther (O'Reilly, 2008)

RIEPILOGO
- Farecontrollare tutti gli input basati sul Web per verificarne la validità e l'affidabilità.

- Farecodificare tutto l'output originato dall'input dell'utente.

- Farecontrassegnare i cookie come HttpOnly

- Fareaggiungere timestamp o timeout alle sessioni soggette ad attacchi XSRF.


- Faretestare regolarmente i punti di ingresso dell'applicazione Web con input di script non validi e
con caratteri di escape per verificare la presenza di XSS e le relative vulnerabilità.

- Farestare al passo con le nuove vulnerabilità in stile XSS, poiché è un campo minato in continua
evoluzione.

- Nonfa eco all'input basato sul Web senza verificare prima la validità.
- Nonfare affidamento su elenchi "non consentiti" (ovvero blacklist o blocklist) come unica difesa.

- Nonmodificare lo stato del server con richieste GET.

- Nonmemorizzare i dati sensibili nei cookie.

- Nonaspettarsi che SSL/TLS aiuti a prevenire uno qualsiasi di questi peccati.

- Nonutilizzare le richieste GET per le operazioni che modificano i dati del server

- Prendere in considerazioneutilizzando quante più difese extra possibile.


3
Relativo al client Web
Vulnerabilità (XSS)

63
64 24 peccati capitali della sicurezza del software

PANORAMICA DEL PECCATO


L'avvento di gadget e widget desktop e web ha inaugurato un tipo di peccato più comune:
quello deltipo-0,Obasato su DOM,vulnerabilità di cross-site scripting. Si noti che abbiamo
detto "più comune" e non "nuovo"; questi peccati non sono nuovi, ma sono diventati più
comuni negli ultimi due anni.
Le due forme di codice più peccaminose che soffrono di XSS di tipo 0 sono

- Gadget e widget
- Pagine HTML statiche sul computer dell'utente

Un gadget o un widget non è altro che una mini-applicazione creata utilizzando


tecnologie web come HTML, JavaScript e XML.
Apple, Nokia e Yahoo! chiamare questi pezzi di codice widget (la piattaforma Yahoo!
Widgets era formalmente conosciuta come Konfabulator); Microsoft e Google li chiamano
gadget; e alcune versioni di Linux hanno anche funzionalità simili a gadget, come gDesklets
per GNOME e widget di KDE Dashboard e framework generici come SuperKaramba e
Screenlets. Ma quando tutto è stato detto e fatto, non sono altro che codice mobile che
viene eseguito nel tuo browser o sul tuo desktop.
Esiste una bozza di lavoro del W3C per i widget che utilizzano file zip per l'impacchettamento e file
XML per la configurazione; sembra seguire il formato del widget Apple.
D'ora in poi, chiameremo semplicemente questi mini-programmi "gadget".
Esempi di gadget includono

- Ticker di borsa

- Feed RSS
- Note adesive
- Informazioni di sistema

- Dati meteorologici

- Orologi

- Sveglie
- Mini giochi
- Risultati sportivi

- Strumenti di social networking

- Notifica via e-mail e messaggistica istantanea

- E molto, molto altro

Una bellezza dei gadget è che possono essere facilmente creati utilizzando le tecnologie attuali. Non sono
richieste abilità speciali. Ora pensaci per un momento. Siamo tutti favorevoli ad abbassare la barriera all'ingresso per
la scrittura di domande, ma ciò significa anche che le persone hanno poca o nessuna considerazione
Peccato 3: Vulnerabilità correlata al client Web (XSS) 65

per sicurezza puoi scrivere questo codice che si trova accanto alle tue altre applicazioni,
facendo chissà cosa! Una rapida occhiata ai siti Web di Microsoft, Yahoo!, Google e
Apple mostra decine di migliaia di gadget disponibili per Windows, Mac OS X e iPhone
e per i siti Web di Google, Yahoo e Windows Live. È un sacco di codice scritto
prevalentemente da dilettanti.
Nel caso di Windows Vista, questi gadget vengono visualizzati nella barra laterale. In
Windows 7 il processo Sidebar esiste ancora, ma non è visibile sullo schermo, quindi i gadget
appaiono essenzialmente ovunque sullo schermo. In Mac OS X, i widget vengono visualizzati
nella Dashboard.
Il problema fondamentale è che i gadget possono eseguire il rendering di input non attendibili che
potrebbero contenere codice, portando a vulnerabilità simili a una vulnerabilità XSS di tipo 1. La grande
differenza è piuttosto che commettere peccati mentre si chiama il codice del server Web, come
Response.Write, un gadget peccaminoso o una pagina HTML sul computer client utilizza in modo non sicuro
costrutti HTML Document Object Model (DOM), come document.location e document. scrivere, solo per
citarne alcuni.

RIFERIMENTI CWE
Le seguenti voci CWE (Common Weakness Enumeration), entrambe elencate nella
CWE/SANS Top 25 Most Dangerous Programming Errors, forniscono informazioni
dettagliate sulle vulnerabilità XSS-0:

- CWE-79: mancata sanificazione delle direttive in una pagina Web (ovvero "Cross-site
scripting" [XSS])

- CWE-94: Iniezione di codice

LINGUE INTERESSATE
Qualsiasi linguaggio di programmazione che può essere visualizzato in un browser è suscettibile a questi
peccati; inclusi JavaScript, Ruby e Python. La maggior parte delle pagine e dei gadget HTML sono scritti
utilizzando HTML con chiamate a JavaScript che potrebbero potenzialmente manipolare il Document Object
Model (DOM).

IL PECCATO SPIEGATO
Un tipo 0 o DOM XSS è un bug che consente a un utente malintenzionato di manipolare il DOM tramite
input non attendibile. Un esempio semplice e in qualche modo innocuo è un file HTML o un gadget che
esegue il rendering, magari chiamando document.innerHTML, il seguente script senza verificarlo
prima:

var liste=document.body.all.tags('A'); for(var


i=0;i<liste.lunghezza;i++)
{lists[i].href="http://www.example.com";}
66 24 peccati capitali della sicurezza del software

Questo codice attraversa il DOM per la pagina web o il gadget corrente e modifica ogni tag di
ancoraggio <a> in modo che punti a http://www.example.com.
Naturalmente, un vero exploit sarebbe un po' subdolo "codificando" l'URL; e ci sono
numerosi modi nefasti per codificare l'intero payload in modo che l'utente non abbia idea di
quale sia l'input.
Certo, è tutto divertimento e giochi, ma un attacco di questa natura potrebbe essere molto peggio; è
anche possibile iniettare codice nel DOM. Ad esempio, un utente malintenzionato potrebbe forzare la pagina
HTML o il gadget a eseguire il rendering di un file QuickTime o Flash non valido per l'esecuzione di codice
arbitrario. Questo non è diverso da un classico attacco "drive-by" basato sul Web in cui l'utente visita una
pagina Web che contiene un file malformato e dannoso. Fondamentalmente, i gadget che vengono eseguiti su
un desktop dovrebbero essere trattati come file eseguibili.
Ripetiamo quest'ultimo punto. I gadget possono avere lo stesso accesso a un computer
di un binario x86 completo e dovrebbero essere creati con la stessa cura di un'applicazione
binaria.
Se hai bisogno di più convincente, ecco un commento dal sito web di Apple:

Sfruttando le tecnologie di Mac OS X

Le funzionalità di HTML, CSS e JavaScript non definiscono l'intero spettro di ciò che è
possibile in un Widget. In realtà, segnano solo il punto di partenza. Da lì, puoi
accedere alle funzionalità approfondite di Mac OS X.

Comandi UNIX

Dall'oggetto widget è possibile accedere a qualsiasi comando o script UNIX, inclusi quelli
scritti in sh, tcsh, bash, tcl, Perl o Ruby nonché AppleScript. Questa capacità di attingere alla
riga di comando significa che è possibile accedere a un'incredibile quantità di potenza da
qualsiasi widget.

Ma questo non è esclusivo di Apple; molti ambienti di gadget includono framework di


supporto per fornire funzionalità extra; Per esempio:

- Windows Sidebar fornisce lo spazio dei nomi System.Sidebar.*.


- Google Desktop fornisce lo spazio dei nomi framework.system.*.
- Yahoo! I widget forniscono gli spazi dei nomi filesystem.* e system.*.
- gDesklets fornisce l'oggetto System.
- Nokia fornisce l'oggetto SystemInfo.
- Apple MAC OS X fornisce l'oggetto widget.system.

Ora immagina di poter sfruttare quelle "capacità profonde" tramite una vulnerabilità
XSS in un gadget!
Peccato 3: Vulnerabilità correlata al client Web (XSS) 67

Implicazioni sulla privacy dei gadget peccaminosi


I framework dei gadget spesso includono classi e metodi che forniscono l'accesso alle risorse di sistema in modo che i
gadget possano visualizzare dati come la potenza del segnale Wi-Fi, le statistiche del disco e molto altro. Di fronte a un
gadget peccaminoso, ciò potrebbe portare alla divulgazione di dati privati a un utente malintenzionato. Ad esempio,
Microsoft risolverà un bug di sicurezza in Internet Explorer che consentiva a un utente malintenzionato di
determinare se un determinato file esisteva sul disco rigido di un utente. Chiaramente, ciò significa che se un gadget
può essere utilizzato per determinare l'esistenza di un file, anche quel gadget ha un bug di sicurezza che deve essere
corretto.
Sebbene non sia ben noto, l'oggetto XMLHttpRequest, spesso utilizzato nei gadget e nelle
applicazioni AJAX, può leggere da file, non solo effettuare richieste HTTP; quindi questo oggetto può
leggere dal file system e inviare i risultati a un utente malintenzionato. Questa è una classica violazione
della privacy.
A peggiorare le cose, alcuni gadget che monitorano i siti Web online memorizzano la password di
un utente nei propri file di configurazione e non solo questi file si trovano in posizioni note con nomi
noti, ma leggono le informazioni sull'account utente in variabili JavaScript, che possono essere lette da
un attacco codice.

Peccaminoso JavaScript e HTML


Abbiamo scelto JavaScript e HTML perché la stragrande maggioranza delle pagine Web e dei gadget
peccaminosi sono scritti utilizzando queste due tecnologie.
Abbiamo ottenuto i seguenti esempi semplicemente scaricando gadget casuali e guardando il
codice sorgente. Proteggeremo l'identità del peccatore; ma questo dimostra semplicemente che la
maggior parte delle persone semplicemente non sa come creare gadget sicuri.
Il primo scrive semplicemente dati non attendibili (elementi del payload XML) in innerHTML:

funzione GetData(url){
se (XMLHttpRequest){
var xhr = nuovo XMLHttpRequest(); }altro{

var xhr = new ActiveXObject("MSXML2.XMLHTTP.3.0");


}
xhr.open("GET", url, true);
xhr.onreadystatechange = funzione(){
if (xhr.readyState == 4 && xhr.status == 200) {
se (xhr.responseXML){
xmlDoc = xhr.responseXML;
risultati.innerHTML = xmlDoc
. Primogenito
. Primogenito
. getElementsByTagName('item')[0]
68 24 peccati capitali della sicurezza del software

. figlioNodi[0]
. figlioNodi[0]
. nodoValore;
}
}
}
xhr.send(nullo);
}

INDIVIDUARE IL MODELLO DEL PECCATO


Una pagina HTML, un gadget o un widget che presenta il seguente pattern è a rischio di questo errore:

- Prende l'input da una fonte non attendibile, che in pratica significa qualsiasi cosa al di fuori
del Web e poi . . .

-... fa eco all'input.

INDIVIDUARE IL PECCATO DURANTE LA REVISIONE DEL CODICE


Praticamente tutti i peccati vengono commessi utilizzando JavaScript, quindi tutti gli esempi che seguono sono
per JavaScript indipendentemente dalla piattaforma. Come minimo, dovresti cercare i seguenti costrutti;
ognuno di questi che fa eco a input non attendibili dovrebbe essere considerato con disprezzo e massima
cautela. L'input può provenire da

- documento.url

- documento.posizione

- Web.Network.createRequest
- XMLHttpRequest

È normale accedere all'oggetto XMLHttpRequest tramite uno di questi due mezzi


comuni in JavaScript:

var req = new XMLHttpRequest();

O
var req = new ActiveXObject("Microsoft.XMLHTTP");

Dopo aver individuato questi punti di ingresso nella pagina HTML o nel gadget,
cerca i seguenti punti di uscita:
Peccato 3: Vulnerabilità correlata al client Web (XSS) 69

Parole chiave da cercare

* . innerHtml
* . html

document.write
* . insertAdjacentHTML
valuta()

tag <oggetto>
System.Sidebar.* in particolare System.Sidebar.Execute (Windows)
filesystem.* e sistema* (Yahoo!)
framework.system (Google)
widget.* (Nokia e Apple), in particolare widget.system. (Mela)
Informazioni di sistema (Nokia)

TECNICHE DI PROVA PER TROVARE IL PECCATO


Storicamente, gli strumenti di test che cercavano problemi XSS lo facevano solo per le applicazioni del
server Web piuttosto che per le installazioni client, rendendo questi strumenti inutili. Il modo migliore
per controllare i peccati XSS DOM è utilizzare un proxy che inserisce snippet XSS casuali nel flusso di
dati in entrata e vedere se i risultati vengono visualizzati dal gadget. Esempi di strumenti che possono
comportarsi come proxy man-in-the-middle includono Burp Proxy (portswigger.net).
I proxy sono utili, ma non esiste un modo infallibile per trovare questo tipo di bug se non
attraverso un'accurata revisione del codice.

ESEMPIO PECCATI
Le seguenti voci sul sito Web Common Vulnerabilities and Exposures (CVE) (http://
cve.mitre.org/) sono esempi di XSS e delle relative vulnerabilità.

Microsoft ISA Server XSS CVE-2003-0526


Questo errore nelle pagine di errore di Microsoft ISA Server è noto anche come MS03-028 da Microsoft. Il bug
è un classico XSS di tipo 0 nelle pagine HTML utilizzato per visualizzare vari messaggi di errore,
70 24 peccati capitali della sicurezza del software

come i messaggi 500 e 404. Se guardi attentamente il codice, DocURL contiene dati non
attendibili e questo finisce per trovare la strada per un document.write. Ops!

<COSCRIZIONE>

funzione Pagina iniziale(){


DocURL = documento.URL;
protocolIndex=DocURL.indexOf("://",4);
serverIndex=DocURL.indexOf("/",protocolIndex + 3);
BeginURL=DocURL.indexOf("#",1) + 1;
urlresult=DocURL.substring(BeginURL,serverIndex);
displayresult=DocURL.substring(protocolIndex + 3 ,serverIndex); document.write('<A
HREF="' +
urlresult + '">' + displayresult +
"</a>");
}
</SCRIPT>

Barra laterale di Windows Vista CVE-2007-3033 e CVE-2007-3032


Denominato MS07-048 da Microsoft, si trattava di un bug di cross-site scripting nel gadget dei titoli dei
feed RSS della barra laterale di Windows Vista e nel gadget dei contatti. Ecco uno snippet di codice dal
gadget RSS:

///////////////////////////////////////////////////// ////////////////////// //Aggiungi elementi del feed agli


elementi di visualizzazione Oggetto HTML da visualizzare nel
gadget //////////////// ///////////////////////////////////////////////////// ///// funzione setNextViewItems()

{
...
g_viewElements.FeedItems[i].innerHtml = feedItemName;

In questo caso feedItemName non è attendibile; è arrivato direttamente dal Web e poi è
stato scritto nel DOM del gadget. Succedono cose brutte se feedItemName contiene script.

Yahoo! Controllo ActiveX della messaggistica istantanea CVE-2007-4515


Probabilmente stai pensando: "cosa c'entra questo con i problemi di XSS?" La risposta è sia niente che
tutto! Questo non è un bug XSS, ma se il tuo codice ha un bug XSS, un utente malintenzionato potrebbe
potenzialmente attivare un codice vulnerabile sul computer, ad esempio il controllo ActiveX della
webcam di Yahoo!, e utilizzare XSS come trampolino di lancio per azioni più insidiose. attacchi agli
utenti.
Peccato 3: Vulnerabilità correlata al client Web (XSS) 71

Se un utente malintenzionato sfruttasse la vulnerabilità dei titoli dei feed RSS della barra laterale di
Windows Vista e fornisse la seguente stringa (sarebbe codificata, non proprio così!) come nome
dell'elemento del feed (variabile feedItemName), potrebbero accadere cose brutte.

<object id="webcam"
classid="CLSID:E504EE6E-47C6-11D5-B8AB-00D0B78F3D48" > </object>

<copione>
webcam.TargetName="Il codice exploit di sovraccarico del buffer va qui"; </
script>

La lezione da questo è che se crei qualsiasi forma di codice mobile, quel codice dovrebbe essere il
più sicuro possibile perché quel codice potrebbe essere riutilizzato in modi che non ti saresti mai
aspettato.

FASI DI RISCATTO
La redenzione più fondamentale è non fidarsi degli input; è sempre così semplice! Quindi,
quando esegui una revisione del codice, guarda dove i dati entrano nel sistema e guarda dove
escono dal sistema e assicurati che da qualche parte tra questi due punti, il codice verifichi che i
dati siano corretti.
La prossima redenzione è non usare costrutti potenzialmente pericolosi e terribilmente
peccaminosi; per esempio, perché usare innerHTML quando innerText sarà sufficiente?
Diamo un'occhiata a ciascuno con esempi di codice.

Non fidarti dell'input


Come minimo assoluto, dovresti limitare la lunghezza della stringa in entrata a qualcosa di sensato.
Abbiamo sentito persone dire: "beh, non possiamo usare espressioni regolari perché l'input può essere
assolutamente qualsiasi cosa!" Ciò potrebbe o non potrebbe essere vero, ma puoi impostare una
lunghezza di input ragionevole. Se necessario, renderlo configurabile. Il seguente codice JavaScript
mostra come limitare l'input a una lunghezza fissa e ricorrere a un valore predefinito di fronte a input
potenzialmente dannosi. In questo caso sta estraendo la richiesta da Yahoo! servizio finanziario, ma la
funzione limita la lunghezza del titolo di borsa e restringe la lunghezza dei dati restituiti.
Potresti pensare: "Ehm, ma la mia pagina web o il mio gadget sta parlando con Yahoo! sito
web e i dati sono sempre attendibili. Non abbiamo dubbi sui dati provenienti da Yahoo! è formato
correttamente, ma non sai se il sito web con cui stai parlando è effettivamente Yahoo! perché la
connessione è una connessione HTTP non autenticata. Attraverso altri attacchi come
avvelenamento DNS e hotspot Wi-Fi canaglia potresti infatti parlare con un altro
72 24 peccati capitali della sicurezza del software

sito web. Puoi correggere la mancanza di autenticazione utilizzando correttamente SSL/TLS; ne parleremo più
dettagliatamente più avanti nel libro, in Sin 22 e 23.

var MAX_TICKER_LEN = 6; var


MAX_RESPONSE_LEN = 64; . . .

funzione getStockInfo(ticker) {

if (ticker.lunghezza > MAX_TICKER_LEN)


return "Non valido";

xhr = nuovo XMLHttpRequest();


xhr.open("OTTIENI",
"http://download.finance.yahoo.com/d/?s="+ticker+"&f=sl1", falso);

xhr.send();

if (xhr.readyState == 4) {
if (xhr.statusText == "OK") {
var risposta = xhr.responseText;
if (risposta.lunghezza <= MAX_RESPONSE_LEN) {
risposta di ritorno;
}
}
}

return "Non valido!";


}

Dovresti anche prendere in considerazione l'utilizzo di un'espressione regolare per convalidare i


dati prima di visualizzarli. Ad esempio, quanto segue verifica che il valore restituito dalla funzione
precedente sia composto solo da A-Za-z ed eventualmente da un punto, una virgola o uno spazio vuoto
e sia lungo tra 1 e 18 caratteri.

funzione isValidStockInfo(stock) {
var re = /^[A-Z0-9\.\,\"\s]{1,18}$/ig; return
re.test(stock);
}

Sostituisci costrutti insicuri con costrutti più sicuri


Alcune funzioni sono suscettibili di abuso, principalmente quelle elencate nella sezione precedente "Individuazione
del peccato durante la revisione del codice". La soluzione più nota è non utilizzare innerHTML ma utilizzare innerText,
che è molto più sicuro. Se un utente malintenzionato fornisce uno script illegale al tuo file web
Peccato 3: Vulnerabilità correlata al client Web (XSS) 73

pagina o gadget, lo script viene visualizzato come testo. In effetti, il tuo commento predefinito quando vedi il codice
che imposta innerHTML dovrebbe essere "perché questo non è innerText?"
Evita di costruire codice HTML e di inserirlo nel DOM utilizzando metodi come
insertAdjacentHTML. Piuttosto, crea un elemento HTML usando createElement, popola le
sue proprietà e poi inseriscilo nel DOM usando i metodi appendChild o insertBefore, come
mostrato qui:

var oAnchor = document.createElement("A");


oAnchor.href = inputUrl;
oAnchor.innerText = "Fai clic qui!";
document.body.appendChild(oAnchor);

MISURE EXTRA DIFENSIVE


Prendi in considerazione l'utilizzo di una tecnologia diversa da HTML o JavaScript per creare gadget;
l'utilizzo di una tecnologia come Windows Presentation Foundation, Adobe Flash o Microsoft Silverlight
può alzare notevolmente l'asticella.
Come accennato in precedenza, l'utilizzo corretto di SSL/TLS per le richieste di rete (ad esempio
utilizzando HTTPS anziché HTTP) può mitigare gli attacchi man-in-the-middle.

ALTRE RISORSE
- Archivio XSS: http://www.xssed.com/archive/special=1
- 2009 CWE/SANS Primi 25 errori di programmazione più pericolosi:
http://cwe.mitre.org/top25
- Widget W3C: 1.0d http://www.w3.org/2008/webapps/wiki/Main_Page
- L'oggetto XMLHttpRequest: http://www.w3.org/TR/XMLHttpRequest/
- “Apple dà accesso ai ladri di identità”: http://www.boston.com/business/
personaltech/articles/2005/05/16/
apple_gives_identity_thieves_a_way_in?pg=full
- Sviluppo di widget Dashboard: http://
developer.apple.com/macosx/dashboard.html
- Strumenti e documentazione di Konfabulator: http://widgets.yahoo.com/tools/
- “Ispeziona il tuo gadget" di Michael Howard e David Ross:
http://msdn.microsoft.com/en-us/library/bb498012.aspx
74 24 peccati capitali della sicurezza del software

RIEPILOGO
- Fareconvalidare tutti i dati della rete esterna.

- Fareconvalidare tutti i dati basati su URL esterni

- Nonfidati di tutti i dati che entrano nella tua pagina web o gadget.
- Nonusa eval() a meno che non ci sia altro modo per scrivere la tua applicazione.

- Prendere in considerazioneutilizzando SSL/TLS per le connessioni al server web.


4
Uso di URL magici,
cookie prevedibili,
e campi modulo nascosti

75
76 24 peccati capitali della sicurezza del software

PANORAMICA DEL PECCATO


Immagina di andare su un sito web per acquistare un'auto a qualsiasi prezzo tu voglia! Ciò potrebbe
accadere se il sito Web utilizza i dati di un modulo Web nascosto per determinare il prezzo dell'auto.
Ricorda, non c'è nulla che impedisca a un utente di guardare il contenuto di origine e quindi inviare un
modulo "aggiornato" a un prezzo enormemente ridotto (usando Perl, per esempio) al server. I campi
nascosti non sono realmente nascosti.
Un altro problema comune sono gli "URL magici": molte applicazioni basate sul Web contengono
informazioni di autenticazione o altri dati importanti negli URL. In alcuni casi, questi dati non
dovrebbero essere resi pubblici, perché possono essere utilizzati per dirottare o manipolare una
sessione. In altri casi, i Magic URL vengono utilizzati come una forma ad hoc di controllo degli accessi,
anziché utilizzare sistemi basati su credenziali. In altre parole, gli utenti presentano i propri ID e
password al sistema e, dopo l'autenticazione riuscita, il sistema crea i token per rappresentare gli
utenti.

RIFERIMENTI CWE
Il progetto Common Weakness Enumeration include le seguenti voci correlate a questo
peccato:

- CWE-642: controllo esterno dei dati sullo stato critico

- CWE-472: controllo esterno del parametro Web presunto immutabile

LINGUE INTERESSATE
Qualsiasi lingua o tecnologia utilizzata per creare un sito Web può essere influenzata; ad
esempio, PHP, Active Server Pages (ASP), C#, VB.NET, ASP.NET, J2EE (JSP, Servlet), Perl, Ruby,
Python e Common Gateway Interface (CGI), nonché in misura minore , C++.

IL PECCATO SPIEGATO
Ci sono due errori distinti associati a questo peccato, quindi diamo un'occhiata a loro uno alla
volta.

URL magici
Il primo errore è URL magici o URL che contengono informazioni sensibili o informazioni che
potrebbero portare un utente malintenzionato a informazioni sensibili. Guarda il seguente URL:

http://www.example.com?id=TXkkZWNyZStwQSQkdzByRA==
Peccato 4: uso di URL magici, cookie prevedibili e campi modulo nascosti 77

Ci chiediamo, cos'è quello dopo l'id? Probabilmente è codificato in base64; puoi dirlo dal
piccolo sottoinsieme di caratteri ASCII e dai caratteri di riempimento "=". Passando rapidamente
la stringa attraverso un decodificatore base64 si ottiene "My$ecre+pA$$w0rD". Puoi vedere
subito che questa è in realtà una password "crittata", dove l'algoritmo di "crittografia" è base64!
Chiaramente, questo è insicuro.
Il seguente frammento di codice C# mostra come codificare e decodificare una stringa in base64:

string s = "<qualche stringa>";


stringa s1 = Convert.ToBase64String(UTF8Encoding.UTF8.GetBytes(s)); stringa s2 =
UTF8Encoding.UTF8.GetString(Convert.FromBase64String(s1));

In breve, i dati contenuti ovunque nell'URL, o nel corpo HTTP per quella materia, che sono
potenzialmente sensibili sono peccaminosi se il payload non è protetto dalle difese crittografiche
appropriate.
Qualcosa da considerare è la natura del sito web. Se i dati dell'URL vengono utilizzati per scopi di
autenticazione, probabilmente hai un problema di sicurezza. Tuttavia, se il sito Web utilizza i dati per
l'iscrizione, forse non è un grosso problema. Ancora una volta, dipende da cosa stai cercando di
proteggere.

Cookie prevedibili
Alcuni siti Web peccaminosi emettono un cookie prevedibile dopo l'autenticazione riuscita. Ad esempio,
utilizzando un valore a incremento automatico nel cookie. Questo è negativo perché basta che un
utente malintenzionato veda che quando si connette al sito un paio di volte, il valore del cookie è
1000034 e poi 1000035, quindi l'attaccante forza il cookie a 1000033 e dirotta la sessione di un altro
utente. Tutto su SSL se necessario!
Immagina il seguente scenario: costruisci e vendi un sito web fotografico online che consente agli utenti
di caricare le foto delle loro vacanze. Questo potrebbe essere considerato un sistema di appartenenza perché
le foto probabilmente non sono sensibili o classificate. Tuttavia, immagina se un utente malintenzionato
(Mallet) potesse vedere le credenziali di un altro utente (Dave) (nome utente, password o valore "magico" o
prevedibile) volare attraverso il cavo nell'URL o nel payload HTTP, incluso il cookie. Mallet potrebbe creare un
payload che include le credenziali di Dave per caricare materiale pornografico sul sito web. A tutti gli utenti del
sistema, queste immagini sembrano provenire da Dave, non da Mallet.

Campi modulo nascosti


Il secondo errore sta passando dati potenzialmente importanti dalla tua applicazione web al client in un
campo modulo nascosto, sperando che il client non (1) lo veda o (2) lo manipoli. Gli utenti
malintenzionati potrebbero visualizzare molto facilmente i contenuti del modulo, nascosti o meno,
utilizzando l'opzione Visualizza origine nei loro browser e quindi creare versioni dannose da inviare al
server. Il server non ha modo di sapere se il client è un browser Web o uno script Perl dannoso! Guarda
l'esempio di peccati che segue per avere un'idea migliore dell'effetto sulla sicurezza di questo peccato.
78 24 peccati capitali della sicurezza del software

Peccati correlati
A volte gli sviluppatori web compiono altri peccati, in particolare il peccato di usare una crittografia
scadente.

INDIVIDUARE IL MODELLO DEL PECCATO


Il modello peccaminoso da osservare è

- Le informazioni sensibili vengono lette dall'app Web da un cookie, un'intestazione HTTP, un modulo
o un URL.

- I dati vengono utilizzati per prendere decisioni sulla sicurezza, sulla fiducia o sull'autorizzazione.

- I dati vengono forniti su un canale non sicuro o non attendibile.

INDIVIDUARE IL PECCATO DURANTE LA REVISIONE DEL CODICE


Per individuare gli URL magici, rivedi tutto il codice del tuo server Web e specifica tutti i punti di
input nell'applicazione che provengono dalla rete. Scansiona il codice per i seguenti costrutti
(nota che ci sono altre forme di input per ogni linguaggio di programmazione e linguaggio di
sviluppo web, quindi dovresti familiarizzare anche con quei metodi, chiamate di funzione e altri
costrutti di input):

Lingua Parole chiave da cercare

ASP.NET Richiesta e manipolazione di etichette come *.text


o *.value
Rubino ActionController::Request o params
Pitone HttpRequest quando si usa Django o tutte le istanze di req*
quando si usa mod_python. Python ha molti framework web,
quindi dovresti esaminare i metodi di richiesta in qualsiasi
framework che usi.
Asp Richiesta
PHP $_REQUEST, $_GET, $_POST o $_SERVER
PHP 3.0 e precedenti $HTTP_
CGI/Perl Chiamare param() in un oggetto CGI

mod_perl Apache::Richiesta
ISAPI (C/C++) Lettura da un elemento dati in
EXTENSION_CONTROL_BLOCK, come
lpszQueryString; o da un metodo, come
GetServerVariable o ReadClient
Peccato 4: uso di URL magici, cookie prevedibili e campi modulo nascosti 79

Lingua Parole chiave da cercare

ISAPI (Microsoft CHttpServer o CHttpServerFilter e quindi la lettura da


classi di base) un oggetto CHttpServerContext
Java Server Page (JSP) getRequest e request.GetParameter

Per i campi modulo nascosti, il compito è un po' più semplice. Scansiona tutto il codice del tuo server web
e verifica la presenza di eventuali HTML inviati al client contenenti il seguente testo:

tipo=nascosto

Ricorda, potrebbero esserci virgolette singole o doppie intorno alla parolanascosto.La


seguente espressione regolare, scritta in C#, ma facilmente trasportabile in altri linguaggi, trova
questo testo:

Regex r = nuovo
Regex("type\\s*=\\s*['\"]?hidden['\"]?",RegexOptions.IgnoreCase); bool isHidden =
r.IsMatch(stringToTest);

Oppure in Perl:

my $isHidden = /type\s*=\s*['\"]?hidden['\"]?/i;

Per ogni elemento nascosto che trovi, chiediti perché è nascosto e cosa accadrebbe se un
utente malintenzionato modificasse il valore nel campo nascosto con un altro valore.

TECNICHE DI PROVA PER TROVARE IL PECCATO


Il modo migliore per trovare questi difetti è attraverso una revisione del codice, ma puoi mettere
in atto alcuni test nel caso in cui la revisione del codice non avvenga mai o ti perdi qualcosa. Ad
esempio, potresti utilizzare strumenti come TamperIE (www.bayden.com/Other) o Web
Developer (www.chrispederick.com/work/firefox/webdeveloper) per mostrarti i moduli nel
browser. Entrambi gli strumenti consentono inoltre di modificare i campi del modulo e di inviarli
al sito Web di origine.
L'eccellente strumento Fiddler di Eric Lawrence (www.fiddler2.com/fiddler2/) può anche trovare moduli e
campi nascosti; è sufficiente effettuare una richiesta da Internet Explorer quando Fiddler viene caricato e
quindi selezionare la scheda Inspectors e quindi la scheda WebForms come mostrato nella Figura 4-1.

Puoi anche fare in modo che Fiddler trovi ed evidenzi le pagine web che contengono moduli nascosti creando
una regola personalizzata:

- Apri il violinista

- Seleziona il menu Regole

- Seleziona Personalizza regole


80 24 peccati capitali della sicurezza del software

Figura 4-1.Fiddler che mostra i dati del modulo web

- Immettere il seguente codice all'inizio della funzione OnBeforeResponse():

if (oSession.oResponse.headers.ExistsAndContains("Content-Type", "html")) {
// Rimuovi qualsiasi compressione o suddivisione in
blocchi oSession.utilDecodeResponse();

var oCorpo =
System.Text.Encoding.UTF8.GetString(oSession.responseBodyBytes); if
(oBody.search(/<input.*hidden.*>/gi)>-1) {
oSessione["ui-bold"] = "vero"; oSessione["ui-
color"] = "rosso";
FiddlerObject.playSound("Notifica");
}
}

Qualsiasi pagina Web con un modulo nascosto apparirà in grassetto rosso nel riquadro Sessioni Web e
Fiddler emetterà un segnale acustico.
Peccato 4: uso di URL magici, cookie prevedibili e campi modulo nascosti 81

ESEMPIO PECCATI
La seguente voce in Common Vulnerabilities and Exposures (CVE), su http://
cve.mitre.org/, è un esempio di questo peccato.

CVE-2005-1784
Questo è un bug in uno strumento di amministrazione host chiamato Host Controller; ha una pagina web non
sicura userprofile.asp che permette agli utenti di modificare i dati del profilo di altri utenti semplicemente
impostando il loro indirizzo e-mail nel campo emailaddress.

FASI DI RISCATTO
Quando pensi alle minacce agli URL magici e ai moduli nascosti e alle possibili
contromisure, considera sempre le seguenti minacce:

- Un utente malintenzionato visualizza i dati o

- Un utente malintenzionato riproduce i dati, o

- Un utente malintenzionato prevede i dati, o

- Un utente malintenzionato modifica i dati

Diamo un'occhiata a ciascuna minaccia e ai possibili riscatti.

L'aggressore visualizza i dati


Questa è una minaccia solo se i dati sono riservati, come una password o un identificatore che
consente all'utente di accedere al sistema. Anche qualsiasi informazione di identificazione personale
(PII) è motivo di preoccupazione. Un semplice rimedio consiste nell'utilizzare Secure Sockets Layer
(SSL), Transport Layer Security (TLS), Internet Protocol Security (IPSec) o qualche altra tecnologia di
crittografia per proteggere i dati sensibili. Ad esempio, è possibile crittografare i dati sul server e quindi
inviarli al client in una forma nascosta o in un cookie e il client invia automaticamente i dati al server.
Poiché la chiave è conservata sul server e il blob crittografato è opaco, questo è un meccanismo
relativamente buono dal punto di vista della pura crittografia.

L'attaccante riproduce i dati


Puoi decidere di crittografare o eseguire l'hashing di alcuni dati di identità sensibili utilizzando il tuo codice sul
server, che può sembrare sicuro. Ma immagina se i dati crittografati o con hash potrebbero esserlo

Potrebbero piacerti anche