Qual è il pericolo di Reflected Cross Site Scripting?

Puoi fare molto quando puoi inserire del codice in una pagina. Ad esempio, puoi

1. rubare le credenziali nei cookie non HTTPOnly.
2. invia richieste a un server con le credenziali dell'utente. Pensa XSRF
3. rubare i segreti che sono memorizzati nelle variabili JS.
4. richiede all'utente di scaricare il contenuto inviando un modulo
5. visualizza testo che sembra provenire dai proprietari del sito. Pensa al phishing.
6. visualizza un input per la password, registra le sequenze di tasti e invia il risultato a un sito di tua scelta
7. reindirizza a un altro sito
8. ottieni dati GPS / videocamera se l'utente ha concesso l'accesso al sito al dispositivo

L' articolo di Wikipedia fa una grande giustizia:

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

...

Non-persistent (aka reflective):

1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information.
2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website (either directly or through an iframe or ajax), but will contain Mallory's malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bob's website.
5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge.

Hai qualche domanda al riguardo?

La difesa XSS standard lavora contro di essa; ad esempio, disinfettare l'input dell'utente non attendibile; ad esempio, lascia che inseriscano un piccolo sottoinsieme di HTML (da un linguaggio di markup limitato sicuro) o passino attraverso un buon disinfettante / purificatore html, non usare schemi non sicuri negli script (ad esempio, eval in javascript sull'input dell'utente), utilizzare idealmente un browser con CSP e sandboxing, ecc.

Da OWASP :

Reflected XSS Attacks: Reflected attacks are those where the injected code 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. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.

Ciò significa che posso inserire codice dannoso come parte dei parametri di query (la parte dell'URL dopo la e commerciale o il punto interrogativo.) Posso inviare un'e-mail dannosa, usare bit.ly o simili o combinare con altri attacca per farti fare una richiesta involontaria, che non sta filtrando per l'XSS.

In termini di attacchi, Phishing sarà il più grande, convincere qualcuno a fidarsi del mio legame malvagio. Questo tipo di attacco può anche essere combinato con CSRF o con un qualsiasi numero di attacchi, in qualsiasi momento e l'utente malintenzionato può ottenere un altro sito per eseguire il suo codice, e tu per eseguire la pagina con javascript abilitato, sarà pessimo.

Alcuni link

• link

Ti consiglio di dare un'occhiata al BeEF - The Browser Exploitation Framework link È fondamentalmente uno strumento per mostrare i pericoli dell'XSS. Usando un attacco XSS riflesso o persistente, si aggancia il manzo nel sito Web specificato e consente al controllo dell'attaccante sul browser sulla pagina specificata. BeEF si integra con Metasploit, che consente a un utente malintenzionato di inviare exploit del browser, ecc. Al browser dell'utente. Puoi rubare dati, rubare sessioni, ecc. Ci sono anche alcuni video decenti.

Qualsiasi cosa BeEF possa fare, anche gli attaccanti possono farlo. XSS può essere piuttosto male.