Sono a conoscenza dei moderni approcci anti-clickjacking, come l'intestazione X-Frame-Options o gli script framekiller. Ma tutte queste tattiche impediscono ai contenuti di essere contenuti in iframe. Ma cosa succede se c'è un requisito per i contenuti in iframe, come il pulsante "Segui" di Twitter o il pulsante "Mi piace" di Facebook? Come proteggere tali iframe dal clickjacking?
I pulsanti di condivisione spesso utilizzano un iframe per proteggerli da CSRF . In questo contesto, CSRF e ClickJacking hanno un impatto identico, talvolta chiamato " LikeJacking ". Devi scegliere di essere vulnerabile a CSRF OPPURE puoi usare un iframe per prevenire CSRF ma poi esporti a ClickJacking. Succede che ClickJacking sia il minore di due mali. FaceBook risolve questo problema logico con l'azione legale . Puoi fare "LikeJacking" e ClickJacking contro i tuoi Termini di servizio e citarli come FaceBook.
Forse esiste una soluzione tecnica a questo problema. Ho inviato un'email a Google Security su questo argomento e mi hanno detto che utilizzavano " Analisi del segnale" per determinare se il comportamento stava avvenendo. Quale è una risposta piuttosto gassosa per non dire altro. Essendo Google fanno spider tutte le pagine che sono piaciute e possono determinare se un metodo clickjacking , come una maschera SVG è stata applicata al loro iframe dalla pagina padre. Ma questa è solo speculazione.
Potresti voler verificare con uno dei DNSBL. Alcuni di loro hanno URL trovati nei messaggi e-mail di spam. Non posso consigliare che in particolare uno ha il miglior database, ma è possibile cercare su Google DNSBL online e vedere i siti web offensivi se sono lì. Tale controllo può essere eseguito in tempo reale durante l'esecuzione della pagina.
DNSBL degli URI Un DNSBL URI è un DNSBL che elenca i nomi di dominio e gli indirizzi IP che si trovano nei link "cliccabili" contenuti nel corpo degli spam, ma generalmente non si trovano all'interno di messaggi legittimi. I DNSBL URI sono stati creati quando è stato stabilito che molto spam ha superato i filtri antispam durante quel breve intervallo di tempo tra il primo utilizzo di un indirizzo IP di invio di spam e il punto in cui quell'indirizzo IP di invio è stato elencato per la prima volta su IP principale di invio DNSBL. In molti casi, tali sfuggenti spam contengono nei loro nomi di dominio o indirizzi IP dei link (collettivamente indicati come URI) dove quell'URI è già stato individuato in spam precedentemente catturato e in cui tale URI non viene trovato nella posta elettronica non spam. Pertanto, quando un filtro antispam estrae tutti gli URI da un messaggio e li confronta con un DNSBL URI, allora lo spam può essere bloccato anche se l'IP di invio per quello spam non è ancora stato elencato su alcun DNSBL di invio IP.
Leggi altre domande sui tag client-side web-browser web-application appsec clickjacking