Attacco attraverso l’inserimento di codici malevoli
Questo tipo di attacco Cross-Site Scripting (XSS) consiste nell’inserimento di codici malevoli, nella maggior parte dei casi tag HTML, facendo in modo di accedere a dati sensibili e nei casi più gravi rubare i dati di sessioni dell’utente, compromettere browser e sistemi opretivi. Tutto questo sembra ancora non bastare per molti sviluppatori che con semplice superbia pensano di essere invincibili.
Possiamo quindi dire, che il Cross-Site Scripting, come il SQL Injection, appartengono alla categoria delle code Injection, con l’unica differenza che se le SQL Injection operavano solo su contenuti dinamici, mentre il Cross-Site Scripting opera su contenuti dinamici e statici.
In sintesi il Cross-Site Scripting (XSS) agisce solamente lato client iniettando codice malevolo dal browser.
Mentre SQL Injection agisce lato server con lo scopo di prenderne possesso.
Questo tipo di attacco costituisce, ad oggi, una delle più importanti minacce per quanto riguarda lo sviluppo Web o il "Cattivo sviluppo Web" purtroppo non tutti ne capiscono ancora il reale pericolo, ci sono però molti articoli in materia è sopratutto grazie al progetto OWASP Secure Headers Project Potremo capire meglio come previnire questi tipi di attacchi inserendo via .htaccess determinati comandi:
HTTP Strict Transport Security (HSTS)
Public Key Pinning Extension for HTTP (HPKP)
X-Frame-Options
X-XSS-Protection
X-Content-Type-Options
Content-Security-Policy
X-Permitted-Cross-Domain-Policies
Referrer-Policy
Expect-CT
Feature-Policy
Come questo esempio (Ovvimante va approffondito comando per comando):
Header unset X-Powered-By
Header set Content-Security-Policy "connect-src 'self';"
Header always set Referrer-Policy "same-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Feature-Policy "microphone 'none'; payment 'none'; sync-xhr 'self' https://iltuosito.it"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
Header always set X-Permitted-Cross-Domain-Policies: "master-only"
Tecniche di Cross-Site Scripting:
- Non Persistent/ Reflected XSS
- Persistent/Stored XSS
- DOM-based
Non Persistent/ Reflected XSS
=============================================================
Gli attacchi non persistenti devono il loro nome al fatto che il codice malevolo iniettato non è permanente nel sito web e le vittime sono soltanto quelle persone che accedono alla pagina compromessa, cliccando su un link realizzato ad hoc.
Prima di tutto l’attaccante dovrà vedere se il sito scelto è realmente vulnerabile e per fare ciò, molto spesso, si servirà della finestra di ricerca, che è presente nella maggior parte di siti web ed è anche la vulnerabilità più ricorrente.
Persistent/Stored XSS
=============================================================
Gli attacchi XSS persistenti, anche conosciuti come Stored XSS o HTML Injection, al contrario degli attacchi XSS non persistenti, iniettano il codice malevolo permanentemente e non richiedono nessun link di riferimento.
La maggior parte degli attacchi avvengono nei siti web che contengono forum, blog, wiki, guest book e così via. Non appena l’utente accede a queste aree danneggiate, il codice viene eseguito in maniera automatica. Questo rende gli Stored XSS molto più dannosi rispetto a quelli non persistenti o DOM Based, perché la vittima non ha alcun modo di difendersi.
DOM-based
=============================================================
Il Cross-Site Scripting, chiamata DOM-based o XSS locale, che differisce completamente dalle due precedenti, in quanto non richiede l’invio del malware dal server, ma è trasferito ed eseguito direttamente sul browser del client.
Ma come viene eseguito il JavaScript dell’attaccante?
Tutto inizia quando l’utente richiede l’URL che è stato infettato con il codice JavaScript dell’attaccante. Nella risposta del server ancora non viene eseguito il malware ma questo avviene quando è il browser a processare la richiesta con la conseguente esecuzione dello script.
Il JavaScript del client può accedere al document object model (DOM) e quindi può determinare l’url usato per caricare questa certa pagina. Un determinato script, scritto ad hoc, può estrarre quindi dei dati contenuti nell’URL, eseguire alcune elaborazioni di dati e successivamente utilizzarle per aggiornare dinamicamente il contenuto della pagina.
Quando un applicazione web è soggetta a questi comportamenti, molto probabilmente è soggetta ad attacchi XSS di tipo DOM-based.
