Gli attacchi di tipo "form grabbing" si verificano quando uno script / programma dannoso cattura il tuo modulo con le tue informazioni private. Il modo più semplice per farlo è con l'estensione javascript.
La migliore prevenzione è:
- utilizza il tuo computer attendibile (malware che potrebbe acquisire dati del modulo),
- installa il tuo sistema operativo / programmi dalla fonte attendibile,
- non installare estensioni del browser / script utente (soprattutto da fonti non attendibili) o almeno utilizzare la navigazione privata (con tutte le estensioni disabilitate) quando si accede a questi siti,
- usa un browser moderno aggiornato,
- usa solo password su connessioni https (questo rende più difficile agli hacker inserire javascript nello scripting cross-site),
- Considera anche la disabilitazione di javascript.
EDIT:
La mia risposta originale riguardava principalmente il titolo How do i protect myself from "Form grabbing" attack? contro come istruire su come scrivere software di sicurezza. Altrimenti concordo con CodesInChaos osservazione: "È una battaglia impossibile da vincere".
Ci possono essere due luoghi distinti che possono occupare la forma: dal browser (ad esempio, un attacco XSS che carica JS dannoso o un'estensione malevola installata nel browser) OPPURE monitorare le chiamate API tramite hooking .
Esistono diversi modi per eseguire il hooking, ma se un utente / malware dispone di privilegi sufficienti per inserire i hook API, probabilmente hanno anche abbastanza energia per rendere non verificabile l'output dei test di rilevamento di hooking.
Ad esempio, se qualcuno stava montando questo tipo di attacco per registrare tutte le richieste http / https è possibile rilevare provare a rilevare se la libreria condivisa (aka DLL) è stata modificata (concesso ogni aggiornamento benigno a tale libreria genererà falsi positivi) o contiene una determinata firma di malware.
Ora diciamo che la libreria condivisa modificata è salvata su disco nella sua forma alterata. Ora il tuo programma anti-hooking calcola un hashsum crittografico per verificare che la libreria non sia stata alterata per confrontarla con la funzione nota della libreria non modificata. Ma cosa impedisce all'aggressore di agganciarsi a quelle chiamate per calcolare il checksum e alterare l'output in modo che sia il checksum pre-modificato ogni volta che viene visualizzato il checksum dannoso? Nulla, a meno che, naturalmente, non si stia analizzando un disco rigido da un sistema operativo sicuro (ad esempio, l'unità è stata installata in sola lettura da un altro computer non infettato dal malware).
Garantito, a causa delle minacce di modifica del runtime delle librerie, è davvero necessario verificare le istruzioni nella memoria del processo in esecuzione rispetto ai file statici. In questo tipo di situazione, è necessario avere il potenziale malware in esecuzione per catturare l'attacco di aggancio dell'API, sebbene tutte le utilità di sicurezza non possano essere considerate attendibili poiché il sistema è già stato compromesso. (Puoi ancora scansionare il disco da una configurazione sicura per qualunque programma stia modificando la memoria per inserire i ganci API, ma è un'attività molto più difficile in cui trovi solo i tipi di attacchi che sai cercare).