In che misura un hacker può potenzialmente causare danni a un server? Puoi per favore dare qualche esempio?
Recentemente, c'è stata una violazione dei dati nel mio sito web e Ho scoperto che questa interfaccia era rivolta al pubblico ed era curioso di vedere se questo potesse essere utilizzato per la violazione dei dati.
To what extent a hacker can potentially cause harm to a server? Can you please give few examples?
Alcuni esempi sono XSS e filtrazione dei dati.
Per ulteriori informazioni sull'exploit di scripting XSS, consultare: link
Per ulteriori informazioni sull'estrazione dei dati, consultare: link
Sembra che ci siano due CVE per MemCache, in particolare:
CVE-2010-5276 - Il modulo Memcache 5.x prima di 5.x-1.10 e 6.x prima di 6.x-1.6 per Drupal non gestisce correttamente l'oggetto $ user in memcache_admin, che potrebbe "portare a una modifica del ruolo non riconosciuta fino a quando l'utente non registra di nuovo. "
CVE-2010-5275 - La vulnerabilità Cross-site scripting (XSS) in memcache_admin nel modulo Memcache 5.x prima di 5.x-1.10 e 6.x prima di 6.x-1.6 per Drupal consente agli autori di attacchi in remoto di inserire script Web o HTML arbitrari tramite vettori non specificati. Tieni presente che potrebbero esserci più vulnerabilità con MemCache che non sono state divulgate pubblicamente.
La prima cosa che mi viene in mente è l'iniezione di script (per Cross-site scripting (XSS) o per scopi di phishing)
In secondo luogo, tutti i dati "privati" memorizzati nella cache sono leggibili dal mondo. (questo potrebbe significare e-mail / password / chiavi / etc ... erano / sono accessibili per chiunque li desideri.)
Il modo in cui il server delle applicazioni è configurato potrebbe uno dei possibili modo un utente malintenzionato può utilizzare le loro opportunità di accessibilità - questo sarà definito come la superficie di attacco per l'applicazione.
Come hai deciso di mantenere il contesto basato su memcache , ti consegnerei le protezioni invece di misurare la superficie di attacco poiché ciò dipende dalle interfacce che sono esposto al pubblico di fronte . Se sei al debian, usa questo per configurare IPSec.
iptables -A INPUT -s 1.1.1.1/32 -p tcp --destination-port 11211 -j ALLOW
iptables -A INPUT -s 0.0.0.0/0 -p tcp --destination-port 11211 -j DROP
Utilizzare quanto sopra per proteggere dai compromessi se un utente malintenzionato tenta di eseguire il backconnect e quindi il root. Questo dipende ancora dall'usabilità, come se il tuo use case è servito bloccando tutte le altre porte tranne quella che usi. Se memcached fa affidamento sullo stesso sistema che ha accessibilità e parla con le istanze MySQL, potrebbe essere necessario preoccuparsi se una qualsiasi delle interfacce è stata sfruttata. Se entrambi si trovano sullo stesso sistema, il tuo server web comunicherà con memcached piuttosto che con il server mysql e quindi qualsiasi probabilità di exploitibility per il webserver porterà conseguenze chiare anche al tuo database web.
Invito anche a dare un'occhiata a questo , che fornirà inoltre lo studio superficie di attacco .