Cos'è l'attacco xss. Attacchi XSS: cosa sono e perché sono pericolosi. Attacca con XSS persistente

Utilizzando XSS, gli aggressori esperti integrano gli script in esecuzione su di essi nelle pagine dei siti delle vittime, che vengono eseguiti al momento della visita delle risorse infette. Esistono diversi tipi di vulnerabilità XSS, che rappresentano vari gradi di gravità.

Caratteristiche della vulnerabilità passiva e attiva

Dovresti stare molto attento con le vulnerabilità attive. Quando un utente malintenzionato inserisce il suo codice SQL in un database accessibile o in un file su un server, ogni visitatore della risorsa infetta può diventare una vittima. Tali luoghi sono spesso integrati, quindi anche i dati archiviati nel database elaborati dalla tua protezione possono comunque rappresentare un certo pericolo.

La creazione di una vulnerabilità XSS passiva richiede un po' di ingegno da parte dell'attaccante. O sei attratto da una risorsa falsa con tutti i tipi di link, oppure cercano di reindirizzarti al sito richiesto con qualsiasi mezzo. Questo di solito avviene tramite lettere dell'amministrazione fittizia della pagina che stai visitando, con richieste di verificare le impostazioni del tuo account. Viene utilizzata attivamente anche una varietà di mailing di spam o post su forum ampiamente visitati.

La vulnerabilità XSS passiva può provenire da entrambi i parametri POST e GET. I primi sono caratterizzati da una serie di trucchi diversi, mentre i secondi codificano la stringa url o inseriscono valori aggiuntivi.

Rubare i biscotti

Molto spesso, sono i tuoi cookie il bersaglio di un attacco XSS. A volte contengono informazioni preziose, inclusi accessi e password degli utenti o il loro hash. Ma anche rubare sessioni attive di siti importanti per te è piuttosto pericoloso, quindi non dimenticare di fare clic sul pulsante "esci" anche quando visiti i siti dal tuo computer di casa. Sebbene la maggior parte delle risorse per prevenire tali azioni utilizzi un limite di durata della sessione automatico. Le restrizioni di dominio di XMLHttpRequest non salvano da tali attacchi.

Dati da moduli compilabili

Anche la lettura delle informazioni nei moduli compilabili è popolare. Per fare ciò, gli eventi vengono monitorati sulle pagine di interesse (onsubmit) e tutti i dati forniti vengono inviati anche ai server degli aggressori. Tali attacchi sono per molti versi simili agli attacchi di phishing, ma il furto non avviene su un falso, ma su un sito reale con una buona reputazione.

Attacchi DDoS distribuiti

Le risorse multivisite vengono utilizzate anche per gli attacchi XSS. Grazie alla vulnerabilità XSS, le richieste in arrivo vengono reindirizzate al server violato, a causa del quale la sua protezione non resiste.

Richieste false tra siti (CSRF/XSRF)

Hanno anche poco a che fare con XSS. Questo è un tipo separato di vulnerabilità utilizzato insieme a XSS. Il loro obiettivo è attirare un utente autorizzato da un sito invulnerabile a una pagina vulnerabile fittizia per operazioni fraudolente. Ad esempio, un cliente che utilizza un sistema di pagamento elettronico viene attirato su un sito vulnerabile che trasferisce denaro sui conti di intrusi. Pertanto, la maggior parte dei sistemi di pagamento fornisce protezione inserendo in aggiunta una password o un codice di conferma dell'operazione.

Iniezione di worm XSS

Un tale attacco XSS al sito è apparso con lo sviluppo di noti social network (Vkontakte, Twitter e altri). Attraverso di loro, interi gruppi di utenti ricevono collegamenti XSS vulnerabili con script integrati che inviano spam sulle reti per loro conto. È anche ampiamente praticato copiare informazioni personali e foto sulle risorse degli intrusi lungo il percorso.

Esempi di XSS innocui

Si noti che molti tipi di contatori agiscono anche come XSS attivi. Da loro vengono trasmessi dati sui visitatori registrati (i loro indirizzi IP, dati sulle apparecchiature utilizzate).

Solo questo codice è integrato nel tuo computer a tuo piacimento. Altri XSS simili possono essere tranquillamente attribuiti a una serie di richieste AJAX tra domini.

Sappiamo tutti cos'è il cross-site scripting, giusto? Si tratta di una vulnerabilità in cui un utente malintenzionato invia dati dannosi (in genere HTML contenente codice Javascript) che vengono successivamente restituiti dall'applicazione, causando l'esecuzione del codice Javascript. Quindi, questo non è vero! C'è un tipo di attacco XSS che non si adatta a questa definizione, almeno nei fondamenti di base. Gli attacchi XSS, come definiti sopra, si dividono in istantanei (i dati dannosi vengono incorporati in una pagina che viene restituita al browser subito dopo la richiesta) e ritardati (i dati dannosi vengono restituiti dopo un po' di tempo). Ma esiste un terzo tipo di attacco XSS che non si basa sull'invio di dati dannosi al server. Sebbene sembri controintuitivo, ci sono due esempi ben documentati di un simile attacco. Questo articolo descrive il terzo tipo di attacchi XSS: da XSS a DOM (DOM Based XSS). Qui non verrà scritto nulla di fondamentalmente nuovo sull'attacco, quanto piuttosto l'innovazione di questo materiale nell'evidenziare i tratti distintivi dell'attacco, che sono molto importanti e interessanti.

Gli sviluppatori e gli utenti di applicazioni applicative dovrebbero comprendere i principi dell'attacco XSS tramite il DOM, poiché rappresenta una minaccia per le applicazioni Web ed è diverso dal normale XSS. Esistono molte applicazioni web su Internet che sono vulnerabili a XSS tramite il DOM e allo stesso tempo testate per XSS e risultate “immuni” a questo tipo di attacco. Gli sviluppatori e gli amministratori del sito dovrebbero acquisire familiarità con i metodi per rilevare e proteggere da XSS tramite il DOM, poiché queste tecniche differiscono da quelle utilizzate quando si tratta di vulnerabilità XSS standard.

introduzione

Il lettore dovrebbe avere familiarità con i principi di base degli attacchi XSS (, , , , ). XSS di solito si riferisce allo scripting cross-site istantaneo () e ritardato. Con Instant XSS, il codice dannoso (Javascript) viene restituito immediatamente dal server attaccato come risposta a una richiesta HTTP. XSS ritardato significa che il codice dannoso è archiviato nel sistema attaccato e può essere successivamente incorporato nella pagina HTML del sistema vulnerabile. Come accennato in precedenza, questa classificazione presuppone che una proprietà fondamentale di XSS sia che il codice dannoso venga inviato dal browser al server e restituito allo stesso browser (XSS immediato) oa qualsiasi altro browser (XSS ritardato). Questo articolo solleva il problema che si tratta di una classificazione errata. La possibilità di un attacco XSS che non si basa sull'iniezione di codice nella pagina restituita dal server avrebbe un impatto importante sui metodi di protezione e rilevamento. I principi di tali attacchi sono discussi in questo articolo.

Esempio e commenti

Prima di descrivere lo scenario di attacco più semplice, è importante sottolineare che i metodi qui descritti sono già stati ripetutamente dimostrati pubblicamente (ad esempio, , e ). Non pretendo che i metodi seguenti siano descritti per la prima volta (sebbene alcuni di essi differiscano dai materiali pubblicati in precedenza).

Un'indicazione di un sito vulnerabile è la presenza di una pagina HTML che utilizza i dati da document.location, document.URL o document.referrer (o qualsiasi altro oggetto che un utente malintenzionato può influenzare) in modo non sicuro.

Nota per i lettori che non hanno familiarità con questi oggetti Javascript: quando il codice Javascript viene eseguito in un browser, accede a diversi oggetti rappresentati all'interno del DOM (Document Object Model). L'oggetto documento è il più importante di questi oggetti e fornisce l'accesso alla maggior parte delle proprietà della pagina. Questo oggetto contiene molti oggetti nidificati come posizione, URL e referrer. Sono gestiti dal browser in base al punto di vista del browser (questo è abbastanza significativo, come si vedrà in seguito). Quindi document.URL e document.location contengono l'URL della pagina, o meglio cosa intende il browser per URL. Nota che questi oggetti non sono presi dal corpo della pagina HTML. L'oggetto documento contiene un oggetto corpo contenente il codice HTML analizzato per la pagina.

Non è difficile trovare una pagina HTML contenente codice Javascript che analizzi una stringa URL (avendovi accesso tramite document.URL o document.location) ed esegue alcune azioni lato client in base al suo valore. Di seguito è riportato un esempio di tale codice.

Per analogia con l'esempio in c, considera la seguente pagina HTML (supponi che questo sia il contenuto http://www.vulnerable.site/welcome.html):

Ben arrivato! Ciao
Benvenuto nel nostro sistema...

Tuttavia, una query come questa -

http://www.vulnerable.site/welcome.html?name=

chiamerebbe XSS. Vediamo perché: il browser della vittima, che ha ricevuto questo link, invia una richiesta HTTP a www.vulnerable.site e riceve la pagina HTML sopra (statica!). Il browser della vittima inizia ad analizzare questo codice HTML. Il DOM contiene un oggetto documento che ha un campo URL e questo campo viene popolato con l'URL della pagina corrente durante la creazione del DOM. Quando il parser raggiunge il codice Javascript, lo esegue, modificando il codice HTML della pagina sottoposta a rendering. In questo caso, il codice fa riferimento a document.URL, e poiché parte di questa stringa è incorporata nell'HTML durante l'analisi, che viene immediatamente analizzata, il codice rilevato (alert(…)) viene eseguito nel contesto della stessa pagina.

Appunti:

1. Il codice dannoso non è incorporato nella pagina HTML (a differenza di altre forme di XSS).
2. Questo exploit funzionerà purché il browser non modifichi i caratteri URL. Mozilla codifica automaticamente il '<’ и ‘>' (rispettivamente in %3C e %3E) nel documento nidificato. Se l'URL è stato digitato direttamente nella barra degli indirizzi, il browser è immune all'attacco descritto in questo esempio. Tuttavia, se l'attacco non richiede il<’ и ‘>' (nella sua forma originale non codificata) l'attacco può essere effettuato. Microsoft Internet Explorer 6.0 non codifica<’ и ‘>' ed è quindi vulnerabile all'attacco descritto senza alcuna restrizione. Tuttavia, ci sono molti diversi scenari di attacco che non richiedono "<’ и ‘>', e quindi anche Mozilla non è immune da questo attacco.

Metodi per rilevare e prevenire vulnerabilità di questo tipo

Nell'esempio sopra, il codice dannoso viene comunque passato al server (come parte della richiesta HTTP), quindi l'attacco può essere rilevato come qualsiasi altro attacco XSS. Ma questo è un problema risolvibile.

Considera il seguente esempio:

http://www.vulnerable.site/welcome.html#name=

Una politica di sicurezza più rigorosa richiederebbe l'invio del parametro name. In questo caso, puoi fare la seguente richiesta:

http://www.vulnerable.site/welcome.html?notname=

Anche se il payload viene analizzato dal server, la protezione può essere garantita solo se la richiesta viene rifiutata o la risposta viene sostituita con del testo di errore. Facendo ancora riferimento a e : se l'intestazione Autorizzazione viene semplicemente rimossa dal sistema di sicurezza intermedio, non avrà alcun effetto se viene restituita la pagina originale. Allo stesso modo, qualsiasi tentativo di elaborare dati sul server, rimuovendo o codificando caratteri illegali, sarà inefficace contro questo attacco.

Nel caso di document.referrer, il payload viene inviato al server tramite l'intestazione Referer. Tuttavia, se il browser dell'utente o la protezione intermedia rimuove questa intestazione, non ci sarà traccia di un attacco che può passare completamente inosservato.

Riassumendo, concludiamo che i metodi tradizionali, vale a dire

1. Codifica dei dati HTML lato server
2. La rimozione/codifica degli input vietati sul lato server non funziona contro DOM XSS.

Il rilevamento automatico delle vulnerabilità bombardando con dati dannosi (a volte chiamato fuzzing) non funzionerà perché i programmi che utilizzano questa tecnica in genere deducono se i dati incorporati sono presenti o meno nella pagina restituita (invece di eseguire codice nel contesto del browser sul lato client e monitorare i risultati). Tuttavia, se il programma è in grado di analizzare staticamente il codice Javascript trovato nella pagina, potrebbe indicare segni sospetti (vedi sotto). E, naturalmente, se gli strumenti di sicurezza possono eseguire codice Javascript (e inizializzare correttamente gli oggetti DOM) o emulare tale esecuzione, saranno in grado di rilevare questo attacco.

Funzionerà anche la ricerca manuale della vulnerabilità utilizzando un browser, poiché il browser può eseguire codice Javascript lato client. I rilevatori di vulnerabilità possono sfruttare questa tecnica ed eseguire codice lato client per monitorare i risultati della sua esecuzione.
Protezione efficace

Evita riscritture, reindirizzamenti o azioni simili dei documenti lato client che utilizzano dati lato client. La maggior parte di queste azioni può essere eseguita utilizzando pagine dinamiche (lato server).
2.

Analisi e miglioramento della sicurezza del codice (Javascript) lato client. I riferimenti ad oggetti DOM che possono essere influenzati dall'utente (attaccante) devono essere attentamente controllati. Particolare attenzione dovrebbe essere prestata ai seguenti oggetti (ma non limitati a):
*URL.documento
*document.URLNon codificato
* document.location (e sue proprietà)
*documento.referrer
* window.location (e sue proprietà)

Si noti che le proprietà del documento e degli oggetti finestra possono essere referenziati in diversi modi: in modo esplicito (l'esempio è window.location), in modo implicito (l'esempio è location) o ottenendo un handle e usandolo (l'esempio è handle_to_some_window.location).

Particolare attenzione dovrebbe essere prestata al codice in cui il DOM viene modificato, in modo esplicito o potenziale, e tramite accesso diretto all'HTML o tramite accesso diretto al DOM. Esempi (questo non è affatto un elenco esaustivo):
* Inserimento nel codice HTML della pagina:
o documento.scrivi(…)
o document.writeln(…)
o document.body.innerHtml=…
* Modifica direttamente il DOM (inclusi gli eventi DHTML):
o document.forms.action=… (e altre variazioni)
document.attachEvent(…)
o document.crea…(…)
document.execCommand(…)
o documento.corpo. ... (accedendo al DOM tramite l'oggetto body)
window.attachEvent(…)
* Modifica URL documento:
o document.location=… (oltre a impostare i valori href, host e hostname dell'oggetto location)
document.location.hostname=…
o document.location.replace(...)
posizione.documento.assegna(…)
documento.URL=…
window.navigate(…)
* Apertura/modifica dell'oggetto finestra:
o document.open(…)
finestra.apri(…)
o window.location.href=… (oltre a impostare l'host e il nome host dell'oggetto posizione)
* Esecuzione diretta dello script:
valutazione(…)
window.execScript(...)
window.setInterval(…)
window.setTimeout(…)

Continuando con l'esempio sopra, per una protezione efficace, lo script originale può essere sostituito dal codice seguente, che controlla la stringa scritta nella pagina HTML per i soli caratteri alfanumerici.

L'uso delle intestazioni di sicurezza è un collegamento importante nella protezione del sito e dei suoi visitatori dagli attacchi degli hacker. Nell'ultimo articolo sulla rubrica protezione e sicurezza, ho promesso di pubblicare regolarmente post su questo argomento. Oggi parlerò della protezione contro gli attacchi XSS.

Cos'è un attacco XSS

Cross Site Scripting è una vulnerabilità che consente a un utente malintenzionato di iniettare codice dannoso (solitamente HTML o JavaScript) nel contenuto di un sito Web. Il codice dannoso viene eseguito nel browser dell'utente che visualizza la pagina infetta sul sito.

Gli aggressori possono sfruttare varie vulnerabilità. I due tipi più comuni di attacco sono:

  • L'XSS riflesso è il tipo di attacco non persistente più comune che richiede un'azione da parte dell'utente.
  • Stored (Persistent XSS): un tipo permanente di attacco con l'introduzione di codice dannoso sul server, non richiede l'intervento dell'utente.

Attacco XSS riflesso

Si attiva quando un utente fa clic su un collegamento appositamente preparato che invia una richiesta a un sito con una vulnerabilità. Questa vulnerabilità è solitamente il risultato di un filtraggio insufficiente delle richieste in arrivo, che consente la manipolazione delle funzioni e l'attivazione di script dannosi.

  1. Un utente malintenzionato inserisce uno script dannoso in un collegamento ipertestuale che consente di visualizzare i cookie di sessione dell'utente e lo invia alla vittima tramite e-mail o altri mezzi di comunicazione.
  2. Quando si fa clic sul collegamento, l'utente viene catturato.
  3. Lo script viene eseguito nel browser dell'utente.
  4. Il browser invia i cookie all'attaccante, fornendo l'accesso ai dati personali dell'utente.

Attacco XSS memorizzato

Per completare con successo un attacco archiviato, un utente malintenzionato deve solo trovare una vulnerabilità su un sito Web e posizionare uno script dannoso sul proprio server. Il sito quindi inserisce il tag

http: //site.com/search.php?q=123

http://site.com/search.php?q=123

http: //site.com/search.php?q=123


lo priveremo di questa opportunità.

Ma questa tecnica ha un'applicazione ancora più interessante e potente. Simuleremo la permanenza dell'utente sul sito dopo aver cliccato sul link, infatti rimarrà sempre sulla stessa pagina, e in questo momento funzionerà uno script di terze parti, estraendo e inviando informazioni all'attaccante. In questo modo, XSS funzionerà fintanto che l'utente segue il collegamento su questo dominio .

Definiamo un'idea.

Il principio generale di funzionamento è questo: quando un utente entra in una pagina con XSS, lo script crea un iframe con lo stesso indirizzo di questa pagina e lo "attacca" in primo piano, l'utente ha l'impressione che la pagina sia stata caricata normalmente, perché l'iframe può essere visto solo nelle codepage.

E lo script ausiliario controlla la logica del bot spia, ovvero controlla quando l'indirizzo cambia nel frame per cambiarlo nella barra degli indirizzi, ma se c'è un altro dominio nell'indirizzo appena cambiato del frame, allora puoi aprirlo in una nuova scheda, oppure dovrai ricaricare la pagina per non addormentarti.
Pertanto, affinché XSS interrompa l'esecuzione in questo momento, l'utente deve aggiornare la pagina manualmente (se XSS è riflesso ed è stato trasmesso con il metodo POST, in altri casi l'aggiornamento non verrà salvato e, tra l'altro, alcuni browser ora è possibile inviare nuovamente la richiesta POST durante l'aggiornamento della pagina) oppure chiudere la scheda o passare a un altro dominio (anche se in questo caso si può comunque evitare di perdere il controllo).

Se va a un sottodominio del dominio attaccato, la scelta dell'attaccante, ovvero XSS, funzionerà, ma c'è una piccola possibilità che l'utente veda una mancata corrispondenza tra l'indirizzo. Penso che sia dovuto alla situazione, ad esempio, se il dominio google.ru è stato attaccato, l'utente è passato al servizio di file cloud di Google, che di solito si trova nel sottodominio drive.google.ru, quindi la probabilità che noterà un cattura quando si guarda la barra degli indirizzi è piuttosto alta, se usava spesso questo servizio. Altrimenti, puoi correre dei rischi. Ma dobbiamo tenere conto del fatto che non potremo più leggere i suoi dati da un frame con un sottodominio, poiché la Cross Origin Policy non lo consentirà. Ma possiamo tranquillamente scalare il dominio principale per conto di esso in modalità invisibile (di seguito, ne parlerò in modo più dettagliato).

Solo questo metodo ha delle limitazioni, ovvero non funzionerà se le risposte del server Web del sito contengono l'intestazione Opzioni X-Frame con significato NEGARE. Ma personalmente, ho incontrato tali siti solo un paio di volte, ora anche la metà STESSA ORIGINE non esibito, per non parlare di una completa restrizione attraverso NEGARE.

Analizziamo l'idea.

Ora molte persone probabilmente hanno ricordato una cosa meravigliosa come BeEF, che ha anche molte cose interessanti. Quindi, a proposito, c'è anche un'opzione per un reindirizzamento forzato dell'utente nel frame, ma l'indirizzo nella barra degli indirizzi non cambia, il che può bruciare rapidamente la scrivania e questa opzione ha scopi leggermente diversi.
In generale, BeEF ha quasi tutto ciò che serve e anche molte funzioni aggiuntive, ma personalmente volevo funzionalità aggiuntive, ovvero:

  • la possibilità di monitorare in tempo reale il codice delle pagine a disposizione dell'utente attaccato;
  • la possibilità di guardare tutto ciò che digita su quel sito (da login e password, a tasti di scelta rapida e messaggi), ovvero keylogger su JS;
  • la possibilità di impartire comandi JS al proprio bot in tempo reale, dopo aver visualizzato il codice delle pagine ricevute;
  • la possibilità di lasciare comandi al bot localmente, in modo che poi li “raccolga” e li esegua senza la nostra diretta partecipazione;
  • una minore probabilità che un bot dorma, o la capacità di un bot di “nascondersi” da occhi indiscreti;

Come accennato in precedenza, ho deciso di prendere in prestito da BeEF una bella idea di una coda di esecuzione dei comandi. Ad esempio, abbiamo analizzato le pagine che il bot ha cancellato quando un utente privilegiato è salito nel suo pannello di controllo con XSS memorizzato, lasciamo i comandi al bot - codice JS, come la prossima volta che l'utente entra, fai clic su questo pulsante, scrivi giù di un tale valore qui, ecc., quando questo utente visita la pagina successiva, il bot legge i comandi e li esegue, e non dobbiamo essere al suo timone per tutto - molto conveniente.

Fondamentalmente, un tale bot, ovviamente, è progettato per gli utenti di stato di alcuni siti che dispongono di "leve" aggiuntive per la gestione dei contenuti, altri utenti e così via. Dalle richieste funzionali si evince che la parte server è indispensabile.

Realizziamo l'idea.

In linea di principio, questa parte dell'articolo può essere saltata, poiché descrive semplicemente il processo di implementazione del bot desiderato e alcuni dei suoi dettagli, nel caso qualcuno voglia rifarlo o finirlo da solo. Anche se il bot all'inizio del codice avrà delle variabili attraverso le quali è possibile impostare alcune impostazioni.
Innanzitutto, l'algoritmo delle azioni del bot dal momento del caricamento:

1) Verifica se l'intestazione esiste Opzioni X-Frame:DENY(se c'è, allora arrotoliamo le canne da pesca);
2) Incorporare un frame e allestire tutti i componenti del bot;
3) Rimozione dello script e di tutte le tracce nel codice HTML;
4) Stabilire un contatto con la parte settentrionale e avviare l'inoltro dei dati, reagire alle risposte (ricevere comandi dal server);

Il primo punto non è stato del tutto chiarito, ovvero il bot controlla solo la prima pagina e l'intestazione principale. Il fatto è che di solito queste intestazioni sono incorporate dal server web per tutte le pagine contemporaneamente e molto raramente che tutto viene fatto "manualmente" per una pagina separata. Sì, e questo titolo in sé è piuttosto raro. Bene, non c'è niente di speciale da dire sul secondo e sul terzo, tutto sarà sotto.

C'è un punto relativamente importante che prima di aggiungere il codice dello script del bot nel codice, è necessario eliminare immediatamente i segni XSS nella barra degli indirizzi (dal codice JS), poiché ciò riduce le possibilità di rilevamento e, soprattutto, impedisce la ricorsione che si verifica quando si aggiunge un indirizzo al frame con lo stesso codice XSS, che a sua volta crea un altro frame con se stesso, e così via.

Ma per ogni evenienza, il codice del bot implementa la capacità di rilevare tale ricorsione del frame e impedirlo al primo tentativo di aggiungere un frame a uno già creato, ma è meglio non fare affidamento solo su di esso, ma eliminare ulteriormente il codice prima caricamento del codice bot. Anche se non ho ancora riscontrato problemi.

Funzione di controllo aggiornamento frame. Ho provato diversi modi per risolvere economicamente questo problema appendendo i gestori di eventi contentWindow o contenutoDocumento, ma niente ha funzionato, quindi ho dovuto scrivere una funzione che controllasse l'indirizzo del frame e lo confrontasse con quello salvato in precedenza, e in base a questo decidere se il frame è aggiornato (se l'indirizzo è cambiato) e quindi chiamarsi ricorsivamente.

La frequenza di tali controlli al secondo è controllata dalla variabile ritardo, che è specificato all'inizio del file del codice bot. Ma più tardi, dopo averlo già scritto, ho trovato una soluzione più efficiente: usa una soluzione semplice e appendi caricare sulla cornice, quindi ho lasciato quella funzione, ma l'ho commentata, nel caso in cui risultasse più popolare in seguito.

Invio del codice HTML della pagina.

Qui lo schema è abbastanza semplice: dopo ogni ricarica del frame (compreso il primo caricamento), il bot invia al server l'intero codice HTML della pagina insieme al suo indirizzo corrente, in modo che in seguito si possa distinguere se il codice appartiene alle pagine desiderate.

Il server implementa la logica di memorizzazione delle pagine: il server per ogni dominio crea una cartella con il nome di questo dominio e vi salva tutti i dati. I codici della pagina vengono salvati e costantemente aggiornati alle versioni correnti, ma allo stesso tempo viene creata una nuova copia della pagina ogni nuovo giorno in modo da poter controllare la cronologia delle versioni, se necessario. Cioè, per /notizie.php Il 1 settembre lo stato verrà aggiornato e il 2 settembre ne verrà creata una copia, rilevante solo per quel giorno, e così ogni giorno (se l'utente visita questa pagina tutti i giorni). Il nome della pagina è costituito dalla data e dal percorso di questa pagina rispetto alla radice del sito (ovvero senza il dominio).

Keylogger in JavaScript.

L'idea è stata già implementata da alcuni appassionati, ma per me i loro sviluppi non erano adatti, se non altro perché la maggior parte erano abbastanza semplici, cioè hanno rilevato il codice del tasto premuto e tramite String.fromCharCode tradotto in simboli. Ma questo metodo presenta una serie di svantaggi: i tasti di controllo come shift, control, spazio, ecc., non vengono tradotti in alcuna forma (spesso solo in un carattere vuoto), l'interazione dei tasti alfanumerici con lo shift viene registrata in modo errato, poiché questo deve essere implementato a livello di codice e inoltre tutti i tasti premuti vengono visualizzati in maiuscolo, il che viene corretto anche a livello di codice.

Di conseguenza, abbiamo ottenuto un keylogger che ha rilevato correttamente tutti i tasti di numeri, lettere e caratteri di base, lavorando su entrambi i layout, reagendo allo spostamento e registrando tutti i principali tasti speciali. È vero, alcuni caratteri (nella parte superiore della riga digitale, che vengono stampati quando si premono il turno e il numero), possono differire su alcune macchine, poiché sono stati implementati secondo lo standard principale, che alcune aziende cambiano.
Ogni porzione di caratteri premuta viene conservata dal client fino a quando l'elemento di testo non perde lo stato attivo. Quindi questa porzione viene inviata al server, dove viene archiviata in un file di testo, che verrà anche creato ogni giorno con una nuova copia in modo che non ci sia crescita a grandi dimensioni e puoi trovare rapidamente ciò che l'utente stava digitando in tale un tempo.
Oltre alle chiavi stesse, le informazioni sull'elemento in cui è stato digitato il testo vengono inviate al server con ciascuna porzione (ovvero se fosse ,