Gdzie byście trzymali token? W localStorage, sessionStorage czy cookies?
0
0
Ja bym NIE trzymał w ciasteczku. Jeśli nie zabezpieczysz go dobrze jest szansa na wykradnięcie takiego tokenu. Nie wiem, jak jest z local i session storage, ale WYDAJE mi się, że jest bezpieczniej. Cookiesy też możesz zabezpieczać np. atrybutem SameSite
4
Ciasteczka są chyba najbardziej bezpieczne. Zgodnie z wytycznymi chyba OWASP, dajesz httpOnly=true (czyli nie da się wczytać ciastka z poziomu JavaScriptu), secure=true (czyli tylko po HTTPsie), wspomniane SameSite, a także domain, path, expiration/age.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
Cookies¶
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:Secure Attribute¶
The Secure cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the Secure cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.
See also: SecureFlag
HttpOnly Attribute¶
The HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. However, if an XSS attack is combined with a CSRF attack, the requests sent to the web application will include the session cookie, as the browser always includes the cookies when sending requests. The HttpOnly cookie only protects the confidentiality of the cookie; the attacker cannot use it offline, outside of the context of an XSS attack.See the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.
See also: HttpOnly
SameSite Attribute¶
SameSite defines a cookie attribute preventing browsers from sending a SameSite flagged cookie with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.See also: SameSite
Domain and Path Attributes¶
The Domain cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The Path cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.It is recommended to use a narrow or restricted scope for these two attributes. In this way, the Domain attribute should not be set (restricting the cookie just to the origin server) and the Path attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
Setting the Domain attribute to a too permissive value, such as example.com allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.