Sicurezza pagine HTML

[Teo80]

Considerando delle pagine HTML statiche senza javascript e vbscript, esiste qualche vulnerabilità di cui tenere conto? A me non viene in mente niente, ma non avevo neanche pensato a quelle che ho visto sulle guide nella sezione sicurezza, per cui meglio chiedere...

[Habanero]

Pagine in puro html statico non possono avere vulnerabilità dovute ad un errato progetto.

A quali guide ti riferisci?

[Teo80]

Intendevo quelle nella sezione sicurezza di HTML.it riguardanti PHP. Non avevo pensato a quei trucchetti.

[Habanero]

quando intendo html statico intendo che queste non vengono generate dal PHP... è ovvio che se lato server le pagine sono in PHP tutto cambia radicalmente... chiarisci meglio, la tua domanda parla di puro html.

[Teo80]

Sì, sì, intendevo se le pagine HTML hanno vulnerabilità.

La seconda cosa che ho detto era che non avrei mai pensato alle vulnerabilità di PHP, per cui forse ci sono vulnerabilità anche in HTML a cui non ho pensato.

[Habanero]

PHP è un linguaggio di programmazione, HTML no! (è un linguaggio di markup).
L'unica possibilità che HTML sia vulnerabile è che la sua implementazione in un particolare browser lo sia... In passato è successo che con solo codice HTML un browser fosse vulnerabile (mi ricordo una pericolosa vulnerabilità di IE) ma questo non è colpa di una errata programmazione, è problema del browser.

In sostanza non esistono vulnerabilità per HTML proprio perchè NON è un linguaggio di programmazione.

[Teo80]

Riprendo la discussione...

Quindi neanche i fogli di stile CSS possono avere problemi di sicurezza (a parte quelli causati da bug del browser)?

E riguardo eventuali funzioni javascript o vbscript? Immagino che girando sul client non creino particolari problemi, è corretto?

Grazie ancora,
Teo

[Sisupoika]

Originariamente inviato da Teo80
Considerando delle pagine HTML statiche senza javascript e vbscript, esiste qualche vulnerabilità di cui tenere conto? A me non viene in mente niente, ma non avevo neanche pensato a quelle che ho visto sulle guide nella sezione sicurezza, per cui meglio chiedere...

- cursori animati
- iiframes, usati da una marea di malware. Un iframe nascosto nella pagina puo' caricarti roba di cui tu potresti non rendertene conto. Tecnica molto usata.
- CSS
- oggetti embedded
- ecc ecc

[Teo80]

Grazie per la risposta, Sisupoika. Però io intendevo eventuali accorgimenti lato webmaster da prendere nel caso nel suo sito ci siano CSS o javascript o vbscript.

[Sisupoika]

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