I miei colleghi sostengono che XSS sia una vulnerabilità sul lato server. Ho sempre pensato che questa fosse una vulnerabilità del lato client. Quale di noi ha ragione e perché?
In un attacco di scripting cross-site, lo script dannoso viene eseguito sul client, ma l'errore reale si trova nell'applicazione. Ciò non significa necessariamente che si tratta di una vulnerabilità strettamente lato server, in quanto il difetto potrebbe essere nel codice JavaScript dell'applicazione, ma in generale, si tratta in effetti di codice lato server e sempre nel codice fornito dal server.
Esistono attenuazioni sul lato client, come la protezione XSS ora incorporata nei principali browser, o plug-in che impediscono l'esecuzione di JavaScript, ma in definitiva XSS è una vulnerabilità di applicazione Web e deve essere risolta dall'applicazione sviluppatori.
Dovrei menzionare che esiste un'altra forma di XSS che non sfrutta né difetti nel client (il browser) né difetti nel server (l'applicazione) ma difetti nell'utente. Questo è spesso chiamato Self-XSS, e sfrutta la volontà di un utente incapace di eseguire JavaScript che ha copiato e incollato da Internet e nella console degli strumenti di sviluppo del suo browser, esclusivamente sulla base della promessa che contro ogni speranza, permetterà magicamente a leggere i post di Facebook della sua ex-fidanzata nonostante il fatto che lei non sia d'accordo e lo abbia bloccato.
Si manifesta sul lato client, ma è perché è consentito farlo dall'applicazione web. L'applicazione non convalida il codice che invia di nuovo al browser. E questo è il motivo per cui si tratta di una vulnerabilità lato server. Pensaci in questo modo. Cosa faresti per risolvere il problema dell'XSS? Risolvi il codice lato server o correggi il browser?
Cross-site Scripting (XSS) possono essere generalmente classificati come:
L'attacco stesso sta avvenendo sul client. Tutti e tre i tipi di attacco potrebbero manifestarsi completamente nel browser stesso nel caso di una singola pagina o di un'applicazione offline. Tuttavia, se i dati sono memorizzati sul server o riflessi dal server, il server assiste la vulnerabilità.
IE8 ha introdotto X -XSS-Protection , che ha reso gli attacchi riflessi più difficili da sfruttare.
La terminologia è un po 'sdrucciolevole, ma in genere un "bug XSS" è un exploit lato client di una vulnerabilità lato server .
Lo scripting cross-site non è, di per sé, un problema di sicurezza . Il problema è che può accadere senza la conoscenza dell'utente finale. La maggior parte dei siti non è codificata perché ciò avvenga, naturalmente: o non usano affatto lo scripting cross-site, o chiariscono che questo è ciò che stanno facendo. Ma se gli utenti possono pubblicare i propri contenuti, è necessario impedire loro di aggiungere tag script arbitrari alle pagine . In caso contrario, potrebbero inserire elementi nella pagina che invia i dati a chi sa dove.
Per evitare ciò, devi analizzare il contenuto creato dall'utente e generare un HTML "pulito" per la visualizzazione che non ha i tag che non vuoi (come i tag di script). Alcuni siti utilizzano questa opportunità per consentire agli utenti di creare il proprio contenuto in una lingua diversa da HTML: Stack Exchange utilizza Markdown. Ma finché analizzi il contenuto correttamente , puoi usare anche l'HTML come lingua di input. Non c'è alcun vantaggio in termini di prestazioni se eseguito correttamente da HTML a HTML, poiché passa attraverso lo stesso tipo di analisi / ciclo di generazione che gli altri linguaggi avrebbero, ma è una lingua in meno per gli sviluppatori (e forse gli utenti) da apprendere. Tuttavia, devi resistere alla tentazione di riutilizzare il contenuto HTML così com'è, o di eseguire alcune sostituzioni di stringhe leggere invece di un ciclo di analisi / generazione.
Un "bug XSS" è ciò che accade quando le persone capiscono come postare codice HTML arbitrario nel sito . Solitamente ciò accade quando gli sviluppatori utilizzano direttamente l'input HTML senza passare attraverso il ciclo parse / generate, ma a volte qualcuno trova un modo per ingannare il generatore del sito e fornire loro HTML che non è stato progettato per fornire. In entrambi i casi, il risultato finale è lo stesso: una volta che un utente può inviare un codice HTML arbitrario, può eseguire lo scripting cross-site con esso, ed è per questo che lo chiamiamo un bug XSS. Ma il bug non si trova nell'XSS stesso: è nel codice lato server che consente di pubblicare script arbitrari in primo luogo.
In genere è consigliabile filtrare il maggior numero possibile di cose sul lato server e non sulla dimensione del client per i seguenti motivi:
Un attacco XSS non è molto diverso da un'iniezione SQL. Entrambi sono causati dal mancato controllo dell'inserimento dell'utente in modo corretto. Gli attacchi XSS sono generalmente memorizzati nel tuo database e distribuiti attraverso il tuo sistema ai tuoi clienti.
Il filtro sugli attacchi XSS dovrebbe essere eseguito sull'input dell'utente, in genere non dovresti accettare alcun tipo di input Javascript. Se si richiede assolutamente che i propri client possano inserire Javascript, nel caso ad esempio di siti di programmazione, si dovrebbe prima scappare.
Spero che sia stato di aiuto. Raccomando questa lettura per ulteriori informazioni: link
Ho letto alcune persone che si preoccupano di non utilizzare l'url o qualsiasi altra cosa per caricare informazioni utente diverse o altro (come ad esempio qui nel tutorial di google - link )
Anche se è bello essere consapevoli di questo, devi ricordare che ogni singola funzione e parte di codice sul lato client possono essere eseguite arbitrariamente. La convalida e la protezione per XSS provengono dal server. Voglio dire, pensaci, puoi aprire la console stessa.
L'idea è l'iniezione di codice dannoso dal client che finisce per essere una vulnerabilità sul server. Ciò potrebbe causare agli altri client la ricezione di pagine Web con script scadenti incorporati in esse. Pensa a un forum: se hai appena salvato e visualizzato tag in quel post, qualcuno potrebbe farti eseguire codice arbitrario per chiunque veda quel post del forum.
Ad esempio, se stackoverflow non è stato scappato correttamente, probabilmente verrai reindirizzato su google.com w / sotto
window.location.href = ' link ' (Immagina di essere circondato da tag di script, SE li formatta e troppo pigri per sfuggirli)
È una vulnerabilità sul lato server che può essere sfruttata tramite applicazioni client.
"Fondamentalmente un utente malintenzionato, creando un'e-mail appositamente formattata, può incorporare JavaScript al suo interno in modo che lo script venga eseguito nel browser della vittima quando l'e-mail viene visualizzata su Yahoo Mail", ha detto Pynnonen in una e-mail a Threatpost. "L'aggressore non ha avuto bisogno di un accesso speciale. In realtà l'attacco può essere effettuato senza nemmeno registrarsi su Yahoo Mail. È necessario solo l'indirizzo email Yahoo della vittima. "
In una descrizione della vulnerabilità pubblicata giovedì, Pynnonen ha spiegato come potrebbe formattare un'e-mail con dati dannosi- * attributi che introdurranno JavaScript malevolo oltre i filtri di Yahoo che eseguono abusando del modo in cui Yahoo Mail visualizza i collegamenti ai siti autorizzati come YouTube . [enter preformatted text here][1]
Contrariamente a quanto molti altri credono, xss è sia lato client che lato server.
Un xss persistente è lato server mentre il server memorizza il codice da eseguire nel client. Quando non è persistente, è considerato lato client, in quanto il client può ottenere il risultato solo attraverso tale input
Ha senso?
Leggi altre domande sui tag web-application xss