26 lines
1.3 KiB
Plaintext
26 lines
1.3 KiB
Plaintext
=== on 2 Oct 2014, 19:32:47 Nicolas Peru wrote:
|
|
This is slightly different than what we discussed, in my mind, this rule should detect calls to request.getHeader("referer"). So a compliant solution should not have this call at all.
|
|
|
|
=== on 3 Oct 2014, 14:07:20 Ann Campbell wrote:
|
|
\[~nicolas.peru] I'm assuming it's the code samples, rather than the description that you take issue with. Better now?
|
|
|
|
=== on 8 Oct 2014, 07:28:53 Nicolas Peru wrote:
|
|
Ok ! :)
|
|
|
|
=== on 12 Dec 2014, 20:51:57 Sébastien Gioria wrote:
|
|
\[~nicolas.peru]: I disagree. You could have calls to request.getHeader("referer"); but you should never use the value returned to perform an authentication or autorization.
|
|
|
|
|
|
|
|
=== on 12 Dec 2014, 20:56:02 Nicolas Peru wrote:
|
|
\[~sebastien.gioria]I agree but how would you distiguish risky calls from correct one ? Idea here is to raise all calls to this method to let the security auditor mute the acceptable ones.
|
|
|
|
=== on 12 Dec 2014, 21:07:38 Sébastien Gioria wrote:
|
|
It the job of the security auditor ;) to distinguish it. If the idea is to trigger attention of the Security auditor, this could be OK.
|
|
|
|
=== on 17 Feb 2021, 09:03:11 Eric Therond wrote:
|
|
This rule is not in SonarWay
|
|
|
|
we can safely deprecate it because taint analysis rules do a better job (referer header is a source) than this rule.
|
|
|