New answers tagged cookies
-1
PHP Cookies are very safe when your site uses HTTPS (the S is for Secured) with a sufficiently complex key in the SSL certificate. PHP instructs your browser's PHPSESSID cookie to contain the file name of the $_SESSION variable. Calling session_start(); loads the file directed to by the browser's PHPSESSID cookie into the $_SESSION variable. Nevertheless, it ...
1
I wonder if this was a not a mistake in the article. They call the stolen cryptographic values "nonces," but a nonce is intended to be used only once and I would not expect them to be stored in an account database because, depending on their use, the value would change many times during an authenticated session.
If I had to guess, what they call a nonce ...
1
TL;DR: If the cookie you use can be used to authorize any action on site B, then that site becomes vulnerable to a CSRF attack.
As @Sjoerd has already pointed out in his comment, you need to set the SameSite attribute of the cookie to None, otherwise the cookie won't be sent to site B when the image is retrieved.
This could very well be a vulnerability, ...
0
For those trying to access a protected resource in CloudFront from a different domain you can not set the cookies cross domain so you're limited to using Signed URLs instead. However you can use javascript on the CloudFront site to use the parameters in the Signed URL to create a Signed Cookie directly in CloudFront. I put together a simple JS script that ...
0
If the openid connect relies on flask's session manager, then the session cookies are predictable.
Flask uses the SECRET_KEY for session management, so if I know you SECRET_KEY, I can make a bogus session cookie and impersonate another user, even the admin user.
https://github.com/pallets/flask/blob/1351d0a56580df36872b466eb245e7634c20dab5/src/flask/...
4
This bypasses the same origin policy, since the base-url is website.com, and script from evil.com is executed in website.com/iframeinjection.
This is not correct. The open redirect vulnerability means that website.com redirects to evil.com. That means that the origin changes. The script is hosted on evil.com, and that is also the origin it will run in. So ...
1
The proposals in this document do not in themselves mitigate the
privacy risks described in Section 7.1 of [RFC6265bis]. Entities who
wish to use cookies to track user activity from cross-site contexts
can continue to do so by setting cookies that declare themselves as
"SameSite=None".
Requiring that explicit declaration, however, ...
Top 50 recent answers are included
