Da dove provengono le richieste sospette dagli utenti che hanno effettuato l'accesso al mio sito web?

Naviga le tue risposte
1

Ho un'applicazione web ASP.Net MVC 4 ospitata su un server Windows 2008. L'applicazione è protetta da un provider di appartenenze ASP.Net personalizzato. Solo gli utenti a cui è stata concessa l'autorizzazione dall'amministratore hanno accesso. L'applicazione contiene dati medici sensibili di individui.

Recentemente, ho scoperto che 60 su 320 utenti registrati inviano richieste sospette al mio sito web. Queste richieste ottengono una risposta 404 dello stato HTTP, in quanto non esistono sul mio sito e sono inadeguate. Ad esempio, questo è il sottoinsieme di URL che contengono "admin": 

    /_vti_bin/_vti_adm/admin.dll
    /admin.php
    /admin/597ea5fc-0805-4b3c-8ab8-3d5320d8683c
    /admin/chgpwd.php
    /admin/default.asp
    /AdminHTML/parse_xml.cgi
    /admin-serv/authenticate
    /admin-serv/config/admpw
    /advwebadmin/adminsettings/browsewebalizerexe.asp
    /advwebadmin/SQLServ/sqlbrowse.asp
    /iisprotect/admin/GlobalAdmin.asp
    /mailman/admin/mailman
    /phpmyadmin/sql.php
    /scripts/admin.cgi
    /shop/admin.php
    /shopscript/admin.php
    /SiteServer/admin/
    /store/admin.php

Ci si può aspettare un piccolo danno da una richiesta come /store/admin.php, poiché nessun file .php è presente sul server. Mi disturba ancora, perché i miei utenti sono loggati quando arrivano le richieste. Cioè, sessioni e cookie di autenticazione vengono inviati con le richieste. Pertanto, se è stata inviata una richiesta valida, il server potrebbe divulgare informazioni sensibili nella risposta, poiché il server ritiene che le richieste siano autentiche. Io uso un token anti-contraffazione per prevenire la falsificazione di richieste tra siti, ma questo eviterà richieste di richieste maligne. Questi sono quasi altrettanto problematici, a causa dei dati sensibili sul sito. Inoltre, se le richieste sospette provengono effettivamente dal browser dell'utente, non esiste "cross-site".

Finora, sono stato in grado di confermare che le richieste autenticate arrivano quando l'utente sta effettivamente utilizzando l'applicazione. Cioè, le richieste sospette arrivano tra richieste valide e il mio registro mostra anche che gli utenti hanno effettuato l'accesso. Ora sto cercando di registrare le richieste complete, inclusi l'indirizzo IP di origine, le intestazioni HTTP e i cookie. Non banale, poiché la mia applicazione si trova dietro un server proxy inverso.

Nel frattempo mi chiedo quale possa essere l'origine di queste richieste, considerando che molti dei miei utenti sono coinvolti. Potrebbe essere:

  1. Molti malware presenti nei browser degli utenti?
  2. Altro malware sui client?
  3. Attacchi man-in-the-middle?
  4. Malware sul server web?
  5. Malware distribuito dalla mia applicazione web, javascript?

Inoltre, l'applicazione web viene regolarmente sottoposta a scansione da uno strumento di test McAfee Penetration. Questo strumento non esegue il login. Ho scoperto che anche gli URL tutti in richieste sospette, creati da sessioni utente, sono eseguiti da McAfee (205 diversi URL, finora). McAfee stessa, tuttavia, ne usa molti altri (3300+). Questo mi fa domandare se le richieste degli utenti possano essere confuse da qualche parte nella rete, a causa del caching o di qualsiasi altra cosa, in modo che io stia effettivamente guardando un non-problema. Certo, ho un problema molto più grande se le richieste sono confuse. D'altra parte, le richieste sono correlate al tempo con le sessioni utente, non con gli intervalli di esecuzione dei test di penetrazione e forse gli URL sono solo le vulnerabilità che il malware sta cercando.

    
posta user39471 04.02.2014 - 17:26
fonte

3 risposte

0

Alla fine, questo era solo un artefatto , come ho già considerato:

This makes me wonder if the requests from users could get mixed up somewhere in the network, due to caching or whatever, so that I am actually looking at a non-issue.

Fortunatamente, solo la registrazione è stata confusa. Io uso log4net. All'inizio di ogni richiesta, ho specificato proprietà come nome utente, URL richiesto e indirizzo IP, in un ThreadContext di log4net. Da qualsiasi punto del codice, è possibile creare una voce di registro, senza conoscere queste proprietà. Tuttavia, a causa della agilità dei thread in ASP.Net, al momento della creazione effettiva di una voce di registro e della lettura delle proprietà su ThreadContext, a volte ASP.Net stava elaborando un'altra richiesta su quel thread rispetto a uno a cui appartenevano le proprietà!

Quindi, grazie per il tuo tempo e il tuo aiuto e le tue scuse per aver segnalato questo problema che ho interpretato male.

Leggi log4net Problemi di contesto con agilità di thread ASP.Net per un'analisi accurata del problema e log4net Proprietà contestuali e ASP.NET per un accurato work-around, che ho effettivamente applicato.

    
risposta data 02.05.2014 - 22:32
fonte
2

L'elenco degli URL visualizzati è simile a quelli prodotti da strumenti come nikto che richiedono un elenco di URL potenzialmente vulnerabili o noti. Ovviamente una lista come questa potrebbe (e probabilmente lo è) usabile dal malware e strumenti di test come nikto.

Un fattore interessante nel tracciare cosa farebbe questo sarebbe, qual è l'agente utente su queste richieste? Molti strumenti di test avranno un agente utente personalizzato in modo che possano essere rilevate attività, mentre il malware probabilmente cercherà di renderlo meno evidente in una normale stringa del browser degli utenti.

In entrambi i casi sarebbe più difficile per lo strumento abbinare completamente la vera stringa del browser dell'utente, quindi abbinare gli user agent "normali" degli utenti con richieste dispari che sembrano provenire da quell'utente potrebbe aiutarti a capire cosa sta succedendo.

    
risposta data 04.02.2014 - 18:26
fonte
2

Could it be:
Much present malware in the browsers of the users?

È possibile.

Other malware on the clients?

È possibile.

Man-in-the-middle attacks?

Meno probabile.

Malware on the web server?

Meno probabile.

Malware distributed by my web application, javascript?

È possibile.

Molto probabilmente, però, è un bot o uno strumento di scansione creato allo scopo di sondare i siti per i punti deboli. Potrebbe essere ospitato sul computer di un utente, o forse no. Quel punto non importa davvero un intero mucchio. Ciò che importa è ciò a cui il bot ha accesso e ciò a cui la tua app è vulnerabile.

Il fatto che un'enorme percentuale di utenti sembrino essere malintenzionati è un po 'sconcertante. Se è effettivamente corretto, ciò significa che devi rendere più rigido il processo di registrazione, ma immagino che tu debba esaminare i tuoi eventi un po 'più da vicino per determinare cosa sta succedendo.

Consiglierei di cercare tra i registri delle richieste effettive (un output di file di testo IIS) che ti porterà l'URL, lo stato, l'agente utente e l'IP di ogni richiesta (tra le altre cose) e puoi correlarlo con altre richieste a verifica se è realmente associato agli utenti che hanno effettuato l'accesso.

    
risposta data 04.02.2014 - 18:26
fonte

Leggi altre domande sui tag

Garantire la sicurezza nell'autenticazione dell'URL Token Perché la modalità monitor è necessaria sulla scheda NIC utilizzata per attaccare WPS con il reaver e altri strumenti?