Se si utilizza l'autenticazione solo IP, l'utente malintenzionato può comunque utilizzare l'applicazione Web tramite attacchi pivot contro un host autorizzato dal firewall ad accedere all'applicazione.
Ad esempio, supponiamo che la tua applicazione si trovi all'interno della intranet (http://192.168.0.5) e uno dei client (192.168.0.100) sta navigando in Internet e visita una pagina Web dannosa che esegue il fingerprinting intranet, richiedendo link (x = 0..255) URL attraverso il browser della vittima (192.168.0.100), trovando in modo efficace gli IP con la porta 80 aperta e segnalandoli a attaccanti. L'attaccante può farlo ad es. con il framework BeEF . Successivamente, utilizzando il browser delle vittime come un proxy, l'utente malintenzionato può inviare richieste all'applicazione di destinazione (http://192.168.0.5). Esiste persino un framework per il rilevamento dei tipi di software installati nella rete Intranet, ad es. Yokoso . L'utilizzo di questi renderà più facili gli attacchi.
Naturalmente, l'attaccante può anche attaccare il SO su uno dei client (ad es. con spear phishing o drive-by-download attacco), in modo che abbia più possibilità di attaccare l'applicazione intranet e non sia limitato dalla stessa politica di origine.
Se autorizzi l'accesso all'applicazione solo per alcuni host nella stessa sottorete (e agli altri host viene negato l'accesso), l'attaccante interno ha più possibilità perché ha più conoscenze (ad esempio potrebbe conoscere gli URL esatti per l'applicazione , è il numero di versione) ed è all'interno della stessa rete, quindi può provare ad esempio ARP spoofing attacco per dirottare il traffico tra l'applicazione e uno dei client consentiti.
Raccomando di ospitare l'applicazione solo su SSL (per proteggere da man-in-the-middle) e aggiungendo l'autenticazione login / password (basata su cookie o semplice autenticazione HTTP)