L'XSS nella memoria locale dovrebbe essere considerato "memorizzato"

Question

L'XSS nella memoria locale dovrebbe essere considerato "memorizzato"

#1 da (2 voti)
#2 da (1 voti)

3

Mi chiedo quale tipo di categoria di cross-site-scripting sarebbe se fosse iniettato nella memoria locale. Sarebbe "memorizzato", "riflesso" o forse qualcos'altro?

Un esempio di cosa intendo:

Ho trovato un sito Web vulnerabile per XSS riflessi (ti rimandiamo a vulnerable.com).
Utilizzando questo XSS riflesso, modifica alcuni JSON nel localStorage.
- Ho modificato una parte del JSON in questo modo: "imgUrl":"https://vulnerable.com/products/some-product.jpg\" onload=\"alert(1)",
Quando l'utente riavvia il browser e apre vulnerable.com, verrà visualizzato un avviso.

OWASP afferma che non è "memorizzato" ( fonte ):

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

Ma OWASP afferma anche che non è "riflesso" ( fonte ):

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

C'è qualcuno che lo sa?

xss

posta Tijme 16.12.2016 - 15:54

fonte

2 risposte

1

In realtà, non ci sono solo 2 classi (o anche 3) di XSS - Stored, Reflected e DOM-based - ci sono 4, lungo 2 diversi assi indipendenti:

Memorizzato / Riflesso
Server / Cliente

(Il cosiddetto XSS basato su DOM è in realtà solo un sottoinsieme di Client XSS.)

Quindi nel tuo caso, è semplicemente Stored Client XSS.

Vedi per es. Tipi di cross-site scripting su OWASP :

Given that both Server XSS and Client XSS can be Stored or Reflected, this new terminology results in a simple, clean, 2 x 2 matrix with Client & Server XSS on one axis, and Stored and Reflected XSS on the other axis as depicted here

risposta data 20.12.2016 - 02:30

fonte

Leggi altre domande sui tag xss

Arpspoof su Debian - Linux non funziona [chiuso] Problemi di sicurezza con accesso MySQL esterno tramite tunneling

score 2 · Accepted Answer

Aggiornamento della mia risposta in base alle informazioni fornite da @AviD (Grazie! Ho appreso qualcosa di nuovo).

Dalla pagina OWASP XSS :

For years, most people thought of these (Stored, Reflected, DOM) as three different types of XSS, but in reality, they overlap. You can have both Stored and Reflected DOM Based XSS. You can also have Stored and Reflected Non-DOM Based XSS too, but that’s confusing, so to help clarify things, starting about mid 2012, the research community proposed and started using two new terms to help organize the types of XSS that can occur:

Server XSS

Client XSS

NonsembraunserverXSSmemorizzatoinbaseaciòchehaidescritto.Seidatinellamemorialocalenonvengonoinviatialserverinognirichiesta(orichiestespecifiche)enonvengono"riflessi" nella risposta HTTP dal server, non dovrebbero essere considerati un server XSS riflesso.

In questo caso, il carico utile (JS) viene memorizzato sul client (browser) nella memoria locale, dovrebbe essere considerato come un Client XS memorizzato (di nuovo, sono d'accordo con @AviD Qui). Ora se questo payload è stato semplicemente inserito di nuovo nel DOM e non viene memorizzato sul client (browser), dovrebbe essere stato il caso di un client XSS riflesso.

Solo una piccola nota su Self XSS - qualcosa non menzionato sul sito OWASP: se solo sei in grado di cambiarlo sul tuo browser e non puoi "remotamente" ingannare questo inserimento del codice JS nella memoria locale di altri browser utente, ad esempio: chiedendo loro di fare clic su un URL, lo considererei come un Self XSS . Gli hacker tendono a sfruttare Self XSS principalmente attraverso truffe come la pubblicazione / condivisione di payload dannosi sulla rete di social media e chiedendo agli utenti di incollarli nelle loro console JS del browser per vedere come accade qualcosa di magico.