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

Tradotto dal Inglese al Italiano - www.onlinedoctranslator.
com
22 24 peccati capitali della sicurezza del software
Redenzione di Ruby on Rails

Post.find(:first, :conditions => ["title = ? ",params[:search_string]])
Java utilizzando il riscatto JDBC

public static booleano doQuery(String arg) {
// consente solo ID validi (1-8 cifre) Pattern p =
Pattern.compile("^\\d{1,8}$"); if (!p.matcher(arg).find())
restituire falso;
Connessione con = nullo;
Tentativo
{
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); con =
DriverManager.getConnection(getConnectionInfo()); PreparedStatement st =
con.prepareStatement(
"exec pubs..sp_GetCreditCard ?");
st.setString(1, arg);
ResultSet rs = st.executeQuery(); while
(rs.next()) {
// Ottieni i dati da rs.getString(1);
}
rs.close();
st.chiudi();
}
cattura (SQLException e)
{
System.out.println("Errore SQL: " + e.toString()); restituire falso;
}
cattura (ClassNotFoundException e2) {
System.out.println("Classe non trovata: " + e2.toString()); restituire falso;
}
Finalmente
{
Tentativo
{
con.close();
} catch(SQLException e) {}
}
restituisce vero;
}
Peccato 1: ione SQL Inject
23
Redenzione ColdFusion
Per ColdFusion, usacfqueryparamnel <cfquery>tag per rendere la query più sicura con i
parametri, ma solo dopo aver eseguito la convalida dei dati:
<CFIF è definito("URL.IDcliente")
AND NOT IsNumeric(URL.clientID)> 
</CFIF>
<CFQUERY>
SELEZIONARE *
DA tblClient
WHERE clientid = <cfqueryparam value="#URL.clientID#"
CFSQLTYPE="CF_SQL_INTEGER">
</CFQUERY>
Si noti l'uso diCFSQLTYPEper limitare ulteriormente i dati in entrata.
Redenzione SQL
Non dovresti davvero eseguire un parametro non attendibile all'interno di una stored procedure. Detto
questo, come meccanismo di difesa in profondità, potresti utilizzare alcune funzioni di controllo delle stringhe
per determinare se il parametro è formato correttamente. Il codice seguente verifica se il parametro in
entrata è composto solo da quattro cifre. Si noti che la dimensione del parametro è stata impostata su una
dimensione molto più piccola, rendendo più difficile l'aggiunta di altri input.
CREATE PROCEDURE dbo.doQuery(@id nchar(4)) AS
DICHIARARE @query nchar(64)

SE RTRIM(@id) LIKE '[0-9][0-9][0-9][0-9]' BEGIN
SELECT @query = 'seleziona ccnum da cust dove id = ''' + @id + '''' EXEC @query
FINE
RITORNO
O, meglio ancora, forza il parametro a essere un numero intero:
CREA PROCEDURA dbo.doQuery(@id smallint)
Microsoft SQL Server 2005 aggiunge espressioni regolari conformi a POSIX, così come Oracle
10Ge più tardi. Le soluzioni per le espressioni regolari sono disponibili anche per DB2 e Microsoft
SQL Server 2000. MySQL supporta le espressioni regolari tramite la clausola REGEXP. Troverai
maggiori informazioni su tutte queste soluzioni nella prossima sezione "Altre risorse".
Usa QUOTENAME e REPLACE

Un'altra difesa importante durante la creazione di istruzioni SQL dall'interno delle procedure memorizzate
consiste nell'utilizzare il fileNOMECITAZIONEOSOSTITUIREfunzioni in SQL Server.NOMECITAZIONEpuò essere
utilizzato per delimitare nomi di oggetti (come nomi di tabelle) e dati, come quelli utilizzati inDOVE clausole.
Puoi anche usareSOSTITUIREper sostituire le virgolette nei dati.
In generale, dovresti usareQUOTENAME(nomeoggetto, '[')per oggetti e
NOMECITAZIONE(@dati, '''')per i dati. Puoi anche usareSOSTITUISCI(@data, '''', '''''')per i
dati.
Dovresti usare DBMS_ASSERT?

Oracolo 10Goffre un pacchetto denominatoDBMS_ASSERTper aiutare a convalidare l'input dell'utente.
Sfortunatamente, non è una difesa molto buona, poiché esistono molti modi noti per aggirare la
convalida dell'input. Se usate una qualsiasi funzione esposta da questo pacchetto, fatelo con estrema
cautela. Vedere la sezione "Altre risorse" per ulteriori informazioni.
Usa CAT.NET
Se utilizzi il set di strumenti di sviluppo Microsoft .NET, dovresti utilizzare CAT.NET per individuare le
vulnerabilità SQL injection (e specifiche per il Web) nel tuo codice. CAT.NET è un componente
aggiuntivo di Visual Studio che esegue l'analisi statica per aiutare a trovare SQL injection e vulnerabilità
specifiche del Web. Ecco un frammento di codice peccaminoso abbreviato scritto in C#; La Figura 1-1
mostra CAT.NET in azione.
nome stringa = txtName.Text; . . .
sql.Open();
stringa sqlstring = "SELEZIONA informazioni" +
" FROM cliente WHERE nome=" + nome; SqlCommand cmd
= new SqlCommand(sqlstring, sql); ccnum =
(stringa)cmd.ExecuteScalar();
Lo strumento lo ha determinatotxtNome.txtnon è attendibile e viene utilizzato per creare una stringa SQL, che
viene quindi utilizzata per eseguire una query SQL. Chiaramente, questo è un vero e proprio bug di SQL injection.
Un collegamento a CAT.NET si trova nella sezione "Altre risorse".
MISURE EXTRA DIFENSIVE

Esistono molte altre difese che puoi utilizzare per ridurre le possibilità di compromissione. Forse
il più importante è negare l'accesso agli oggetti di database sottostanti come le tabelle e
concedere l'accesso solo alle stored procedure e alle viste. Se per qualche motivo l'attaccante
riesce a superare le tue difese, non può accedere direttamente ai dati della tabella. Questa difesa
non è una difesa programmatica; è una difesa IT definita dagli amministratori del database.
Ecco alcune altre difese che dovresti impiegare.
25
Figura 1-1.CAT.NET che individua una vulnerabilità di SQL injection
Crittografa i dati sensibili, PII o riservati

Questa difesa è fondamentale perché dimostra che hai eseguito un certo grado di due diligence
oltre a creare software più sicuro seguendo le migliori pratiche di sicurezza. La crittografia dei
dati all'interno del database richiede che il motore del database supporti la crittografia; per
fortuna, i sistemi di database come SQL Server 2005, Oracle, IBM DB2 e MySQL supportano la
crittografia.
Usa URLScan
Microsoft ha aggiornato URLScan, uno strumento che limita le richieste HTTP al server Web IIS,
nel 2008 per aiutare a difendersi da alcune classi di attacchi SQL injection da Internet.
Come nota finale, storicamente, una ben nota difesa PHP era assicurarsi di impostare
magic_quotes_gpc=1in php.ini, ma questa funzionalità è deprecata in PHP 6.0.0 e versioni successive.
ALTRE RISORSE
- CWE-89: Mancata sanificazione dei dati all'interno delle query SQL (ovvero "SQL
Injection"): http://cwe.mitre.org/data/definitions/89.html
- 2009 CWE/SANS Primi 25 errori di programmazione più pericolosi:

http://cwe.mitre.org/top25
- Sarbanes-Oxley Act del 2002: www.aicpa.org/info/
sarbanes_oxley_summary.htm
- Standard di sicurezza dei dati del settore delle carte di

pagamento: https://www.pcisecuritystandards.org
- L'Open Web Application Security Project (OWASP):

www.owasp.org
- “Advanced SQL Injection nelle applicazioni SQL Server" di Chris Anley:
www.nextgenss.com/papers/advanced_sql_injection.pdf
- “Rilevamento di SQL Injection in Oracle” di Pete Finnigan:
www.securityfocus.com/infocus/1714
- “Perché dovresti aggiornare a Rails 2.1”: http://blog.innerewut.de/2008/6/16/
why-you-should-upgrade-to-rails-2-1
- “Nuovi attacchi di troncamento SQL e come evitarli” di Bala Neerumalla: http://
msdn.microsoft.com/en-us/magazine/cc163523.aspx
- “Le Nazioni Unite al servizio del malware” di Dancho Danchev: http://
ddanchev.blogspot.com/2008/04/united-nations-serving-malware.html
- “Qualcuno conosce www.nihaorr1.com/1.js”: http://
forums.iis.net/t/1148917.aspx?PageIndex=1
- “Come un criminale potrebbe infiltrarsi nella tua rete” di Jesper Johansson:
www.microsoft.com/technet/technetmag/issues/2005/01/
AnatomyofaHack/default.aspx
- “Attacchi SQL Injection by Example” di Stephen J. Friedl:
www.unixwiz.net/techtips/sql-injection.html
- Scrittura di codice sicuro, seconda edizionedi Michael Howard e David C. LeBlanc (Microsoft
Press, 2002), capitolo 12, "Problemi di input del database"
- Riferimento tascabile per le espressioni regolari Oracledi Jonathan Gennick e

Peter Linsley (O'Reilly, 2003)
- “Le espressioni regolari semplificano la corrispondenza dei modelli e l'estrazione dei dati"
di David Banister: http://msdn.microsoft.com/en-us/magazine/cc163473.aspx
- “DB2 porta la potenza della corrispondenza delle espressioni regolari in SQL”:
www-106.ibm.com/developerworks/db2/library/techarticle/0301stolze/
0301stolze.html
- Espressioni regolari MySQL: http://dev.mysql.com/
doc/mysql/en/Regexp.html
- “Cheat Sheet di SQL Injection”: http://ferruh.mavituna.com/
sql-injection-cheatsheet-oku/
- “Elimina gli attacchi SQL Injection in modo indolore con LINQ”:
www.devx.com/dotnet/Article/34653
27
- ColdFusion cfqueryparam: www.adobe.com/livedocs/coldfusion/5.0/

CFML_Reference/Tags79.htm
- “Bypassare Oracle dbms_assert” di Alex Kornbrust: www.red-
database-security.com/wp/bypass_dbms_assert.pdf
- “Utilizzo di UrlScan”: http://learn.iis.net/page.aspx/473/using-urlscan
- CAT.NET: http://snurl.com/89f0p
RIEPILOGO
- Farecapire il database che usi. Supporta le stored procedure? Cos'è
l'operatore di commento? Consente all'attaccante di richiamare
funzionalità estese?
- Farecomprendere i comuni metodi di attacco SQL injection contro il database
utilizzato.
- Farecontrollare l'input per la validità e l'attendibilità.
- Fareverificare la validità dell'input sul server.
- Fareutilizzare query con parametri, note anche come istruzioni preparate,

segnaposto o associazione di parametri, per creare istruzioni SQL.
- Fareutilizzare le funzioni di citazione o di delimitazione se è necessario creare categoricamente

SQL dinamico.
- Farearchiviare le informazioni di connessione al database in una posizione esterna

all'applicazione, ad esempio un file di configurazione opportunamente protetto o il
registro di Windows.
- Farecrittografare i dati sensibili del database.
- Farenegare l'accesso agli oggetti di database sottostanti e concedere l'accesso solo alle stored
procedure e alle viste.
- Nonelimina semplicemente le "parolacce". Ci sono spesso una miriade di varianti e

fughe che non rileverai, e talvolta l'eliminazione delle parolacce lascia le parolacce:
immagina di rimuovere "delete" da "deldeleteete".
- Nonattendibilità dell'input utilizzato per creare istruzioni SQL.
- Nonutilizzare la concatenazione di stringhe per creare istruzioni SQL a meno che non ci sia
assolutamente altro modo per creare un'istruzione SQL in modo sicuro.
- Noneseguire parametri non attendibili all'interno di stored procedure.
- Nonverificare la validità dell'input solo presso il client.

- Nonconnettersi al database come account con privilegi elevati, ad esempio sa

Oradice.
- Nonincorporare la password di accesso al database nell'applicazione o nella stringa di
connessione.
- Nonmemorizzare le informazioni di configurazione del database nella radice web.
- Prendere in considerazionerimuovere l'accesso a tutte le tabelle definite dall'utente nel

database e concedere l'accesso solo tramite stored procedure. Quindi crea la query utilizzando
stored procedure e query con parametri.
2
Relativo al server Web
Vulnerabilità
(XSS, XSRF e
Divisione della risposta)
29
PANORAMICA DEL PECCATO

Quando la maggior parte degli sviluppatori pensa across-site scripting (XSS)bug, pensano ai bug nei siti
Web che portano ad attacchi ai browser dei client, ma negli ultimi anni c'è stato un aumento dei bug
XSS del server e un aumento allarmante dei problemi XSS lato client. Quest'ultima forma di attacco è
relativamente nuova ed è oggetto del prossimo capitolo.
Dal momento che abbiamo scritto l'originale19 peccati capitali della sicurezza del software,la ricerca di
MITRE Corporation mostra che i bug XSS hanno superato l'umile ma comune sovraccarico del buffer come il
bug de jour.
Riteniamo che la ragione dell'aumento dei problemi XSS sia sfaccettata.
- Innanzitutto, c'è stata un'esplosione nella quantità di applicazioni basate sul web.
- In secondo luogo, nella folle corsa alla scrittura e distribuzione di applicazioni Web, gli sviluppatori
continuano a essere completamente all'oscuro dei problemi di sicurezza e scrivono codice non
sicuro!
- In terzo luogo, l'avvento delle applicazioni Asynchronous JavaScript e XML (AJAX),

aggravato da una mancanza di conoscenza della sicurezza, ha portato a più problemi XSS.
- In quarto luogo, una grande quantità di ricerca all'interno della comunità della sicurezza ha
trovato nuove e interessanti varianti di bug relative a XSS che potrebbero potenzialmente rendere
inerti le difese comuni.
- In quinto luogo, i bug XSS sono abbastanza facili da individuare con poco più di un browser
web e un po' di know-how.
- Infine, poiché i grandi ISV rafforzano i loro sistemi operativi, il numero e l'impatto delle
classiche vulnerabilità di sovraccarico del buffer stanno diminuendo, quindi gli aggressori e i
ricercatori devono trovare nuovi tipi di vulnerabilità, quindi perché non scegliere qualcosa
che sia più onnipresente di Microsoft Windows? La rete!
Diamine, c'è persino un sito web, www.xssed.com/, che elenca le vulnerabilità XSS e
relative a XSS su siti web pubblici!
Tieni presente che i test per problemi XSS su un sito Web che non ti appartiene potrebbero portare
a un problema con la legge. Leggi "Segnalare le vulnerabilità è per i coraggiosi" (vedi "Altre risorse")
per alcune informazioni.
I bug XSS del server Web e relativi a XSS sono una forma di bug di sicurezza univoco per le applicazioni
basate sul Web che consentono a un utente malintenzionato di compromettere un client che si connette al
server Web vulnerabile. Esempi di compromissione includono il furto di cookie o la manipolazione della
pagina web così come viene vista dall'utente. Ora abbiamo visto una serie di worm basati sul Web che
utilizzano le vulnerabilità XSS per propagarsi.
Ora chiariamo bene una cosa prima di continuare. I bug XSS non sono un bug nel server
web stesso; piuttosto sono bug nelle pagine web rese dal server web. Quindi non incolpare
Microsoft Internet Information Services (IIS) o Apache. Certo, alcune di quelle pagine
potrebbero venire con l'installazione del server!
Peccato 2: vulnerabilità legate al server Web (XSS, XSRF e Response Spl itt ing) 31
Detto questo, per un po' c'è stato molto dito puntato. Gli sviluppatori del server Web hanno
detto: "È colpa del client, stanno rendendo spazzatura" e gli sviluppatori del client avrebbero
ribattuto "beh, ci stai servendo spazzatura".
Fondamentalmente, non c'è modo per il browser di sapere quali tag di script sono previsti dal
programmatore e quali vengono iniettati da un utente malintenzionato.
RIFERIMENTI CWE
Il progetto Common Weakness Enumeration include le seguenti voci; i primi due fanno
anche parte della CWE/SANS Top 25 Most Dangerous Programming Errors:
- CWE-79: mancato mantenimento della struttura della pagina Web (noto anche come "Cross-site scripting" [XSS])
- CWE-352: falsificazione di richieste tra siti (CSRF)

- CWE-113: mancata sanificazione delle sequenze CRLF nelle intestazioni HTTP (nota anche come "suddivisione
della risposta HTTP")
LINGUE INTERESSATE
Qualsiasi linguaggio o tecnologia utilizzata per creare un'applicazione Web, ad esempio Ruby on
Rails, Python, PHP, C++, Active Server Pages (ASP), C#, VB.Net, ASP.NET, J2EE (JSP, Servlet), Perl e
Common Gateway Interface (CGI), può essere interessato.
IL PECCATO SPIEGATO
Tecnicamente, ci sono tre tipi di peccati XSS e due tipi di peccato correlati; sono
- XSS basato su DOM, noto anche come XSS locale o tipo 0

- XSS riflesso: questo è un bug classico, chiamato anche XSS non persistente o tipo 1
- XSS memorizzato, chiamato anche XSS persistente o tipo 2
- Suddivisione della risposta HTTP
- Falsificazione di richieste cross-site (XSRF, a volte CSRF)
Diamo un'occhiata a ciascun peccato un po' più in dettaglio.
XSS basato su DOM o tipo 0

L'obiettivo di questo capitolo è "Vulnerabilità relative ai server Web", ma questa variante del peccato, l'XSS
basato su DOM, non coinvolge necessariamente pagine non sicure sui server Web; l'esecuzione di questo
attacco non richiede che l'utente si connetta a un server Web vulnerabile. L'attacco dipende esclusivamente da
una pagina HTML scritta in modo insicuro sul computer dell'utente e l'attaccante può portare a termine il suo
attacco se riesce a convincere l'utente ad avviare quella pagina HTML con un input dannoso.
Poiché così tanti bug XSS basati su DOM sono attacchi locali, tratteremo questa variante del
peccato in modo molto più dettagliato nel prossimo capitolo, perché abbiamo visto questo
peccato commesso più e più volte nelle nuove tecnologie di Microsoft, Apple, Yahoo e Google
chiamate gadget o widget, che sono, a tutti gli effetti, mini-applicazioni create da raccolte di
pagine HTML, file JavaScript e file di configurazione e grafica di supporto.
XSS riflesso, XSS non persistente o tipo 1

Ecco come commettere questo peccato: costruire un'applicazione web prende un input da un utente (noto anche
come utente malintenzionato), forse da una stringa di query, non convalida correttamente l'input e quindi fa eco a
quell'input direttamente in una pagina web.
È davvero così semplice commettere questo peccato!
Come puoi vedere, questo è un classico problema di attendibilità dell'input. L'applicazione Web si aspetta del
testo, ad esempio un nome, in una stringa di query, ma il cattivo fornisce qualcosa che lo sviluppatore
dell'applicazione Web non si sarebbe mai aspettato. Il divertimento inizia quando un utente malintenzionato fornisce
un frammento di codice scritto in un linguaggio di script come JavaScript come querystring e chiede alla vittima di fare
clic su quel collegamento.
Questo è anche un ottimo esempio del perché sia pericoloso mescolare codice e dati, eppure lo facciamo
ogni giorno sul web. Nel caso di una pagina Web, i dati sono il markup HTML e il codice è lo script.
Naturalmente, potremmo fermare la maggior parte degli attacchi XSS sul nascere se costringessimo gli utenti
a disattivare tutti gli script nei loro browser, ma ciò porterebbe utenti arrabbiati che non sarebbero in grado di
prenotare voli, effettuare acquisti online, condividere foto o aggiornare il loro stato sui social network.
Potresti aver notato che abbiamo usato le parole "la maggior parte degli attacchi XSS" perché una nuova ricerca
ha dimostrato che è possibile montare alcune forme di attacco, come il furto della cronologia del browser senza l'uso
di script! Fare riferimento all'articolo "Steal Browser History Without JavaScript" elencato nella sezione "Altre risorse"
per saperne di più.
La Figura 2-1 mostra come funziona un attacco XSS di tipo 1. Il motivo per cui questo peccato
è chiamato "XSS riflesso" è perché l'input dannoso viene ripetuto, o riflesso, immediatamente dal
server Web al client.
Poiché il codice dannoso (il codice che si trovava nella stringa di query e
successivamente echeggiato dal server nel browser della vittima) è in esecuzione nel
contesto del dominio del server Web vulnerabile (ad esempio, www.example.com), può
accedere il cookie della vittima legato al dominio del server vulnerabile. Il codice può
anche accedere al Document Object Model (DOM) del browser e modificare qualsiasi
elemento al suo interno; ad esempio, il codice di attacco potrebbe aggiornare tutti i
collegamenti in modo che puntino a siti porno o di odio. Oppure, come nel caso delle
elezioni presidenziali del 2008, il sito web della campagna di Barack Obama potrebbe
puntare al sito web della campagna di Hillary Clinton! A molti utenti (e ad alcuni
membri della stampa) sembrava che il sito web di Obama fosse stato violato, ma in
realtà non era così;
Figura 2-1.Una pagina web peccaminosa soggetta a una vulnerabilità XSS di tipo 1 sotto attacco
Non è necessario che l'output sia visibile per portare a un bug XSS; qualsiasi tipo di eco sarà sufficiente. Ad
esempio, il server web potrebbe ripetere l'input come argomento in un blocco JavaScript valido nella pagina
web, o forse i dati sono il nome di un file immagine in un tag <img>.
Ricorda, un exploit XSS ha accesso in lettura e scrittura a tutte le pagine servite dal dominio che
ospita la pagina Web incriminata. Ad esempio, www.example.com/about.jsp può potenzialmente
attaccare qualsiasi contenuto proveniente da www.example.com in conformità con la politica della
stessa origine del browser web.
Puoi provare tu stesso l'attacco semplicemente scrivendo parte del codice peccaminoso mostrato più
avanti in questo capitolo, e poi usando una stringa come
<script>avviso("XSS");</script>
come input per il campo sinful o querystring.

Si potrebbe pensare che eseguire un attacco con qualcosa di simile al codice precedente
nella querystring sia un po' troppo ovvio! Ebbene, l'aggressore può sfuggire alla sequenza in
molti modi o, meglio ancora, utilizzare un servizio come tinyurl.com o snurl.com per creare una
ricerca abbreviata. Ad esempio, l'URL
http://tinyurl.com/3asxla
mappe a
http://www.dailymail.co.uk/home/search.html?s=y&searchPhrase=">
<script>alert('xss');</script>
A un certo punto, il sito Web DailyMail nel Regno Unito ha commesso un peccato XSS, ma se
inserisci l'URL tinyurl, non vedrai il payload XSS. Scaltro!
XSS memorizzato, XSS persistente o Tipo 2

Questo tipo di peccato XSS è una variante della vulnerabilità XSS di tipo 1, ma invece di
riflettere l'input, il server Web persiste l'input e quell'utente viene presentato in seguito a
vittime ignare.
Esempi di applicazioni Web comuni soggette ad attacchi XSS di tipo 2 includono applicazioni Web di recensioni/
feedback di blog o prodotti perché questi tipi di applicazioni devono leggere l'input HTML arbitrario di un utente (o di
un utente malintenzionato) e quindi ripetere tale testo affinché tutti possano leggerlo all'indirizzo un tempo
successivo.
La Figura 2-2 mostra come funziona un attacco XSS di tipo 2. Come puoi vedere, l'unica
differenza tra XSS tipo 1 e XSS tipo 2 è l'aggiunta di un passaggio intermedio che memorizza
l'input non attendibile, magari in un database o nel file system, prima di infliggere l'input alla
vittima.
Questo tipo di XSS ha il potenziale per essere il tipo più pericoloso di XSS, poiché non è richiesta
alcuna ingegneria sociale: la vittima deve solo visitare una pagina, magari una che ha già visitato 100
volte, per essere attaccata.
Per brevità, tutti gli esempi di codice XSS in questo capitolo mostrano bug XSS di tipo 1, ma potrebbero
facilmente essere resi di tipo 2 aggiungendo qualche forma di persistenza.
Divisione della risposta HTTP

Proprio quando l'industria della sicurezza pensava di aver capito i peccati XSS, è arrivata una
variante sottile ma potente chiamata HTTPdivisione della risposta,di seguito indicato
semplicemente come RS per brevità. I due tipi precedenti di problema XSS, tipo 1 e tipo 2, si
basano su input dannosi che vengono inseriti nella pagina Web come parte del payload HTML e
quindi inviati alla vittima. RS è diverso in quanto l'input dannoso è inserito nel fileIntestazioni
HTTPdella pagina web inviata alla vittima. La Figura 2-3 mostra la differenza critica tra le due
forme di attacco.
A livello programmatico, l'unica vera differenza tra i peccati XSS e i peccati RS sono le
funzioni oi metodi utilizzati sul server per restituire all'utente i dati non attendibili.
Figura 2-2.Una pagina web peccaminosa soggetta a una vulnerabilità XSS di tipo 2 sotto attacco
Figura 2-3.La differenza tra XSS e HTTP Response Splitting

Come probabilmente avrai già intuito, i peccati XSS "classici" vengono commessi utilizzando
funzionalità che scrivono l'output nel corpo HTML, come ASP.NET e JSP e l'operatore "<%=" di
Ruby on Rails. I peccati RS vengono impegnati utilizzando funzioni o metodi che scrivono nelle
intestazioni HTTP, come i metodi Response.SetHeader, Response.SetCookie o Response.Redirect
di ASP.NET, response.setHeader di JSP, response.headers di Ruby on Rails o PHP funzione
header().
Si noti che per impostazione predefinita ASP.NET è immune ai bug di divisione della risposta
Response.Redirect perché esegue automaticamente l'escape di molti caratteri non validi, incluse le
combinazioni CRLF.
È importante conoscere tutti i metodi che impostano le intestazioni nelle risposte HTTP. Pensa a
cosa fanno questi metodi; Response.Redirect, ad esempio, aggiunge un'intestazione 302 (Oggetto
spostato) alla risposta, nonché la posizione a cui reindirizzare. Si verificano problemi se l'argomento di
Response.Redirect non viene convalidato e finisce per essere inserito nell'intestazione HTTP Location:.
HTTP/1.1 302 Oggetto spostato Ubicazione:

SomeUntrustedInput Server: Microsoft-IIS/7.0
Data: lunedì 23 gennaio 2009 15:16:35 GMT
Connessione: chiudi
Posizione: test2.aspx
Contenuto-Lunghezza: 130
Aggiungi un CRLF alla fine di quell'input non attendibile e l'attaccante può iniziare a inserire le
proprie intestazioni nella risposta, o persino fabbricare nuove risposte, come questa:
HTTP/1.1 302 Posizione dell'oggetto spostato:

SomeUntrustedInput [CRLF] ThisUntrusted:
InputtCanBeUsed [CRLF] ToCauseAll: SortsOfFun
[CRLF]
AndGames: AndGeneralMayhem [CRLF]
Server: Microsoft-IIS/7.0
Data: lunedì 23 gennaio 2009 15:16:35 GMT
Connessione: chiusa
Posizione: test2.aspx
Contenuto-Lunghezza: 130
È possibile avere varianti di divisione della risposta HTTP non persistenti e persistenti, ma a
differenza dei peccati XSS, oggi non sono suddivise in questo modo.
Il tipo di danno che un utente malintenzionato può causare con un attacco RS è tutto ciò che può fare con un
attacco XSS e altro ancora, incluso l'avvelenamento della cache Web e proxy, il che significa manipolare le pagine
memorizzate nella cache in modo che altri utenti recuperino pagine contaminate.
Falsificazione di richieste cross-site

Molti lo sostengonofalsificazione di richieste tra siti (XSRF)i bug non hanno assolutamente alcuna
relazione con i bug XSS e probabilmente avrebbero ragione! Le vulnerabilità XSS e RS sfruttano la
fiducia del client nel server per "fare la cosa giusta", mentre le vulnerabilità XSRF sono causate
dall'eccessiva fiducia del server nel client.
Dai un'occhiata alla Figura 2-4.
In questo esempio, lo sviluppatore ha commesso un errore fatale e altamente peccaminoso durante la progettazione
della sua applicazione: ha progettato l'applicazione per accettare le richieste dal client utilizzando l'input della stringa di query.
Ad esempio, un'applicazione di posta elettronica basata sul Web potrebbe contenere i seguenti verbi:
http://www.example.com/request.php?create-new http://www.example.com/
request.php?read-NNNN http://www.example.com/request.php?delete- NNNN
http://www.example.com/request.php?junk-NNNN http://www.example.com/
request.php?move-NNNN-ToFolder-YYYY http://www.example.com/
request .php?delete-all
In questi esempi, NNNN è un valore univoco (probabilmente un GUID) che identifica l'elemento di posta
elettronica e YYYY è una cartella di destinazione.
Figura 2-4.XSRF in azione

Se l'utente si è già autenticato con il sistema di posta elettronica di back-end e l'aggressore può indurre
l'utente ad aprire una pagina Web che include un collegamento al sistema di posta elettronica dell'utente, il
browser effettuerà la richiesta come se l'utente aveva avviato lei stessa la richiesta.
Ad esempio, se la pagina Web dell'attaccante ha un collegamento come questo:
<IMG SRC=http://www.example.com/request.php?delete-98765-124871>
E Mary apre la pagina web dell'aggressore, il numero di posta elettronica 98765-124871 verrà rimosso
dalla posta in arrivo di Mary.
In breve, XSRF è quando il server non è in grado di dire se l'utente ha avviato fisicamente un'operazione o se un
utente malintenzionato ha causato l'avvio dell'operazione da parte del browser dell'utente.
Diamo un'occhiata ad alcuni esempi di codice peccaminoso.
Rubino peccaminoso su rotaie (XSS)

Proprio come con qualsiasi altro linguaggio e framework di programmazione web, è davvero molto semplice
creare problemi XSS con Ruby on Rails:
<%= commento.corpo %>
Sinful Ruby on Rails (Divisione della risposta)

La seguente singola riga di codice da un'applicazione Ruby on Rails apre la tua nuova brillante
applicazione web a un peccato RS se l'argomento per redirect_to non è attendibile.
redirect_to(url)
Applicazione CGI peccaminosa in Python (XSS)

Questo codice prende l'input da un modulo e lo riecheggia senza riguardo per il contenuto.
importa cgi
modulo = cgi.FieldStorage()
email = form.getvalue("EmailAddress") print
"Content-Type: text/html" print
print "<P>Ciao: %s</P>" % (email)
Applicazione CGI peccaminosa in Python (divisione della risposta)

Questo è molto simile al codice precedente, ma il codice imposta un cookie utilizzando dati non attendibili.
importa cgi
importare Cookie
c = Cookie.SimpleCookie() form =
cgi.FieldStorage()
email = form.getvalue("EmailAddress") c['addr'] =
email
Sinful ColdFusion (XSS)

Questo codice prende l'input da un modulo e semplicemente lo fa eco all'utente.
<cfoutput>
ID oggetto: #Form.itemID#
</cfoutput>
Sinful ColdFusion (XSS)

Analogamente al codice precedente, questo codice non emette l'itemID come parte dell'HTML ma utilizza i
dati non attendibili come parte delle informazioni sui cookie, il che significa che i dati non attendibili non
fanno parte del corpo della risposta HTTP.
<cfcookie name = "item" value =

"#Form.itemID#">
Sinful C/C++ ISAPI (XSS)

Questo codice mostra un'applicazione ISAPI IIS che legge una stringa di query, anteponendo la
parola "Hello" e quindi inviandola al browser dell'utente.
DWORD WINAPI HttpExtensionProc(_In_ EXTENSION_CONTROL_BLOCK *lpEcb){

char szTemp [2048];
...
if (lpEcb && *lpEcb->lpszQueryString) {
sprintf_s(szTemp,
_countof(szTemp),
"Ciao, %s.",
lpEcb->lpszQueryString)
size_t dwSize = strlen_s(szTemp, _countof(szTemp)); se (dimensione
dw)
lpEcb->WriteClient(lpEcb->ConnID, szTemp, &dwSize, 0);
}
...
}
Sinful C/C++ ISAPI (divisione della risposta)

In questa riga di un esempio di codice sorgente molto più ampio, lo sviluppatore aggiunge una nuova
intestazione alla risposta HTTP e l'argomento non è attendibile.
pFC->AddHeader(pFC,"X-SomeHeader:", lpEcb->lpszQueryString);
L'esempio seguente imposta un cookie basato su dati non attendibili. Chiaramente peccaminoso.
string cookie("Set-Cookie: "); cookie.append(lpEcb-

>lpszQueryString); cookie.append("\r\n");
pFC->AddResponseHeaders(pFC, cookie.c_str(), 0);
ASP peccaminoso (XSS)

Questi esempi richiedono poche spiegazioni, a parte il fatto che <%= (utilizzato nel secondo esempio) è
uguale a Response.Write.
<% Response.Write(Request.QueryString("Nome")) %>
O
<img src='<%= Request.Querystring("Nome") %>'>
ASP peccaminoso (divisione della risposta)

In questo esempio di codice, querstrying viene utilizzato come URL di destinazione per un reindirizzamento.
Response.Redirect base + "/checkout/main.asp? " + Request.QueryString()
Forme ASP.NET peccaminose (XSS)

In questo esempio, ASP.NET tratta una pagina Web come un modulo e può leggere e scrivere elementi
del modulo come se fossero un Windows Form. Ciò può rendere problematica la ricerca di problemi
XSS perché il lavoro di richiesta e risposta viene gestito dal runtime di ASP.NET.
private void btnSubmit_Click(oggetto mittente, System.EventArgs e) {

lblGreeting.Text = txtName.Text;
}
Sinful ASP.NET (divisione della risposta)

Il seguente frammento di codice C# mostra come indurre un bug RS nel codice, in questo caso impostando un
cookie su un valore non attendibile:
protetto System.Web.UI.WebControls.TextBox txtName; . . .
nome stringa = txtName.Text;

HttpCookie cookie = new HttpCookie("nome", nome);
Response.Cookies.Add(cookie);
Peccaminoso JSP (XSS)

Questi esempi sono praticamente gli stessi degli esempi ASP.
<% out.println(request.getParameter("Nome")) %>
<%= request.getParameter("Nome") %>
Sinful JSP (divisione della risposta)

Il seguente codice RS in JSP è altrettanto semplice da scrivere come in qualsiasi altro linguaggio di
programmazione. Come puoi vedere, il parametro "lcid" viene utilizzato per determinare a quale pagina Web
reindirizzare.
<%
response.sendRedirect("/language.jsp?lcid="+
request.getParameter("lcid"));
%>
PHP peccaminoso (XSS)

Questo codice legge la variabile name dalla richiesta in arrivo, quindi fa eco alla stringa
di query:
<?php
$nome=$_GET['nome'];
if (asset($nome)) {
echo "Ciao $nome";
}
?>
Sinful PHP (divisione della risposta)

In questo esempio di codice viene aggiunta una nuova intestazione controllata dall'attaccante:
<?php
$lcid = $_GET['lcid'];
...
header("locale: $lcid");
?>
Sinful CGI usando Perl (XSS)

Questo codice è quasi uguale al codice PHP:
# !/usr/bin/perl
usa CGI;
usare rigoroso;
my $cgi = nuovo CGI; print
CGI::header();
my $nome = $cgi->param('nome'); print
"Ciao, $nome";
Sinful mod_perl (XSS)

L'interprete mod_perl spesso richiede un po' più di codice rispetto a CGI che utilizza Perl per produrre
l'output HTML. A parte qualche codice di impostazione dell'intestazione, questo esempio è uguale agli
esempi CGI e PHP.
# !/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;
$apr->print("Ciao");
$apr->stampa($nome);
Sinful mod_perl (Divisione della risposta)

Codice simile a quello precedente, ma piuttosto che utilizzarestampa(),utilizzandointestazione_out() con dati
non attendibili, è peccaminoso.
Richieste HTTP peccaminose (XSRF)

Potresti pensare: "Perché HTTP, perché non Perl, Python o C#?" Ricorda, i bug XSRF sono
dovuti al fatto che il server ha troppa fiducia nel client o, più precisamente, il server ritiene
che la richiesta provenga da una richiesta utente valida. Anche solo guardare l'HTML lato
client non ti darà tutte le risposte, ma se vedi qualcosa come il codice che segue nel codice
client, allora dovresti avere motivo di preoccupazione.
http[s]://example.com?qualcheverbo
INDIVIDUARE IL MODELLO DEL PECCATO

Qualsiasi applicazione con il seguente pattern è a rischio di cross-site scripting:
- L'applicazione Web accetta l'input da un'entità HTTP come una stringa di query, un'intestazione
o un modulo.
- L'applicazione non verifica la validità dell'input.

- L'applicazione ritrasmette i dati in un browser, nell'HTML o nelle intestazioni
HTTP.
Discutiamo brevemente di individuare il sin pattern XSRF.
INDIVIDUARE IL PECCATO XSS DURANTE LA REVISIONE DEL CODICE

Quando si esamina il codice per XSS e i bug correlati, cercare il codice che legge da un qualche tipo di oggetto
richiesta e quindi passa i dati letti dall'oggetto richiesta a un oggetto risposta. In realtà è difficile mostrare il
codice del server che mostra questo tipo di vulnerabilità, poiché è davvero un problema di progettazione
piuttosto che un problema di codifica!
L'autore di questo capitolo ama scansionare il codice per i seguenti costrutti:
Lingua Parole chiave da cercare
ASP.NET PathInfo, Request.*, Response.*, <%= e manipolazione

di oggetti di pagine Web come *.text o
* . valore quando i dati non sono convalidati
correttamente. Nota, ASP.NET codificherà correttamente
molte proprietà .text e .value, ma non tutte.
Pagine server attive (ASP) Request.*, Response.* e <%= quando i dati non sono
convalidati correttamente.
Rubino sulle rotaie <%=, cookie o redirect_to con dati non attendibili.
Pitone form.getvalue, SimpleCookie quando i dati non sono
convalidati correttamente.
Fusione fredda <cfoutput>, <cfcookie> e <cfheader>.
PHP Accesso a $_REQUEST, $_GET, $_POST o
$_SERVER seguito da echo, print, header o
printf.
PHP 3.0 e versioni precedenti (è necessario Accesso a $HTTP_ seguito da echo, print o
eseguire l'aggiornamento!) printf.
Lingua Parole chiave da cercare
CGI/Perl Chiamare param() in un oggetto CGI.
mod_perl Apache::Request seguito da Apache::Response o

header_out.
ISAPI (C/C++) Lettura da un elemento dati in
EXTENSION_CONTROL_BLOCK, come
lpszQueryString, o un metodo come
GetServerVariable o ReadClient, quindi
chiamata WriteClient con i dati o passaggio
di dati simili a AddResponseHeaders.
ISAPI (Classi Microsoft CHttpServer o CHttpServerFilter e quindi
Foundation) scrivere in un oggetto CHttpServerContext.
Pagine JavaServer (JSP) addCookie, getRequest, request.getParameter
seguito da <jsp:setProperty o <%= o
response.sendRedirect.
Una volta che ti rendi conto che il codice sta eseguendo input e output, devi ricontrollare se i dati
sono disinfettati e ben formati o meno. In caso contrario, probabilmente hai un bug di sicurezza XSS.
I dati potrebbero non passare direttamente da un oggetto richiesta a un oggetto risposta; potrebbe esserci qualche
intermediario come un database, quindi fai attenzione anche a questo.
Individuazione del peccato XSRF durante la revisione del codice

Per i problemi XSRF, la revisione del codice è complicata perché hai a che fare con un problema di
progettazione. Come minimo, è necessario identificare e valutare tutto il codice che crea URL che seguono
questo schema:
http[s]://example.com?qualcheverbo
Pensa a come un utente malintenzionato può trarre vantaggio da quel tipo di URL.
TECNICHE DI PROVA PER TROVARE IL PECCATO

Il modo più semplice per testare i problemi XSS (non XSRF) consiste nell'effettuare una richiesta sulla
tua applicazione Web e impostare tutti i parametri di input su un valore dannoso noto. Quindi guarda
la risposta HTML; non guardare la rappresentazione visiva della risposta. Guarda il flusso di byte HTML
non elaborato e verifica se i dati che hai inserito ritornano. In tal caso, potresti avere problemi XSS nel
tuo codice. Questo semplice codice Perl mostra la base di tale test:
# !/usr/bin/perl
usa HTTP::Request::Common qw(POST GET); usa
LWP::UserAgent;
# Imposta la stringa dell'agente utente.

my $ua = LWP::UserAgent->new(); $ua-
>agente("XSSInject/v1.40");
# Stringhe di iniezione
my @xss = ('><script>alert(window.location);</script>',
'\"; avviso(1);',
'\' onmouseover=\'alert(1);\' \'',
'\"><script>alert(1);</script>',
'\"<<script>alert(1);</ script>', '\"></
a><script>alert(1);</script>', '{[alert(1)]};',
'\xC0\xBCscript>[foo]\xC0\xBC/script>', '</XSS/*-*/STYLE=xss:e/**/
xpression(alert(\'XSS\'))>', '<a href=\”javascript#foo\”>',
'xyzzy');
# Costruisci la richiesta.
mio $url = "http://127.0.0.1/form.asp"; my
$inject;
foreach $inject (@xss) {
my $req = POST $url, [Nome => $inject,
Indirizzo => $iniettare,
Zip => $iniettare];
my $res = $ua->request($req);
# Ottieni la risposta.
# Se vediamo lo script iniettato, potremmo avere un problema. $_ =
$res->come_stringa;
print "Potenziale problema XSS [$url]\n" if (index(lc $_, lc $inject)!=-1);
}
Il sito http://ha.ckers.org mantiene un cheat sheet XSS che include stringhe per aiutare a
bypassare i controlli XSS. Vedere la sezione "Altre risorse" per tutti i dettagli.
Sono disponibili numerosi strumenti per testare i bug XSS e XSRF, inclusi, ma non
limitati a, i seguenti:
- Watchfire AppScan di IBM: www-304.ibm.com/jct09002c/gsdod/

solutiondetails.do?solution=16838
- libwhisker: sourceforge.net/projects/whisker/
- DevPartner SecurityChecker di Compuware:

www.compuware.com/products/devpartner/securitychecker.htm
- WebScarab: www.owasp.org/software/webscarab.html
- CAT.NET: http://snurl.com/89f0p
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à.
CVE-2003-0712 Microsoft Exchange 5.5 Outlook Web Access XSS

Il 15 ottobre 2003, Microsoft ha emesso un bollettino sulla sicurezza, MS03-047, che risolveva una
vulnerabilità XSS nel front-end Web di Outlook Web Access (OWA) al software Exchange 5.5 di
Microsoft. Questo è un classico esempio di peccato XSS. Guarda come viene ripetuta la variabile urlView
alla fine dello snippet di codice senza alcuna sanificazione o codifica dell'input.
<%
in caso di errore riprendere
successivo . . .
urlView = Request.QueryString("visualizza")
%>
<HTML>
<TITLE>Microsoft Outlook Web Access</TITLE> <script
language='javascript'>
...
var iCurView = <%=urlView%>;
CVE-2004-0203 Microsoft Exchange 5.5 Outlook Web Access

Divisione della risposta
Il 10 agosto 2004 Microsoft ha emesso un altro bollettino, MS04-026, nello stesso componente OWA
corretto in MS03-047, ma questa volta per correggere un bug di suddivisione della risposta HTTP.
<% @ LANGUAGE=VBSCRIPT CODEPAGE = 1252 %>   <% SendHeader 0, 1%>
 
<%
In caso di errore Riprendi Avanti
If Request.QueryString("mode") <> "" Then

Response.Redirect bstrVirtRoot + _ "/inbox/Main_fr.asp?" +
Request.QueryString() End If
Probabilmente hai appena notato che abbiamo elencato due vulnerabilità nello stesso componente che
sono state risolte da due aggiornamenti rilasciati a quasi un anno di distanza! Quello che è successo? È
interessante notare che le correzioni del codice erano relativamente vicine l'una all'altra. Al momento in cui
Microsoft ha rilasciato MS03-047, il mondo non aveva sentito parlare delle vulnerabilità di HTTP Response
Splitting. Quindi, il 4 marzo 2004, Sanctum (acquistato da Watchfire, che da allora è stato acquistato da IBM)
ha pubblicato un documento intitolato "Divide and Conquer" che descrive la variazione XSS. Quando gli
ingegneri Microsoft hanno risolto il primo bug, la seconda classe di bug era sconosciuta.
Questo è un meraviglioso esempio della massima "Gli attacchi migliorano solo".
CVE-2005-1674 Centro assistenza dal vivo (XSS e XSRF)

Ciò che rende interessante questo CVE è il buffet di correzioni di bug. C'è tutto: scripting
cross-site, contraffazione di richieste cross-site e SQL injection per completare le cose.
L'applicazione web Help Center Live PHP utilizza le richieste GET per eseguire alcune attività
amministrative; ad esempio, quanto segue eliminerà un ticket di assistenza:
http://www.example.com/support/cp/tt/view.php?tid=2&delete=1
FASI DI RISCATTO (XSS E DIVISIONE DELLA RISPOSTA)

Ci sono due passaggi sulla strada per la redenzione della suddivisione della risposta XSS e HTTP:
1. Limita l'input solo a input validi. Molto probabilmente userai espressioni

regolari per questo.
2. Codificare l'output. Utilizzerai la codifica HTML o la codifica URL, a seconda
del modulo di output (corpo HTML o intestazioni HTTP)
3. Per l'input che finisce nelle intestazioni, rimuovi in modo aggressivo le
combinazioni CRLF.
Dovresti davvero eseguire tutte le serie di passaggi di riscatto nel tuo codice; i seguenti esempi di codice
illustrano come eseguire uno o entrambi i passaggi.
Riscatto Ruby on Rails (XSS)

Per fortuna, Ruby on Rails semplifica l'evasione dell'output per renderlo più sicuro. Si noti l'inclusione
dell'operatore "h" dopo <%=, che è un metodo helper di Rails per eseguire l'escape dei dati prima che
vengano emessi.
<%=h comment.body %>

Redenzione ISAPI C/C++ (XSS)

Chiamare il codice come il codice che segue prima di scrivere i dati nel browser
codificherà l'output.
///////////////////////////////////////////////////// ////////////////// // HtmlEncode
// Converte un flusso HTML non elaborato in una versione con codifica HTML //
Args
// strRaw: puntatore ai dati HTML
// risultato: un riferimento al risultato, contenuto in std::string
// Ritorna
// false: impossibile codificare tutti i dati HTML true:
// codificati tutti i dati HTML
bool HtmlEncode(const char *strRaw, std::string &risultato) {
size_t iLen = 0;
dimensione_t i = 0;
if (strRaw && (iLen=strlen(strRaw))) {
per (i=0; i < iLen; i++)
switch(strRaw[i]) {
case '\0' : break; caso '<'
: risultato.append("<"); rottura; :
caso '>' risultato.append(">"); rottura; :
caso '(' risultato.append("("); rottura; :
caso ')' risultato.append(")"); rottura; :
caso '#' risultato.append("#"); rottura; :
caso '&' risultato.append("&"); rottura; :
caso '"' risultato.append("""); rottura;
case '\'' : result.append("'"); rottura; caso '%'
: risultato.append("%"); rottura; :
caso '+' risultato.append("+"); rottura; :
caso '-' risultato.append("-"); rottura; :
predefinito risultato.append(1,strRaw[i]); rottura;
}
}
return i == iLen ? vero falso;
}
Se si desidera utilizzare le espressioni regolari in C/C++, è necessario utilizzare il supporto per le

espressioni regolari incluso nell'aggiornamento del rapporto tecnico 1 della libreria di modelli standard
(STL TR1). Ad esempio, il seguente codice verificherà se un indirizzo IP è valido o meno:
# include <regex>
...
usando lo spazio dei nomi

std::tr1; . . .
regex rx("^(\\d{1,2}|1\\d\\d|2[0-4]\\d|25[0-5])\\."
"(\\d{1,2}|1\\d\\d|2[0-4]\\d|25[0-5])\\." "(\\d{1,2}|1\\d\
\d|2[0-4]\\d|25[0-5])\\." "(\\d{1,2}|1\\d\\d|2[0-4]\\d|
25[0-5])$");
if (regex_match(strIP,rx)) {
// valido
} altro {
// Non valido
}
Questa libreria è disponibile in Visual C++ 2008 SP1 e versioni successive e gcc 4.3 e versioni successive.
Redenzione Python (XSS)

Nel caso di Python, nella sua forma più semplice, dovresti eseguire l'escape dell'input utilizzato come output; per fare
ciò, usa cgi.escape():
importa cgi
modulo = cgi.FieldStorage()
email = form.getvalue("EmailAddress") print
"Content-Type: text/html" print
print "<P>Ciao: %s</P>" % (cgi.escape(email))
Rimborso ASP (XSS)

Usa una combinazione di espressioni regolari (in questo caso, l'oggetto VBScript RegExp, ma
chiamandolo da JavaScript) e la codifica HTML per disinfettare i dati HTML in arrivo:
<%
nome = Richiesta.Querystring("Nome")
Imposta r = new RegExp
r.Pattern = "^\w{5,25}$"
r.IgnoreCase = Vero
Impostare m = r.Execute(name)
If (len(m(0)) > 0) Then
Response.Write(Server.HTMLEncode(nome)) End If
%>
Riscatto di Web Form ASP.NET (XSS)

Questo codice è simile all'esempio precedente, ma usa le librerie .NET Framework e C#
per eseguire l'espressione regolare e la codifica HTML.
utilizzando System.Web; // Assicurati di aggiungere l'assembly System.Web.dll . . .
private void btnSubmit_Click(oggetto mittente, System.EventArgs e) {
Regex r = new Regex(@"^\w{5,25}"); if

(r.Match(txtValue.Text).Success) {
lblName.Text = "Ciao, " + HttpUtility.HtmlEncode(txtValue.Text); } altro {
lblName.Text = "Chi sei?";

}
Una soluzione più robusta consiste nell'utilizzare la libreria Microsoft AntiXss per ripulire l'output come
mostrato nel seguente frammento di codice ASP.NET:
utilizzando Microsoft.Security.Application; . . .
lblName.Text = "Ciao," + AntiXss.HtmlEncode txtValue.Text);
AntiXss è più robusto della codifica HTML per due motivi:
- Fa più della semplice codifica HTML; ad esempio, può codificare XML, script
e URL.
- Funziona in modo più sicuro non codificando ciò che è noto per essere sicuro, ma
codificando tutto il resto. La codifica HTML codifica ciò che sa essere potenzialmente
pericoloso e che non può mai essere totalmente sicuro a lungo termine.
ASP.NET Web Form Redemption (RS)

Questo è l'esempio di codice del cookie ASP.NET reso più sicuro utilizzando i metodi AntiXss UrlEncode()
e un semplice controllo per verificare che la stringa codificata non sia troppo lunga e che la versione
codificata sia uguale alla versione in entrata non attendibile. L'ultimo passaggio è davvero hardcore,
ma è efficace!
utilizzando Microsoft.Security.Application; . . .
protetto System.Web.UI.WebControls.TextBox txtName; . . .
static int MAX_COOKIE_LEN = 32; . . .
nome stringa = AntiXss.UrlEncode(txtName.Text); if (r.Equals(s)

&& r.Length < MAX_COOKIE_LEN) {
HttpCookie cookie = new HttpCookie("nome", nome);

Response.Cookies.Add(cookie);
}
Riscatto JSP (XSS)

JSP ha un porting di AntiXss di Microsoft chiamato AntiXSS per Java; vedere la sezione "Altre
risorse" per ulteriori informazioni.
In JSP, probabilmente useresti un tag personalizzato. Questo è il codice di un tag codificatore HTML:
importa java.io.IOException; import

javax.servlet.jsp.JspException; import
javax.servlet.jsp.tagext.BodyTagSupport;
classe pubblica HtmlEncoderTag estende BodyTagSupport {

public HtmlEncoderTag() {
super();
}
public int doAfterBody() genera JspException {
if(corpoContenuto != null) {
System.out.println(bodyContent.getString()); Contenuto
della stringa = bodyContent.getString(); String regExp =
new String("^\\w{5,25}$");
// Esegui una regex per trovare le cose buone

if (contents.matches(regExp)) {
Tentativo {
bodyContent.getEnclosingWriter().
scrivere(contenuto);
} cattura (IOException e) {
System.out.println("Eccezione" + e.getMessage());
}
restituisce EVAL_BODY_INCLUDE;
} altro {
Tentativo {
bodyContent.getEnclosingWriter().
write(codifica(contenuto)); }
cattura (IOException e) {
System.out.println("Eccezione" + e.getMessage());
}
System.out.println("Contenuto: " + content.toString());

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

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

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

Caricato da

Copyright:

Formati disponibili

Tradotto dal Inglese al Italiano - www.onlinedoctranslator.

22 24 peccati capitali della sicurezza del software

Redenzione di Ruby on Rails

Java utilizzando il riscatto JDBC

System.out.println("Classe non trovata: " + e2.toString()); restituire falso;

Si noti l'uso diCFSQLTYPEper limitare ulteriormente i dati in entrata.

CREATE PROCEDURE dbo.doQuery(@id nchar(4)) AS

DICHIARARE @query nchar(64)

O, meglio ancora, forza il parametro a essere un numero intero:

CREA PROCEDURA dbo.doQuery(@id smallint)

Usa QUOTENAME e REPLACE

Dovresti usare DBMS_ASSERT?

nome stringa = txtName.Text; . . .

MISURE EXTRA DIFENSIVE

Figura 1-1.CAT.NET che individua una vulnerabilità di SQL injection

Crittografa i dati sensibili, PII o riservati

- 2009 CWE/SANS Primi 25 errori di programmazione più pericolosi:

- Standard di sicurezza dei dati del settore delle carte di

- L'Open Web Application Security Project (OWASP):

- Riferimento tascabile per le espressioni regolari Oracledi Jonathan Gennick e

- ColdFusion cfqueryparam: www.adobe.com/livedocs/coldfusion/5.0/

- Fareutilizzare query con parametri, note anche come istruzioni preparate,

- Fareutilizzare le funzioni di citazione o di delimitazione se è necessario creare categoricamente

- Farearchiviare le informazioni di connessione al database in una posizione esterna

- Farecrittografare i dati sensibili del database.

- Nonelimina semplicemente le "parolacce". Ci sono spesso una miriade di varianti e

- Noneseguire parametri non attendibili all'interno di stored procedure.

- Nonverificare la validità dell'input solo presso il client.

- Nonconnettersi al database come account con privilegi elevati, ad esempio sa

- Nonmemorizzare le informazioni di configurazione del database nella radice web.

- Prendere in considerazionerimuovere l'accesso a tutte le tabelle definite dall'utente nel

PANORAMICA DEL PECCATO

- In terzo luogo, l'avvento delle applicazioni Asynchronous JavaScript e XML (AJAX),

- CWE-352: falsificazione di richieste tra siti (CSRF)

- XSS basato su DOM, noto anche come XSS locale o tipo 0

- XSS memorizzato, chiamato anche XSS persistente o tipo 2

- Suddivisione della risposta HTTP

- Falsificazione di richieste cross-site (XSRF, a volte CSRF)

Diamo un'occhiata a ciascun peccato un po' più in dettaglio.

XSS basato su DOM o tipo 0

XSS riflesso, XSS non persistente o tipo 1

come input per il campo sinful o querystring.

XSS memorizzato, XSS persistente o Tipo 2

Divisione della risposta HTTP

Figura 2-3.La differenza tra XSS e HTTP Response Splitting

HTTP/1.1 302 Oggetto spostato Ubicazione:

HTTP/1.1 302 Posizione dell'oggetto spostato:

Falsificazione di richieste cross-site

Figura 2-4.XSRF in azione

Rubino peccaminoso su rotaie (XSS)

<%= commento.corpo %>

Sinful Ruby on Rails (Divisione della risposta)

Applicazione CGI peccaminosa in Python (XSS)

print "<P>Ciao: %s</P>" % (email)

Applicazione CGI peccaminosa in Python (divisione della risposta)

Sinful ColdFusion (XSS)

Sinful ColdFusion (XSS)

<cfcookie name = "item" value =

Sinful C/C++ ISAPI (XSS)

DWORD WINAPI HttpExtensionProc(_In_ EXTENSION_CONTROL_BLOCK *lpEcb){

Sinful C/C++ ISAPI (divisione della risposta)

string cookie("Set-Cookie: "); cookie.append(lpEcb-

pFC->AddResponseHeaders(pFC, cookie.c_str(), 0);

ASP.NET PathInfo, Request., Response., <%= e manipolazione