Skip to content

Commit

Permalink
fix(appunti): Correzione e aggiunta appunti Santini (#43)
Browse files Browse the repository at this point in the history 
Apportate modifiche e miglioramenti alla parte di Santini degli appunti di Cybersecurity:

- 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
- Aggiunto capitolo WebSecurity - Santini

#minor
  • Loading branch information
@ncvescera
ncvescera authored Aug 17, 2023
2 parents 7353145 + b57906a commit c3e1e13
Show file tree
Hide file tree
Showing 47 changed files with 643 additions and 456 deletions.
Binary file modified magistrale/Anno 1/Cybersecurity/Appunti_Cybersecurity-Santini.pdf
View file
Binary file not shown.
103 changes: 43 additions & 60 deletions magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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.}\

Expand All @@ -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}

Expand All @@ -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}

Expand All @@ -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}).
Expand All @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -421,7 +416,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.
Expand All @@ -443,7 +438,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
Expand All @@ -453,44 +448,32 @@ \subsection{Mitigation}

\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.}\ \\
I minatori hanno la possibilità di regolare leggermente i timestamp, il che può rivelarsi pericoloso se essi venissero utilizzati in modo scorretto.

\begin{figure}[H]
\centering
\includegraphics[width=12cm, keepaspectratio]{capitoli/ethereum/imgs/timestamp.png}
\caption{Sezione di codice vulnerabile alla Timestamp Manipulation.}
\end{figure}
\paragraph{Esempio.}\

Prendiamo in considerazione in precedente codice di un contratto che simula
una roulette.
Prendiamo in considerazione il codice (Figura~\ref{fig:timestamp}) 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).

\begin{figure}[H]
\centering
\includegraphics[width=12cm, keepaspectratio]{capitoli/ethereum/imgs/timestamp.png}
\caption{Sezione di codice vulnerabile alla Timestamp Manipulation.}
\label{fig:timestamp}
\end{figure}

\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.

Expand Down Expand Up @@ -525,7 +508,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
Expand Down Expand Up @@ -566,7 +549,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
Expand Down
52 changes: 15 additions & 37 deletions magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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}
Expand All @@ -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}
Expand Down Expand Up @@ -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}
Expand Down Expand Up @@ -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:
Expand All @@ -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
Expand Down Expand Up @@ -178,7 +172,7 @@ \section{Proof of Stake (PoS)}
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.
Expand All @@ -191,6 +185,7 @@ \section{Proof of Stake (PoS)}
non servono immense potenze di calcolo per risolvere complesse operazioni matematiche.
Alcune cryptocurrencies che sfruttano il PoS sono:


\begin{itemize}
\item ShadowCash
\item Nxt
Expand All @@ -200,32 +195,20 @@ \section{Proof of Stake (PoS)}

\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:

\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 queste caratteristiche:

\begin{enumerate}
\item Opera all'interno della sua blockchain
Expand All @@ -234,13 +217,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}

Expand Down
Loading

0 comments on commit c3e1e13

Please sign in to comment.