28 lines
1.4 KiB
Plaintext
28 lines
1.4 KiB
Plaintext
=== on 15 Sep 2015, 21:15:24 Evgeny Mandrikov wrote:
|
|
IMO from an implementation point of view this RSPEC is underspecified, so removing targeting for ``{cpp}`` for now.
|
|
|
|
=== on 12 Nov 2015, 18:00:43 Linda Martin wrote:
|
|
\[~elena.vilchik] It seems that it would be hard to get real issue with this rule because the domain value for cookie is usually set through variables.
|
|
|
|
In JavaScript cookies are set through the document object, as the following:
|
|
|
|
----
|
|
document.cookie="username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/; domain=.com";
|
|
// But might not be that straightforward
|
|
document.cookie="username=" + name + "; expires=" + date + "; domain=" + domains + ";";
|
|
----
|
|
|
|
The return value of an implementation that will detect only the first case is sensitive; and the second case requires a CFG.
|
|
|
|
So I will let you decide wether or not it would be valuable.
|
|
|
|
=== on 2 Dec 2019, 16:08:33 Pierre-Loup Tristant wrote:
|
|
This rule has very little value as it only raise on "single level" cookie (ex: domain=.com). This type of cookie are called https://en.wikipedia.org/wiki/HTTP_cookie#Supercookie[supercookies] and they are denied by all modern web browser.
|
|
|
|
One option could be to make the rule raise on https://portswigger.net/kb/issues/00500300_cookie-scoped-to-parent-domain[cookie scoped to parent domain] (ex: domain=.sonarsource.com) but it would probably be very noisy as this setting is wildly used.
|
|
|
|
Deprecating this rule seams to be the right thing to do.
|
|
|
|
|
|
|