Scusami, non avevo inteso.

Allora, le due tecniche di attacco diretto su pagine web, che mi vengono in mente al momento, perche' sono le piu' utilizzate (ma non uniche)

1) Un utente malintenzionato, potrebbe abilitare il cross-site scripting tra frames nel proprio browser, caricare il tuo sito e uno suo (con codice, diciamo, "maligno") in due frame di una stessa pagina. Una volta fatto cio', lui potrebbe far eseguire suoi script facendoli accedere alle proprieta' delle tue pagine, modificandone il comportamento per qualunque cosa possa essere modificabile o bypassabile con javascript.
Risolvere non e' cosi' semplice a dire il vero. Tanto per cominciare, dipende se ne hai bisogno nelle tue pagine Magari no. Ma se c'e' qualcosa che potrebbe comportare un rischio e riguarda azioni js, allora forse devi pensare a come evitare che dall'esterno il comportamento del tuo codice js o in generale delle tue pagine possa essere alterato.
La protezione da questo genere di attacchi (che se fatti bene, fidati, possono essere ingegnosi e molto dannosi) non prevede una sola strada. Dipende molto dalle tue pagine, dal comportamento logico della tua applicazione ecc. Comincia a studiarti un po' la materia cercando articoli su Cross-Site Scripting, o XSS.

Un es. di attacco che in pratica realizza un vero e proprio (ingegnoso) Denial Of Service attack ad un sito. L'attacker, come detto,
- abilita XSS in un browser
- avvia una pagina contenente due frames: in un frame ci mette il tuo sito, nell'altro ci mette una sua pagina col codice "maligno".
- tale codice, una volta avviato, aggiunge del codice Javascript alla TUA pagina.
- una volta aggiunto del javascript alla tua pagina, lo fa eseguire: questo codice maligno non fa altro che eseguire richieste XML HTTP alla pagina stessa, asincronamente. In pochi minuti, il tuo sito e' KO per le troppe richieste. E' ovvio che l'efficacia dipende dal numero, in realta', di computer che contemporaneamente fanno girare il sistema.
Chi subisce questo attacco, non troverebbe mai chi l'ha fatto, semplicemente perche' tutte le richieste che hanno causato il DoS sembrerebbero provenienti dal sito stesso.


2) Immagina la tua applicazione abbia un form di login (e' un esempio, ma ci sono molte possibilita', comunque inerenti i form). Se non c'e' alcun controllo sulla provenienza dei dati POST/GET nella pagina che elabora il form, un attacker potrebbe inviare a catena dati di login generati automaticamente, al form, osservandone la risposta. E' un vero e proprio Brute Force Attack, che puo' scovare dati di login con una certa facilita', anche se puo' impiegare molto tempo (ma pensa a quanti utenti usano stupide password).

Per proteggersi: bloccare temporaneamente (es. 5-10 minuti) un indirizzo ip dalle quali siano pervenute un certo numero di tentativi di login falliti (es. 5).

E' una protezione nella maggioranza dei casi se aggiunta a:
- controllo referer
- dati browser
- salvataggio in un cookie del numero tentativi falliti

ma,

Problema: se l'attacker

- usa un sistema di rotazione proxy, per esempio, per cambiare il suo ip ad ogni connessione o dopo un timeout ecc ecc
- usa curl o simili per cambiare "virtualmente" il browser in uso ad ogni tentativo e...
- ...il referer
- disabilita i cookies

TI ATTACCHI AL TRAM