Test di sicurezza - Guida rapida

I test di sicurezza sono molto importanti per mantenere il sistema protetto da attività dannose sul Web.

Che cos'è il test di sicurezza?

Il test di sicurezza è una tecnica di test per determinare se un sistema informativo protegge i dati e mantiene la funzionalità come previsto. I test di sicurezza non garantiscono la sicurezza completa del sistema, ma è importante includere i test di sicurezza come parte del processo di test.

I test di sicurezza adottano le sei misure seguenti per fornire un ambiente protetto:

• Confidentiality - Protegge dalla divulgazione di informazioni a destinatari involontari.

• Integrity - Consente il trasferimento delle informazioni desiderate accurate e corrette dai mittenti ai destinatari previsti.

• Authentication - Verifica e conferma l'identità dell'utente.

• Authorization - Specifica i diritti di accesso agli utenti e alle risorse.

• Availability - Garantisce la disponibilità delle informazioni su richiesta.

• Non-repudiation - Assicura che non vi sia alcuna negazione da parte del mittente o del destinatario per aver inviato o ricevuto il messaggio.

Esempio

Individuare un difetto di sicurezza in un'applicazione basata sul Web richiede passaggi complessi e pensiero creativo. A volte, un semplice test può esporre il più grave rischio per la sicurezza. Puoi provare questo test molto semplice su qualsiasi applicazione web -

• Accedi all'applicazione web utilizzando credenziali valide.

• Esci dall'applicazione web.

• Fare clic sul pulsante INDIETRO del browser.

• Verifica se ti viene chiesto di accedere di nuovo o se riesci a tornare nuovamente alla pagina di accesso.

I test di sicurezza possono essere visti come un attacco controllato al sistema, che scopre i difetti di sicurezza in modo realistico. Il suo obiettivo è valutare lo stato attuale di un sistema IT. È anche conosciuto comepenetration test o più comunemente come ethical hacking.

Il test di penetrazione viene eseguito in fasi e qui in questo capitolo discuteremo il processo completo. La documentazione adeguata dovrebbe essere eseguita in ogni fase in modo che tutti i passaggi necessari per riprodurre l'attacco siano prontamente disponibili. La documentazione serve anche come base per il report dettagliato che i clienti ricevono al termine di un penetration test.

Penetration Test - Flusso di lavoro

Il test di penetrazione comprende quattro fasi principali:

• Stampa del piede
• Scanning
• Enumeration
• Exploitation

Questi quattro passaggi vengono ripetuti più volte, il che va di pari passo con il normale SDLC.

Il software dannoso (malware) è qualsiasi software che conferisce un controllo parziale o completo del sistema all'autore dell'attacco / creatore di malware.

Malware

Di seguito sono elencate varie forme di malware:

• Virus- Un virus è un programma che crea copie di se stesso e le inserisce in altri programmi per computer, file di dati o nel settore di avvio del disco rigido. In caso di replica riuscita, i virus causano attività dannose sugli host infetti come il furto di spazio su disco rigido o tempo di CPU.

• Worm - Un worm è un tipo di malware che lascia una copia di se stesso nella memoria di ogni computer sul suo percorso.

• Trojan - Trojan è un tipo di malware non autoreplicante che contiene codice dannoso, che al momento dell'esecuzione provoca la perdita o il furto di dati o possibili danni al sistema.

• Adware- L'adware, noto anche come freeware o pitchware, è un software per computer gratuito che contiene annunci commerciali di giochi, barre degli strumenti desktop e utilità. È un'applicazione basata sul Web e raccoglie i dati del browser Web per indirizzare gli annunci pubblicitari, in particolare i popup.

• Spyware- Lo spyware è un software di infiltrazione che monitora in modo anonimo gli utenti che consente a un hacker di ottenere informazioni sensibili dal computer dell'utente. Lo spyware sfrutta gli utenti e le vulnerabilità delle applicazioni che sono spesso collegate ai download di software online gratuiti o ai collegamenti cliccati dagli utenti.

• Rootkit - Un rootkit è un software utilizzato da un hacker per ottenere l'accesso a livello di amministratore a un computer / rete che viene installato tramite una password rubata o sfruttando una vulnerabilità del sistema all'insaputa della vittima.

Misure preventive

È possibile adottare le seguenti misure per evitare la presenza di malware in un sistema:

• Assicurati che il sistema operativo e le applicazioni siano aggiornati con patch / aggiornamenti.

• Non aprire mai strane e-mail, specialmente quelle con allegati.

• Quando scarichi da Internet, controlla sempre cosa installi. Non fare semplicemente clic su OK per chiudere le finestre popup. Verifica l'editore prima di installare l'applicazione.

• Installa un software antivirus.

• Assicurati di scansionare e aggiornare regolarmente i programmi antivirus.

• Installa il firewall.

• Abilita e utilizza sempre le funzionalità di sicurezza fornite dai browser e dalle applicazioni.

Software anti-malware

Il seguente software aiuta a rimuovere i malware da un sistema:

• Microsoft Security Essentials
• Microsoft Windows Defender
• AVG Internet Security
• Spybot - Cerca e distruggi
• Avast! Home Edition per uso personale
• Panda Internet Security
• MacScan per Mac OS e Mac OS X

Comprendere il protocollo è molto importante per avere una buona conoscenza dei test di sicurezza. Sarai in grado di apprezzare l'importanza del protocollo quando intercettiamo i dati del pacchetto tra il server web e il client.

Protocollo HTTP

Il protocollo HTTP (Hypertext Transfer Protocol) è un protocollo a livello di applicazione per sistemi informativi distribuiti, collaborativi e ipermediali. Questa è la base per la comunicazione dei dati per il World Wide Web dal 1990. HTTP è un protocollo generico e senza stato che può essere utilizzato anche per altri scopi utilizzando l'estensione dei suoi metodi di richiesta, codici di errore e intestazioni.

Fondamentalmente, HTTP è un protocollo di comunicazione basato su TCP / IP, che viene utilizzato per fornire dati come file HTML, file di immagine, risultati di query ecc. Sul web. Fornisce un modo standardizzato per i computer di comunicare tra loro. La specifica HTTP specifica come i dati richiesti dai client vengono inviati al server e come i server rispondono a queste richieste.

Caratteristiche di base

Ci sono le seguenti tre caratteristiche di base che rendono HTTP un protocollo semplice ma potente:

• HTTP is connectionless- Il client HTTP, cioè il browser avvia una richiesta HTTP. Dopo aver effettuato una richiesta, il client si disconnette dal server e attende una risposta. Il server elabora la richiesta e ristabilisce la connessione con il client per inviare la risposta.

• HTTP is media independent- Qualsiasi tipo di dati può essere inviato tramite HTTP purché sia ​​il client che il server sappiano come gestire il contenuto dei dati. Ciò è necessario affinché il client e il server specifichino il tipo di contenuto utilizzando il tipo MIME appropriato.

• HTTP is stateless- HTTP è un protocollo senza connessione e questo è un risultato diretto che HTTP è un protocollo senza stato. Il server e il client si conoscono solo durante una richiesta corrente. In seguito, entrambi si dimenticano l'un l'altro. A causa di questa natura del protocollo, né il client né il browser possono conservare le informazioni tra le diverse richieste nelle pagine web.

HTTP / 1.0 utilizza una nuova connessione per ogni scambio di richiesta / risposta mentre la connessione HTTP / 1.1 può essere utilizzata per uno o più scambi di richiesta / risposta.

Architettura

Il diagramma seguente mostra un'architettura di base di un'applicazione web e mostra dove risiede HTTP:

Il protocollo HTTP è un protocollo di richiesta / risposta basato sull'architettura client / server in cui browser web, robot e motori di ricerca ecc. Agiscono come client HTTP e il server web funge da server.

• Client - Il client HTTP invia una richiesta al server sotto forma di metodo di richiesta, URI e versione del protocollo, seguita da un messaggio simile a MIME contenente modificatori di richiesta, informazioni sul client e possibile contenuto del corpo su una connessione TCP / IP.

• Server - Il server HTTP risponde con una riga di stato, inclusa la versione del protocollo del messaggio e un codice di successo o errore, seguito da un messaggio simile a MIME contenente informazioni sul server, meta informazioni dell'entità e possibile contenuto del corpo dell'entità.

HTTP: svantaggi

• HTTP non è un protocollo completamente protetto.

• HTTP utilizza la porta 80 come porta predefinita per la comunicazione.

• HTTP opera a livello dell'applicazione. È necessario creare più connessioni per il trasferimento dei dati, il che aumenta i costi di amministrazione.

• Non sono richiesti crittografia / certificati digitali per l'utilizzo di HTTP.

Dettagli del protocollo HTTP

Per comprendere la profondità del protocollo HTTP, fare clic su ciascuno dei collegamenti sottostanti.

• HTTP Parameters

• HTTP Messages

• HTTP Requests

• HTTP Responses

• HTTP Methods

• HTTP Status Codes

• HTTP Header Fields

• HTTP Security

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) o HTTP su SSL è un protocollo web sviluppato da Netscape. Non è un protocollo, ma è solo il risultato della stratificazione dell'HTTP su SSL / TLS (Secure Socket Layer / Transport Layer Security).

In breve, HTTPS = HTTP + SSL

Quando è richiesto HTTPS?

Quando navighiamo, normalmente inviamo e riceviamo informazioni utilizzando il protocollo HTTP. Quindi questo porta chiunque a origliare la conversazione tra il nostro computer e il server web. Molte volte abbiamo bisogno di scambiare informazioni sensibili che devono essere protette e per impedire l'accesso non autorizzato.

Protocollo HTTP utilizzato nei seguenti scenari:

• Siti web bancari
• Casello stradale
• Siti web di acquisto
• Tutte le pagine di accesso
• App di posta elettronica

Funzionamento di base di HTTPS

• Chiave pubblica e certificati firmati sono necessari per il server nel protocollo HTTPS.

• Richieste client per la pagina https: //

• Quando si utilizza una connessione https, il server risponde alla connessione iniziale offrendo un elenco di metodi di crittografia supportati dal server web.

• In risposta, il client seleziona un metodo di connessione e il client e il server si scambiano i certificati per autenticare le proprie identità.

• Al termine, sia il server Web che il client si scambiano le informazioni crittografate dopo essersi assicurati che entrambi stiano utilizzando la stessa chiave e la connessione viene chiusa.

• Per l'hosting delle connessioni https, un server deve disporre di un certificato di chiave pubblica, che incorpora le informazioni sulla chiave con una verifica dell'identità del proprietario della chiave.

• Quasi tutti i certificati vengono verificati da una terza parte in modo che i clienti abbiano la certezza che la chiave sia sempre sicura.

Che cos'è la codifica e la decodifica?

La codifica è il processo di inserimento di una sequenza di caratteri come lettere, numeri e altri caratteri speciali in un formato specializzato per una trasmissione efficiente.

La decodifica è il processo di riconversione di un formato codificato nella sequenza di caratteri originale. È completamente diverso dalla crittografia che di solito interpretiamo erroneamente.

La codifica e la decodifica vengono utilizzate nelle comunicazioni e nell'archiviazione dei dati. La codifica NON deve essere utilizzata per il trasporto di informazioni sensibili.

Codifica URL

Gli URL possono essere inviati solo su Internet utilizzando il set di caratteri ASCII e ci sono casi in cui l'URL contiene caratteri speciali oltre ai caratteri ASCII, deve essere codificato. Gli URL non contengono spazi e vengono sostituiti con un segno più (+) o con% 20.

Codifica ASCII

Il browser (lato client) codificherà l'input in base al set di caratteri utilizzato nella pagina Web e il set di caratteri predefinito in HTML5 è UTF-8.

La seguente tabella mostra il simbolo ASCII del carattere e il suo simbolo uguale e infine la sua sostituzione che può essere utilizzata nell'URL prima di passarlo al server -

ASCII	Simbolo	Sostituzione
<32		Codifica con% xx dove xx è la rappresentazione esadecimale del carattere.
32	spazio	+ o% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	>	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	UN	UN
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	io	io
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	%5 D
94	^	% 5E
95	_	_
96	"	% 60
97	un	un
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	io	io
106	j	j
107	K	K
108	l	l
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	S	S
116	t	t
117	u	u
118	v	v
119	w	w
120	X	X
121	y	y
122	z	z
123	{	% 7B
124	|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Codifica con% xx dove xx è la rappresentazione esadecimale del carattere

Cos'è la crittografia?

La crittografia è la scienza per crittografare e decrittografare i dati che consente agli utenti di memorizzare informazioni sensibili o trasmetterle attraverso reti non sicure in modo che possano essere lette solo dal destinatario previsto.

Vengono chiamati dati che possono essere letti e compresi senza misure speciali plaintext, mentre viene chiamato il metodo per mascherare il testo in chiaro per nasconderne la sostanza encryption.

Il testo in chiaro crittografato è noto come testo cifrato e il processo di ripristino dei dati crittografati in testo normale è noto come decryption.

• La scienza dell'analisi e dell'interruzione della comunicazione sicura è nota come crittoanalisi. Le persone che eseguono lo stesso noto anche come aggressori.

• La crittografia può essere forte o debole e la forza è misurata dal tempo e dalle risorse necessarie per recuperare il testo in chiaro.

• Quindi è necessario uno strumento di decodifica appropriato per decifrare i messaggi crittografati forti.

• Sono disponibili alcune tecniche crittografiche con le quali anche un miliardo di computer che eseguono un miliardo di controlli al secondo, non è possibile decifrare il testo.

• Poiché la potenza di calcolo aumenta di giorno in giorno, è necessario rendere gli algoritmi di crittografia molto potenti per proteggere i dati e le informazioni critiche dagli aggressori.

Come funziona la crittografia?

Un algoritmo crittografico funziona in combinazione con una chiave (può essere una parola, un numero o una frase) per crittografare il testo in chiaro e lo stesso testo in chiaro crittografa in un testo cifrato diverso con chiavi diverse.

Quindi, i dati crittografati dipendono completamente da una coppia di parametri come la forza dell'algoritmo crittografico e la segretezza della chiave.

Tecniche di crittografia

Symmetric Encryption- La crittografia convenzionale, nota anche come crittografia convenzionale, è la tecnica in cui viene utilizzata una sola chiave sia per la crittografia che per la decrittografia. Ad esempio, DES, algoritmi Triple DES, MARS di IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption- È la crittografia a chiave pubblica che utilizza una coppia di chiavi per la crittografia: una chiave pubblica per crittografare i dati e una chiave privata per la decrittografia. La chiave pubblica viene pubblicata per le persone mantenendo segreta la chiave privata. Ad esempio, RSA, Digital Signature Algorithm (DSA), Elgamal.

Hashing- L'hashing è una crittografia UNIDIREZIONALE, che crea un output codificato che non può essere invertito o almeno non può essere invertito facilmente. Ad esempio, l'algoritmo MD5. Viene utilizzato per creare certificati digitali, firme digitali, archiviazione di password, verifica delle comunicazioni, ecc.

La Same Origin Policy (SOP) è un concetto importante nel modello di sicurezza delle applicazioni web.

Qual è la politica della stessa origine?

Secondo questa politica, consente l'esecuzione di script su pagine provenienti dallo stesso sito che possono essere una combinazione dei seguenti:

• Domain
• Protocol
• Port

Esempio

La ragione di questo comportamento è la sicurezza. Se hai try.com in una finestra e gmail.com in un'altra finestra, NON vuoi che uno script da try.com acceda o modifichi i contenuti di gmail.com o esegua azioni nel contesto di gmail per tuo conto.

Di seguito sono riportate le pagine Web dalla stessa origine. Come spiegato prima, la stessa origine prende in considerazione dominio / protocollo / porta.

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

Di seguito sono riportate le pagine Web di origine diversa.

• http://www.site.co.uk (un altro dominio)
• http://site.org (un altro dominio)
• https://site.com (un altro protocollo)
• http://site.com:8080 (un'altra porta)

Eccezioni ai criteri della stessa origine per IE

Internet Explorer ha due principali eccezioni a SOP.

• Il primo è correlato a "Zone attendibili". Se entrambi i domini si trovano in una zona altamente affidabile, il criterio Stessa origine non è applicabile completamente.

• La seconda eccezione in IE è relativa alla porta. IE non include la porta nella policy Same Origin, quindi http://website.com e http://wesite.com:4444 sono considerati dalla stessa origine e non vengono applicate restrizioni.

Cos'è un cookie?

Un cookie è una piccola porzione di informazione inviata da un server web per essere memorizzata su un browser web in modo che possa essere letta successivamente dal browser. In questo modo, il browser ricorda alcune informazioni personali specifiche. Se un hacker si impossessa delle informazioni sui cookie, possono verificarsi problemi di sicurezza.

Proprietà dei cookie

Ecco alcune importanti proprietà dei cookie:

• Di solito sono piccoli file di testo, dati tag ID che vengono memorizzati nella directory del browser del tuo computer.

• Sono utilizzati dagli sviluppatori web per aiutare gli utenti a navigare nei loro siti web in modo efficiente ed eseguire determinate funzioni.

• Quando l'utente naviga nuovamente sullo stesso sito web, i dati memorizzati nel cookie vengono rinviati al server web per notificare al sito web le precedenti attività dell'utente.

• I cookie sono inevitabili per i siti Web che dispongono di database enormi, necessitano di accessi, hanno temi personalizzabili.

Contenuto dei cookie

Il cookie contiene le seguenti informazioni:

• Il nome del server da cui è stato inviato il cookie.
• La durata del cookie.
• Un valore, di solito un numero univoco generato in modo casuale.

Tipi di cookie

• Session Cookies- Questi cookie sono temporanei che vengono cancellati quando l'utente chiude il browser. Anche se l'utente accede di nuovo, viene creato un nuovo cookie per quella sessione.

• Persistent cookies- Questi cookie rimangono sul disco rigido a meno che l'utente non li cancelli o scadano. La scadenza dei cookie dipende da quanto tempo possono durare.

Cookie di test

Ecco i modi per testare i cookie:

• Disabling Cookies- In qualità di tester, dobbiamo verificare l'accesso al sito web dopo aver disabilitato i cookie e controllare se le pagine funzionano correttamente. Navigare in tutte le pagine del sito Web e osservare gli arresti anomali delle app. È inoltre necessario informare l'utente che i cookie sono necessari per utilizzare il sito.

• Corrupting Cookies- Un altro test da eseguire è corrompere i cookie. Per fare lo stesso, è necessario trovare la posizione del cookie del sito e modificarlo manualmente con dati falsi / non validi che possono essere utilizzati per accedere alle informazioni interne dal dominio che a loro volta possono essere utilizzate per hackerare il sito.

• Removing Cookies - Rimuovere tutti i cookie del sito Web e verificare come reagisce il sito Web.

• Cross-Browser Compatibility - È anche importante verificare che i cookie vengano scritti correttamente su tutti i browser supportati da qualsiasi pagina che scrive cookie.

• Editing Cookies- Se l'applicazione utilizza i cookie per memorizzare le informazioni di accesso, come tester dovremmo provare a cambiare l'utente nel cookie o nella barra degli indirizzi con un altro utente valido. La modifica del cookie non dovrebbe consentire di accedere a un account utente diverso.

Visualizzazione e modifica dei cookie

I browser moderni supportano la visualizzazione / modifica delle informazioni sui cookie all'interno del browser stesso. Esistono plugin per mozilla / chrome che ci consentono di eseguire correttamente la modifica.

• Modifica il plug-in dei cookie per Firefox

• Modifica questo cookie plugin per Chrome

È necessario eseguire i passaggi per modificare un cookie:

• Scarica il plug-in per Chrome da qui

• Modifica il valore del cookie semplicemente accedendo al plug-in "modifica questo cookie" da Chrome come mostrato di seguito.

Esistono varie metodologie / approcci che possiamo utilizzare come riferimento per eseguire un attacco.

Applicazione Web - Metodologie di PenTesting

Si possono tenere in considerazione i seguenti standard durante lo sviluppo di un modello di attacco.

Tra il seguente elenco, OWASP è il più attivo e ci sono numerosi collaboratori. Ci concentreremo sulle tecniche OWASP che ogni team di sviluppo prende in considerazione prima di progettare un'app web.

• PTES - Penetration Testing Execution Standard

• OSSTMM - Manuale metodologico di test di sicurezza open source

• Tecniche di test OWASP - Open Web Application Security Protocol

OWASP Top 10

Il team di Open Web Application Security Protocol ha rilasciato le prime 10 vulnerabilità più diffuse nel web negli ultimi anni. Di seguito è riportato l'elenco dei difetti di sicurezza più diffusi in un'applicazione basata sul Web.

Applicazione - Hands On

Per comprendere ciascuna delle tecniche, lavoriamo con un'applicazione di esempio. Eseguiremo l'attacco a "WebGoat", l'applicazione J2EE sviluppata esplicitamente con falle di sicurezza per scopi di apprendimento.

È possibile trovare i dettagli completi sul progetto webgoat https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. Per scaricare l'applicazione WebGoat, vai ahttps://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) e vai alla sezione download.

Per installare l'applicazione scaricata, assicurati innanzitutto di non avere alcuna applicazione in esecuzione sulla porta 8080. Può essere installata utilizzando un solo comando: java -jar WebGoat-6.0.1-war-exec.jar. Per maggiori dettagli, visita Installazione di WebGoat

Dopo l'installazione, dovremmo essere in grado di accedere all'applicazione navigando in http://localhost:8080/WebGoat/attack e la pagina verrà visualizzata come mostrato di seguito.

Possiamo utilizzare le credenziali dell'ospite o dell'amministratore visualizzate nella pagina di accesso.

Proxy Web

Per poter intercettare il traffico tra client (Browser) e Server (Sistema in cui è ospitata l'applicazione Webgoat nel nostro caso), dobbiamo utilizzare un proxy web. Useremo Burp Proxy che può essere scaricato dahttps://portswigger.net/burp/download.html

È sufficiente scaricare la versione gratuita della suite burp come mostrato di seguito.

Configurazione di Burp Suite

Burp Suite è un web proxy in grado di intercettare ogni pacchetto di informazioni inviato e ricevuto dal browser e dal webserver. Questo ci aiuta a modificare i contenuti prima che il client invii le informazioni al Web-Server.

Step 1- L'app è installata sulla porta 8080 e Burp è installato sulla porta 8181 come mostrato di seguito. Avvia la suite Burp ed effettua le seguenti impostazioni per visualizzarla nella porta 8181 come mostrato di seguito.

Step 2- Dovremmo assicurarci che Burp stia ascoltando la porta # 8080 dove è installata l'applicazione in modo che la suite Burp possa intercettare il traffico. Questa impostazione deve essere eseguita nella scheda Ambito di Burp Suite come mostrato di seguito.

Step 3- Quindi effettua le impostazioni proxy del tuo browser per ascoltare la porta 8181 (porta Burp Suite). Quindi abbiamo configurato il proxy Web per intercettare il traffico tra il client (browser) e il server (server Web) come mostrato di seguito -

Step 4 - L'istantanea della configurazione è mostrata di seguito con l'aiuto di un semplice diagramma del flusso di lavoro come mostrato di seguito

La tecnica di iniezione consiste nell'iniettare una query SQL o un comando utilizzando i campi di input dell'applicazione.

Applicazione Web - Iniezione

Una SQL injection riuscita può leggere, modificare i dati sensibili dal database e può anche eliminare i dati da un database. Consente inoltre all'hacker di eseguire operazioni amministrative sul database come l'arresto del DBMS / l'eliminazione dei database.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempi

L'applicazione utilizza dati non attendibili nella costruzione della seguente chiamata SQL vulnerabile:

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

Mani su

Step 1 - Navigare nell'area SQL Injection dell'applicazione come mostrato di seguito.

Step 2- Come indicato nell'esercizio, utilizziamo String SQL Injection per bypassare l'autenticazione. Usa SQL injection per accedere come boss ("Neville") senza utilizzare la password corretta. Verifica che il profilo di Neville possa essere visualizzato e che tutte le funzioni siano disponibili (incluse Cerca, Crea ed Elimina).

Step 3 - Inietteremo un SQL in modo tale da poter bypassare la password inviando il parametro come 'a' = 'a' o 1 = 1

Step 4 - Dopo lo sfruttamento, siamo in grado di accedere come Neville che è l'amministratore come mostrato di seguito.

Prevenire SQL Injection

Esistono molti modi per prevenire l'iniezione SQL. Quando gli sviluppatori scrivono il codice, devono assicurarsi di gestire i caratteri speciali di conseguenza. Ci sono cheat sheet / tecniche di prevenzione disponibili da OWASP che è sicuramente una guida per gli sviluppatori.

• Utilizzo di query con parametri
• Sfuggire a tutti gli input forniti dall'utente
• Abilita il privilegio minimo per il database per gli utenti finali

Quando le funzioni di autenticazione relative all'applicazione non sono implementate correttamente, consente agli hacker di compromettere le password o gli ID di sessione o di sfruttare altri difetti di implementazione utilizzando le credenziali di altri utenti.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Un utente autenticato del sito inoltra l'URL ai propri amici per conoscere le vendite scontate. Invia tramite posta elettronica il collegamento precedente senza sapere che l'utente sta fornendo anche gli ID di sessione. Quando i suoi amici usano il collegamento, usano la sua sessione e la carta di credito.

Mani su

Step 1- Accedi a Webgoat e vai alla sezione "Difetti di gestione delle sessioni". Ignoriamo l'autenticazione falsificando il cookie. Di seguito l'istantanea dello scenario.

Step 2 - Quando effettuiamo il login utilizzando le credenziali webgoat / webgoat, troviamo da Burp Suite che l'ID JSESSION è C8F3177CCAFF380441ABF71090748F2E mentre AuthCookie = 65432ubphcfx in caso di autenticazione riuscita.

Step 3 - Quando accediamo utilizzando l'aspetto / aspetto delle credenziali, troviamo da Burp Suite che l'ID JSESSION è C8F3177CCAFF380441ABF71090748F2E mentre AuthCookie = 65432udfqtb dopo l'autenticazione riuscita.

Step 4- Ora dobbiamo analizzare gli AuthCookie Patterns. La prima metà "65432" è comune per entrambe le autenticazioni. Quindi ora siamo interessati ad analizzare l'ultima parte dei valori di authcookie come - ubphcfx per webgoat user e udfqtb per aspect user rispettivamente.

Step 5- Se diamo uno sguardo approfondito ai valori di AuthCookie, l'ultima parte ha la stessa lunghezza di quella del nome utente. Quindi è evidente che il nome utente viene utilizzato con alcuni metodi di crittografia. Dopo tentativi ed errori / meccanismi di forza bruta, troviamo che dopo aver invertito il nome utente, webgoat; finiamo con taogbew e quindi il carattere dell'alfabeto prima è quello che viene utilizzato come AuthCookie. cioè ubphcfx.

Step 6- Se passiamo questo valore del cookie e vediamo cosa succede. Dopo l'autenticazione come utente webgoat, modificare il valore AuthCookie per deridere l'utente Alice trovando l'AuthCookie per lo stesso eseguendo il passaggio 4 e il passaggio 5.

Meccanismi di prevenzione

• Sviluppare un'autenticazione forte e controlli di gestione della sessione in modo tale da soddisfare tutti i requisiti di autenticazione e gestione della sessione definiti nello standard di verifica della sicurezza dell'applicazione OWASP.

• Gli sviluppatori dovrebbero assicurarsi di evitare i difetti XSS che possono essere utilizzati per rubare gli ID di sessione.

Cross-site Scripting (XSS) si verifica ogni volta che un'applicazione accetta dati non attendibili e li invia al client (browser) senza convalida. Ciò consente agli aggressori di eseguire script dannosi nel browser della vittima che possono comportare il dirottamento delle sessioni utente, la deturpazione di siti Web o il reindirizzamento dell'utente a siti dannosi.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Tipi di XSS

• Stored XSS - XSS memorizzato, noto anche come XSS persistente, si verifica quando l'input dell'utente viene memorizzato sul server di destinazione come database / forum di messaggi / campo commenti ecc. Quindi la vittima è in grado di recuperare i dati memorizzati dall'applicazione web.

• Reflected XSS - XSS riflesso, noto anche come XSS non persistente, si verifica quando l'input dell'utente viene immediatamente restituito da un'applicazione Web in un messaggio di errore / risultato di ricerca o l'input fornito dall'utente come parte della richiesta e senza memorizzare in modo permanente i dati forniti dall'utente.

• DOM Based XSS - DOM Based XSS è una forma di XSS quando l'origine dei dati è nel DOM, anche il sink è nel DOM e il flusso di dati non lascia mai il browser.

Esempio

L'applicazione utilizza dati non attendibili nella costruzione senza convalida. I caratteri speciali dovrebbero essere evitati.

http://www.webpage.org/task/Rule1?query=try

L'autore dell'attacco modifica il parametro della query nel proprio browser in:

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Mani su

Step 1- Accedi a Webgoat e vai alla sezione Cross-site scripting (XSS). Cerchiamo di eseguire un attacco XSS (Stored Cross-Site Scripting). Di seguito l'istantanea dello scenario.

Step 2- Come per lo scenario, accediamo come Tom con la password "tom" come indicato nello scenario stesso. Fare clic su "Visualizza profilo" e accedere alla modalità di modifica. Poiché Tom è l'attaccante, inseriamo lo script Java in quelle caselle di modifica.

<script> 
   alert("HACKED")
</script>

Step 3 - Non appena l'aggiornamento è terminato, Tom riceve una finestra di avviso con il messaggio "hacked" che significa che l'app è vulnerabile.

Step 4 - Ora come per lo scenario, dobbiamo accedere come jerry (HR) e verificare se jerry è interessato dallo script iniettato.

Step 5 - Dopo aver effettuato l'accesso come Jerry, seleziona "Tom" e fai clic su "Visualizza profilo" come mostrato di seguito.

Durante la visualizzazione del profilo di Tom dall'account di Jerry, è in grado di ottenere la stessa finestra di messaggio.

Step 6 - Questa finestra di messaggio è solo un esempio, ma l'attaccante effettivo può eseguire molto di più che visualizzare una finestra di messaggio.

Meccanismi preventivi

• Gli sviluppatori devono assicurarsi di sfuggire a tutti i dati non attendibili in base al contesto HTML come corpo, attributo, JavaScript, CSS o URL in cui vengono inseriti i dati.

• Per quelle applicazioni che richiedono caratteri speciali come input, dovrebbero esserci robusti meccanismi di convalida in atto prima di accettarli come input validi.

È probabile che si verifichi un riferimento diretto a un oggetto quando uno sviluppatore espone un riferimento a un oggetto di implementazione interna, come un file, una directory o una chiave di database senza alcun meccanismo di convalida che consenta agli aggressori di manipolare questi riferimenti per accedere a dati non autorizzati.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

L'app utilizza dati non verificati in una chiamata SQL che accede alle informazioni sull'account.

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

L'autore dell'attacco modifica il parametro della query nel browser in modo che punti all'amministratore.

http://webapp.com/app/accountInfo?acct=admin

Mani su

Step 1- Accedi a Webgoat e vai alla sezione dei difetti di controllo degli accessi. L'obiettivo è recuperare tomcat-users.xml navigando nel percorso in cui si trova. Di seguito l'istantanea dello scenario.

Step 2 - Il percorso del file viene visualizzato nel campo "la directory corrente è" - C: \ Users \ userName $ \. Extract \ webapps \ WebGoat \ lesson_plans \ en e sappiamo anche che il file tomcat-users.xml è conservato sotto C: \ xampp \ tomcat \ conf

Step 3- Dobbiamo attraversare completamente la directory corrente e navigare da C: \ Drive. Possiamo eseguire lo stesso intercettando il traffico utilizzando Burp Suite.

Step 4 - Se il tentativo ha esito positivo, visualizza tomcat-users.xml con il messaggio "Congratulazioni. Hai completato con successo questa lezione."

Meccanismi preventivi

Gli sviluppatori possono utilizzare le seguenti risorse / punti come guida per prevenire riferimenti diretti non sicuri agli oggetti durante la fase di sviluppo stessa.

• Gli sviluppatori devono utilizzare solo un utente o una sessione per i riferimenti a oggetti indiretti.

• Si consiglia inoltre di verificare l'accesso prima di utilizzare un riferimento a un oggetto diretto da una fonte non attendibile.

L'errata configurazione della sicurezza si verifica quando le impostazioni di sicurezza vengono definite, implementate e mantenute come predefinite. Una buona sicurezza richiede una configurazione sicura definita e distribuita per l'applicazione, il server Web, il server database e la piattaforma. È altrettanto importante che il software sia aggiornato.

Esempio

Alcuni esempi classici di configurazione errata della sicurezza sono i seguenti:

• Se l'elenco delle directory non è disabilitato sul server e se l'attaccante scopre lo stesso, l'attaccante può semplicemente elencare le directory per trovare qualsiasi file ed eseguirlo. È anche possibile ottenere la base di codice effettiva che contiene tutto il codice personalizzato e quindi trovare un grave difetto nell'applicazione.

• La configurazione del server app consente di restituire agli utenti tracce dello stack, esponendo potenzialmente i difetti sottostanti. Gli aggressori raccolgono quelle informazioni extra fornite dai messaggi di errore che sono sufficienti per essere penetrate.

• I server delle app di solito vengono forniti con app di esempio che non sono ben protette. Se non viene rimosso dal server di produzione, potrebbe compromettere il tuo server.

Mani su

Step 1- Avvia Webgoat e vai alla sezione di configurazione non sicura e cerchiamo di risolvere questa sfida. Di seguito viene fornita un'istantanea dello stesso:

Step 2- Possiamo provare quante più opzioni possiamo pensare. Tutto ciò di cui abbiamo bisogno per trovare l'URL del file di configurazione e sappiamo che gli sviluppatori seguono un tipo di convenzione di denominazione per i file di configurazione. Può essere qualsiasi cosa elencata di seguito. Di solito è fatto con la tecnica della forza BRUTA.

• web.config
• config
• appname.config
• conf

Step 3 - Dopo aver provato varie opzioni, troviamo che 'http://localhost:8080/WebGoat/conf'ha successo. La pagina seguente viene visualizzata se il tentativo ha esito positivo:

Meccanismi preventivi

• Tutti gli ambienti come sviluppo, controllo qualità e ambienti di produzione devono essere configurati in modo identico utilizzando password diverse utilizzate in ogni ambiente che non possono essere facilmente violate.

• Garantire l'adozione di un'architettura applicativa solida che fornisca una separazione efficace e sicura tra i componenti.

• Può anche ridurre al minimo la possibilità di questo attacco eseguendo scansioni automatizzate ed effettuando periodicamente controlli.

Poiché le applicazioni online continuano a inondare Internet giorno dopo giorno, non tutte le applicazioni sono protette. Molte applicazioni Web non proteggono adeguatamente i dati sensibili degli utenti come le informazioni sulle carte di credito / le informazioni sul conto bancario / le credenziali di autenticazione. Gli hacker potrebbero finire per rubare quei dati scarsamente protetti per condurre frodi con carte di credito, furti di identità o altri crimini.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

Alcuni dei classici esempi di configurazione errata della sicurezza sono i seguenti:

• Un sito semplicemente non utilizza SSL per tutte le pagine autenticate. Ciò consente a un utente malintenzionato di monitorare il traffico di rete e rubare il cookie di sessione dell'utente per dirottare la sessione dell'utente o accedere ai propri dati privati.

• Un'applicazione memorizza i numeri di carta di credito in un formato crittografato in un database. Al momento del recupero vengono decrittografati consentendo all'hacker di eseguire un attacco SQL injection per recuperare tutte le informazioni sensibili in un testo chiaro. Ciò può essere evitato crittografando i numeri di carta di credito utilizzando una chiave pubblica e consentendo alle applicazioni di back-end di decrittografarli con la chiave privata.

Mani su

Step 1- Avvia WebGoat e vai alla sezione "Archiviazione non sicura". L'istantanea dello stesso è visualizzata di seguito.

Step 2- Immettere il nome utente e la password. È ora di imparare diversi tipi di codifica e metodologie di crittografia che abbiamo discusso in precedenza.

Meccanismi preventivi

• Si consiglia di non archiviare dati sensibili inutilmente e di eliminarli il prima possibile se non sono più necessari.

• È importante garantire che incorporiamo algoritmi di crittografia forti e standard e che sia in atto una corretta gestione delle chiavi.

• Può anche essere evitato disabilitando il completamento automatico sui moduli che raccolgono dati sensibili come password e disabilitare la memorizzazione nella cache per le pagine che contengono dati sensibili.

La maggior parte delle applicazioni Web verifica i diritti di accesso a livello di funzione prima di rendere tale funzionalità accessibile all'utente. Tuttavia, se gli stessi controlli di controllo degli accessi non vengono eseguiti sul server, gli hacker sono in grado di penetrare nell'applicazione senza un'adeguata autorizzazione.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

Ecco un classico esempio di controllo dell'accesso a livello di funzione mancante:

L'hacker forza semplicemente gli URL di destinazione. Di solito l'accesso amministratore richiede l'autenticazione, tuttavia, se l'accesso all'applicazione non è verificato, un utente non autenticato può accedere alla pagina di amministrazione.

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

Mani su

Step 1 - Effettuiamo il login come account manager esaminando prima l'elenco degli utenti e i loro privilegi di accesso.

Step 2 - Dopo aver provato varie combinazioni, possiamo scoprire che Larry ha accesso al gestore dell'account delle risorse.

Meccanismi preventivi

• Il meccanismo di autenticazione dovrebbe negare tutti gli accessi per impostazione predefinita e fornire l'accesso a ruoli specifici per ogni funzione.

• In un'applicazione basata sul flusso di lavoro, verificare lo stato degli utenti prima di consentire loro di accedere a qualsiasi risorsa.

Un attacco CSRF costringe un utente autenticato (vittima) a inviare una richiesta HTTP contraffatta, incluso il cookie di sessione della vittima a un'applicazione Web vulnerabile, che consente all'aggressore di forzare il browser della vittima a generare una richiesta in modo che l'app vulnerabile percepisca come la vittima.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

Ecco un classico esempio di CSRF:

Step 1 - Diciamo che l'applicazione vulnerabile invia una richiesta di modifica dello stato come testo normale senza alcuna crittografia.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Ora l'hacker costruisce una richiesta che trasferisce denaro dall'account della vittima all'account dell'aggressore incorporando la richiesta in un'immagine che viene archiviata su vari siti sotto il controllo dell'aggressore -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Mani su

Step 1- Eseguiamo una contraffazione CSRF incorporando uno script Java in un'immagine. L'istantanea del problema è elencata di seguito.

Step 2 - Ora dobbiamo simulare il trasferimento in un'immagine 1x1 e fare in modo che la vittima faccia clic sulla stessa.

Step 3 - Dopo aver inviato il messaggio, il messaggio viene visualizzato come evidenziato di seguito.

Step 4- Ora se la vittima fa clic sul seguente URL, viene eseguito il trasferimento, che può essere trovato intercettando l'azione dell'utente utilizzando la suite burp. Siamo in grado di vedere il trasferimento individuandolo in Ricevi messaggio come mostrato di seguito -

Step 5 - Ora, facendo clic su Aggiorna, viene visualizzato il segno di completamento della lezione.

Meccanismi preventivi

• CSRF può essere evitato creando un token univoco in un campo nascosto che verrebbe inviato nel corpo della richiesta HTTP piuttosto che in un URL, che è più incline all'esposizione.

• Costringere l'utente a autenticarsi nuovamente o dimostrare di essere utenti al fine di proteggere CSRF. Ad esempio, CAPTCHA.

Questo tipo di minaccia si verifica quando i componenti come le librerie e i framework utilizzati all'interno dell'app vengono quasi sempre eseguiti con privilegi completi. Se un componente vulnerabile viene sfruttato, rende più facile il lavoro dell'hacker causare una grave perdita di dati o il controllo del server.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

I seguenti esempi riguardano l'utilizzo di componenti con vulnerabilità note:

• Gli aggressori possono richiamare qualsiasi servizio Web con autorizzazione completa non fornendo un token di identità.

• L'esecuzione di codice in modalità remota con la vulnerabilità di iniezione di Expression Language viene introdotta tramite Spring Framework per le app basate su Java.

Meccanismi preventivi

• Identifica tutti i componenti e le versioni che vengono utilizzate nelle webapp non solo limitate a database / framework.

• Mantieni aggiornati tutti i componenti come database pubblici, mailing list del progetto ecc.

• Aggiungi wrapper di sicurezza attorno ai componenti di natura vulnerabile.

La maggior parte delle applicazioni Web su Internet reindirizza e inoltra frequentemente gli utenti ad altre pagine o altri siti Web esterni. Tuttavia, senza convalidare la credibilità di tali pagine, gli hacker possono reindirizzare le vittime a siti di phishing o malware o utilizzare i forward per accedere a pagine non autorizzate.

Cerchiamo di comprendere agenti di minaccia, vettori di attacco, debolezza della sicurezza, impatto tecnico e impatto sul business di questo difetto con l'aiuto di un semplice diagramma.

Esempio

Alcuni esempi classici di reindirizzamenti e inoltri non convalidati sono quelli forniti:

• Supponiamo che l'applicazione abbia una pagina - redirect.jsp, che accetta un parametro redirectrul . L'hacker aggiunge un URL dannoso che reindirizza gli utenti che eseguono phishing / installa malware.

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

• Tutte le applicazioni Web utilizzate per inoltrare gli utenti a diverse parti del sito. Per ottenere lo stesso risultato, alcune pagine utilizzano un parametro per indicare dove l'utente deve essere reindirizzato se un'operazione ha successo. L'autore dell'attacco crea un URL che supera il controllo di controllo dell'accesso dell'applicazione e quindi inoltra l'autore dell'attacco a funzionalità amministrative per cui l'attaccante non ha accesso.

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

Meccanismi preventivi

• È meglio evitare di utilizzare redirect e forward.

• Se è inevitabile, dovrebbe essere fatto senza coinvolgere i parametri dell'utente nel reindirizzamento della destinazione.

Javascript asincrono e XML (AJAX) è una delle ultime tecniche utilizzate per sviluppare applicazioni web in modo da offrire una ricca esperienza utente. Poiché si tratta di una nuova tecnologia, ci sono molti problemi di sicurezza che devono ancora essere completati stabiliti e di seguito sono riportati i pochi problemi di sicurezza in AJAX.

• La superficie di attacco è maggiore poiché ci sono più input da proteggere.

• Espone anche le funzioni interne delle applicazioni.

• Mancata protezione delle informazioni e delle sessioni di autenticazione.

• C'è una linea molto stretta tra lato client e lato server, quindi ci sono possibilità di commettere errori di sicurezza.

Esempio

Ecco un esempio per AJAX Security:

Nel 2006, un worm ha infettato il servizio di posta yahoo utilizzando XSS e AJAX sfruttando una vulnerabilità nella gestione degli eventi onload di Yahoo Mail. All'apertura di un'e-mail infetta, il worm ha eseguito il proprio JavaScript, inviando una copia a tutti i contatti Yahoo dell'utente infetto.

Mani su

Step 1- Dobbiamo provare ad aggiungere più premi al tuo set di premi consentito utilizzando l'iniezione XML. Di seguito l'istantanea dello scenario.

Step 2- Assicurati di intercettare sia la richiesta che la risposta utilizzando Burp Suite. Impostazioni uguali a quelle mostrate di seguito.

Step 3- Immettere il numero di conto come indicato nello scenario. Saremo in grado di ottenere un elenco di tutti i premi per i quali siamo idonei. Abbiamo diritto a 3 premi su 5.

Step 4- Ora facciamo clic su "Invia" e vediamo cosa otteniamo nell'XML di risposta. Come mostrato di seguito, i tre premi che siamo idonei ci vengono trasmessi come XML.

Step 5 - Ora modifichiamo questi XML e aggiungiamo anche gli altri due premi.

Step 6- Ora tutti i premi verranno visualizzati all'utente affinché possa selezionarli. Seleziona quelli che abbiamo aggiunto e fai clic su "Invia".

Step 7 - Viene visualizzato il seguente messaggio che dice "* Congratulazioni. Hai completato con successo questa lezione."

Meccanismi preventivi

Lato client -

• Usa .innerText invece di .innerHtml.
• Non utilizzare eval.
• Non fare affidamento sulla logica del client per la sicurezza.
• Evita di scrivere codice di serializzazione.
• Evita di creare XML in modo dinamico.
• Non trasmettere mai segreti al cliente.
• Non eseguire la crittografia nel codice lato client.
• Non eseguire la logica che influisce sulla sicurezza sul lato client.

Lato server -

• Usa la protezione CSRF.
• Evita di scrivere codice di serializzazione.
• I servizi possono essere chiamati direttamente dagli utenti.
• Evita di costruire XML a mano, usa il framework.
• Evita di creare JSON a mano, usa un framework esistente.

Nelle moderne applicazioni basate sul Web, l'utilizzo dei servizi Web è inevitabile e sono anche soggetti ad attacchi. Poiché i servizi Web richiedono il recupero da più siti Web, gli sviluppatori devono adottare alcune misure aggiuntive per evitare qualsiasi tipo di penetrazione da parte degli hacker.

Mani su

Step 1- Vai all'area dei servizi web di Webgoat e vai a Scansione WSDL. Dobbiamo ora ottenere i dettagli della carta di credito di un altro numero di conto. L'istantanea dello scenario è come indicato di seguito.

Step 2 - Se selezioniamo il nome, la chiamata alla funzione 'getFirstName' viene effettuata tramite richiesta SOAP xml.

Step 3- Aprendo il WSDL, possiamo vedere che esiste un metodo per recuperare i dati della carta di credito e "getCreditCard". Ora manomettiamo gli input usando la suite Burp come mostrato di seguito -

Step 4 - Ora modifichiamo gli input usando la suite Burp come mostrato di seguito -

Step 5 - Possiamo ottenere le informazioni sulla carta di credito di altri utenti.

Meccanismi preventivi

• Poiché i messaggi SOAP sono basati su XML, tutte le credenziali passate devono essere convertite in formato testo. Quindi bisogna stare molto attenti nel trasmettere le informazioni sensibili che devono essere sempre crittografate.

• Protezione dell'integrità del messaggio implementando meccanismi come il checksum applicato per garantire l'integrità del pacchetto.

• Protezione della riservatezza dei messaggi: la crittografia asimmetrica viene applicata per proteggere le chiavi di sessione simmetriche, che in molte implementazioni sono valide per una sola comunicazione e vengono eliminate successivamente.

Un buffer overflow si verifica quando un programma tenta di memorizzare più dati in un'area di memorizzazione temporanea dei dati (buffer) di quanti ne avrebbe previsto. Poiché i buffer vengono creati per contenere una quantità finita di dati, le informazioni aggiuntive possono traboccare in buffer adiacenti, corrompendo così i dati validi in essi contenuti.

Esempio

Ecco un classico esempio di buffer overflow. Dimostra un semplice overflow del buffer causato dal primo scenario in cui si basa su dati esterni per controllarne il comportamento. Non c'è modo di limitare la quantità di dati che l'utente ha inserito e il comportamento del programma dipende dal numero di caratteri che l'utente ha inserito.

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

Mani su

Step 1- Dobbiamo effettuare il login con nome e numero di camera per ottenere l'accesso a Internet. Ecco l'istantanea dello scenario.

Step 2 - Abiliteremo anche "Scopri i campi modulo nascosti" in Burp Suite come mostrato di seguito -

Step 3- Ora inviamo un input nel campo del nome e del numero della stanza. Cerchiamo anche di inserire un numero abbastanza grande nel campo del numero della stanza.

Step 4- I campi nascosti vengono visualizzati come mostrato di seguito. Facciamo clic su accetta termini.

Step 5 - L'attacco ha successo in modo tale che, a seguito dell'overflow del buffer, ha iniziato a leggere le posizioni di memoria adiacenti e visualizzato all'utente come mostrato di seguito.

Step 6- Ora accediamo utilizzando i dati visualizzati. Dopo la registrazione, viene visualizzato il seguente messaggio:

Meccanismi preventivi

• Revisione del codice
• Formazione per sviluppatori
• Strumenti del compilatore
• Sviluppo di funzioni sicure
• Scansione periodica

L'attacco Denial of Service (DoS) è un tentativo degli hacker di rendere non disponibile una risorsa di rete. Di solito interrompe l'host, temporaneo o indefinito, che è connesso a Internet. Questi attacchi in genere prendono di mira servizi ospitati su server Web mission critical come banche, gateway di pagamento con carta di credito.

Sintomi di DoS

• Prestazioni di rete insolitamente lente.
• Indisponibilità di un particolare sito web.
• Impossibilità di accedere a qualsiasi sito web.
• Drastico aumento del numero di e-mail di spam ricevute.
• Negazione a lungo termine dell'accesso al Web o a qualsiasi servizio Internet.
• Indisponibilità di un particolare sito web.

Mani su

Step 1- Avvia WebGoat e vai alla sezione "Denial of Service". Di seguito viene fornita l'istantanea dello scenario. Dobbiamo accedere più volte lì violando la dimensione massima del pool di thread del DB.

Step 2- Per prima cosa dobbiamo ottenere l'elenco degli accessi validi. In questo caso usiamo SQL Injection.

Step 3 - Se il tentativo ha esito positivo, vengono visualizzate tutte le credenziali valide per l'utente.

Step 4- Ora accedi con ciascuno di questi utenti in almeno 3 sessioni diverse per far sì che l'attacco DoS abbia successo. Come sappiamo che la connessione DB può gestire solo due thread, utilizzando tutti gli accessi creerà tre thread che rendono l'attacco riuscito.

Meccanismi preventivi

• Eseguire convalide di input approfondite.

• Evita operazioni che consumano molta CPU.

• È preferibile separare i dischi dati dai dischi di sistema.

Gli sviluppatori spesso utilizzano o concatenano direttamente input potenzialmente vulnerabili con file o presumono che i file di input siano autentici. Quando i dati non vengono controllati correttamente, il contenuto vulnerabile può essere elaborato o richiamato dal server web.

Esempio

Alcuni degli esempi classici includono:

• Carica il file .jsp nella struttura ad albero web.
• Carica .gif da ridimensionare.
• Carica file enormi.
• Carica il file contenente i tag.
• Carica il file .exe nella struttura ad albero web.

Mani su

Step 1- Avvia WebGoat e vai alla sezione Esecuzione di file dannosi. L'istantanea dello scenario è fornita di seguito:

Step 2 - Per completare questa lezione, dobbiamo caricare guest.txt nella suddetta posizione.

Step 3- Creiamo un file jsp in modo tale che il file guest.txt venga creato durante l'esecuzione del jsp. La denominazione di jsp non ha alcun ruolo da svolgere in questo contesto poiché stiamo eseguendo il contenuto del file jsp.

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4- Ora carica il file jsp e copia il percorso del collegamento dello stesso dopo il caricamento. Il caricamento prevede un'immagine, ma stiamo caricando un file jsp.

Step 5 - Navigando al file jsp, non ci sarà alcun messaggio per l'utente.

Step 6 - Ora aggiorna la sessione in cui hai caricato il file jsp e riceverai il messaggio "* Congratulazioni. Hai completato con successo la lezione".

Meccanismi preventivi

• Proteggi i siti Web utilizzando le autorizzazioni del sito Web.
• Adotta contromisure per la sicurezza delle applicazioni web.
• Comprendere gli account utente e di gruppo incorporati in IIS 7.0.

Sono disponibili vari strumenti per eseguire test di sicurezza di un'applicazione. Esistono pochi strumenti in grado di eseguire test di sicurezza end-to-end, mentre alcuni sono dedicati a individuare un particolare tipo di difetto nel sistema.

Strumenti open source

Alcuni strumenti di test di sicurezza open source sono i seguenti:

S.No.	Nome strumento
1	Zed Attack Proxy Fornisce scanner automatici e altri strumenti per individuare i difetti di sicurezza. https://www.owasp.org
2	OWASP WebScarab Sviluppato in Java per l'analisi delle richieste Http e Https. https://www.owasp.org/index.php
3	OWASP Mantra Supporta framework di test di sicurezza multilingue https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy Strumento per intercettare e modificare il traffico e funziona con certificati SSL personalizzati. https://www.portswigger.net/Burp/
5	Firefox Tamper Data Utilizza i dati di manomissione per visualizzare e modificare le intestazioni HTTP / HTTPS e i parametri dei post https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools L'estensione per sviluppatori Web aggiunge vari strumenti per sviluppatori Web al browser. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor Consente all'utente di aggiungere, eliminare, modificare, cercare, proteggere e bloccare i cookie https://chrome.google.com/webstore

Set di strumenti specifici

I seguenti strumenti possono aiutarci a individuare un particolare tipo di vulnerabilità nel sistema:

S.No.	Link
1	DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/
2	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
3	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
4	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
5	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
6	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
7	THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/
8	Brutus − Brute Force Password http://www.hoobie.net/brutus/
9	Ncat − Brute Force Password https://nmap.org/ncat/
10	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
11	Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz
12	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

Strumenti di test Black Box commerciali

Di seguito sono riportati alcuni degli strumenti di test black box commerciali che ci aiutano a individuare i problemi di sicurezza nelle applicazioni che sviluppiamo.

S.No	Attrezzo
1	NGSSQuirreL https://www.nccgroup.com/en/our-services
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
3	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

Analizzatori di codice sorgente gratuiti

S.No	Attrezzo
1	OWASP Orizon https://www.owasp.org/index.php
2	OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform
3	SearchDiggity https://www.bishopfox.com/resources/tools
4	FXCOP https://www.owasp.org/index.php/FxCop
5	Splint http://splint.org/
6	Boon https://www.cs.berkeley.edu/~daw/boon/
7	W3af http://w3af.org/
8	FlawFinder https://www.dwheeler.com/flawfinder/
9	FindBugs http://findbugs.sourceforge.net/

Analizzatori di codice sorgente commerciale

Questi analizzatori esaminano, rilevano e segnalano i punti deboli del codice sorgente, che sono soggetti a vulnerabilità:

S.No	Attrezzo
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
3	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/