Cyber Security per Applicazioni Web

Roberto Abbate

• Publisher: Società Editrice Esculapio
• Year: 2019
• Print ISBN: 9788893851671
• eBook ISBN: 9788835339267
• Topic: Informatica
• Subtopic: Sicurezza informatica

Cyber Security per Applicazioni Web è un libro di Sicurezza applicativa dedicato a proteggere lo strato di frontend e il layer di integrazione con API REST. Il testo presenta un approccio fortemente ingegneristico: quali sono le pieghe nascoste nell'architettura del Web? Quali sono le vulnerabilità che consentono ad un malintenzionato di eseguire un attacco? Come è possibile mitigare questi rischi? Il libro riesce ad astrarre la struttura e la metodologia di un'aggressione informatica, presentando una piattaforma concettuale che contestualizzi le singole tecniche in moderni modelli di attacco.

1

Security by Design

Non è più possibile progettare architetture moderne e affidabili senza considerare, fin dal principio, la Cyber Security. Progettare soluzioni informatiche con questa priorità, permette di avere la sicurezza come fattore abilitante invece che come ostacolo evolutivo. La sicurezza ha un costo, computazionale ed economico, che è meglio affrontare fin dall'inizio così da trasformarlo in investimento ed evitare che diventi debito tecnico.

La Cyber Security pensata e applicata ex post, comporta un dispendio maggiore che altro non è se non gli interessi del debito tecnico. Il rincorrersi di patch e work around faranno percepire la sicurezza come ciò che in realtà non è: un impedimento.

Per perseguire questo paradigma, ci si affida alla Security by Design.

Security by Design, conosciuto anche come Secure by Design o by Default, è un approccio alla progettazione di componenti informatiche, software e/o hardware, che considera la sicurezza come parte fondamentale e presente fin dall’inizio dello sviluppo.

1.1 PRINCIPI DELLA SECURITY BY DESIGN

I tre pilastri su cui si basa la Cyber Security sono:

• Confidenzialità: è possibile ottenere solo le informazioni per le quali si ha diritto.
• Integrità: le informazioni possono essere modificate solo da chi ha l'autorizzazione a farlo.
• Disponibilità: le informazioni sono raggiungibili quando occorrono.

Per riuscire a perseguire questi fondamenti, sono stati sviluppati dei principi che garantiscono, dalle basi, la sicurezza informatica. Ne esistono molti ma ci concentreremo su dieci paradigmi che ritengo indispensabili per la progettazione di applicazioni Web Secure by Design.

1.1.1 Least Privilege

Ogni utenza, applicativa o persona che sia, deve avere il diritto di operare esclusivamente su ciò che le necessita. Privilegi più ampi possono comportare rischi per la disponibilità della soluzione o consentire un accesso non autorizzato ad informazioni riservate, violandone la confidenzialità.

Un'applicazione che ha più privilegi di quanti gliene occorrano, in caso di difetti, potrebbe superare il limite di richieste tollerato dal sistema, mandare in crisi la CPU o la RAM, superare i limiti di banda della rete, far emergere informazioni riservate o ancora sovrascrivere o cancellare file necessari al corretto funzionamento del sistema.

E le stesse considerazioni possono valere per una persona.

1.1.2 Evitare la Security by Obscurity

La Security by Obscurity è un anti-pattern in cui si persegue la sicurezza di una soluzione basandosi sul fatto che nessuno sia a conoscenza delle debolezze intrinseche che la caratterizzano.

Sarebbe come nascondere le chiavi di casa sotto lo zerbino davanti alla porta. Per un'applicazione Web, potrebbe rappresentare la realizzazione di un back office di gestione dell'applicazione stessa, raggiungibile da un URL non adeguatamente protetto. Tanto nessuno sa che all'indirizzo:

https://www.sito.it/back-office

Si possa avere accesso immediato ad un pannello di controllo.

Questo, per lo meno, non deve essere l'unico principio su cui fare affidamento. Può essere quindi considerato corretto tenere nascosto l'URL del proprio pannello di amministrazione, ma ciò deve essere affiancato da un appropriato sistema di autenticazione.

1.1.3 Adopt Industry-Supported Standards

È importante citare questo principio, collegato al precedente. Conosciuto con nomi che possono essere diversi quali Do Not Invent Security o Never Invent Security Technology et similia.

Ricordiamo che la Cyber Security è un argomento più complesso che complicato. Per questo esistono professionisti altamente specializzati che collaborano per offrire soluzioni che diventano standard internazionali.

Per tradurre questi concetti, non sognatevi di realizzare sistemi di Single Sign On personali convincendovi che siano più efficaci, non realizzate vostre librerie di crittografia e in generale, non pensate che le soluzioni che potreste progettare internamente siano più sicure solo perché nessuno all'esterno della vostra realtà ne conosce le vulnerabilità. Rischiereste anche di perseguire l'anti-pattern della Security by Obscurity.

1.1.4 Fail Securely

In caso di eccezioni o errori, la soluzione potrebbe non essere più in grado di garantire la disponibilità delle informazioni. In questo caso, è indispensabile assicurare, sempre e comunque, la confidenzialità e l'integrità dei dati.

Per fare un esempio, se la nostra applicazione Web facesse riferimento ad un servizio di autorizzazione esterno per conoscere il ruolo, il profilo e/o il perimetro dei privilegi di un'utenza, applicativa o personale, in caso di mancata risposta del servizio, non deve essere garantito l'accesso alla soluzione.

1.1.5 Secure Defaults

La soluzione deve essere progettata per essere in grado, di principio, di garantire la sicurezza del sistema e degli utenti che vi accedono.

Questo paradigma si declina, per citare alcuni casi esemplificativi e non esaustivi, in aree riservate che richiedano password con scadenze preimpostate e un livello minimo di complicatezza. Se le credenziali di accesso fosse indispensabile preassegnarle, queste dovranno essere modificate durante l'installazione della soluzione o se ciò non fosse possibile, al primo accesso. Ed eventualmente, dove necessario, fornire un secondo fattore di autenticazione.

1.1.6 Separation of Duties

Con Separation of Duties (o Segregation of Duties), si intende la necessità che per alcuni processi operativi sia previsto l'intervento di più di una persona per il corretto completamento dell'operazione.

Un esempio pratico dell'applicazione di questo paradigma è il Principio dei Four Eyes (o quattr'occhi), dove alla richiesta di esecuzione di un'operazione da parte di un'utenza del sistema informativo, risulta necessario l'intervento di un'altra persona che la autorizzi. Può essere utile per limitare non solo i tentativi di frode, ma anche per intercettare errori o dimenticanze.

Questo principio può essere applicato sia all'utente finale che agli sviluppatori software, come l'approvazione di una Pull Request su un repository GIT.

1.1.7 Reduce Your Attack Surface

Con Attack Surface si intende l'insieme delle risorse esposte e raggiungibili da un'aggressione. Per il perimetro di studio del presente libro, all'interno del frontend di un'applicazione Web, ciò può essere rappresentato dai campi in cui un utente può immettere o modificare informazioni che verranno poi elaborate dal backend e che possono essere fonti di Code Injection, oppure le API che lo stesso frontend è in grado di raggiungere direttamente su Internet.

Tutto questo si traduce in soluzioni che riducano i punti in cui un utente possa interagire, direttamente o indirettamente, con il backend. Oppure a livello architetturale, in una infrastruttura che divida le proprie reti a seconda dell'importanza dei dati contenuti, utilizzando firewall che impongano esplicita e preventiva autorizzazione per essere attraversati.

1.1.8 Defense in Depth

L'applicazione Web deve essere irrobustita e securizzata in ognuno dei layer che la compongono. Non è sufficiente provvedere ad un unico strumento di difesa perché in caso di exploit su questo singolo componente, l'intero sistema sarebbe vulnerabile.

Non è sufficiente quindi installare un Firewall (o un Web Application Firewall, come vedremo nel proseguo) davanti alla nostra applicazione per ritenersi al sicuro. Così come non basta installare un certificato HTTPS per essere certi di blindare il canale di comunicazione.

1.1.9 Reduce Complexity

Conosciuto anche come Keep it Simple o Simplest Solution Possible. In altre parole, la complessità non aiuta la comprensione e ciò ne mina la sicurezza. È indispensabile rimuovere le caratteristiche ridondanti o non utilizzate, snellire l'architettura e semplificare i processi.

Per la fase di login ad un'area riservata, piuttosto che aumentare la complessità di una password non si potrebbe prevedere di implementare un secondo fattore di autenticazione?

1.1.10 Audit Sensitive Events

Ogni azione che viene eseguita sul Sistema Informativo da un'utenza, applicativa o personale, deve essere tracciata e rintracciabile su un sistema di log, meglio se firmato digitalmente così da garantirne l'integrità.

2

HTTP

HTTP è il protocollo su cui si basa l'architettura del World Wide Web. Specifica come devono essere effettuate le comunicazioni tra client e server e si colloca ad un livello di astrazione superiore rispetto al TCP che invece si occupa del trasporto delle informazioni.

Nel tempo i client si sono evoluti: dai browser dei Computer Desktop passando per i piccoli reader WML dei primi telefonini connessi alla Rete fino ai navigatori degli smartphone moderni. Anche le app che si collegano a Internet, comunicano con i propri server di riferimento utilizzando il protocollo HTTP.

2.1 NASCITA ED ESIGENZA

L'idea di HTTP si inserisce in un contesto più datato. Sul finire degli anni 80 Internet già esisteva ma era molto diversa rispetto a come siamo abituati a viverla oggi. Lo scambio di informazioni era per lo più concentrato sulla trasmissione e sulla ricezione di documenti. Le email e il protocollo FTP la facevano da padroni.

Le email erano in formato plain/text senza collegamenti o altre formattazioni. FTP invece, per quanto goda tutt'ora di buona salute, permette solo lo scambio di file, tutto qui. Come è possibile immaginare, il concetto di divulgazione delle informazioni non era così immediato, era un po' come muoversi all'interno del File System di un qualunque PC, solo molto più lento.

2.1.1 L’ipertesto

È in questo contesto che si inserisce l'idea geniale di Tim Berners-Lee: l'ipertesto. Nasce tutto da qui. Mentre leggo un documento, potrei avere la necessità di approfondire i concetti dietro a una parola: così l'autore del documento crea un collegamento ipertestua...

Table of contents

• Title Page
• Indice
• Prefazione
• Introduzione
• PREREQUISITI
• LA SICUREZZA ADESSO
• COS UNAPPLICAZIONE WEB
• 1 - Security by Design
• 2 - HTTP
• 2.2 FUNZIONAMENTO
• 2.3 LA REQUEST
• 2.4 HEADER HTTP
• 2.5 LA RESPONSE
• 2.6 HTTPS
• 2.7 ALTRI HEADER HTTP DI SICUREZZA
• 2.8 HTTP 2
• 2.9 API REST
• 3 - Same Origin Policy
• 3.1 DOVE NON INTERVIENE LA SOP
• 3.3 CORS: CROSS ORIGIN RESOURCE SHARING
• 3.4 CHIAMATE SU DOMINI DI TERZO LIVELLO DIFFERENTI
• 3.6 JSON
• 3.7 PROXY ABUSE
• 3.8 XSHM: CROSS SITE HISTORY MANIPULATION
• 4 - Cookie e Cookieless
• 4.2 COOKIE DI SESSIONE E PERMANENTI
• 4.3 TECNICHE COOKIELESS E PRIVACY
• 4.4 SESSIONI STATELESS
• 4.5 ABITUDINI DELLUTENTE E MACHINE LEARNING
• 5 - Session Riding: CSRF e altri
• 5.2 COSA PU OTTENERE LATTACCANTE
• 5.3 XS-LEAKS
• 5.4 XSSI: CROSS SITE SCRIPTING INCLUSION
• 5.5 ESISTE UNA PROTEZIONE GLOBALE?
• 6 - Cross Site Scripting
• 6.2 XSS REFLECTED
• 6.3 XSS STORED
• 6.4 DIFFERENZE TRA XSS REFLECTED E XSS STORED
• 6.5 ATTACCHI E MITIGAZIONI
• 6.6 UTILIZZO DEGLI INPUT DELLUTENTENEL SORGENTE APPLICATIVO
• 6.7 SANITIZZAZIONI PI PERMISSIVE
• 6.8 SANITIZZAZIONI DEBOLI
• 6.9 APPROCCIO ARCHITETTURALEAL CROSS SITE SCRIPTING
• 6.10 CONTENT-SECURITY-POLICY
• 6.11 CONSIDERAZIONI FINALI SULLA SICUREZZA ANTI-XSS
• 7 - Altri Code Injection
• 7.2 PROTOTYPE POLLUTION
• 7.3 HTML INJECTION
• 7.4 CSS INJECTION
• 8 - Attacchi diversi
• 8.2 SRI: SUBRESOURCE INTEGRITY
• 8.3 ATTACCO DOS CON HTML 5
• 8.4 ROBOTS.TXT
• 8.5 DIRECTORY BROWSING
• 8.6 REFERRAL SPAM
• 9 - Login
• 9.1 LE LOGIN CON USERNAME E PASSWORD SONO FALLIMENTARI
• 9.2 IL BRUTE FORCE
• 9.3 IL SECONDO FATTORE DI AUTENTICAZIONE
• 9.4 PHISHING
• 9.5 WEB AUTHENTICATION (FIDO 2)
• 9.6 UNA LOGIN PI SICURA
• 10 - Sicurezza delle API
• 10.2 OAUTH 2
• 10.3 JSON WEB TOKEN
• 10.4 INSICUREZZA DELLE API
• Back Cover