Gli aggressori devono identificare quali applicazioni sono ospitate sul tuo dominio. Possono identificarli eseguendo la scansione di file e strutture di directory comuni sulla piattaforma. Ad esempio, se esegui Wordpress, un utente malintenzionato può cercare /wp-admin e, se restituisce 200, sa che stai utilizzando Wordpress.
Una volta che conoscono il framework o l'applicazione in esecuzione, inizieranno a navigare tra vulnerabilità note o addirittura a 0 giorni, fino a quando non saranno in grado di compromettere la tua piattaforma.
Ora tienilo a mente perché CloudFlare serve semplicemente come ReverseProxy per aiutarti a proteggerti. Ciò significa che le richieste in arrivo al tuo server verranno originate da CloudFlare, non dall'attaccante.
Pensaci in questo modo:
[Attacker] -----> [ YourSite ]
[ CloudFlare ] -----> [Your Server Request]
[ CloudFlare ] <----- [Your Server Response]
[Attacker] <---- [ YourSite ]
CloudFlare sembra il tuo server fisico per gli aggressori. Eseguono query, recuperi, post, ecc. Sul tuo dominio. CloudFlare riceve prima la richiesta, quindi esegue un controllo sulla richiesta e la inoltra al server fisico.
Quindi quando vedi le richieste provenienti da CloudFlare, è perché stanno servendo da proxy inverso. /like e /undefined potrebbero ancora essere un utente malintenzionato che tenta di identificare vulnerabilità note sul tuo sito.