58 lines
3.6 KiB
Plaintext
58 lines
3.6 KiB
Plaintext
=== on 26 Aug 2015, 19:34:37 Ann Campbell wrote:
|
|
\[~linda.martin] I recognize that this one may be a bear to implement since the flag could be set either in php.ini _or_ in code. If possible I'd like to see it work like this:
|
|
|
|
----
|
|
if ( HTTPOnly in php.ini) {
|
|
no issue
|
|
} else if (set(cookie) && ! cookie.has(HTTPOnly)){
|
|
issue
|
|
}
|
|
----
|
|
|
|
Also, I didn't provide any code samples because I wasn't sure whether you'd want to show code or configuration
|
|
|
|
=== on 15 Sep 2015, 21:16:36 Evgeny Mandrikov wrote:
|
|
IMO from an implementation point of view this RSPEC is underspecified, so removing targeting for ``{cpp}`` for now.
|
|
|
|
=== on 17 Sep 2015, 15:19:48 Ann Campbell wrote:
|
|
\[~evgeny.mandrikov] what more are you looking for?
|
|
|
|
=== on 17 Sep 2015, 16:07:55 Evgeny Mandrikov wrote:
|
|
\[~ann.campbell.2] what this RSPEC supposed to find in {cpp} code
|
|
|
|
but the reason of removal targeting: currently there are too much (for my taste) issues in backlog targeting {cpp} and about which I have no idea of how implementation can look like, which complicates work with this backlog
|
|
|
|
=== on 13 Nov 2015, 15:06:03 Linda Martin wrote:
|
|
\[~ann.campbell.2] sorry for the delay, looks good that way and maybe both configuration and code could be given as they could both trigger issues.
|
|
|
|
=== on 17 Nov 2015, 14:45:56 Ann Campbell wrote:
|
|
Code samples added
|
|
|
|
=== on 18 Oct 2016, 17:09:17 Pierre-Yves Nicolas wrote:
|
|
My understanding is that cookies can be created with http://php.net/manual/en/function.setcookie.php[setcookie], but PHP also manages directly the "session cookie": the settings of the session cookie can be modified with http://php.net/manual/en/session.configuration.php#ini.session.cookie-httponly[session.cookie_httponly] in php.ini or inside PHP code with http://php.net/manual/en/function.session-set-cookie-params.php[session_set_cookie_params]. The rule should probably check all 3 usages.
|
|
|
|
=== on 2 Dec 2018, 22:54:25 Lars Svensson wrote:
|
|
There could be many legitimate reasons why an application needs script access to a cookie. To mitigate CSRF is just one example. Another example could be for user interface settings that are persisted across page refreshes.
|
|
|
|
|
|
(Also, when mitigating CSRF, there are multiple ways you can go. Using a cookie is just one of them. And the cookie name is framework specific - even though it happens to be called "XSRF-TOKEN" in some popular frameworks, there are many examples of other names used in the field)
|
|
|
|
|
|
IMO, it is only relevant to set the HttpOnly flag for security-sensitive cookies. Since it could be difficult to detect whether a cookie is used in a security context, perhaps this rule should be changed into a Security Hotspot instead.
|
|
|
|
|
|
I also propose to lower the default severity as a missing HttpOnly flag is not an exploitable vulnerability in itself, even if the cookie is used in a security context. It is only together with for example a Cross Site Scripting vulnerability that it is exploitable.
|
|
|
|
=== on 18 Dec 2018, 10:22:50 Alexandre Gigleux wrote:
|
|
My take on this one is that I guess that the FP Rate is below 10% and so majority of the time, HttpOnly should be set. Yes, we will have FPs on CSRF Cookies and in that case, I would expect users to raise the point on \https://community.sonarsource.com to start a discussion. I propose to keep it like this for the moment and see users' reactions.
|
|
|
|
=== on 9 Oct 2019, 17:50:01 Ann Campbell wrote:
|
|
\[~eric.therond] generally speaking you want to use _either_ "this" or "here" in the message:
|
|
|
|
|
|
* Make sure creating a cookie without the "HttpOnly" flag is safe here.
|
|
* Make sure creating this cookie without the "HttpOnly" flag is safe.
|
|
|
|
IMO the 2nd version is nicer.
|
|
|