Il payload per XSS basato su DOM è definito come originato solo all'interno del browser o anche all'esterno di esso

1

Ho letto in più punti viste contraddittorie su ciò che potrebbe essere considerato un XSS basato su DOM. Sembra che la definizione originale indichi che si tratta di una forma di XSS in cui il carico utile proviene esclusivamente dall'interno del browser, ma alcune persone lo vedono anche come una forma di XSS in cui il carico utile non può necessariamente provenire dall'interno del browser, ma viene utilizzato modificare il DOM.

La seconda visione è ciò che mi confonde. Cosa significa esattamente che il carico utile viene utilizzato per modificare il DOM? La pagina OWASP che descrive DOM XSS , fornisce un esempio che, a mio parere, sembra essere lo stesso dell'XSS riflesso.

Dice:

A DOM Based XSS attack against this page can be accomplished by sending the following URL to a victim: http://www.some.site/page.html?default=<script>alert(document.cookie)</script>. When the victim clicks on this link, the browser sends a request for: /page.html?default=<script>alert(document.cookie)</script>. The server responds with the page containing the above Javascript code.

The original Javascript code simply echoes it into the page (DOM) at runtime. The browser then renders the resulting page and executes the attacker’s script: alert(document.cookie)

Poiché il carico utile sta passando dal browser della vittima al server e sta tornando al browser, come invece non si riflette l'XSS?

Devo interpretare questo come XSS riflessa significa essere in grado di iniettare tag <script> in un contesto HTML e XSS basato su DOM significa essere in grado di iniettare payload all'interno di un <script> già esistente?

    
posta user1720897 31.07.2016 - 08:26
fonte

2 risposte

2

XSS basato su DOM vs XSS riflesso

Should I interpret this as Reflected XSS means being able to injecting <script> tags in an HTML context, and DOM based XSS means being able to inject payload inside an already existing <script>?

No.

XSS riflesso significa che il carico utile immesso si riflette nella risposta fornita dal server ed eseguita dal browser (non importa dove viene inserito il payload, a condizione che venga interpretato da il browser).

Con XSS basato su DOM , il carico utile può o non può essere consegnato nella risposta del server, ma non sarà eseguito dal browser così com'è. Invece, il codice JavaScript fornito dal server lo prenderà e lo inserirà nel DOM, portando così alla sua esecuzione.

Interazione basata su server XSS e server

Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

Perché il fatto che venga inviato al server e viceversa non è rilevante per l'attacco.

Ciò che è rilevante per l'attacco è che il codice JavaScript fornito dal server legge l'URL e lo inserisce nel DOM, eseguendo in tal modo il codice inserito.

Se continui a leggere, OWASP descrive anche questo:

The server responds with the page containing the above Javascript code. The browser creates a DOM object for the page, in which the document.location object contains the string:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

The original Javascript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime.
[...]
In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.

Quindi OWASP afferma anche specificamente che un attacco basato su DOM può andare sul server e tornare indietro.

    
risposta data 31.07.2016 - 09:32
fonte
1

Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

In questo esempio, non sta per tornare al server come XSS.

Il codice vulnerabile è in Javascript:

<script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script>

Anche se nell'esempio in questione viene inviato al server:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

Ma non deve:

http://www.some.site/page.html#default=<script>alert(document.cookie)</script>

... sarebbe anche valido per questo attacco. La sezione "identificatore di frammento" dell'URL ( # ) non viene mai inviata al server, tuttavia può essere rilevata da Javascript.

Nel loro esempio, viene inviato al server ma non è il server che causa l'XSS, è il codice lato client. Questo è ciò che definisce XSS basato su DOM.

Per citare OWASP:

...the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

    
risposta data 02.08.2016 - 16:23
fonte

Leggi altre domande sui tag