La protezione CSRF può funzionare anche se esiste una vulnerabilità XSS?

No, non la penso così. Potrebbe essere aggirato creando un iframe con display: none , contenente la pagina add-users.php . Quindi tutto ciò che l'utente malintenzionato deve fare è compilare i campi del modulo e inviare il modulo con JavaScript e l'utente malintenzionato ha aggiunto un utente senza il consenso o la conoscenza della vittima. Il controllo dell'intestazione referer non lo fermerebbe, poiché avrebbe il valore corretto.

OWASP ha le seguenti informazioni sull'utilizzo del referente per la protezione CSRF :

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.

(Nota a margine, vorrei contestare che la risoluzione di questo problema "attenuerebbe notevolmente" i danni da XSS: un utente malintenzionato potrebbe ancora rubare le password, oltre alle altre cose elencate. / p>     

Shouldn't it be possible to use referrer checks as CSRF protection which work even if an XSS vulnerability exists?

No. Se sei uno script iniettato, puoi creare un <form> che punta alla stessa origine, includere un token CSRF rimorchiato e inviarlo con l'intestazione Referer prevista. (Anche i referrer checks sono in generale problematici, ed è improbabile che siano di qualche utilità se si tratta di un'applicazione che fa qualcosa con XHR.)

But wouldn't it work if the exact script is checked?

No. Una volta all'interno di un'origine non esiste un limite di sicurezza interno. Lo script iniettato può aprire qualsiasi URL all'interno dell'origine (ad esempio in un iframe o pop-up) e inserire script arbitrari direttamente in quella finestra, da cui restituirà il referente esatto previsto. (E in questi giorni con l'API di cronologia HTML5 puoi semplicemente modificare l'URL del documento corrente direttamente.)

Non c'è quasi nulla che un utente possa fare interagendo con una pagina web che non può essere riprodotta da uno script su quella pagina. Quindi OWASP ha ragione su questo: XSS in generale ti dà un più severo superset di vulnerabilità rispetto a XSRF. Non c'è nulla che tu possa utilmente fare per mitigarlo una volta che è successo, ed è per questo che l'enfasi è solitamente rivolta a far sì che il testo gestisca / fugga giusto per evitare che le iniezioni avvengano in primo luogo.