( SzBlackY | 2017. 04. 13., cs - 20:42 )

The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)

Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's
confidentiality. An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details).


8.6 ...

An active network attacker can also inject cookies into the Cookie
header sent to https://example.com/ by impersonating a response from
http://example.com/ and injecting a Set-Cookie header. The HTTPS
server at example.com will be unable to distinguish these cookies
from cookies that it set itself in an HTTPS response. An active
network attacker might be able to leverage this ability to mount an
attack against example.com even if example.com uses HTTPS

Servers can partially mitigate these attacks by encrypting and
signing the contents of their cookies. However, using cryptography
does not mitigate the issue completely because an attacker can replay
a cookie he or she received from the authentic example.com server in
the user's session, with unpredictable results.

(RFC 6265)

Vagyis cseszheted a HTTPS-es belépésed és a secure sütid, ha én a HTTP-re irányuló forgalomba beszúrtam egy session id-t, amit én is ismerek - amint beléptél, van egy session-öm, amin be vagy jelentkezve.

Egyébként a csúnya gonosz fejlesztőék ezt is megbloatosították :(

Starting with Chrome 52 and Firefox 52, insecure sites (http:) can't set cookies with the "secure" directive anymore.


"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)