Security/CSP/CSRFModule: Difference between revisions

Jump to navigation Jump to search
Line 59: Line 59:
This section contains a list of open issues.  
This section contains a list of open issues.  


*The attacker could bypass the defense by hyperlinking to attacker.com, which isn't using CSP, and then submit the CSRF request from there. Form submission should only be allowed to <tt>self</tt> URIs when <tt>anti-csrf</tt> is enabled (the allowed set of URIs should be made extensible by other policy declarations). Link activations are still vulnerable to this attack, however.
*The attacker could bypass the defense by hyperlinking to attacker.com, which isn't using CSP, and then submit the CSRF request from there.
**To address this threat, form submission should only be allowed to <tt>self</tt> URIs when <tt>anti-csrf</tt> is enabled (the allowed set of URIs should be made extensible by other policy declarations).
**Link activations are still vulnerable to this attack, however.
*The list of HTTP requests where <tt>Cookie</tt> header is allowed to be sent must be exhaustive.
*The list of HTTP requests where <tt>Cookie</tt> header is allowed to be sent must be exhaustive.
*The CSP policy should be allowed to contain URI that are excepted from <tt>anti-csrf</tt> restrictions.
*The CSP policy should be allowed to contain URI that are excepted from <tt>anti-csrf</tt> restrictions.
35

edits

Navigation menu