1. casa
  2. Domanda e risposta
  3. Prevenzione attacchi XSS

Prevenzione attacchi XSS

2010-05-06 15 views
5

Sto sviluppando un'applicazione Web in cui gli utenti possono rispondere alle voci del blog. Questo è un problema di sicurezza perché possono inviare dati pericolosi che saranno resi ad altri utenti (ed eseguiti da javascript).Prevenzione attacchi XSS

Non possono formattare il testo che inviano. No "grassetto", niente colori, niente niente. Semplicemente testo. sono arrivato fino a questo regex per risolvere il mio problema: ". " "?"

[^\\w\\s.?!()]

Quindi tutto ciò che non è un carattere di parola (az, AZ, 0-9), non è uno spazio bianco,,," ! "," ("o") "sarà sostituito con una stringa vuota. Di ogni marchio di valutazione verrà sostituito con: "& quot".

Controllo i dati sul front-end e lo controllo sul mio server.

C'è qualche modo che qualcuno possa ignorare questa "soluzione"?

Mi chiedo come StackOverflow fa questa cosa? Ci sono molte formattazioni qui, quindi devono fare un buon lavoro con esso.

fonte

2010-05-06 Colby77

+0

Qual è la lingua del lato server? –

+0

Java. Io uso servlet – Colby77

+0

Non hai detto nulla su '<>', che è probabilmente il carattere più vitale usato in xss ... – rook

risposta

0

Il front-end può essere ignorato utilizzando Fiddler, ad esempio aggiungendo le informazioni sul modulo. Sul back end utilizzare la codifica html, ad es. <a> = & lt; a & gt;

In questo modo il testo verrà visualizzato come testo non come elementi HTML.

fonte

2010-05-06 13:44:00

1
  1. Non consentire tag HTML.
  2. Non emette nulla di un utente immesso senza prima l'escape di HTML. Questo è il punto molto più importante! Fai questo e non avrai mai un problema XSS.
  3. Fornisce una funzione di anteprima in modo che gli utenti possano vedere come sarà prima di pubblicare.

Se è necessario consentire i tag HTML, definire una whitelist e controllare l'input dell'utente su di esso. Puoi anche usare espressioni regolari per questo.

Dire si consente <p>, <a href="..."> e <img src="...">:

  1. trovare tutto nella stringa user che corrisponde <\S[^>]*>
  2. per ogni partita, controllare contro <(p|a href="[^"]+"|img src="[^"]+")/?>|</(a|p)>
  3. se non va bene che una rigorosa regex , buttalo via.
  4. Vedere il punto 2 sopra.
  5. Prova a distruggere deliberatamente il tuo sistema. Chiedi agli altri di provare a distruggere il tuo sistema.

fonte

2010-05-06 14:03:48 Tomalak

2

Concordo con Tomalak, e volevo solo aggiungere alcuni punti.

  1. Non consentire tag HTML. L'idea è di trattare gli input dell'utente come testo e i caratteri html-escape prima di renderli. Utilizzare il progetto OWASP's ESAPI per questo scopo. This page explains the various possible encodings di cui dovresti essere a conoscenza.
  2. Se si deve consentire i tag HTML, utilizzare una libreria per fare il filtraggio per voi. NON scrivere le proprie espressioni regexe; sono difficili da ottenere. Usa OWASP's Anti-Samy project - è stato progettato specificamente per questo caso d'uso.

fonte

2010-05-06 17:52:49

3

Se si desidera semplicemente il testo non preoccuparsi di filtrare specifici tag html. Vuoi l'equivoco a PHP htmlspecialchars(). Un buon modo per utilizzare questo è print htmlspecialchars($var,ENT_QUOTES); Questa funzione eseguirà le seguenti codifiche:

'&' (ampersand) becomes '&amp;' 
'"' (double quote) becomes '&quot;' when ENT_NOQUOTES is not set. 
''' (single quote) becomes '&#039;' only when ENT_QUOTES is set. 
'<' (less than) becomes '&lt;' 
'>' (greater than) becomes '&gt;'

Questo sta risolvendo il problema di XSS al livello più basso, e non hai bisogno di un po 'di complesso di librerie/regex che don' t capire (ed è probabilmente insicuro dopo che tutta la complessità è il nemico della sicurezza).

Assicurati di PROVA IL TUO FILTRO XSS eseguendo un free xss scanner.

fonte

2010-05-06 18:04:05 rook

1

Si consiglia di leggere the XSS Prevention Cheat Sheet quali dettagli migliori pratiche per evitare attacchi XSS. In sostanza, ciò che è necessario filtrare dipende dal contesto in cui verrà utilizzato.

Ad esempio, in questo tipo di scenario:

<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>

quello che devi fare:

& --> &amp; 
< --> &lt; 
> --> &gt; 
" --> &quot; 
' --> &#x27;  &apos; is not recommended 
/--> &#x2F;  forward slash is included as it helps end an HTML entity

Mentre, nel caso di un href="" esempio, è necessario fare un urlescape:

"Tranne caratteri alfanumerici, sfuggire tutti i caratteri con valori ASCII inferiori a 256 con %HH formato di escape. Inclusione di dati non attendibili nei dati: gli URL non dovrebbero essere consentiti in quanto non esiste un buon metodo per disattivare gli attacchi con l'escape per impedire la disconnessione dall'URL. Tutti gli attributi dovrebbero essere citati. Gli attributi non quotati possono essere scomposti con molti caratteri incluso [spazio]% * +, - /; < =>^e |. Si noti che la codifica delle entità è inutile in questo contesto."

Mentre l'articolo citato dà il pieno verdetto, si spera non c'è abbastanza informazioni in questa risposta per iniziare.

fonte

2010-05-24 14:07:14

0

Rimuovere eventuali sequenze di caratteri cattivi prima, ad esempio, overlong UTF-8, Unicode valido.

Avrai bisogno di essere più espliciti se <e> sono spogliati o trasformate in entità.

Avrete anche bisogno di spogliarsi o codificare doppia e virgolette singole, altrimenti un utente malintenzionato può aggiungere un evento intrinseco dove non ci si aspettava, ad es. valore < di input name = 'commento' = 'foo 'onSomething = payload; a ='' >

Se davvero si vuole consentire un sottoinsieme di HTML, fare attenzione a cercare di analizzarlo con regex, specialmente quelli che si venire con te stesso, ad es i browser renderanno difficili i tag <a b=">"onMouseOver=alert(42)> bene, in cui una regex potrebbe non corrispondere. Controlla il già citato Anti-Samy.

Se stai permettendo tag HTML che hanno href o src attributi, assicurarsi che essi indicano http(s): schemi, non javascript: quelli.

fonte

2010-06-18 07:57:40 Mike

Problemi correlati

 Problemi correlati