Tag Info

New answers tagged

0

A token and a session is basically the same thing on a different view. A cookie would be a different thing. As the HTTP protocol is stateless, the server must have a way to maintain the state of the connection. A session (generally) is a file stored on the server, with all the state variables of the client on it. The token is the value send back from the ...


1

A lot depends on what it is your trying to do and what the risks are associated with session hijacking. Generally, if you have a real need to ensure the session is actually owned by the right user, you would add additional checks, such as username and password etc. The EFF has been doing a bit of work on how you can do browser fingerprinting to track ...


1

Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee? I don't think you can provide such a guarantee, except by perhaps saying so in your privacy policy and then following that policy. The scope would be restricted to a one, or a very limited set of URLs, Setting scope can be ...


3

I was planning on user AES256 to ensure the client can't change the value of the cookie. Encryption provides confidentiality, it does not provide authentication. If you do not want users to see a session data value, then you should encrypt then authenticate the value. This prevents a bit flipping attack from changing the value inside of the encrypted ...


2

Encryption alone is not enough because it only provides confidentiality and this task also requires authenticity. If the plaintext in the attacker's cookie contains something like User number 9 is authenticated then the attacker can change bits in the ciphertext that when it is decrypted on the server it will say User number 1 is authenticated and be ...


5

From OWASP: In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based ...


1

I don't think this will provide any benefit. On a secure web application, the less you depend on client data, the better. I can see some issues: This will surely create a vulnerability named Session Fixation: an attacker can create a session, lure your client to a special page, and have the session data on his hands. The server has no means to know if a ...



Top 50 recent answers are included