Perché gli attributi ID richiedono una convalida più rigorosa?

4

In base a foglio trucchi OWASP XSS Prevenzione , dovresti

Strictly validate unsafe attributes such as background, id and name

Comprendo che background potrebbe contenere data: urls e può quindi essere sfruttato anche se il contenuto è codificato in HTML in base a Regola 2 .

Ma perché devo convalidare rigorosamente id e name ? È solo perché può essere usato per iniettare ancore che potrebbero innescare i gestori di eventi che sono stati iniettati con altri mezzi? O è per prevenire XSS basato su DOM a causa di script vulnerabili che caricano il codice da elementi utilizzando l'ID (ad esempio, l'ombreggiatura di qualche altro elemento che è presente nella pagina)?

    
posta 0x89 11.05.2015 - 14:21
fonte

2 risposte

3

Questo non impedisce che le virgolette doppie, le virgolette singole o gli spazi escano dal contesto dell'attributo, poiché questo è coperto da "Codifica delle Entità HTML Aggressive".

Per background , un attacco come questo è possibile:

<body background="javascript:alert('XSS')">

Per id e name , questi attributi vengono spesso utilizzati come punti di riferimento nel DOM.

Se un utente malintenzionato può falsificare questi punti di riferimento, potrebbe essere in grado di ingannare gli script esistenti per ottenere e impostare valori da luoghi diversi da quelli progettati, il che potrebbe essere pericoloso a seconda del contesto utilizzato.

Questo vale anche per i moduli HTML dove name viene utilizzato per identificare la coppia nome / valore. Ad esempio, se un sito Web non codifica un particolare campo modulo quando viene emesso, ma poiché il campo modulo è generato dal server e il modulo è protetto contro CSRF mediante l'uso di token, non può essere sfruttato in modo normale. Tuttavia, un utente malintenzionato potrebbe essere in grado di invogliare un utente a visitare un URL con un parametro che viene utilizzato in name , contenente un carico utile XSS da eseguire alla presentazione del modulo.

es. Uso normale:

https://example.com/product?item_name=watch&qty=1

che esegue il rendering di un modulo

<form>

<input type="hidden" name="watch" value="1" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

E poi viene emesso come

Thank you for buying from Bob's Supplies.

Tuttavia, un utente malintenzionato potrebbe inviare un link all'utente in questo modo:

https://example.com/product?item_name=shop_name&qty=<script>alert('xss')</script>

Poiché l'applicazione è correttamente codificata in HTML a questo punto, restituisce il modulo come

<form>

<input type="hidden" name="shop_name" value="&lt;script&gt;alert(&#039;xss&#039;)&lt;/script&gt;" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

Questo viene quindi visualizzato come

Thank you for buying from <script>alert('xss')</script>.

poiché questa pagina non codifica il parametro shop_name in quanto è attendibile e il framework dell'applicazione prende sempre il primo valore nel caso di duplicati. Molto artificioso, ma è stata la prima cosa che mi è venuta in mente per dimostrare il punto.

    
risposta data 12.05.2015 - 11:14
fonte
0

Il testo dice che è necessario convalidare l'input non attendibile quando viene usato come qualsiasi attributo. È solo una riformulazione di regola 2 . Personaggi come " potrebbero causare grossi problemi.

    
risposta data 12.05.2015 - 03:10
fonte

Leggi altre domande sui tag