






Studia grazie alle numerose risorse presenti su Docsity
Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium
Prepara i tuoi esami
Studia grazie alle numerose risorse presenti su Docsity
Prepara i tuoi esami con i documenti condivisi da studenti come te su Docsity
Trova i documenti specifici per gli esami della tua università
Preparati con lezioni e prove svolte basate sui programmi universitari!
Rispondi a reali domande d’esame e scopri la tua preparazione
Riassumi i tuoi documenti, fagli domande, convertili in quiz e mappe concettuali
Studia con prove svolte, tesine e consigli utili
Togliti ogni dubbio leggendo le risposte alle domande fatte da altri studenti come te
Esplora i documenti più scaricati per gli argomenti di studio più popolari
Ottieni i punti per scaricare
Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium
Traduzione delle slide del corso di Sicurezza delle Reti dell'Università di Pisa, con eventuali approfondimenti
Tipologia: Traduzioni
1 / 11
Questa pagina non è visibile nell’anteprima
Non perderti parti importanti!







Attacchi tipici nel Web.
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.
Attacco XSS: panoramica generale.
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:
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:
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
▪ Il collegamento viene caricato nel browser senza interazione dell'utente, ma in un dominio di origine diverso
▪ 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
◦ 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