From 7ccffe7fc0aed3d949045642958bce5ecb2f7c4d Mon Sep 17 00:00:00 2001 From: AmnesiA <57435273+Meht-evaS@users.noreply.github.com> Date: Fri, 16 Jun 2023 09:39:48 +0200 Subject: [PATCH 1/3] Per modificare file LaTex Installazione compiler LuaTex per modificare gli appunti LaTex del repository in quanto hanno delle emoji al loro interno --- .../Windows/TeXstudio + MiKTeX.txt | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 magistrale/Anno 1/Installazione compiler LuaTex/Windows/TeXstudio + MiKTeX.txt diff --git a/magistrale/Anno 1/Installazione compiler LuaTex/Windows/TeXstudio + MiKTeX.txt b/magistrale/Anno 1/Installazione compiler LuaTex/Windows/TeXstudio + MiKTeX.txt new file mode 100644 index 000000000..994a11c04 --- /dev/null +++ b/magistrale/Anno 1/Installazione compiler LuaTex/Windows/TeXstudio + MiKTeX.txt @@ -0,0 +1,75 @@ +Premessa: + - Ambiente di lavoro Windows con editor TeXstudio e distribuzione LaTex MiKTeX + - Tecnicamente MiKTeX, dopo aver installato LuaTex, dovrebbe avere già al proprio interno tutto ciò che serve per poter + modificare il file LaTex in questione ma a me ha dato problemi e questa è la procedura per risolverli... Voi magari fate una prova di compilazione subito dopo aver installato LuaTex che magari vi va di lusso + + +1) Scarica LuaTex da qua: + + https://distribution.contextgarden.net/setup/ + +2) Estrai i file in una cartella a tuo piacere. Nel mio caso io ho creato: + + C:\Portable\LuaTeX\ + +3) Da powershell eseguire il file batch nella cartella "context" con il flag --platform=all + + .\first-setup.bat --platform=all + + +4) Scarica questo repository GitHub nella stessa cartella "LuaTeX" creata prima ( C:\Portable\LuaTeX\ ): + + https://github.com/latex3/fontspec + +5) Estrai la repo così da ottenere il path: + + C:\Portable\LuaTeX\fontspec-develop\ + +6) Modifica il file "C:\Portable\LuaTeX\context-setup-win64\context\tex\texmf\web2c\texmf.cnf" inserendo a riga 49, + dopo "OSFONTDIR = " il path della directory appena salvata da github, così da ottenere: + + OSFONTDIR = C:\Portable\LuaTeX\fontspec-develop\ + +7) Scaricati dove vuoi la directory GitHub che contiene il file LaTex da modificare (nel mio caso Santini): + + https://github.com/Typing-Monkeys/AppuntiUniversita/tree/master/magistrale/Anno%201/Cybersecurity/latex/santini + +8) Estraila. Nel mio caso io avrò: + + C:\Users\path\to\file\Typing-Monkeys-Latex-Santini + +9) In questa directory crea la cartella "fonts": + + C:\Users\path\to\file\Typing-Monkeys-Latex-Santini\fonts + +10) Scarica il font che ci serve ("NotoColorEmoji.ttf") da questo repository GitHub: + + https://github.com/googlefonts/noto-emoji/tree/main/fonts + + e salvala nella cartella fonts appena creata così da ottenere: + + C:\Users\path\to\file\Typing-Monkeys-Latex-Santini\fonts\NotoColorEmoji.ttf + +11) Per modificare e compilare il file "main.tex" io uso l'editor "TeXstudio" e in questo caso dobbiamo modificare alcuni + parametri per compilare correttamente. In particolare dobbiamo: + + 1) Aprire il file "main.tex" con "TeXstudio" + 2) Aprire il menù "Opzioni > Configura TeXstudio... > Comandi" + 3) Scrolla in basso fino a trovare "latexmk" + 4) Modifica quella voce con: + + latexmk.exe -lualatex -silent -synctex=1 % + + Per più dettagli su questo passaggio guarda qua: + + https://tex.stackexchange.com/questions/351711/texstudio-with-lualatex-and-latexmk-is-this-possible + + 5) Apri il menù "Compila" (sotto al menù "Comandi") + 6) Modifica il "Compilatore predefinito" in "Latexmk" + 7) Salva le modifiche cliccando su "Ok" + 8) Vai sul file "main.tex" e cercca la riga "\setemojifont{NotoColorEmoji.ttf}[Path=fonts/]" + 9) Se serve modifica il "Path" che vedi verso la cartella in cui hai salvato il font "NotoColorEmoji.ttf" + 10) Clicca su "Compila e visualizza" + 11) Conferma il download di tutti i package che ti richiede + + 12) Prega che funzioni sennò non so che ditte \ No newline at end of file From 2980cceebca47944369198c362b9e9571ffa78af Mon Sep 17 00:00:00 2001 From: AmnesiA <57435273+Meht-evaS@users.noreply.github.com> Date: Fri, 23 Jun 2023 23:18:34 +0200 Subject: [PATCH 2/3] Correzione Appunti Santini Aggiunta lingua italiana per correggere sillabazione ritorno a capo Corretti alcuni esempi (sia di buffer overflow che SQL INJECTION) Aggiornata piccola parte sulla PoS di Etheruem Corretti errori grammaticali o lessicali Sostituiti i simboli delle doppie virgolette con gli apici aperti e chiusi Parziale miglioramento dell'impaginazione generale --- .../capitoli/ethereum/contract_security.tex | 98 +++++---- .../capitoli/ethereum/introduzione.tex | 59 ++---- .../id_managing/capitolo6_IDmanag.tex | 8 +- .../santini/capitoli/id_managing/oauth.tex | 21 +- .../santini/capitoli/id_managing/saml.tex | 12 +- .../santini/capitoli/os_security/syscall.tex | 2 +- .../secure_coding/capitolo2_buff_over.tex | 85 +++++--- .../capitoli/secure_coding/capitolo3_ROP.tex | 29 +-- .../capitoli/secure_coding/capitolo4_heap.tex | 10 +- .../secure_coding/capitolo5_Pointer_sub.tex | 14 +- .../secure_coding/capitolo6_threads.tex | 79 +++---- .../secure_coding/capitolo7_fuzztesting.tex | 70 ++----- .../secure_coding/capitolo8_sqlinjection.tex | 99 +++------ .../capitoli/secure_coding/capitolo9_xss.tex | 198 +++++++----------- .../img/cap_2/disass_intel_1.png | Bin 441095 -> 416982 bytes .../img/cap_2/es_esecuzione_processo.png | Bin 55510 -> 46139 bytes .../img/cap_2/esempio_sizet_mod.png | Bin 0 -> 80897 bytes .../img/cap_2/null_string_example.png | Bin 0 -> 60830 bytes .../img/cap_2/null_string_new.png | Bin 0 -> 82739 bytes .../img/cap_5/es_pointer_var.png | Bin 49710 -> 51311 bytes .../capitoli/secure_coding/img/cap_9/dom.png | Bin 224740 -> 231823 bytes .../latex/santini/fonts/NotoColorEmoji.ttf | Bin 0 -> 10353636 bytes .../Cybersecurity/latex/santini/main.tex | 6 +- 23 files changed, 345 insertions(+), 445 deletions(-) create mode 100644 magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/img/cap_2/esempio_sizet_mod.png create mode 100644 magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/img/cap_2/null_string_example.png create mode 100644 magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/img/cap_2/null_string_new.png create mode 100644 magistrale/Anno 1/Cybersecurity/latex/santini/fonts/NotoColorEmoji.ttf diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex index bf6aebd77..7f51f1fad 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex @@ -21,21 +21,20 @@ \section{Introduzione} programmazione di uno Smart Contract, gli sviluppatori sono spesso tentati di provare a scrivere codice molto complesso ed articolato. Invece, si dovrebbe trovare il modo per fare meno, con meno linee di -codice, meno complessità e meno "features". -Se esiste già una libreria o un contratto che fa gran parte del necessario, -riutilizzatela. -All'interno del codice, seguite il principio \textit{DRY}: Don't Repeat Yourself. -Attenzione alla sindrome del "Not Invented Here", dove si è tentati di -"migliorare" una caratteristica o un componente costruendola da zero. +codice, meno complessità e meno ``features''. +Se esiste già una libreria o un contratto che fa gran parte del necessario, utilizzatela. +All'interno del codice, seguite il principio \textit{DRY}: ``Don't Repeat Yourself''. +Attenzione alla sindrome del ``Not Invented Here'', dove si è tentati di +``migliorare'' una caratteristica o un componente costruendola da zero. Non si dovrebbe trattare la programmazione a Smart Contract allo stesso modo della programmazione generale. Piuttosto, si dovrebbero applicare rigorose metodologie di ingegneria e di sviluppo software. -Una volta "lanciato" il vostro codice, c'è poco da fare per risolvere eventuali +Una volta ``lanciato'' il vostro codice, c'è poco da fare per risolvere eventuali problemi. Il vostro codice deve essere chiaro e facile da comprendere. Più è facile da leggere, più è facile da controllare. -I contratti intelligenti sono pubblici, poiché tutti possono leggere il bytecode +Gli Smart Contract sono pubblici, poiché tutti possono leggere il bytecode e chiunque può invertirlo e modificarlo. Pertanto, è utile sviluppare il proprio lavoro in pubblico, utilizzando @@ -65,7 +64,7 @@ \section{IF e REQUIRE} \paragraph{REQURIE.} Controlla sempre una condizione ma, se non si avvera, la transazione viene abortita e -ripristinata. Viene rimborsato anche il gas. +ripristinata. Viene rimborsato anche il gas non ancora utilizzato. \ \\ \paragraph{Esempio.}\ @@ -82,12 +81,11 @@ \section{IF e REQUIRE} \end{lstlisting} \verb|sender| è l'indirizzo di chi chiama la transazione e spedisce denaro. -Il corpo della funzione salva in \verb|sender| l'indirizzo \verb|msg.sender|. +Il corpo della funzione salva in \verb|sender| l'indirizzo \verb|msg.sender|.\\ \verb|msg| è il messaggio che viene -mandato al contratto. \verb|require| richiede che l'input passato sia $ > 100$. -Se il valore passato \verb|_input| nella transazione è $ > 100$, -allora si aggiorna la variabile \verb|input|. -Altrimenti fallisce. Aggiornando \verb|input| si aggiorna lo stato del contratto. +mandato al contratto.\\ +\verb|require| richiede che l'input passato sia $ >= 100$. +Se il valore passato \verb|_input| nella transazione è $ >= 100$, allora si aggiorna la variabile \verb|input|, altrimenti fallisce. Aggiornando \verb|input| si aggiorna lo stato del contratto. \section{DAO Attack} @@ -103,7 +101,7 @@ \subsection{Reentrancy} (attraverso una funzione di fallback). Attacchi di questo tipo sono stati utilizzati nel famigerato hack DAO. Il 17 giugno 2016 il DAO è stato violato e $3,6$ milioni di ether ($658.002.709$ euro) -sono stati rubati con quello che viene considerato i primo attacco di reentrancy. +sono stati rubati con quello che viene considerato il primo attacco di reentrancy. \subsection{Attacco} @@ -121,8 +119,8 @@ \subsection{Attacco} per proteggere la blockchain. Se la transazione fallisce, viene effettuata un'operazione di ripristino (revert) automatico, cioè si ritorna allo stato originale.\\ -A differenza delle due precedenti, \verb|someAddress.call.value(y)()| non ha questo -tipo di protezione, invocandola verrà inviato +A differenza delle due precedenti, \verb|someAddress.call.value(y)| non ha questo +tipo di protezione. Invocandola verrà inviato l'ether specificato e farà scattare l'esecuzione di una specifica parte di codice del contratto chiamante (funzione di \textit{fallback}). @@ -131,6 +129,8 @@ \subsection{Attacco} questo tipo di trasferimento di valori unsafe contro il reentrancy. Non ci sono quindi limiti, si può andare anche oltre $2300$ gas. +\newpage + \paragraph{ESEMPIO.}\ \\ \verb|contract.sol|\\ Di seguito il codice di uno Smart Contract simile a quello del DAO Attack. @@ -255,17 +255,12 @@ \section{Arithmetic underflow/overflow} \begin{figure}[H] \centering \includegraphics[width=10cm, keepaspectratio]{capitoli/ethereum/imgs/aritmetic.png} - \caption{Esempio di codice dove vulnerabile ad Arithmetic underflow/overflow.} + \caption{Esempio di codice vulnerabile ad Arithmetic underflow/overflow.} \end{figure} -La keyword \verb|mapping| fungono da tabelle di hash che consistono in coppia -\verb|chiave-valore|. In questo caso abbiamo 2 mapping: \verb|balances| e \verb|lockTime|, -il primo associa ogni indirizzo ethereum di chi chiama questo contratto ad un numero -che rappresenta il saldo di quell'indirizzo; il secondo associa ad ogni indirizzo -un numero che rappresenta il lock-time (quanto deve passare da un ritiro all'altro). -La funzione \verb|deposit| incrementa il saldo dell'indirizzo chiamante (\verb|msg.sender|) -di quanto ha versato (\verb|msg.value|) (riga 7). Viene anche impostato il lockTime -dello specifico indirizzo ad 1 settimana (riga 8): tra 1 settimana sarà possibile ritirare i fondi. +La keyword \verb|mapping| funge da tabelle di hash che consistono in coppie \verb|chiave-valore|. In questo caso abbiamo 2 mapping: \verb|balances| e \verb|lockTime|, il primo associa ogni indirizzo ethereum di chi chiama questo contratto ad un numero +che rappresenta il saldo di quell'indirizzo; il secondo associa ad ogni indirizzo un numero che rappresenta il lock-time (quanto deve passare da un ritiro all'altro). +La funzione \verb|deposit| incrementa il saldo dell'indirizzo chiamante (\verb|msg.sender|) di quanto ha versato (\verb|msg.value|) (riga 7). Viene anche impostato il lockTime dello specifico indirizzo ad 1 settimana (riga 8): tra 1 settimana sarà possibile ritirare i fondi. La funzione \verb|increaseLockTime| permette di allungare il \verb|lockTime|, specificando il numero di secondi. La funzione \verb|withdraw|, dopo aver controllato se abbiamo abbastanza denaro @@ -283,6 +278,8 @@ \section{Arithmetic underflow/overflow} quantità porterà ad avere il massimo numero rappresentabile in uint. Così facendo posso andare a resettare il limite di tempo imposto da \verb|lockTime|. +\vspace{-1.5em} + \subsection{Mitigation} La tecnica normalmente utilizzata per proteggersi dalle vulnerabilità di @@ -293,6 +290,8 @@ \subsection{Mitigation} Per esempio, OpenZeppelin è una libreria per lo sviluppo sicuro di un Smart Contract. +\vspace{-1.5em} + \section{Unexpected Ether} Ci sono dei casi in cui è possibile mandare ether ad un contratto senza che ci @@ -421,7 +420,7 @@ \section{Entropy Illusion} Questi valori però sono controllati dal miner che estrae il blocco e pertanto non sono del tutto casuali. -\paragraph{Esempio.}\ \\ +\paragraph{Esempio.}\ Si consideri uno Smart Contract di roulette che restituisce un numero nero se il blocco successivo termina con un numero pari. @@ -434,6 +433,8 @@ \section{Entropy Illusion} soluzione con l'hash del blocco come numero pari (supponendo comunque che la ricompensa del blocco e le tasse siano meno di 1 milione di dollari). +\vspace{-1em} + \subsection{Mitigation} Per i motivi elencati prima, le block variables non dovrebbero essere usate per @@ -443,7 +444,7 @@ \subsection{Mitigation} Ciò può essere ottenuto cambiando il modello di trust in un gruppo di partecipanti, come avviene in -\verb|RandDAO|. Viene creata infatti una sorta di “terza parte” che si fa garante +\verb|RandDAO|. Viene creata infatti una sorta di ``terza parte'' che si fa garante della creazione di variabili casuali ma ciò allo stesso tempo avviene in modo distribuito. Le regole quindi sono riassunte in un contratto: abbiamo pegno, invio di una parte @@ -451,13 +452,19 @@ \subsection{Mitigation} generazione di un numero aleatorio, restituzione del pegno più parte delle tasse. Questo è un DAO: Organizzazione Anonima Decentrata. +\vspace{-1em} + \section{Manipolazione dei Time Blockstamp} I minatori hanno la possibilità di regolare leggermente i timestamp, il che può rivelarsi pericoloso se essi venissero utilizzati in modo scorretto. -\paragraph{Esempio.}\ \\ +\vspace{-1em} + +\paragraph{Esempio.}\ + +\vspace{-0.5em} \begin{figure}[H] \centering @@ -465,32 +472,21 @@ \section{Manipolazione dei Time Blockstamp} \caption{Sezione di codice vulnerabile alla Timestamp Manipulation.} \end{figure} -Prendiamo in considerazione in precedente codice di un contratto che simula -una roulette. +Prendiamo in considerazione il precedente codice di un contratto che simula una roulette. Chiunque può puntare 10 ether (riga 8). -Il secondo \verb|require| (riga 9) controlla che ci sia una -sola transazione nel nuovo blocco; -poi questa verrà aggiornata subito, -per indicare il fatto che qualcuno ha già giocato. -Supponiamo che qualcuno ha -esattamente puntato in questo -momento, ovvero quando si -verifica la condizione $now \%15 == 0$ (riga 11); allora lui sarà -il vincitore e con la \verb|transfer| (riga 12) -riceverà tutto il denaro che è stato versato dagli altri giocatori nelle +Il secondo \verb|require| (riga 9) controlla che ci sia una sola transazione nel nuovo blocco; +poi questa verrà aggiornata subito, per indicare il fatto che qualcuno ha già giocato. +Supponiamo che qualcuno ha esattamente puntato in questo +momento, ovvero quando si verifica la condizione $now \%15 == 0$ (riga 11); allora lui sarà il vincitore e con la \verb|transfer| (riga 12) riceverà tutto il denaro che è stato versato dagli altri giocatori nelle transazioni precedenti. In realtà, \verb|now| è leggermente modificabile. -Di conseguenza, potrebbe accadere che il -miner aggiusti il tempo in cui punta e in cui mina il blocco, -in modo che la condizione si -verifichi (parliamo sempre di una modifica molto piccola). +Di conseguenza, potrebbe accadere che il miner aggiusti il tempo in cui punta e in cui mina il blocco, +in modo che la condizione si verifichi (parliamo sempre di una modifica molto piccola). \section{Delegate Call} -Gli opcode \verb|CALL| e \verb|DELEGATECALL| permettono lo sviluppo modulare -del codice di un contratto di Ethereum. -Tuttavia con \verb|DELEGATECALL| l'esecuzione del codice specificato -nell'indirizzo viene eseguita utilizzando il contesto del contratto chiamante, +Gli opcode \verb|CALL| e \verb|DELEGATECALL| permettono lo sviluppo modulare del codice di un contratto di Ethereum. +Tuttavia con \verb|DELEGATECALL| l'esecuzione del codice specificato nell'indirizzo viene eseguita utilizzando il contesto del contratto chiamante, cosa che non si verifica con \verb|CALL|. Questo può causare delle vulnerabilità che vedremo ora con un esempio. @@ -525,7 +521,7 @@ \subsection{Attacco} dunque se nella libreria abbiamo la variabile nella posizione $0$ (\verb|slot[0]|) che corrisponde a \verb|start| (riga 4 di a) e chiamiamo la funzione \verb|setStart| con \verb|delegatecall|, non utilizzeremo la variabile in -posizione $0$ nella libreria me quella del contratto chiamante, +posizione $0$ nella libreria ma utilizzeremo quella del contratto chiamante, che nel nostro caso corrisponde all'indirizzo del contratto (libreria). Questo permette ad un utente malevolo di cambiare l'indirizzo della libreria a piacimento, dirottando l'esecuzione @@ -566,7 +562,7 @@ \subsection{Attacco} la Lotteria: viene scelto un utente vincitore che può ritirare la somma vincente, mentre viene lasciata a disposizione una piccola quantità di denaro ritirabile dagli altri utenti solo dopo la riscossione della vincita. -La vulnerabilità è presenta alla riga 11, dove la funzione \verb|send| viene +La vulnerabilità è presente alla riga 11, dove la funzione \verb|send| viene invocata senza controllare il suo valore di ritorno. Se fallisce l'invio della vincita, per colpa del numero insufficiente di gas o per via dell'account del vincitore, tutta la vincita viene lasciata a disposizione della funzione diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex index cb6fc15fc..84bab38f6 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex @@ -2,7 +2,7 @@ \chapter{Introduzione ad Ethereum} Ethereum è un piattaforma di calcolo decentralizzata che permette di eseguire programmi chiamati \textit{Smart Contracts}, sfruttando la blockchain per sincronizzare e salvare i cambiamenti di stato del sistema. -Spesso viene denotata con "World Computer". +Spesso viene denotata con ``World Computer''. Oltre ai contratti, ethereum sfrutta anche una criptovaluta chiamata \textit{Ether} per misurare e vincolare le risorse per l'esecuzione dei contratti. @@ -20,7 +20,6 @@ \section{Ethereum vs Bitcoin} \begin{itemize} \item P2P, \item Un algoritmo di consenso per sincronizzare gli stati, - \item Concetto simile alla PoW (Proof of Work), \item Utilizzo di funzioni crittografiche (hash, firme digitali, ...), \item Criptovaluta. \end{itemize} @@ -38,6 +37,7 @@ \section{Ethereum vs Bitcoin} non è quindi Turing-Completo e risulta molto più sicuro. \item La disponibilità massima di Bitcoin è pari a 21 milioni di unità, mentre gli Ether sono illimitati. + \item Bitcoin = PoW (Proof of Work), Ethereum = PoS (Proof of Stake) \end{itemize} \section{Componenti della Blockchain} @@ -73,13 +73,7 @@ \section{Componenti della Blockchain} \item \textbf{Data Structure}: lo stato di Ethereum è salvato localmente su ogni nodo come un database contenente transazioni e stato del sistema in una struttura dati chiamata \textit{Merker Patricia Tree}. - \item \textbf{Algoritmo del Consenso}: Ethereum utilizza lo stesso metodo dei Bitcoin - (Nakamoto Consensus) che utilizza la PoW per approvare le transazioni, - determinando così lo stato attuale in base a qual'è la catena più lunga. - Ci sono piani per passare alla PoS (Proof of Stake) che verranno introdotti dal - progetto Casper. - \item \textbf{Economic Security}: Ethereum utilizza un algoritmo di PoW chiamato \textit{Ethash}, - ma verrà abbandonato quando si passerà alla PoS. + \item \textbf{Algoritmo del Consenso}: Ethereum usa la PoS (Proof of Stake) in cui la sicurezza della rete è data da una serie di ricompense e sanzioni applicate al capitale bloccato degli staker. Questa struttura di incentivi incoraggia i singoli staker a validare onestamente le transazioni e punisce coloro che non lo fanno. \item \textbf{Clients}: Ethereum ha diverse implementazioni di vari client, tutte quante valide ed intercambiabili, tra cui Go-Ethereum (Geth) e Parity. \end{itemize} @@ -114,7 +108,7 @@ \section{DApps} \begin{itemize} \item uno smart contract - \item alcune interfacce utenti web + \item alcune interfacce utente web \end{itemize} Ma possono anche presentare: @@ -133,7 +127,7 @@ \section{JSON-RPC} sia una serie uniforme di metodi su cui si basano le applicazioni. JSON-RPC è un protocollo di chiamata della procedura remota (RPC) leggero e privo di stato. Principalmente, la specifica definisce diverse strutture di dati e le regole intorno alla loro -elaborazione. È indipendente dal trasporto, poiché i concetti sono utilizzabili entro lo stesso +elaborazione. È indipendente dal trasporto poiché i concetti sono utilizzabili entro lo stesso processo, su prese, via HTTP o in svariati ambienti di passaggio dei messaggi. Usa JSON (RFC 4627) come formato dei dati. Di solito, l'accesso alle RPC è fornito da un servizio HTTP sulla porta 8584 che @@ -173,12 +167,14 @@ \section{Tipi di Account} non può iniziare transazioni, ma può solo reagire a transazioni chiamando altri contratti o spostando ether. +\vspace{-2em} + \section{Proof of Stake (PoS)} Come il PoW, il PoS (Proof of Stake) è un modo per validare e dare consenso alle transazioni. Il PoW paga miner che risolvono problemi matematici con lo scopo di creare e validare nuovi blocchi per far crescere la blockchain. Con il PoS, il creatore di un nuovo blocco viene scelto in base alla quantità -di moneta che possiede, quanto "stake" ha quella persona nella determinata moneta +di moneta che possiede, quanto ``stake'' ha quella persona nella determinata moneta (currency). \textit{More stake, more power}. Lo stake non è solo definito come la quantità di moneta posseduta ma è importante anche da quanto tempo questa persona possiede la valuta. @@ -191,6 +187,8 @@ \section{Proof of Stake (PoS)} non servono immense potenze di calcolo per risolvere complesse operazioni matematiche. Alcune cryptocurrencies che sfruttano il PoS sono: +\vspace{-0.5em} + \begin{itemize} \item ShadowCash \item Nxt @@ -198,34 +196,26 @@ \section{Proof of Stake (PoS)} \item Nav Coin \end{itemize} +\vspace{-1em} + \section{Smart Contracts} -Il termine Smart Contract è stato coniato da Nick Szabo ed è definito come: -"un insieme di promesse, specificato in forma digitale che includono protocolli, -all'interno dei quali le due parti coinvolte adempiono alle loro promesse -contrattuali". -Il concetto di Smart Contract quando usato in riferimento ad Ethereum può essere -fuorviante in quanto -non si riferisce a contratti legali ma ad un programma software che viene eseguito -dalla EVM sull'Ethereum +Il termine Smart Contract è stato coniato da Nick Szabo ed è definito come: ``un insieme di promesse, specificato in forma digitale che includono protocolli, all'interno dei quali le due parti coinvolte adempiono alle loro promesse contrattuali.'' +Il concetto di Smart Contract quando usato in ù riferimento ad Ethereum può essere fuorviante in quanto +non si riferisce a contratti legali ma ad un programma software che viene eseguito dalla EVM sull'Ethereum World Computer. Gli Smart Contract hanno 2 caratteristiche: +\vspace{-0.5em} + \begin{itemize} - \item Sono \textbf{immutabili}: una volta mandato in esecuzione il - codice di uno smart contract esso non potrà cambiare. - L'unico modo per modificarne il codice è quello di effettuare un - nuovo deployment. - \item Sono \textbf{deterministici}: l'output di uno smart contract sarà - sempre lo stesso su ogni macchina che lo esegue dato il contesto della - transazione che lo ha inizializzato e lo stato della blockchain nel momento - dell'esecuzione. + \item Sono \textbf{immutabili}: una volta mandato in esecuzione il codice di uno smart contract esso non potrà cambiare. L'unico modo per modificarne il codice è quello di effettuare un nuovo deployment. + \item Sono \textbf{deterministici}: l'output di uno smart contract sarà sempre lo stesso su ogni macchina che lo esegue dato il contesto della transazione che lo ha inizializzato e lo stato della blockchain nel momento dell'esecuzione. \end{itemize} \section{Coins and Tokens} In questo paragrafo andremo ad analizzare brevemente le differenze tra Coin e Token. -\paragraph{Coins:} -un Coin può essere definito tale se rispetta le seguenti caratteristiche: +\paragraph{Coins:} un Coin può essere definito tale se rispetta le seguenti caratteristiche: \begin{enumerate} \item Opera all'interno della sua blockchain @@ -234,13 +224,8 @@ \section{Coins and Tokens} \end{enumerate} \paragraph{Tokens:} -la principale differenza con i Coin è che un Token non ha una sua propria blockchain -ma si appoggia ad altre già esistenti, come per esempio ERC20, BAT e BNT che -sfruttano Ethereum. Un'altra sostanziale differenza è che le transazioni di Coins -sono gestite dalla blockchain mentre quelle di token sono governate da Smart Contract. -Quando un token viene "speso" viene fisicamente spostato da un posto ad un altro, -a differenza dei Coin, quando un coin viene speso viene solo aggiornato il saldo -delle due parti. Un esempio di token sono gli NFT (Non Fungible Tokens). +la principale differenza con i Coin è che un Token non ha una sua propria blockchain ma si appoggia ad altre già esistenti, come per esempio ERC20, BAT e BNT che sfruttano Ethereum. Un'altra sostanziale differenza è che le transazioni di Coins sono gestite dalla blockchain mentre quelle di token sono governate da Smart Contract. +A differenza dei Coin, quando un token viene ``speso'', viene fisicamente spostato da un posto ad un altro mentre, quando un coin viene speso viene solo aggiornato il saldo delle due parti. Un esempio di token sono gli NFT (Non Fungible Tokens). \section{Hard Fork} diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/capitolo6_IDmanag.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/capitolo6_IDmanag.tex index 167a0c230..8f9a718ea 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/capitolo6_IDmanag.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/capitolo6_IDmanag.tex @@ -14,7 +14,7 @@ \subsection{Identità digitale} Tale agente può essere una persona, un'organizzazione, un'applicazione o un dispositivo. \textit{ISO/IEC 24760-1} definisce l'\textbf{identità} come -"insieme di attributi relativi a un'entità". +``insieme di attributi relativi a un'entità''. Le informazioni contenute in un'\textbf{identità digitale} consentono di valutare e autenticare un utente che interagisce con un sistema aziendale sul web/Network, senza il coinvolgimento di operatori umani. @@ -28,7 +28,7 @@ \subsection{Autenticazione} un \textbf{oggetto univoco} come una carta di credito bancaria, le \textbf{informazioni riservate} come una una password o la risposta a una domanda prestabilita, \textbf{la conferma della proprietà di un indirizzo e-mail}. -Le soluzioni più robuste ma relativamente costose utilizzando metodologie di +Le soluzioni più robuste ma relativamente costose utilizzano metodologie di crittografia. \subsection{Autorizzazione} @@ -45,14 +45,14 @@ \section{Identity} \subsection{Identifier} -Il termine "\textbf{identificatore}" si riferisce a un singolo attributo il cui scopo +Il termine ``\textbf{identificatore}'' si riferisce a un singolo attributo il cui scopo è quello di identificare in modo univoco una persona o un'entità, all'interno di un contesto specifico. Alcuni esempi sono indirizzo email, numero passaporto, ecc... . \subsection{Identità} -Il termine "identità" è definito come un insieme di attributi associati a una +Il termine ``identità'' è definito come un insieme di attributi associati a una specifica persona/entità in un particolare contesto. Un'identità comprende uno o più identificatori e può contenere altri attributi associati a una persona/entità. diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/oauth.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/oauth.tex index 319bdf54d..f0072331c 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/oauth.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/oauth.tex @@ -2,9 +2,11 @@ \chapter{OAuth} +\vspace{-3em} + Nelle applicazioni odierne si utilizzano spesso le \textit{API} \emoji{bee}, che permettono all'applicazione di ottenere accesso a dati e servizi di valore. Per questo motivo -è necessario restringere l'accessi delle \api{} a gruppi autorizzati. Serviranno dunque +è necessario restringere l'accesso delle \api{} a gruppi autorizzati. Serviranno dunque delle autorizzazioni per chiamare le \api{}. Nel passato un utente spesso doveva condividere le proprie credenziali con l'applicazione per assicurarsi che tale chiamata \api{} funzionasse correttamente. Questo forniva alle applicazioni una quantità di dati @@ -13,6 +15,8 @@ \chapter{OAuth} \textbf{OAuth 2.0} fornisca una soluzione migliore per autorizzare le applicazioni ad effettuare chiamate alle \api{}. +\vspace{-1em} + \section{API Authorization} Un applicazione potrebbe aver bisogno di chiamare un \api{} per conto di un utente @@ -22,6 +26,7 @@ \section{API Authorization} \begin{figure}[H] \centering \includegraphics[width=\textwidth, keepaspectratio]{capitoli/id_managing/imgs/api1.png} + \vspace{-0.5em} \caption{\api{} Authorization: user-based vs client-based flow.} \end{figure} @@ -73,6 +78,8 @@ \subsection{Roles} singola entità. \end{itemize} +\vspace{-1em} + \subsection{Tipi di Client} In OAuth 2.0 ci sono 2 tipi di client: @@ -86,6 +93,8 @@ \subsection{Tipi di Client} e può autenticarsi con il server solo tramite OAuth. \end{itemize} +\vspace{-1em} + \subsection{Client Profiles} In OAuth 2.0 ci sono 3 tipi di profili in base alla tipologia di applicazione: @@ -104,10 +113,10 @@ \subsection{Client Profiles} \subsection{Token e Codici di Autorizzazione} -In OAuth 2.0 ci sono 2 token di sicurezza e un token di autorizzazione intermedio: +In OAuth 2.0 ci sono 2 token di sicurezza e un codice di autorizzazione intermedio: \begin{itemize} - \item \textbf{Authorization Token}: un codice opaco intermediario ritornato + \item \textbf{Authorization Code}: un codice opaco intermediario ritornato da un'applicazione ed utilizzato per ottenere un token di accesso e opzionalmente un token di refresh. Ogni authorization code è utilizzato una volta. @@ -144,7 +153,7 @@ \subsection{Authorization Code Grant} Questo reindirizzamento consente all'authorization server di interagire con l'utente per farlo autenticare. Dopo aver ottenuto il consenso, l'utente viene reindirizzato all'applicazione -con l'authorization conde. L'applicazione utilizzerà questo codice per mandare una +con l'authorization code. L'applicazione utilizzerà questo codice per mandare una backchannel request all'authorization server per ottenere l'access token. L'authorization server risponderà con un access token che verrà utilizzato per chiamare le \api{} @@ -177,7 +186,7 @@ \subsubsection{Authorization Code Grant + PKCE} Il meccanismo \textit{Proof of Key for Code Exchange} (PKCE) permette di assicurarsi che l'applicazione che ha richiesto il codice di autorizzazione è la stessa che lo utilizza per ottenere l'access token. Questo vuol dire che PKCE serve per proteggersi -da potenziali intercettazioni delle richiesti di autorizzazione. +da potenziali intercettazioni delle richieste di autorizzazione. Per poter utilizzare PKCE l'applicazione crea una stringa crittografata in maniera aleatoria chiamata \textbf{code verifier}. L'applicazione poi calcola un valore derivato chiamato \textbf{code challenge} dal code verifier. Quando l'applicazione manda un @@ -273,7 +282,7 @@ \subsection{Client Credential Grant} \section{Chiamare le API} Una volta ottenuto il token l'applicazione può effettuare le chiamate \api{} e tipicamente -è fatto utilizzando la richiesta HTTP "Authorization" e specificando l'access token +è fatto utilizzando la richiesta HTTP ``Authorization'' e specificando l'access token nel campo \verb|Authorization| dell'header. \begin{lstlisting} diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/saml.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/saml.tex index e2e72db5b..90e0d92b2 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/saml.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/saml.tex @@ -23,7 +23,7 @@ \chapter{SAML} un problema molto importante in quanto dovrebbe trovarsi a gestire un grandissimo numero di account. \saml{} permette alle applicazioni di delegare la fase dell'autenticazione dell'utente ad un'entità remota chiamata Identity Provider. -Questa identità autentica l'utente e ritorna all'applicazione informazioni riguardanti +Questo provider autentica l'utente e ritorna all'applicazione informazioni riguardanti l'utente autenticato e la fase di autenticazione. Se l'utente accede ad una seconda applicazione che delega l'autenticazione allo stesso Identity Provider, non gli verrà richiesto di effettuare nuovamente il login ma potrà utilizzare @@ -57,7 +57,7 @@ \section{Terminologia} ricevute dall'Identity Provider. \item \textbf{SAML Protocol Binding}: una descrizione di come gli elementi dei messaggi \saml{} sono mappati in protocolli di comunicazione standard, - come HTTP, per trasmetter informazioni tra il Service Provider e l'Identity + come HTTP, per trasmettere informazioni tra il Service Provider e l'Identity Provider. In pratica, le richieste e risposte \saml{} sono inviate utilizzando il protocollo HTTPS tramite HTTP-Redirect o HTTP-POST, usando i relativi bindings, HTTP-Redirect Binding e HTTP-POST binding. @@ -80,7 +80,7 @@ \section{Come Funziona ?} una relazione di fiducia tra il Service Provider e l'Identity Provider, questo è necessario che avvenga affinché l'Identity Provider possa autenticare un utente per il Service Provider. Una volta che questa configurazione mutuale dei provider -è impostata, quando un utente prova ad accedere al Server Provider, il suo +è impostata, quando un utente prova ad accedere al Service Provider, il suo browser viene indirizzato all'identity provider con un \saml{} Authentication Request Message. L'Identity Provider autenticherà l'utente per poi reindirizzarlo all'applicazione con un \saml{} Authentication Response Message. Questa risposta @@ -129,7 +129,7 @@ \subsection{IdP-Initiated Flow} \begin{enumerate} \item L'utente visita il portale della corporazione. - \item Il portare reindirizza l'utente all'Identity Provider con una \saml{} + \item Il portale reindirizza l'utente all'Identity Provider con una \saml{} Authentication Request. \item L'Identity Provider interagisce con l'utente per l'autenticazione. \item L'utente si autentica e l'Identity Provider valida le credenziali. @@ -155,7 +155,7 @@ \section{Identity Federation} Questo viene deciso quando gli amministratori del Service Provider scambiano meta-dati riguardo i loro ambienti e li utilizzano per creare la \textit{Federation Information} tra la loro applicazione e l'Identity Provider. -L'Identity Provider dovrà poi essere in gradi di fornire i corretti dati relativi +L'Identity Provider dovrà poi essere in grado di fornire i corretti dati relativi ad ogni potenziale Service Provider. \begin{figure}[H] @@ -189,7 +189,7 @@ \section{Benefici di SAML} \item \textbf{Phishing Prevention}: se non hai una password per l'app non verrai ingannato per entrare in una fake login page. \item \textbf{IT Friendly}: \saml{} semplifica la vita per IT perché centralizza - l'autenticazione, fornisce grande visibilità e render la + l'autenticazione, fornisce grande visibilità e rende la directory integration più facile. \end{itemize} \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/os_security/syscall.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/os_security/syscall.tex index 7f2d37413..49517db83 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/os_security/syscall.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/os_security/syscall.tex @@ -161,7 +161,7 @@ \subsection{setuid} \subsection{Linux Capabilities} -Le \textit{capabilities} sono delle flag che possono essere assegnati ad un thread +Le \textit{capabilities} sono delle flag che possono essere assegnate ad un thread per determinare se questo può o no effettuare determinate azioni. Ce ne sono più di 30, ed un esempio è \verb|CAP_NET_BIND_SERVICE| che permette di fare il bind ad un porta inferiore alla 1024; \verb|CAP_SYS_BOOT| che impedisce ad eseguibili diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo2_buff_over.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo2_buff_over.tex index 029ef7c71..abccfb339 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo2_buff_over.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo2_buff_over.tex @@ -95,7 +95,7 @@ \section{Collegamento con CIA} \chapter{Linguaggio C} Il linguaggio di programmazione C è conosciuto per essere un linguaggio leggero con -un numero di "tracce" ridotto. +un numero di ``tracce'' ridotto. Alcuni programmatori abituati ad usare altri linguaggi come Java, Pascal o Ada credono che il linguaggio li protegga di più rispetto a quello che effettivamente fa. Queste false ipotesi hanno portato i programmatori a fallire nel prevenire la @@ -193,7 +193,7 @@ \subsection{Esempi} numero rappresentabile (perché \verb|1 - 2| dà questo risultato ed è unsigned. Sarebbe \(2^{64} - 1\)). A quel punto la \verb|malloc(size + 1)| diventerà uguale a 0. Avere \verb|malloc = 0| porta ad un \textbf{comportamento indefinito}. Le -conseguenze di questo vento dipendono dal compilatore.\\ +conseguenze di questo flusso dipendono dal compilatore.\\ \textbf{\textit{Esempio}} @@ -255,8 +255,8 @@ \section{Vulnerabilità degli Interi} \item \textbf{Integer Type Selection}: consiste nel selezionare il tipo più appropriato per il codice che si ha sotto mano. - Un esempio è l'uso del tipo \verb|size_t| quando si vuole salvare la - dimensione di un oggetto dato che ideato per questo scopo + Un esempio è l'uso del tipo \verb|size_t| che è stato appositamente ideato per salvarci la + dimensione di un oggetto ("INT01-C. Use \verb|size_t| for all integer values representing the size of an object."). Si può anche utilizzare \verb|short|.\\ @@ -264,7 +264,7 @@ \section{Vulnerabilità degli Interi} Un altro esempio: \begin{figure}[H] \centering - \includegraphics[width=12cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/esempio_sizet.png} + \includegraphics[width=12cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/esempio_sizet_mod.png} \end{figure} \item \textbf{Type Range Checking}: @@ -344,6 +344,8 @@ \section{Array e stringhe} Quest'ultima risulta deprecata e eliminata, il CERT consiglia di non utilizzare funzioni deprecate o obsolete. +\newpage + \paragraph{Lettura da \textit{stdin()}.} La lettura dei dati da una una fonte illimitata come \textbf{stdin()} crea dei problemi per il programmatore poiché non è possibile conoscere in anticipo quanti @@ -373,12 +375,12 @@ \section{Array e stringhe} \paragraph{Null terminating string.} In Figura \ref{fig:null_string} possiamo vedere che il risultato di \verb|strcpy()| su c porta l'utente a poter scrivere oltre i limiti dell'array poiché la stringa -salvata in \verb|a[]| non terminata correttamente (null-terminating). +salvata in \verb|a[]| non è terminata correttamente (null-terminating). \begin{figure}[H] \centering - \includegraphics[width=10cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/null_string.png} + \includegraphics[width=10cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/null_string_new.png} \caption{Esempio null terminating string .}\label{fig:null_string} \end{figure} @@ -386,20 +388,21 @@ \section{Array e stringhe} required.”} \paragraph{Funzionamento esempio \ref{fig:null_string}} -Abbiamo 3 array lunghi 16 caratteri, copiamo la stringa "0123456789abcdef" -in \textbf{a} e in \textbf{b}, come si può notare questa stringa ha una lunghezza di -16 caratteri. Successivamente si copia la stringa contenuta in \textbf{a} -nell'array \textbf{c} e questo porta ad avere dei problemi ovvero: +Abbiamo 3 array lunghi 16 caratteri. Copia\-mo la stringa ``ciaociaociaociao'' in \textbf{a} e ``0123456789abcdef'' in \textbf{b}. Come si può notare, entrambe le stringhe sono lunghe 16 caratteri. Successivamente si copia la stringa contenuta in \textbf{b} nell'array \textbf{c} e questo porta ad avere dei problemi ovvero: \begin{itemize} - \item non viene salvato sia in \textbf{a} che in \textbf{b} il carattere di fine - stringa "\verb|\0|" allora essendo che la stringa non termina - e che 'array \textbf{b} è memorizzato subito dopo \textbf{a} si ha di conseguenza che - \[a = [0123456789abcde0123456789abcde\backslash 0]\] - \item quindi quando si va a copiare \textbf{a} dentro \textbf{c} si copiano 32 - caratteri più "\verb|\0|" e non 16 sforando così la memoria allocata inizialmente. + \item non viene salvato, sia in \textbf{a} che in \textbf{b}, il carattere di fine stringa ``\verb|\0|''. Allora, essendo che la stringa non termina correttamente e che l'array \textbf{b} è memorizzato nello stack subito dopo \textbf{a} (quindi sopra ad \textbf{a}) si ha di conseguenza che + \[b = [0123456789abcdefciaociaociaociao\backslash 0]\] + \item quindi quando si va a copiare \textbf{b} dentro \textbf{c} si copiano 32 + caratteri più ``\verb|\0|'' e non 16, sforando così la memoria allocata inizialmente. \end{itemize} +\begin{figure}[H] + \centering + \includegraphics[width=12cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/null_string_example.png} + \caption{Esempio pratico null terminating string .}\label{fig:null_string_example} +\end{figure} + \section{Vulnerabilità delle stringhe ed exploit} \subsection{Valori corrotti} @@ -491,10 +494,12 @@ \subsection{Organizzazione di un processo in memoria} un numero più alto a uno più basso e viceversa (come una fisarmonica). La memoria è struttura in questo modo così la parte dinamica (heap) non si incontra con la parte statica (stack) a meno che non viene riempita completamente.\\ -La memoria UNIX è molto simili alla memoria generale, l'unica differenza sta nel +La memoria UNIX è molto simile alla memoria generale, l'unica differenza sta nel fatto che la parte \textbf{Data} nella memoria generale viene suddivisa in due in quella UNIX: +\vspace{-0.5em} + \begin{itemize} \item \textbf{Data:} vengono salvate delle variabili globali/statiche inizializzate; @@ -502,16 +507,20 @@ \subsection{Organizzazione di un processo in memoria} che non sono state inizializzate e vengono di default inizializzate a 0. \end{itemize} +\vspace{-0.5em} + Il segmento \textbf{Text} è l'equivalente del segmento \textbf{Code}, entrambi includono le istruzioni e i dati read-only. +\vspace{-1em} + \paragraph{Esecuzione di un programma.} Vediamo un primo esempio di esecuzione di un programma. -In questo caso possiamo vedere due funzioni \verb|main()| e \verb|fun(...)|, si parte +In questo caso possiamo vedere due funzioni: \verb|main()| e \verb|fun(...)|; si parte salvando in memoria le variabili locali presenti nella funzione \verb|main()| la quale richiama l'altra. In Figura \ref{fig:es_esec_processo} possiamo vedere che le variabili vengono salvate in sequenza dal basso verso l'alto in base a come sono state -inizializzate, successivamente con la chiamata di \verb|fun()| si salvano i parametri +inizializzate. Successivamente con la chiamata di \verb|fun()| si salvano i parametri che essa prende in input, l'indirizzo di ritorno (\textbf{return address}\footnote{indica l'indirizzo di ritorno dopo che è stata eseguita la funzione in questione, in questo caso indica l'indirizzo del main.}) @@ -524,12 +533,16 @@ \subsection{Organizzazione di un processo in memoria} dati dinamica in grado di supportare qualsiasi livello di annidamento all'interno vincoli di memoria. +\vspace{-0.5em} + \begin{figure}[H] \centering - \includegraphics[width=13cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/es_esecuzione_processo.png} + \includegraphics[width=11cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/es_esecuzione_processo.png} \caption{Esempio esecuzione processo.}\label{fig:es_esec_processo} \end{figure} +\vspace{-1em} + \subsection{Puntatori} \subsubsection{Extended base pointer (EBP)} @@ -566,13 +579,13 @@ \section{Stack overflow} (\verb|main|, \verb|f1| e \verb|f2|) che si chiamano a vicenda. Quando viene eseguito il programma viene inserito nello stack il frame del \verb|main|, supponiamo che esso inizi dall'indirizzo 1000, il quale viene salvato all'interno -del ebp e del registro della CPU. Successivamente quando viene chiamata la +del ebp e del registro della CPU. Successivamente, quando viene chiamata la funzione \verb|f1| l'ebp all'interno del registro della CPU cambia con quello dell'inizio del frame di \verb|f1|, ovvero 1008. -All'interno del frame di \verb|f1| vengono salvati oltre alle variabili locali +All'interno del frame di \verb|f1| vengono salvati, oltre alle variabili locali, anche il valore del ebp corrente(1008) e il valore di ritorno, il quale è uguale -all'epb del \verb|main| poiché appena terminata \verb|f1| la CPU deve tornare a -eseguire le istruzioni successive alla chiamata di funzione nel frame \verb|main|. +al valore che aveva l'eip prima di effettuare la call alla funzione \verb|f1| poiché appena terminata \verb|f1| la CPU deve tornare a +eseguire le istruzioni successive alla chiamata di funzione nel frame \verb|main|. Inoltre, terminata la funzione \verb|f1|, verrà ripristinato il valore del ebp al suo valore precedente ovvero all' ebp del \verb|main|. \begin{figure}[H] \centering @@ -592,7 +605,7 @@ \section{Stack overflow} mentre nel commento a riga 4 viene allocato come secondo rispetto a MyStrPtr poiché gli argomenti delle funzioni vengono allocati da destra verso sinistra, per comodità seguiamo la spiegazione delle slides. -A livello assembly quando viene chiamata la funzione vengono effettuate le seguente operazioni,: +A livello assembly, quando viene chiamata la funzione, vengono effettuate le seguente operazioni: \begin{enumerate} \item \verb|mov eax, [ebp- 4]|: si sposta quello che si trova in ebp-4 (MyStrPtr) @@ -606,6 +619,8 @@ \section{Stack overflow} \item \verb|add esp, 8|: aggiunge 8 byte al puntatore esp dopo il return di foo. \end{enumerate} +\vspace{-1.5em} + \begin{figure}[H] \centering \includegraphics[width=13cm, keepaspectratio]{capitoli/secure_coding/img/cap_2/disass_intel_1.png} @@ -689,6 +704,8 @@ \section{Stack overflow} \caption{Valori di ritorno.}\label{fig:ret_values} \end{figure} +\newpage + \section{Stack smashing} Stack smashing è quando un attaccante intenzionalmente fa overflow di un buffer nello @@ -705,7 +722,7 @@ \subsubsection{Esempio \textit{IsPasswordOk}: Arc Injection} Nell'esempio in Figura \ref{fig:password} il programma è vulnerabile a stack smashing. Questo difetto può essere facilmente dimostrato inserendo una password di 20 caratteri -“1234567890123456 W$\triangleright$*!” che porta a far saltare il programma in modo +``1234567890123456 W$\triangleright$*!'' che porta a far saltare il programma in modo imprevisto. \begin{figure}[H] @@ -723,7 +740,7 @@ \subsubsection{Esempio \textit{IsPasswordOk}: Arc Injection} In memoria l'ultima sequenza di quattro caratteri W$\triangleright$*! corrisponde a un indirizzo di 4 byte che sovrascrive l'indirizzo di ritorno nello stack, quindi invece di tornare all'istruzione subito dopo la chiamata in main() ritorna al ramo -“Access granted” bypassando così il controllo della password e autorizzando ad avere +``Access granted'' bypassando così il controllo della password e autorizzando ad avere accesso al sistema. Un metodo per capire dove è salvato il return address di una funzione nello stack è l'utilizzo del comando @@ -734,7 +751,7 @@ \subsubsection{Esempio \textit{IsPasswordOk}: Arc Injection} La tecnica di \textbf{Arc Injection} (a volte chiamata \textbf{return into-libc}) prevede -il trasferimento del controllo al codice esiste già nella memoria di processo. +il trasferimento del flusso di controllo ad una parte di codice già esistente nello spazio di memoria del programma. Questi exploit sono chiamati così perché inseriscono un nuovo arco (trasferimento del flusso di controllo) nel flusso di controllo del programma invece di iniettare nuovo codice. Questa tecnica è preferita rispetto al code injection @@ -754,7 +771,7 @@ \subsection{Code Injection (Shell Code)} raramente indica istruzioni valide. Per un attaccante è possibile creare delle stringhe speciali che contengono \textbf{un puntatore a qualche codice malevolo}, sempre creato dall'attaccante. Questo implica che quando il return address sovrascritto -viene invocato il controllo è trasferito al codice iniettato, il quale viene +viene invocato, il controllo è trasferito al codice iniettato e che quindi viene eseguito con i permessi del programma. Per questo i programmi che vengono eseguiti con permessi di \textbf{root} o dei \textbf{privilegi elevati} sono il target di certi attacchi, infatti frequentemente il codice malevolo apre una shell remota @@ -782,10 +799,10 @@ \subsubsection{Esempio \textit{IsPasswordOk}: Code Injection.} parametri che passeremo successivamente alle funzioni del exploit: \begin{itemize} - \item \textbf{"/usr/bin/cal"}: il primo esadecimale si traduce con il + \item \textbf{``/usr/bin/cal''}: il primo esadecimale si traduce con il comando \verb|/usr/bin/cal|. - \item \textbf{"null pointer"}: il secondo è un puntatore a null. - \item \textbf{"NULL"}: caratteri nulli. + \item \textbf{``null pointer''}: il secondo è un puntatore a null. + \item \textbf{``NULL''}: caratteri nulli. \end{itemize} \textbf{Spiegazione exploit code.} Vediamo nel dettaglio cosa fanno i comandi scritti @@ -800,7 +817,7 @@ \subsubsection{Esempio \textit{IsPasswordOk}: Code Injection.} char *const argv[], char *const envp[] );\end{lstlisting} - \item \verb|lea (%esp), %ebx|: "load effective address", calcola l'indirizzo + \item \verb|lea (%esp), %ebx|: ``load effective address'', calcola l'indirizzo effettivo del secondo operando (operando sorgente) e lo salva nel primo (operando destinatario). L'operando sorgente è un indirizzo di memoria (parte offset) specificato con una delle modalità di indirizzamento del processore mentre l'operando di destinazione è un diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo3_ROP.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo3_ROP.tex index bfedcf7ba..1c81d71b4 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo3_ROP.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo3_ROP.tex @@ -23,10 +23,12 @@ \section{Funzionamento dell'attacco} e \textit{code signing} \footnote{La firma del codice è il processo di firma digitale di eseguibili e script per confermare l'autore del software e garantire che - il codice non sia stato alterato o danneggiato da quando è stato firmato.} + il codice non sia stato alterato o danneggiato da quando è stato firmato.}. + +\newpage \paragraph{Esempio gadget.} Il gadget che vediamo in questo esempio -è \verb|pop %ebx; ret;|, costituito da due istruzioni. A sinistra possiamo vedere +è costituito da due istruzioni: \verb|pop %ebx; ret;| . A sinistra possiamo vedere il suo corrispettivo nel linguaggio assembly il quale copia il valore costante \verb|$0xdeadbeef| nel registro ebx e poi passa all'istruzione successiva grazie al puntatore eip, mentre la parte destra mostra il gadget equivalente. @@ -51,8 +53,8 @@ \section{Funzionamento dell'attacco} \paragraph{Esempio di attacco.} L'obiettivo dell'attacco è di invocare la chiamata di sistema \\ -\verb|ssize_t sys_write(unsigned int fd, const char * buf, size_t count)| -in modo da stampare a schermo “xxxHACKEDxxx”. Questa istruzione prende in input +\verb|size_t sys_write(unsigned int fd, const char * buf, size_t count)| +in modo da stampare a schermo ``xxxHACKEDxxx''. Questa istruzione prende in input un \textit{file descriptor} in questo caso un stdout, una stringa e la dimensione della stringa da stampare. @@ -62,7 +64,7 @@ \section{Funzionamento dell'attacco} \caption{Esempio attacco ROP.}\label{fig:es_attacco_rop} \end{figure} -Vediamo nel dettaglio come funziona, per inserire il codice nello stack possiamo +Vediamo nel dettaglio come funziona. Per inserire il codice nello stack possiamo fare un buffer overflow come abbiamo visto nell'esempio del code injection: \begin{enumerate} @@ -73,7 +75,7 @@ \section{Funzionamento dell'attacco} \item \verb|movl str_addr, %ecx|: copia l'indirizzo della stringa nel registro ecx; \item \verb|movl $13, %edx|: inserisce la grandezza della stringa nel registro edx, in questo modo abbiamo caricato nella - CPU tutto quello che ci serve. Per prima mette la chiamata di + CPU tutto quello che ci serve. Per prima mette la chiamata di sistema sys\_write e poi tutti i suoi parametri che abbiamo visto in precedenza; \item \verb|int $0x80|: int interrompe l'esecuzione della CPU e salta al @@ -93,11 +95,11 @@ \section{Funzionamento dell'attacco} istruzioni viste in precedenza. Come si può vedere in Figura \ref{fig:es_attacco_rop_gadget} partendo dal basso verso l'alto dove il buff ha un indirizzo più basso rispetto -alla stringa “xxxHACKEDxxx”, abbiamo i primi due spazi di memoria dedicati al main +alla stringa ``xxxHACKEDxxx'', abbiamo i primi due spazi di memoria dedicati al main frame con l'ebp e il buffer, successivamente la prima istruzione da effettuare è la \textbf{ret} del Gadget1. -La ret permette di eliminare tutto quello che ci stava prima di "0x4" compreso il -"return addr to gadget1" per poi passare a eseguire la prossima +La ret permette di eliminare tutto quello che ci stava prima di ``0x4'' compreso il +``return addr to gadget1'' per poi passare a eseguire la prossima istruzione del gadget1 che è \textbf{pop \%eax}. Questa operazione è simile al funzionamento di eip ovvero esso contiene l'istruzione successiva da eseguire senza eliminare quello che è salvato prima. @@ -114,9 +116,9 @@ \subsection{Qualche problema teorico} In generale se il file eseguibile è più grande di 3 MB c'è una buona probabilità che si può trovare un insieme di gadget per ogni exploit, più il file è piccolo più diminuisce la probabilità di trovare dei gadget. Inoltre non è sempre necessario usare -la ret ma possiamo usare anche il jump o altre, i ROP possono lavorare anche +la ret ma possiamo usare anche il jump o altre; i ROP possono lavorare anche senza \textbf{libc} ma utilizzando il codice fornito. La tecnica ROP fornisce un -"linguaggio" (Turing complete) completamente funzionale che un utente malintenzionato +``linguaggio'' (Turing complete) completamente funzionale che un utente malintenzionato può utilizzare in modo da far eseguire qualsiasi operazione desiderata a una macchina compromessa. @@ -127,9 +129,8 @@ \subsection{Come si fa exploit/previene} binario. Esso ricerca all'interno del file binario dei potenziali gadget utili e tenta di assemblarli in un payload di attacco che produce una shell. Un altro modo semplice di creare un attacco ROP è tramite il framework -CTF(Capture The Flag) \textbf{pwtools} \footnote{http://docs.pwntools.com/en/stable/rop/rop.html}, -scritto in Python è stato progettato per la prototipazione rapida e per rendere -la scrittura di exploit il più semplice possibile. +CTF(Capture The Flag) \textbf{pwtools} \footnote{http://docs.pwntools.com/en/stable/rop/rop.html} (scritto in Python e progettato per la prototipazione rapida così da rendere +la scrittura di exploit il più semplice possibile). \newpage diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo4_heap.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo4_heap.tex index 61a98aecb..b2228d230 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo4_heap.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo4_heap.tex @@ -19,6 +19,8 @@ \section{Alcuni problemi dello heap} \paragraph{Double free.} Consiste nel liberare lo stesso blocco di memoria più di una volta. +\newpage + \section{Heap overflow} \subsection{Dlmalloc} @@ -54,7 +56,7 @@ \subsubsection{Bin} Ogni bin ha una \textit{head}(testa) che contiene il puntatore in avanti e indietro che puntano rispettivamente al primo e all'ultimo blocco nella lista. Sia il chunk allocato che quello libero fanno uso di un bit \verb|PREV_INUSE| -(rappresentato da P \ref{fig:bin}) che indica se il chunk precedente è allocato o +(rappresentato da P in Figura \ref{fig:chunk_lib_alloc}) che indica se il chunk precedente è allocato o meno. \begin{figure}[H] @@ -63,6 +65,7 @@ \subsubsection{Bin} \caption{Esempio di un bin.}\label{fig:bin} \end{figure} + \subsubsection{UNLINK} \verb|unlink()| è una macro usata per rimuovere un chunk dalla sua lista doppiamente @@ -78,6 +81,7 @@ \subsubsection{UNLINK} } \end{verbatim} + \paragraph{Funzionamento macro.} Dalla Figura \ref{fig:ulink} si può capire bene il funzionamento della macro, essa prende in input tre puntatori @@ -124,6 +128,8 @@ \subsection{Tecnica unlink} \caption{Contenuto dell'heap alla prima chiamata di free().}\label{fig:heap_prima_free} \end{figure} +\vspace{-1em} + Se il secondo blocco non è allocato, l'operazione \verb|free()| prova a consolidarlo con il primo blocco. Per determinare se il secondo chunk è allocato o meno bisogna guardare il \verb|PREV_INUSE| bit del terzo blocco. La locazione di ogni blocco è @@ -136,7 +142,7 @@ \subsection{Tecnica unlink} con il secondo chunk della memoria, perché questo tag di confine è collocato immediatamente dopo la fine del primo blocco. La grandezza del primo chunk (672 byte) è il risultato della grandezza richiesta di 666 byte, più 4 byte per la grandezza, -arrotondato al multiplo più vicino a 8 poiché tutti chunk devono essere divisibili +arrotondato al multiplo più vicino a 8 poiché tutti i chunk devono essere divisibili per 8 byte. \begin{figure}[H] diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo5_Pointer_sub.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo5_Pointer_sub.tex index aeb0e1d27..1c73f37c8 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo5_Pointer_sub.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo5_Pointer_sub.tex @@ -34,12 +34,16 @@ \subsection{Puntatore a oggetti} Lo stesso metodo può essere applicato ai puntatori a variabili. +\vspace{-1em} + \begin{figure}[H] \centering \includegraphics[width=10cm, keepaspectratio]{capitoli/secure_coding/img/cap_5/es_pointer_var.png} \caption{Esempio pointer subterfuge su puntatori a variabili.}\label{fig:es_poin_var} \end{figure} +\vspace{-0.5em} + In questo caso abbiamo il \verb|buff[100]| di grandezza 100 caratteri seguito da una variabile di tipo long e un puntatore sempre long. Nell'esempio di prima andavamo a fare una \verb|strncpy| che portava al buffer overflow, qui invece facciamo @@ -55,7 +59,7 @@ \subsection{Puntatore a oggetti} \paragraph{Ultimo esempio} Questo ultimo esempio differenzia da quelli precedenti per il modo in cui vengono -chiamate le funzioni, esse possono essere chiamate in modo diretto o indiretto. +chiamate le funzioni. Esse possono essere chiamate in modo diretto o indiretto. \begin{figure}[H] \centering @@ -63,14 +67,14 @@ \subsection{Puntatore a oggetti} \caption{Esempio pointer subterfuge.}\label{fig:ult_es_poin} \end{figure} -A riga 9 in Figura \ref{fig:ult_es_poin}possiamo vedere un esempio di chiamate diretta, -mentre a riga 8 abbiamo una indiretta poiché \verb|good_function| è chiamata tramite +A riga 9 di Figura \ref{fig:ult_es_poin} possiamo vedere un esempio di chiamate diretta, +mentre a riga 8 ne abbiamo una indiretta poiché \verb|good_function| è chiamata tramite il puntatore a quest'ultima. In Figura \ref{fig:dissas_ult_es_poin} vediamo a livello -assembly la differenza fra le due chiamate, la chiamate diretta è più semplice perché +assembly la differenza fra le due chiamate. La chiamata diretta è più semplice perché viene effettuata, oltre la push per inserire nello stack la stringa da passare alla funzione, direttamente una call a \textbf{good\_function}. Al contrario la chiamata indiretta è un pò più complessa visto che non si fa una call -diretta a \textbf{good\_function} ma si chiama il puntatore a esse \verb|funcPtr| +diretta a \textbf{good\_function} ma si chiama il puntatore a essa, \verb|funcPtr|, che contiene l'indirizzo dove è salvata la funzione chiamata. L'istruzione di chiamata, ad esempio, salva l'informazione di ritorno sullo stack e trasferisce il controllo alla chiamata di funzione specificata dall'operando di destinazione (target). Il target diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo6_threads.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo6_threads.tex index a566fdc73..a47939e16 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo6_threads.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo6_threads.tex @@ -2,7 +2,7 @@ \chapter{Race Condition} \section{Introduzione} -Una “concorrenza incontrollata” può portare a un comportamento non deterministico +Una ``concorrenza incontrollata'' può portare a un comportamento non deterministico (cioè un programma può mostrare un comportamento diverso per lo stesso insieme di input). Una \textit{race condition} si verifica in qualsiasi scenario in cui due (o più) @@ -29,6 +29,10 @@ \section{Introduzione} controllo deve modificare lo stato dell'oggetto in condivisione. \end{enumerate} +\newpage + +\vspace{-2em} + \section{Race Window} Le Race Condition sono un difetto del software e sono una frequente fonte di @@ -51,17 +55,19 @@ \section{Race Window} Una race window è un segmento di codice che accede all'oggetto condiviso in modo da aprire una finestra di opportunità -durante la quale altri flussi concorrenti potrebbero "correre dentro" (race in) +durante la quale altri flussi concorrenti potrebbero ``correre dentro'' (race in) e alterare l'oggetto. Fondamentalmente è una zona di codice sottoposta a più flussi di controllo. Una race window non è protetta da un lock o da qualsiasi altro meccanismo. Se viene -protetta da una lock o simili viene detta “\textit{sezione critica}”. +protetta da una lock o simili viene detta ``\textit{sezione critica}''. -\paragraph{Esempio.}\ \\ +\vspace{-1em} + +\paragraph{Esempio.}\ -Gli esempi più subdoli possono dipendere anche da come è fatto il processore ! +Gli esempi più subdoli possono dipendere anche da come è fatto il processore! Prendiamo in considerazione il seguente codice: \begin{figure}[H] @@ -70,6 +76,8 @@ \section{Race Window} \caption{Codice di due thread.} \end{figure} +\vspace{-1em} + Come possiamo notare, i due thread assegnano un valore diverso alla stessa variabile condivisa. Queste istruzioni possono essere eseguite in modo diverso a livello architetturale. @@ -81,18 +89,19 @@ \section{Race Window} \end{figure} La race windows in questo caso, sono gli assegnamenti da entrambe le parti. -I registri possono essere -trattati come due metà differenti, indipendentemente dalla dimensione. -Come il compilatore -compila e come il processore si organizza è trasparente al programmatore. +I registri possono essere trattati come due metà differenti, indipendentemente dalla dimensione. +Come il compilatore compila e come il processore si organizza è trasparente al programmatore. Supponiamo che l'assegnamento venga effettuato in due parti da 8 bit. -Il thread 2 scrive 300, cioè $255+45$. Prima setta la parte bassa, -cioè la parte meno -significativa, a $45$; quella più significativa ad $255$. +Il thread 2 scrive 300, cioè $256+44$. Prima setta la parte bassa, cioè la parte meno significativa, a $44$; poi quella più significativa a $256$. $300$ infatti non ci sta in 8 bit. -Nel mentre però arriva il thread 1 che setta solo la parte bassa, quella meno \ -significativa a $100$. -Alla fine la variabile \verb|x| conterrà il valore $100+255=355$. +Nel mentre però arriva il thread 1 che setta solo la parte bassa, quella meno significativa, a $100$. +Alla fine la variabile \verb|x| conterrà il valore $100+256=356$. \\ +In big endian, con short int, si ha:\\ +\verb|300=44+256= 00101100| || \verb|100=100+0= 01100100| || \verb|Dopo 01100100 = 356|\\ +\verb| 00000001| || \verb| 00000000| || \verb|esecuzione 00000001 = 100+256| + +\vspace{-1em} + \section{Race Condition su File} @@ -107,6 +116,8 @@ \section{Race Condition su File} \paragraph{Esempio.}\ \\ +\vspace{-1em} + \begin{wrapfigure}{l}{0.5\textwidth} \centering \includegraphics[width=0.4\textwidth, keepaspectratio]{capitoli/secure_coding/img/cap_6/esempio_dir.png} @@ -129,9 +140,9 @@ \section{Race Condition su File} \section{TOCTOU} -Race Condition possono verificarsi durante I/O dei file. +Le Race Condition possono verificarsi durante I/O dei file. La finestra avviene tra il tempo in cui controllo qualcosa -(\textit{checking} di una risorsa, per esempio) e il tempo in cui la uso (\textit{using}). +(\textit{checking} di una risorsa, per e\-sempio) e il tempo in cui la uso (\textit{using}). Se questo intervallo è particolarmente grande, è probabile che si verifichi una race in nel flusso di controllo. \paragraph{Esempio.}\ \\ @@ -146,7 +157,7 @@ \section{TOCTOU} Alla linea 7 avviene il check mentre alla 9 il time-to-use. Tra questi due momenti c'è una race condition. Supponiamo che il processo stia girando con i \textbf{diritti di root}. -Ricordiamo che una delle operazioni più importanti da compiere quando si configura +Ricordiamo che una delle ope\-razioni più importanti da compiere quando si configura un sistema Unix è quello di disabilitare l'utente root. Immaginiamo però di aver dimenticato questa parte. Andremo a vedere come sfruttare questa vulnerabilità. @@ -266,7 +277,7 @@ \section{Prevenzione} in un ambiente con più thread che concorrono tra di loro. \begin{itemize} - \item Dimenticarsi di utilizzare il il lock quando si accede ai dati condivisi + \item Dimenticarsi di utilizzare il lock quando si accede ai dati condivisi (non bloccare la risorsa quando vi si accede); \item Rilasciare prematuramente un lock. Non si è chiusa la race window, quindi possono ancora accadere race conditions; @@ -285,7 +296,7 @@ \section{Prevenzione} \subsection{Memory Fencing} -“Fencing” vuol dire \textbf{barriera}, cancello. +``Fencin'' vuol dire \textbf{barriera}, cancello. In questo esempio la scrittura e la lettura vengono riorganizzate dal compilatore. È possibile che sia \verb|r1| che \verb|r2| siano settati a 0. Infatti, nel thread 2 (se nel primo \verb|x| non è ancora stata scritta) \verb|r2| @@ -305,35 +316,28 @@ \subsection{Memory Fencing} \caption{Possibile soluzione con memory fencing.} \end{figure} -Esiste una speciale funzione \verb|atomic_thread_fence| (alla linea 5) che -forza ad apportare le modifiche in memoria. +Esiste una speciale funzione \verb|atomic_thread_fence| (alla linea 5) che forza ad apportare le modifiche in memoria. Per cui saremo certi del fatto che i cambiamenti verranno apportati. -A questo punto solo uno tra \verb|r1| e \verb|r2| sarà uguale a 0, -dipende chi viene eseguito per primo. +A questo punto solo uno tra \verb|r1| e \verb|r2| sarà uguale a 0, dipende chi viene eseguito per primo. \subsection{File Locks} È possibile utilizzare la creazione di un file come lock. Tutti i processi controllano se il file è già stato creato. -Se così è, vanno in “sleep”. I vari controlli avvengono chiaramente in mutua esclusione. -Alla fine, il primo processo che termina cancella il file; -il primo che invece si sveglia e si rende conto del fatto che non c'è più, lo ricrea. +Se così è, vanno in ``sleep''. I vari controlli avvengono chiaramente in mutua esclusione. +Alla fine, il primo processo che termina cancella il file; il primo che invece si sveglia e si rende conto del fatto che non c'è più, lo ricrea. In realtà questa soluzione non è consigliata: è meglio usare strutture apposite, tipo mutex e simili. \subsection{Tools} Esistono dei tools per controllare se vi sono race condition. -Uno strumento di \textbf{analisi statica} analizza il software per ritrovarle, -senza eseguirlo effettivamente. -In generale la condition detection è un problema è NP completo (esponenziale). +Uno strumento di \textbf{analisi statica} analizza il software per ritrovarle, senza eseguirlo effettivamente. +In generale la condition detection è un problema NP completo (esponenziale). Diventa sempre più complesso con l'aumentare dei flussi di controllo. -Per questo motivo gli strumenti di rilevamento statico delle race condition forniscono -un'identificazione approssimativa. -Di conseguenza, tutti gli algoritmi di analisi statica sono soggetti ad alcuni falsi -negativi e falsi positivi. -Esiste il \textit{Clang thread Safety Analysis} (Google) che esegue un controllo -per capire se sono presenti race conditions: +Per questo motivo gli strumenti di rilevamento statico delle race condition forniscono un'identificazione approssimativa. +Di conseguenza, tutti gli algoritmi di analisi statica sono soggetti ad alcuni falsi negativi e falsi positivi. +Esiste il \textit{Clang thread Safety Analysis} (Google) che esegue un controllo per capire se sono presenti race conditions: \begin{lstlisting} clang -c -Wthread-safety example.cpp @@ -348,5 +352,4 @@ \subsection{Tools} \item spesso c'è un overhead di tempo di esecuzione. \end{itemize} -Possibili tools sono: Intel Inspector (a pagamento) e Helgrind -(parte di Valgrind, cioè una suite di 6 tools differenti). +Possibili tools sono: Intel Inspector (a pagamento) e Helgrind (parte di Valgrind, cioè una suite di 6 tools differenti). diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo7_fuzztesting.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo7_fuzztesting.tex index a8eafdf28..61113762d 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo7_fuzztesting.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo7_fuzztesting.tex @@ -1,13 +1,8 @@ \chapter{FuzzTesting e Sanitization} -Il \textbf{fuzzing} o \textbf{fuzz testing} è una tecnica di test automatizzata -del software che consiste nel fornire dati non validi, inaspettati o comunque casuali -come input ad un programma. In questo modo mettiamo in crisi il programma, -vediamo come reagisce alle varie possibilità e riusciamo a capire se ci sono bug o no. -Consiste quindi in una strategia per trovare problemi di affidabilità (reliability); -alcuni di essi possono in realtà rappresentare vulnerabilità. -Qualsiasi interfaccia di applicazione (per esempio, rete, input di file, riga di comando, -modulo Web e così via) può essere sottoposta a fuzz-test. +Il \textbf{fuzzing} o \textbf{fuzz testing} è una tecnica di test automatizzata del software che consiste nel fornire dati non validi, inaspettati o comunque casuali come input ad un programma. In questo modo mettiamo in crisi il programma, vediamo come reagisce alle varie possibilità e riusciamo a capire se ci sono bug o no. +Consiste quindi in una strategia per trovare problemi di affidabilità (reliability); alcuni di essi possono in realtà rappresentare vulnerabilità. +Qualsiasi interfaccia di applicazione (per esempio rete, input di file, riga di comando, modulo Web e così via) può essere sottoposta a fuzz-test. Gli obiettivi del fuzzing possono variare a seconda del tipo di interfaccia che si sta testando. \begin{figure}[H] @@ -16,62 +11,36 @@ \chapter{FuzzTesting e Sanitization} \caption{Lifecycle del fuzz testing.} \end{figure} -Anche in questo caso esistono tools dinamici di sicurezza. -Si dividono in: +Anche in questo caso esistono tools dinamici di sicurezza. Si dividono in: \begin{itemize} - \item \textbf{Black-box} fuzzing: non presuppongono niente riguardo il programma, - semplicemente eseguono i propri compiti. Modificano a caso ("fuzz") l'input ben formato - cioè scritto bene. - \item \textbf{White-box} fuzzing: hanno la possibilità di vedere il codice ed agire di - conseguenza sull'input. + \item \textbf{Black-box} fuzzing: non presuppongono niente riguardo il programma, semplicemente eseguono i propri compiti. Modificano a caso (``fuzz'') l'input ben formato cioè scritto bene. + \item \textbf{White-box} fuzzing: hanno la possibilità di vedere il codice ed agire di conseguenza sull'input. \end{itemize} \section{White-box vs Black-box} -\paragraph{Black-box fuzzing}: consiste nell'invio di dati malformati senza verifica -effettiva di quali percorsi di codice sono stati colpiti e quali no; non vede il codice. +\paragraph{Black-box fuzzing}: consiste nell'invio di dati malformati senza verifica effettiva di quali percorsi di codice sono stati testati e quali no; non vede il codice. È più semplice da scrivere e da utilizzare, ma meno efficace. -\paragraph{White-box fuzzing}: consiste nell'invio di malformati con verifica. -È a conoscenza dei vari percorsi che fanno le informazioni nel programma ed è in grado di -generare dati più ottimizzati, al fine di tirare fuori i comportamenti inaspettati. +\paragraph{White-box fuzzing}: consiste nell'invio di dati malformati con verifica. +È a conoscenza dei vari percorsi che fanno le informazioni nel programma ed è in grado di generare dati più ottimizzati al fine di tirare fuori comportamenti inaspettati. Attraversa quindi tutte le validazioni dei dati nel codice testato. -Risulta però essere più difficili da scrivere di un Black-box fuzzer.\\ +Risulta però essere più difficile da scrivere di un Black-box fuzzer.\\ -Il black-box ha una \textit{path coverage} del codice inferiore rispetto a tecniche più -sofisticate come il fuzzing automatico delle white-box -(che viene anche detto “fuzzing intelligente”). -Si raccomanda generalmente l'utilizzo di un mix di metodologie per massimizzare -l'efficacia della scoperta della vulnerabilità. +Il black-box ha una \textit{path coverage} del codice inferiore rispetto a tecniche più sofisticate come il fuzzing automatico delle white-box (che viene anche detto ``fuzzing intelligente''). +Si raccomanda generalmente l'utilizzo di un mix di metodologie per massimizzare l'efficacia della scoperta delle vulnerabilità. \section{Tools} Di seguito alcuni strumenti per il fuzz-testing del codice. -\paragraph{CERT Basic Fuzzing Framework,} in breve BFF, è uno strumento di test -black-box del software che trova difetti nelle applicazioni che girano su piattaforme Windows, -Linux e macOs. BFF raccoglie automaticamente i casi di test che causano il crash del software. - -\paragraph{LibFuzzer} è uno strumento per effettuare fuzz-testing di librerie o programmi. -Viene selezionato uno specifico punto di ingresso (la funzione a cui passare gli input) -chiamata \textit{target function} per poi tenere traccia di quali aree del codice -vengono raggiunte. Vengono anche generate delle mutazioni sul -\textit{corpus} di dati in ingresso al fine di massimizzare la copertura del codice. -I fuzzer coverage-guided come libFuzzer sono \textbf{black-box} e si basano su un -corpus di input, -campione per il codice in prova, che è uguale per tutti. -Questo corpus dovrebbe idealmente essere riempito con una collezione variegata di input -validi e non validi per il codice in prova. -Il fuzzer genera mutation casuali basate sugli ingressi del campione nel corpus corrente. -Se una mutation fa scattare l'esecuzione di un path non coperto in precedenza, -allora quella mutazione viene salvata nel corpus per le future variazioni. - -\paragraph{Address sanitizer} è un rilevatore di errori di memoria veloce. -È un fuzz tester focalizzato sugli indirizzi; vede cosa succede se vengono passati degli -strani indirizzi di memoria. -È costituito da un modulo del compilatore di C++ e da una libreria di run-time. -Lo strumento è in grado di rilevare i seguenti tipi di bug: +\paragraph{CERT Basic Fuzzing Framework,} in breve BFF, è uno strumento di test black-box del software che trova difetti nelle applicazioni che girano su piattaforme Windows, Linux e macOs. BFF raccoglie automaticamente i casi di test che causano il crash del software. + +\paragraph{LibFuzzer} è uno strumento per effettuare fuzz-testing di librerie o programmi. Viene selezionato uno specifico punto di ingresso (la funzione a cui passare gli input) chiamata \textit{target function} per poi tenere traccia di quali aree del codice vengono raggiunte. Vengono anche generate delle mutazioni sul \textit{corpus} di dati in ingresso al fine di massimizzare la copertura del codice. I fuzzer coverage-guided come libFuzzer sono \textbf{black-box} e si basano su un corpus di input, campione per il codice in prova, che è uguale per tutti. Questo corpus dovrebbe idealmente essere riempito con una collezione variegata di input validi e non validi per il codice in prova. Il fuzzer genera mutation casuali basate sugli ingressi del campione nel corpus corrente. Se una mutation fa scattare l'esecuzione di un path non coperto in precedenza, allora quella mutazione viene salvata nel corpus per le future variazioni. + +\paragraph{Address sanitizer} è un rilevatore di errori di memoria veloce. È un fuzz tester focalizzato sugli indirizzi; vede cosa succede se vengono passati degli +strani indirizzi di memoria. È costituito da un modulo del compilatore di C++ e da una libreria di run-time. Lo strumento è in grado di rilevare i seguenti tipi di bug: \begin{itemize} \item Accessi Out-of-bounds a heap, stack and globals; @@ -89,7 +58,6 @@ \section{Tools} \begin{itemize} \item Overflow di Signed integer; - \item Conversione in, da, o tra tipi a virgola mobile, che causerebbero l'overflow della - destinazione; + \item Conversione in, da, o tra tipi a virgola mobile, che causerebbero l'overflow della destinazione; \item Utilizzo di un puntatore disallineato o nullo. \end{itemize} \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo8_sqlinjection.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo8_sqlinjection.tex index b21f216b2..33b5b10b8 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo8_sqlinjection.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo8_sqlinjection.tex @@ -1,25 +1,12 @@ \chapter{SQL Injection} -SQL injection è una tecnica di \textit{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). +SQL injection è una tecnica di \textit{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). Sfrutta quindi le vulnerabilità di sicurezza del codice -di un'applicazione. Un classico esempio è un'applicazione che si interfaccia -con un database -e che prende in input dati provenienti da una form web. -SQL Injection è comune con PHP e ASP (ormai abbandonato) a causa della -prevalenza di -vecchie interfacce funzionali. -Per quanto sia estremamente semplice evitare questo tipo di problemi, -molte applicazioni -commerciali (e non) sono soggette a questa vulnerabilità -(che può portare ad accessi non -autorizzati e alla distruzione di database aziendali) dovuta all'eccessiva -fiducia negli input -degli utenti.\\ +di un'applicazione. Un classico esempio è un'applicazione che si interfaccia con un database e che prende in input dati provenienti da una form web. +SQL Injection è comune con PHP e ASP (ormai abbandonato) a causa della prevalenza di +vecchie interfacce funzionali. Per quanto sia estremamente semplice evitare questo tipo di problemi, +molte applicazioni commerciali (e non) sono soggette a questa vulnerabilità (che può portare ad accessi non +autorizzati e alla distruzione di database aziendali) dovuta all'eccessiva fiducia negli input degli utenti.\\ Potenziali vulnerabilità ad SQL injection si verificano quando: @@ -74,7 +61,7 @@ \subsection{Esempio 1} WHERE firstname = $input1 AND lastname = $input2 \end{lstlisting} -Assumiamo che il valore delle due variabili \verb|\$input1| \verb|\$input2| +Assumiamo che il valore delle due variabili \verb|$input1| \verb|$input2| sia: \begin{lstlisting}[language=PHP] @@ -82,7 +69,7 @@ \subsection{Esempio 1} $input2 = "Newman" \end{lstlisting} -La query quindi risulterà essere la seguente: +La query risulterà essere la seguente: \begin{lstlisting}[language=Sql] SELECT id, firstname, lastname @@ -90,8 +77,9 @@ \subsection{Esempio 1} WHERE firstname = 'evil'ex' AND lastname = 'Newman' \end{lstlisting} -Avremo quindi un errore, in quanto il database tenterà di eseguire \verb|evil| -come un comando SQL (\verb|Incorrect syntax near il'|). +Avremo quindi un errore in quanto il singolo apice inserito in \verb|$input1| va a chiudere e troncare la stringa in input. Il database tenterà poi di eseguire \verb|ex| come un comando SQL ma genererà un errore (\verb|Incorrect syntax near il'|). + +\newpage \subsection{Esempio 2} @@ -109,11 +97,11 @@ \subsection{Esempio 2} \end{lstlisting} Se l'utente \verb|wiley| imposta il valore dell'attributo\\ -\verb|ItemName.Text| a \verb|name' OR 'a'='a'|, la query risulterà essere: +\verb|ItemName.Text| a \verb|name' OR 'a'='a|, la query risulterà essere: \begin{lstlisting}[language=SQL] SELECT * FROM items - WHERE (owner = 'wiley' AND itemname = 'name') + WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; \end{lstlisting} @@ -129,7 +117,7 @@ \subsection{Esempio 3} Mettiamo che l'utente \verb|hacker| inserisca come input la stringa: \begin{lstlisting}[language=SQL] - "name'); DELETE FROM items; --" + name'; DELETE FROM items; -- \end{lstlisting} La query risulterà essere: @@ -145,9 +133,10 @@ \subsection{Esempio 3} Siamo quindi riusciti ad eliminare l'intera tabella !\\ Questo accade perché molti database (incluso Microsoft SQL Server 2000) -permettono l'esecuzione consecutiva di più query separata da un \verb|;|. -Per esempio, questo non funzionerebbe in Oracle DB in quanto non permette questo -comportamento. +permettono l'esecuzione consecutiva di più query separate da un ``\verb|;|''. +Per esempio, questo non funzionerebbe in Oracle DB in quanto non permette tale comportamento. + +\newpage \section{Mitigation} @@ -173,18 +162,11 @@ \section{Mitigation} \subsection{Dichiarazioni Preparate} -Tutti i linguaggi garantiscono la possibilità di “preparare” dei comandi. +Tutti i linguaggi garantiscono la possibilità di ``preparare'' dei comandi. L'uso di dichiarazioni preparate con vincoli variabili, anche dette -\textit{query parametrizzate}, è il -modo corretto con cui tutti gli sviluppatori dovrebbero prima essere istruiti su -come scrivere -le query del database. -Le query parametrizzate costringono lo sviluppatore a definire prima tutto il -codice SQL, per -poi passare ogni parametro alla query in secondo momento. -Le istruzioni preparate assicurano che un aggressore non sia in grado di -modificare l'intento -di una query, anche se vengono passati come input dei comandi SQL.\\ +\textit{query parametrizzate}, è il modo corretto con cui tutti gli sviluppatori dovrebbero prima essere istruiti su come scrivere le query del database. +Le query parametrizzate costringono lo sviluppatore a definire prima tutto il codice SQL, per poi passare ogni parametro alla query in un secondo momento. +Le istruzioni preparate assicurano che un aggressore non sia in grado di modificare l'intento di una query, anche se vengono passati come input dei comandi SQL.\\ Alcuni esempi pratici: @@ -215,10 +197,10 @@ \subsection{Dichiarazioni Preparate} "; // qui viene effettuato il binding e reso sicuro l'input - PreparedStatement pstmt = connection.prepareStatement( query ); - pstmt.setString( 1, custname); + PreparedStatement pstm = connection.prepareStatement(query); + pstm.setString(1, custname); - ResultSet results = pstmt.executeQuery( ); + ResultSet results = pstm.executeQuery(); \end{lstlisting} \subsection{Procedura Memorizzata} @@ -289,7 +271,8 @@ \subsection{Escaping degli Input} \begin{lstlisting}[language=Php] $mysqli = new mysqli( 'hostname', - 'db_username', 'db_password', + 'db_username', + 'db_password', 'db_name' ); $query = sprintf( @@ -307,33 +290,15 @@ \subsection{Escaping degli Input} \subsection{Altre Difese Aggiuntive} -Oltre ad adottare una delle quattro difese primarie (quelle elencate in precedenza), -è raccomandato anche di adottare tutte -queste tecniche per assicurare una difesa migliore. +Oltre ad adottare una delle quattro difese primarie (quelle elencate in precedenza), è raccomandato anche adottare tutte queste tecniche per assicurare una difesa migliore. \paragraph{Least Privilege.} -Per ridurre i potenziali danni di un attacco SQL injection, è necessario ridurre -al minimo i -privilegi assegnati ad ogni account. Non assegnate diritti di accesso di tipo DBA -o admin agli -account dell'applicazione. È meglio partire da zero per determinare quali diritti -di accesso -richiedono gli account piuttosto che cercare di capire quali diritti di accesso -si devono togliere. -In breve: +Per ridurre i potenziali danni di un attacco SQL injection, è necessario ridurre al minimo i privilegi assegnati ad ogni account. Non assegnate diritti di accesso di tipo DBA o admin agli account dell'applicazione. È meglio partire da zero per determinare quali diritti di accesso richiedono gli account piuttosto che cercare di capire quali diritti di accesso si devono togliere. In breve: \begin{itemize} - \item Assicuratevi che agli account che necessitano solo di un accesso in - lettura sia - concesso solo l'accesso in lettura alle tabelle a cui hanno bisogno di accedere; - \item Se un account ha bisogno di accedere solo ad alcune porzioni di una - tabella, - considerare la possibilità di creare una vista che limiti l'accesso a quella - porzione di - dati e di assegnare invece l'accesso dell'account alla vista, piuttosto che - alla tabella sottostante; - \item Raramente, se non mai, concedere l'accesso totale agli account del - database. + \item Assicuratevi che agli account che necessitano solo di un accesso in lettura sia concesso solo l'accesso in lettura alle tabelle a cui hanno bisogno di accedere; + \item Se un account ha bisogno di accedere solo ad alcune porzioni di una tabella, considerare la possibilità di creare una vista che limiti l'accesso a quella porzione di dati e di assegnare invece l'accesso dell'account alla vista, piuttosto che alla tabella sottostante; + \item Raramente, se non mai, concedere l'accesso totale agli account del database. \end{itemize} \paragraph{Multiple DB users.} diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo9_xss.tex b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo9_xss.tex index 0df7fe9a2..2db6b692f 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo9_xss.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo9_xss.tex @@ -50,15 +50,10 @@ \section{Attacchi} \subsection{Stored} -Gli attacchi di tipo \textit{Stored} (memorizzati) sono quelli in cui lo -script iniettato viene memorizzato in -modo permanente sui server di destinazione, ad esempio in una banca dati, -in un forum di -messaggi, nel registro dei visitatori, nel campo dei commenti, ecc. -La vittima recupera quindi lo script dannoso dal server quando richiede le -informazioni memorizzate. -Gli XSS memorizzati vengono anche chiamati \textit{XSS Persistenti} o -\textit{XSS di tipo I}. +Gli attacchi di tipo \textit{Stored} (memorizzati) sono quelli in cui lo script iniettato viene memorizzato in +modo permanente sui server di destinazione, ad esempio in una banca dati, in un forum di messaggi, nel registro dei visitatori, nel campo dei commenti, ecc. +La vittima recupera quindi lo script dannoso dal server quando richiede le informazioni memorizzate. +Gli XSS memorizzati vengono anche chiamati \textit{XSS Persistenti} o \textit{XSS di tipo I}. \paragraph{Esempio.} Prendiamo in esame il seguente schema che rappresenta un attacco che avviene @@ -73,10 +68,10 @@ \subsection{Stored} \begin{enumerate} \item L'attaccante inserisce del codice javascript in un post e questo viene automaticamente memorizzato nel database. - \item La vittima che vuole vedere quel post, ci clicca + \item La vittima che vuole vedere quel post, ci clicca. \item Il commento viene scaricato automaticamente dal database e viene visualizzato nel browser dell'utente andando ad eseguire il codice - javascript al suo interno + javascript al suo interno. \end{enumerate} Attacchi di questo tipo possono ad esempio rubare e @@ -84,24 +79,18 @@ \subsection{Stored} \subsection{Reflected} -Gli attacchi \textit{Reflected} (riflessi) sono quelli in cui lo script iniettato -viene “riflesso” dal server web, ad -esempio in un messaggio di errore, in un risultato di ricerca o in qualsiasi altra -risposta che +Gli attacchi \textit{Reflected} (riflessi) sono quelli in cui lo script iniettato viene ``riflesso'' dal server web, ad esempio in un messaggio di errore, in un risultato di ricerca o in qualsiasi altra risposta che include parte o tutto l'input inviato al server come parte della richiesta. -Gli attacchi riflessi -vengono quindi consegnati alle vittime attraverso un'altra via, ad esempio in un -messaggio di -posta elettronica o su un altro sito web. -Quando un utente viene ingannato a cliccare su un link maligno, a inviare un modulo -appositamente creato o anche solo a navigare su un sito maligno, il codice -iniettato viaggia -verso il sito web vulnerabile, che riflette l'attacco al browser dell'utente. -Il browser esegue poi il codice perché proviene da un server "di fiducia". -Gli XSS riflessi -sono anche chiamati \textit{XSS Non-Persistenti} o \textit{XSS di tipo II}. - -\paragraph{Esempio "\textit{Client Reflected}".} +Gli attacchi riflessi vengono quindi consegnati alle vittime attraverso un'altra via, ad esempio in un +messaggio di posta elettronica o su un altro sito web. +Quando un utente viene ingannato a cliccare su un link maligno, a inviare un modulo appositamente creato o anche solo a navigare su un sito maligno, il codice +iniettato viaggia verso il sito web vulnerabile, che riflette l'attacco al browser dell'utente. +Il browser esegue poi il codice perché proviene da un server ``di fiducia''. +Gli XSS riflessi sono anche chiamati \textit{XSS Non-Persistenti} o \textit{XSS di tipo II}. + +\newpage + +\paragraph{Esempio ``\textit{Client Reflected}''.} Analizziamo il seguente schema: \begin{figure}[H] @@ -132,124 +121,67 @@ \subsection{Reflected} \item ...viene eseguito il codice javascript malevolo. \end{enumerate} -L'attacco viene detto "\textit{reflected}" perché il server web ha riflesso la -domanda. Il sito è giusto, -il server web è lecito (fa solo da veicolo), ma la keyword è stata scritta in -modo da far eseguire il codice malevolo nel browser. +L'attacco viene detto "\textit{reflected}" perché il server web ha riflesso la domanda. Il sito è giusto, +il server web è lecito (fa solo da veicolo), ma la keyword è stata scritta in modo da far eseguire il codice malevolo nel browser. \subsection{DOM Based} -DOM Based XSS (o, come viene chiamato in alcuni testi, "\textit{type-0 XSS}") è -un attacco XSS in -cui il payload dell'attacco viene eseguito come risultato della modifica -dell'"ambiente" DOM -nel browser della vittima utilizzato dallo script originale lato client, -in modo che il codice -venga eseguito in modo "inaspettato". -Il Document Object Model (DOM) è un'interfaccia di programmazione applicativa -indipendente dalla piattaforma e dal linguaggio che tratta un documento HTML, -XHTML o XML -come una struttura ad albero in cui ogni nodo è un oggetto che rappresenta una -parte del documento. -Quando una pagina web viene caricata, il browser crea un Document Object Model -della pagina, che è una rappresentazione orientata agli oggetti di un documento -HTML, che funge -da interfaccia tra JavaScript e il documento stesso e permette la creazione di -pagine web dinamiche. +DOM Based XSS (o, come viene chiamato in alcuni testi, ``\textit{type-0 XSS}'') è un attacco XSS in +cui il payload dell'attacco viene eseguito come risultato della modifica dell'``ambiente'' DOM +nel browser della vittima utilizzato dallo script originale lato client, in modo che il codice +venga eseguito in modo ``inaspettato''. +Il Document Object Model (DOM) è un'interfaccia di programmazione applicativa indipendente dalla piattaforma e dal linguaggio che tratta un documento HTML, XHTML o XML come una struttura ad albero in cui ogni nodo è un oggetto che rappresenta una parte del documento. +Quando una pagina web viene caricata, il browser crea un Document Object Model della pagina, che è una rappresentazione orientata agli oggetti di un documento +HTML, che funge da interfaccia tra JavaScript e il documento stesso e permette la creazione di pagine web dinamiche. + +\vspace{-1em} \begin{figure}[H] \centering \includegraphics[width=\textwidth, keepaspectratio]{capitoli/secure_coding/img/cap_9/dom.png} \end{figure} +\vspace{-2em} + \paragraph{Esempio.} -Supponiamo che un codice venga utilizzato per creare un modulo che permetta -all'utente di -scegliere la lingua preferita. Nella query viene fornita anche una lingua -predefinita, come -parametro "default". -La pagina viene invocata con un URL. Un attacco contro questa pagina può essere -effettuato inviando il seguente URL a una vittima. Quando la vittima clicca su -questo link, il -browser invia una certa richiesta. Il server risponde con la pagina contenente il -codice Javascript. Il browser crea un oggetto DOM per la pagina, in cui l'oggetto -\verb|document.location| contiene la stringa. -Il codice Javascript originale nella pagina non si aspetta che il parametro di -default contenga -il markup HTML, e come tale lo fa semplicemente echeggiare nella pagina (DOM) a -runtime. +Supponiamo che un codice venga utilizzato per creare un modulo che permetta all'utente di scegliere la lingua preferita. Nella query viene fornita anche una lingua +predefinita, come parametro ``default''. +La pagina viene invocata con un URL. Un attacco contro questa pagina può essere effettuato inviando il seguente URL a una vittima. Quando la vittima clicca su +questo link, il browser invia una certa richiesta. Il server risponde con la pagina contenente il codice Javascript. Il browser crea un oggetto DOM per la pagina, in cui l'oggetto \verb|document.location| contiene la stringa. +Il codice Javascript originale nella pagina non si aspetta che il parametro di default contenga il markup HTML, e come tale lo fa semplicemente echeggiare nella pagina (DOM) a runtime. \subsection{Un'altra Classificazione} -Secondo la prima classificazione \textbf{Stored}, \textbf{Reflected} e -\textbf{DOM Based} sono tre diversi tipi di XSS, ma in -realtà questi si sovrappongono. Si possono avere gli DOM Based XSS sia Stored che -Reflected. Si possono avere anche Non-DOM Based XSS Stored e Reflected. +Secondo la prima classificazione \textbf{Stored}, \textbf{Reflected} e \textbf{DOM Based} sono tre diversi tipi di XSS, ma in realtà questi si sovrappongono. Si possono avere gli DOM Based XSS sia Stored che Reflected. Si possono avere anche Non-DOM Based XSS Stored e Reflected. Possiamo effettuare un'ulteriore distinzione: \textit{Server Side} o \textit{Client Side}. -\paragraph{Server Side: } si verifica quando i dati forniti -dall'utente untrusted sono inclusi in una -risposta HTML generata dal server. La -fonte di questi dati potrebbe provenire dalla -richiesta o da una posizione stored -(memorizzata). -E' possibile avere sia Reflected che Stored -Server XSS. -In questo caso, l'intera vulnerabilità è in -codice lato server, e il browser sta -semplicemente prendendo la risposta ed -eseguendo uno script valido incorporato. - -\paragraph{Client Side: } si verifica quando i dati forniti -dall'utente untrusted vengono utilizzati per -aggiornare il DOM con una chiamata -JavaScript che non è sicura. Una chiamata -JavaScript è considerata unsafe se può -essere utilizzata per introdurre JavaScript +\paragraph{Server Side: } si verifica quando i dati forniti dall'utente untrusted sono inclusi in una +risposta HTML generata dal server. La fonte di questi dati potrebbe provenire dalla richiesta o da una posizione stored (memorizzata). +E' possibile avere sia Reflected che Stored Server XSS. +In questo caso, l'intera vulnerabilità è in codice lato server, e il browser sta semplicemente prendendo la risposta ed eseguendo uno script valido incorporato. + +\paragraph{Client Side: } si verifica quando i dati forniti dall'utente untrusted vengono utilizzati per +aggiornare il DOM con una chiamata JavaScript che non è sicura. Una chiamata JavaScript è considerata unsafe se può essere utilizzata per introdurre JavaScript valido nel DOM. -Questa fonte di dati potrebbe -provenire dal DOM o potrebbe essere stata -inviata dal server (tramite una chiamata -AJAX o un page load). La fonte finale dei -dati potrebbe provenire da una richiesta o -da una posizione memorizzata sul client o -sul server. -È possibile avere sia Reflected che Stored -Client XSS. +Questa fonte di dati potrebbe provenire dal DOM o potrebbe essere stata inviata dal server (tramite una chiamata AJAX o un page load). La fonte finale dei +dati potrebbe provenire da una richiesta o da una posizione memorizzata sul client o sul server. +È possibile avere sia Reflected che Stored Client XSS. \section{Mitigation} -Per cercare di arginare questo tipo di problemi -possiamo fare riferiamo soprattutto a strumenti per l'individuazione. -\textbf{BlueClosure Detect} può analizzare qualsiasi codice scritto con framework -JavaScript come -\textit{Angular.js}, \textit{jQuery}, \textit{Meteor.js}, \textit{React.js} e -molti altri. BlueClosure Detect utilizza un avanzato -motore di strumentazione Javascript per capire il codice. Il motore BCD è in grado -di -ispezionare qualsiasi codice, indipendentemente da quanto sia offuscato. -La tecnologia BlueClosure è in grado di scansionare automaticamente un intero sito -web. -Questo è il modo più veloce per scansionare e analizzare GRANDI portali aziendali -con -ricchi contenuti Javascript come farebbe un tester con il suo browser. -Ci sono poi i tools di \textit{Pentest}: \textbf{Nessus}, \textbf{Nikto}, e alcuni -altri strumenti disponibili possono -aiutare a scansionare un sito web per questi difetti, ma soltanto superficialmente. -Se una -parte di un sito web è vulnerabile, è molto probabile che ci siano anche altri -problemi.\\ - -Per uno sviluppatore web, ci sono due modi diversi di eseguire la gestione sicura -degli input: +Per cercare di arginare questo tipo di problemi possiamo fare riferiamo soprattutto a strumenti per l'individuazione. +\textbf{BlueClosure Detect} può ana\-lizzare qualsiasi codice scritto con framework JavaScript come +\textit{Angular.js}, \textit{jQuery}, \textit{Meteor.js}, \textit{React.js} e molti altri. BlueClosure Detect utilizza un avanzato motore di strumentazione Javascript per capire il codice. Il motore BCD è in grado di ispezionare qualsiasi codice, indipendentemente da quanto sia offuscato. +La tecnologia BlueClosure è in grado di scansionare automaticamente un intero sito web. +Questo è il modo più veloce per scansionare e analizzare GRANDI portali aziendali con ricchi contenuti Javascript come farebbe un tester con il suo browser. +Ci sono poi i tools di \textit{Pentest}: \textbf{Nessus}, \textbf{Nikto}, e alcuni altri strumenti disponibili possono aiutare a scansionare un sito web per questi difetti, ma soltanto superficialmente. +Se una parte di un sito web è vulnerabile, è molto probabile che ci siano anche altri problemi.\\ + +Per uno sviluppatore web, ci sono due modi diversi di eseguire la gestione sicura degli input: \begin{itemize} - \item \textbf{Encoding}, che fa escape all'input dell'utente in modo che - il browser lo interpreti solo - come dati, non come codice. - \item \textbf{Validation}, che filtra l'input dell'utente in modo che il - browser lo interpreti come codice - senza comandi dannosi. + \item \textbf{Encoding}, che fa escape all'input dell'utente in modo che il browser lo interpreti solo come dati, non come codice. + \item \textbf{Validation}, che filtra l'input dell'utente in modo che il browser lo interpreti come codice senza comandi dannosi. \end{itemize} Questi metodi condividono caratteristiche comuni, importanti da comprendere @@ -293,15 +225,21 @@ \subsection{Gestione input Inbound/Outbound} dannosa, la gestione sicura degli input deve essere eseguita nel codice lato client. Questo viene fatto utilizzando JavaScript. +\newpage + \subsection{XSS Prevention Cheat Sheet} Vediamo ora una lista di suggerimenti utili per prevenire attacchi XSS. +\vspace{-0.5em} + \paragraph{Rule \#0:} non inserire mai dati non attendibili, se non in posizioni consentite. -La prima regola è quella di negare tutto (dey all), non inserire dati non +La prima regola è quella di negare tutto (deny all), non inserire dati non attendibili nel documento HTML a meno che non si trovino all'interno di uno degli -slot definiti dalla Rule \#1 alla Rule \#5. +slot definiti dalla Rule \#0 alla Rule \#4. + +\vspace{-0.5em} \paragraph{Rule \#1:} : \textit{effettuare \textbf{escaping} del codice HTML prima di inserire dati non attendibili nell'HTML}. @@ -323,6 +261,8 @@ \subsection{XSS Prevention Cheat Sheet} \item \verb|/| $\rightarrow$ \verb|/| \end{itemize} +\vspace{-0.5em} + \paragraph{Rule \#2:} \textit{escaping degli attributi prima di inserire dati non attendibili negli attributi comuni HTML}. Regola per inserire dati non attendibili in valori tipici degli attributi come @@ -331,10 +271,14 @@ \subsection{XSS Prevention Cheat Sheet} \verb|href|, \verb|src|, \verb|style|, o qualsiasi gestore di eventi come \verb|onmouseover|. +\vspace{-0.5em} + \paragraph{Rule \#3:} \textit{javascript escape prima di inserire dati non attendibili nei valori dei dati javascript}. Riguarda il codice JavaScript generato dinamicamente. +\vspace{-0.5em} + \paragraph{Rule \#4:} \textit{css escape e validare rigorosamente prima di inserire dati non attendibili nei valori delle proprietà di stile HTML}. Sempre validare ed effettuare l'escaping quando si desidera inserire dati non diff --git a/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/img/cap_2/disass_intel_1.png b/magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/img/cap_2/disass_intel_1.png index bdbd4ea4cc6e1d323edbb5eb35a206b54bbae047..520cc29635d6a9cb7ce1d34d6ce3f55c0221ca92 100644 GIT binary patch literal 416982 zcmd42W0NR66D>NnZQHhO+cSG?+cSG?+qP}nwrzXPexJH^&tEtnQb{NIkg9Y#Su3l< z739QWp|GF;003YmB}9|}06?Sx0DwUufd2IW%is3=s{oyp#DxHAW^m5`86akYvVs5r z^|8=jhM@m!NP7uQCjbDr!T%M&QM)o@0D#|ONfAL6cfG4`aDUuU7cwaI(M&RO7)LNb zAd>zpC$vUUYDJY48eZ)O&(#*=TfW+^meq~z)(_k!Ju4H*6q?#V+Vuvapfmt50Fbb( zLx8mYBWI`5-_MGVmn}$u5D-cr1wV=>6?G1mnQ~{j(n?T40;8cYL}IZh495R84!ivE zexm=c{cpetzdjWC|DW)$@d*C^N{1E#h~ZNfP@0;zmFnntni3mH58$X=b67}|q)L$F zwfJd8ie5R9eDlRZSS1rO0X9)V)rA&f9Jk4b@!KLD=d=+b5aJlspJ%ej!aS*{+2M4l zGPTJ|13}dob1Bmi)ltdfZ3pjyh%2f0)&vNVA^=ozJ(mLuMzKmD)o#nBaxwW3$Z8Aa zq?`zV4tJ@%JgUmGoQ{1+8+H4HqkDy<$}?szlj*Xl;H|KLFcs8hN`-Pg-SZ-ab!4ro zKrB1}R6Nv7nI@(
Com1v(VSqZ1Zy>WXOq>FBbC$+Z))&1B`}Rf|>khJUHbG9+TldKqPE
zD$V7>nJpj`j8Wsm-XSE?1@w=_OjK--S*WyS|J&0U)hsVOxHnkueaxoQx^P2AIAPHk
zOKHxA_ljtKl%|ma)X-z&O3z{l3JIc~kP}jwX%)m|Xds0Wx=i?R(11ch>N+5NIXH}0
zmO*4NE$~y5c5Q4x3d 9A|A|v`WTDeP>@$gl@It6G4G$G1nZY?T>?7r$Rx~;gCa?y{R3S1pbJ7QB
z#<|AmP?I+5Npw2Lk>*JA7daJDD$>9XNSP^-Qwd;QK^4-t49&QK=JP{