26 lines
1.3 KiB
Plaintext
26 lines
1.3 KiB
Plaintext
|
=== On 2014-10-02T19:32:47Z 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 2014-10-03T14:07:20Z 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 2014-10-08T07:28:53Z Nicolas Peru Wrote:
|
||
|
|
Ok ! :)
|
||
|
|
|
||
|
|
=== On 2014-12-12T20:51:57Z 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 2014-12-12T20:56:02Z 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 2014-12-12T21:07:38Z 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 2021-02-17T09:03:11.806Z 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.
|
||
|
|
|