Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Attacchi ai sistemi web, Traduzioni di Sicurezza delle reti

Traduzione delle slide del corso di Sicurezza delle Reti dell'Università di Pisa, con eventuali approfondimenti

Tipologia: Traduzioni

2018/2019

Caricato il 28/02/2019

maurizius7
maurizius7 🇮🇹

5

(1)

21 documenti

1 / 11

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
SICUREZZA DEL CLOUD COMPUTING.
Attacchi tipici nel Web.
Input non convalidato
SQL Injection utile contro SaaS→ utile contro SaaS
Cross-Site-Scripting (XSS)
Errori di progettazione Attacchi al client
Cross-Site-Request-Forgery (XSRF)
Condizioni al contorno
La gestione delle eccezioni
Convalida accesso
SQL injection è una tecnica di code injection, usata per attaccare applicazioni di gestione dati,
con la quale vengono inserite delle stringhe di codice SQL malevole all'interno di campi di input
in modo che queste ultime vengano poi eseguite (ad esempio per fare inviare il contenuto del
database all'attaccante). L'SQL injection sfrutta le vulnerabilità di sicurezza del codice di
un'applicazione, ad esempio quando l'input dell'utente non è correttamente filtrato da 'caratteri
di escape' contenuti nelle stringhe SQL oppure non è fortemente tipizzato e viene eseguito
inaspettatamente. L'SQL injection è più conosciuto come attacco per i siti web, ma è anche
usato per attaccare qualsiasi tipo di database SQL.
SQL in pagine Web
SQL Injection di solito si verifica quando si richiede un input da parte dell'utente, come il
proprio nome utente / userid, e invece di un nome / id, l'utente fornisce un'istruzione SQL che
verrà eseguita inconsapevolmente sul proprio database.
Guarda il seguente esempio che crea un'istruzione SELECT aggiungendo una variabile
(txtUserId) a una stringa di selezione. La variabile viene recuperata dall'input dell'utente
(getRequestString):
Esempio:
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
SQL Injection basato su 1 = 1 è sempre True
Guarda l'esempio sopra di nuovo. Lo scopo originale del codice era creare un'istruzione SQL
per selezionare un utente, con un determinato ID utente.
Se non c'è nulla che impedisca a un utente di inserire input "errati", l'utente può inserire alcuni
input "intelligenti" come questo:
UserId: 105 o 1 = 1
Quindi, l'istruzione SQL sarà simile a questa:
SELECT * FROM Users WHERE UserId = 105 OR 1=1;
L'SQL precedente è valido e restituirà TUTTE le righe dalla tabella "Utenti", poiché OR 1 = 1 è
sempre TRUE. L'esempio sopra sembra pericoloso? Cosa succede se la tabella "Utenti" contiene
nomi e password? L'istruzione SQL sopra è molto simile a questa:
SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1;
Un hacker potrebbe ottenere l'accesso a tutti i nomi utente e le password in un database,
semplicemente inserendo 105 OR 1 = 1 nel campo di input.
SQL Injection basato su "" = "" è sempre vero
Qua sotto un esempio di login:
Username: John Doe
Password: myPass
pf3
pf4
pf5
pf8
pf9
pfa

Anteprima parziale del testo

Scarica Attacchi ai sistemi web e più Traduzioni in PDF di Sicurezza delle reti solo su Docsity!

SICUREZZA DEL CLOUD COMPUTING.

Attacchi tipici nel Web.

  • Input non convalidato ◦ SQL Injection → utile contro SaaSutile contro SaaS ◦ Cross-Site-Scripting (XSS)
  • Errori di progettazione Attacchi al client ◦ Cross-Site-Request-Forgery (XSRF)
  • Condizioni al contorno
  • La gestione delle eccezioni
  • Convalida accesso SQL injection è una tecnica di code injection, usata per attaccare applicazioni di gestione dati, con la quale vengono inserite delle stringhe di codice SQL malevole all'interno di campi di input in modo che queste ultime vengano poi eseguite (ad esempio per fare inviare il contenuto del database all'attaccante). L'SQL injection sfrutta le vulnerabilità di sicurezza del codice di un'applicazione, ad esempio quando l'input dell'utente non è correttamente filtrato da 'caratteri di escape' contenuti nelle stringhe SQL oppure non è fortemente tipizzato e viene eseguito inaspettatamente. L'SQL injection è più conosciuto come attacco per i siti web, ma è anche usato per attaccare qualsiasi tipo di database SQL. SQL in pagine Web SQL Injection di solito si verifica quando si richiede un input da parte dell'utente, come il proprio nome utente / userid, e invece di un nome / id, l'utente fornisce un'istruzione SQL che verrà eseguita inconsapevolmente sul proprio database. Guarda il seguente esempio che crea un'istruzione SELECT aggiungendo una variabile (txtUserId) a una stringa di selezione. La variabile viene recuperata dall'input dell'utente (getRequestString): Esempio:

txtUserId = getRequestString("UserId");

txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

SQL Injection basato su 1 = 1 è sempre True Guarda l'esempio sopra di nuovo. Lo scopo originale del codice era creare un'istruzione SQL per selezionare un utente, con un determinato ID utente. Se non c'è nulla che impedisca a un utente di inserire input "errati", l'utente può inserire alcuni input "intelligenti" come questo: UserId: 105 o 1 = 1 Quindi, l'istruzione SQL sarà simile a questa: SELECT * FROM Users WHERE UserId = 105 OR 1=1; L'SQL precedente è valido e restituirà TUTTE le righe dalla tabella "Utenti", poiché OR 1 = 1 è sempre TRUE. L'esempio sopra sembra pericoloso? Cosa succede se la tabella "Utenti" contiene nomi e password? L'istruzione SQL sopra è molto simile a questa: SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1; Un hacker potrebbe ottenere l'accesso a tutti i nomi utente e le password in un database, semplicemente inserendo 105 OR 1 = 1 nel campo di input. SQL Injection basato su "" = "" è sempre vero Qua sotto un esempio di login: Username: John Doe Password: myPass

Codice che recepisce le credenziali: uName = getRequestString("username"); uPass = getRequestString("userpassword"); sql = 'SELECT * FROM Users WHERE Name ="' + uName + '" AND Pass ="' + uPass + '"' Risultato: SELECT * FROM Users WHERE Name ="John Doe" AND Pass ="myPass" Un hacker potrebbe ottenere l'accesso ai nomi utente e alle password in un database semplicemente inserendo "OR" "=" nella casella di testo nome utente o password: Username: “ or “”=” Password: “”=” Il codice sul server creerà un'istruzione SQL valida come questa: SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""="" Lo SQL sopra è valido e restituirà tutte le righe dalla tabella "Users", poiché OR "" = "" è sempre TRUE. SQL Injection basato su dichiarazioni SQL in batch La maggior parte dei database supporta istruzioni SQL in batch. Un batch di istruzioni SQL è un gruppo di due o più istruzioni SQL, separate da punti e virgola. L'istruzione SQL seguente restituirà tutte le righe dalla tabella "Utenti", quindi eliminerà la tabella "Fornitori". SELECT * FROM Users; DROP TABLE Suppliers Guardando il seguente esempio: txtUserId = getRequestString("UserId"); txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId; E il seguente input: Userid: 105; DROP TABLE Suppliers L'istruzione SQL valida sarebbe simile a questa: SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers; Prevenire SQL Injection.

  • Liste bianche (Whitelist) → utile contro SaaS ◦ Perché? I caratteri in blacklist non funzionano: ▪ dimentica di filtrare alcuni caratteri ▪ Potrebbe impedire l'input valido (ad esempio, nome utente O'Brien) ◦ Consenti un insieme ben definito di valori sicuri: ▪ [A-Za-Z0-9] * ▪ [0-1] [0-9] ◦ Set di input valido definito tramite reg. espressioni ◦ Può essere implementato in un firewall per applicazioni Web
  • Escaping ◦ Per ingressi stringa validi come username o'connor, usa escape ▪ caratteri. Es: escape (o'connor) = o''connor (funziona solo per gli input stringa) Dichiarazioni preparate e variabili di binding query parsed w / o parametri bind le variabili vengono digitate per es. int, string, ecc ... *

Attacco XSS: panoramica generale.

  1. L'attaccante invia codice dannoso
  2. Il server memorizza il messaggio
  3. L'utente richiede un messaggio
  4. Il messaggio viene consegnato dal server
  5. Il browser esegue lo script nel messaggio CERT® Advisory CA-2000-02 Tag HTML dannosi incorporati nelle richieste Web del client Data di rilascio originale: 2 febbraio 2000 Ultima revisione: 3 febbraio 2000 Un sito Web potrebbe inavvertitamente includere tag o script HTML malevoli in una pagina generata dinamicamente in base all'input non convalidato proveniente da fonti non attendibili. Questo può essere un problema quando un server Web non garantisce in modo adeguato che le pagine generate siano codificate correttamente per impedire l'esecuzione involontaria di script e quando l'input non viene convalidato per impedire che l'HTML dannoso venga presentato all'utente.
  • XSS è un vecchio problema
    • Prima attenzione pubblica 5 anni fa
    • Ora regolarmente elencato su BUGTRAQ
  • Tuttavia sono interessate molte applicazioni Web Qual è la fonte del problema?
    • Controllo di input / output insufficiente!
    • Problema vecchio come i linguaggi di programmazione Cosa è affetto da XSS? Il primo obiettivo dell'attacco XSS è il client
    • Il client si fida del server (non si aspetta un attacco)
    • Il browser esegue script dannosi Ma secondo obiettivo = azienda che esegue il server
    • Perdita di immagine pubblica (colpa)
    • Perdita di fiducia dei clienti
    • Perdita di denaro L’impatto di un attacco XSS: Accesso alle credenziali di autenticazione per l'applicazione Web, ottenendo quindi Cookies, nome utente e password → utile contro SaaSXSS non è quindi un difetto innocuo! Per quanto riguarda invece gli utenti normali:
    • Accesso ai dati personali (carta di credito, conto bancario)
    • Accesso ai dati aziendali (dettagli dell'offerta, dettagli di costruzione)
    • Account abusivo (ordina beni costosi) Per gli utenti con privilegi elevati:
    • Controllo sull'applicazione Web
    • Controllo / accesso: macchina server Web
    • Controllo / accesso: sistemi di backend / database Denial-of-Service
    • Crash Users`Browser, Pop-Up-Flodding, Reindirizzamento Accesso al computer degli utenti
    • Usa oggetti ActiveX per controllare la macchina
    • Carica i dati locali sulla macchina dell'attaccante Vizia l'immagine pubblica della compagnia
    • Carica il contenuto del frame principale da "altri" percorsi
    • Reindirizza al download di dialer Attacco Riflessivo XSS

Reflected: l’ aggressore crea un Url appositamente studiato per compiere l’attacco, ad esempio un link che arriva sulla propria casella di posta nei messaggi di phishing. Le vulnerabilità cross-site scripting di tipo reflected sono sicuramente le più comuni. È possibile sfruttarle quando i dati forniti dall'utente (di solito tramite form HTML) sono usati immediatamente dallo script lato server per costruire le pagine risultanti senza controllare la correttezza della richiesta. Dato che i documenti HTML hanno una struttura piatta in cui sono mescolate istruzioni di controllo, di formattazione e di contenuto effettivo, se tutti i dati forniti dall'utente non validati sono inclusi nella pagina risultante senza un'adeguata codifica HTML, questo può portare a iniezione di codice di markup. Un esempio classico di un potenziale vettore è il motore di ricerca del sito: se si cerca una stringa, in genere questa verrà visualizzata di nuovo nella pagina dei risultati per indicare cosa si è cercato. Se questa risposta non evita o rigetta i caratteri di controllo HTML si consegue che è vulnerabile ad attacchi cross-site scripting. Un attacco non persistente è tipicamente inviato via mail o da un sito web neutrale. L'esca è un URL dall'aspetto innocente, che punta a un sito attendibile ma che contiene un vettore XSS. Se il sito affidabile è vulnerabile a quel vettore, il click sul link può causare l'esecuzione di script iniettato nel browser della vittima. Attacco XSS persistente (stored). Una vulnerabilità XSS persistente (o stored) è una variante più devastante di cross-site scripting: si verifica quando i dati forniti dall'attaccante vengono salvati sul server, e quindi visualizzati in modo permanente sulle pagine normalmente fornite agli utenti durante la normale navigazione, senza aver eliminato dai messaggi visualizzati dagli altri utenti la formattazione HTML. Ad esempio, supponiamo che ci sia un sito di incontri in cui i membri visionano i profili degli altri membri per cercare interessi comuni. Per motivi di privacy, questo sito nasconde a tutti il vero nome e la mail degli utenti. Queste informazioni sono tenute segrete dal server. L'unico momento in cui il nome reale e l'email sono visualizzati è quando il membro si autentica, non potendo vedere comunque i dati di chiunque altro. Supponiamo che un attaccante si colleghi al sito e vuole capire i veri nomi delle persone che vede sul sito. Per fare ciò scrive uno script progettato per essere eseguito dal browser delle altre persone quando visitano il suo profilo. Lo script invia un breve messaggio al suo server che raccoglie queste informazioni. Per fare questo, per il quesito “Descrivi il tuo primo appuntamento ideale”, l'attaccante dà una risposta breve (dall'aspetto consueto) ma il testo alla fine della risposta è lo script per rubare i nomi e le mail. Se lo script è racchiuso all'interno di un elemento ◦ Response.Write(Session["name"]); ◦ Response.Write(Application["name"]); Cosa viene considerato Input? Non solo valori di campo con input fornito dall'utente Dovrebbe essere trattato come input: Tutti i valori dei campi: anche i campi nascosti Tutti i campi di intestazione HTTP: Referer E anche il descrittore del metodo HTTP Cosa succede se si richiede quanto segue dal proprio server Web?

◦ Non tutte le applicazioni possono essere protette Questa non è una soluzione! SSL:

  • L'attacco non è basato su falle nella sicurezza delle comunicazioni
  • L'attacco è basato su problemi di sicurezza dell'applicazione Controllo dell'input lato client:
  • Può essere sovvertito facilmente
  • Accesso diretto all'URL

GET /file.jsp?fname= CRSF (Cross Site Request Forgery) Cross-site request forgery (CSRF), noto anche come attacco con un clic o sessione: in un attacco CSRF, un sito malintenzionato ordina al browser della vittima di inviare una richiesta (pericolosa) a un sito onesto, come se la richiesta fosse parte dell'interazione della vittima con il sito onesto. Gli attacchi CSRF sono efficaci in una serie di situazioni, tra cui:

  • La vittima ha una sessione attiva sul sito di destinazione.
  • La vittima viene autenticata tramite l'autenticazione HTTP sul sito di destinazione.
  • La vittima si trova sulla stessa rete locale del sito di destinazione. Un attacco che costringe un utente finale a eseguire azioni indesiderate su un'applicazione web in cui sono attualmente autenticati. Gli attacchi CSRF mirano in modo specifico a richieste di modifica dello stato, non al furto di dati, poiché l'autore dell'attacco non ha modo di vedere la risposta alla richiesta falsificata. Con un piccolo aiuto di ingegneria sociale (come l'invio di un collegamento via e-mail o chat), un utente malintenzionato può ingannare gli utenti di un'applicazione Web nell'eseguire azioni di scelta dell'utente malintenzionato. Se la vittima è
  • un utente normale, un attacco CSRF riuscito può costringere l'utente a eseguire richieste di modifica dello stato come il trasferimento di fondi, la modifica dell'indirizzo e-mail e così via.
  • un account amministrativo, CSRF può compromettere l'intera applicazione Web. Sicurezza Cross-Domain
  • Dominio: dove sono ospitate le nostre applicazioni e servizi
  • Same-Origin-Policy (SOP): lo script è consentito solo per riconnettersi all'origine (dominio, porta, protocollo) dal quale è stato servito
  • Cross-domain: minacce alla sicurezza dovute alle interazioni tra le nostre applicazioni e pagine su altri domini Problemi con l’esportazione di dati. Abuso dell'indirizzo IP dell'utente
  • Può inviare comandi ai server all'interno di una rete protetta da firewall Lettura dello stato del browser
  • Può emettere richieste con i cookie allegati Scrittura dello stato del browser
  • Può emettere richieste che causano la sovrascrittura dei cookie "Session riding" è un nome fuorviante. Attacco CSRF. Nell'attacco CSRF, l'attaccante interrompe l'integrità della sessione utente ←→ utile contro SaaS un sito web

Stesse politiche di origine: Importante misura di sicurezza nei browser per lo scripting lato client. "Gli script possono accedere solo alle proprietà associate ai documenti della stessa origine" L'origine riflette la tripla: § Nome host § Protocollo § Porta (*) Esempi: http://www.company.com/jobs/index.html

  • http://www.company.com/news/index.html ◦ Same origin (same host, protocol, port)
  • https://www.company.com/jobs/index.html ◦ Different origin (different protocol)
  • http://www.company.com:81/jobs/index.html ◦ Different origin (different port)
  • http://company.com/jobs/index.html ◦ Different origin (different host)
  • http://extranet.company.com/jobs/index.html ◦ Different origin (different host) Gli effetti sulle stesse politiche di origine si possono riassumere in:
  • Limita le capacità di rete ◦ Legato dalla tripletta d'origine ◦ Eccezione importante: i collegamenti interdominio nel DOM sono consentiti
  • L'accesso agli elementi DOM è limitato allo stesso dominio di origine ◦ Gli script non possono leggere elementi DOM da un altro dominio La stessa politica di origine risolve XSRF? Quale può essere il danno derivante dall'iniettare gli script se viene applicata la politica origine origine? Nonostante la stessa politica di origine, i documenti di origini diverse possono ancora interagire: § Mediante collegamenti ad altri documenti § Usando iframe § Usando script esterni § Presentando le richieste § … Interazioni cross-domain.
  • Collegamenti ad altri documenti ◦ Click here! ◦ ▪ I collegamenti vengono caricati nel browser (con o senza interazione dell'utente) eventualmente utilizzando le credenziali memorizzate nella cache

▪ Il collegamento viene caricato nel browser senza interazione dell'utente, ma in un dominio di origine diverso

• Caricamento di script esterni

▪ Il dominio di origine della sceneggiatura sembra essere www.domain.com

▪ Tuttavia, lo script viene valutato nel contesto della pagina allegata ▪ Risultato: § Lo script può ispezionare le proprietà della pagina allegata § La pagina allegata può definire l'ambiente di valutazione per lo script

  • Inizializzare le richieste HTTP POST

◦ Il modulo è nascosto e inviato automaticamente dal browser, utilizzando le credenziali memorizzate nella cache ◦ Il modulo viene inviato come se l'utente abbia fatto clic sul pulsante di invio nel modulo

  • Tramite un oggetto di tipo immagine
  • Tramite proprietà document.*

◦ document.location = http://bank.com/xfer?from=1234&to=21543&amount=399;

  • Reindirizzamento via meta direttiva ◦ ecc. Prevenzione di XSRF
  • Ispezione delle intestazioni di riferimento ◦ specifica il documento che ha originato la richiesta ◦ ok, ma non è pratico dato che potrebbe essere falsificato o oscurato (anche da utenti legittimi) --------- → utile contro SaaSAttenzione plis
  • Firewall dell'applicazione Web ◦ non funziona perché la richiesta sembra autentica per bank.com ---- → utile contro SaaSAttenzione plis
  • Convalida tramite Segreto fornito dall'utente (User-Provided Secret) ◦ chiedere la password corrente per le transazioni importanti -- → utile contro SaaSOK
  • Convalida tramite "Action Token" ◦ aggiungi dei token speciali a forme "genuine" per distinguerli dalle forme "forgiate" ▪ ok! Attacco CSRF e Cloud
  • Nel piano di attacco questo può essere il primo passo di un attacco per rimuovere alcuni meccanismi di difesa che impediscono all'intruso di inviare dati / informazioni dannosi al cloud
  • Si noti che l'obiettivo può essere qualsiasi utente del cloud perché è condiviso tra organizzazioni distinte ciascuna con i propri utenti e la propria politica di sicurezza