2 ms·

[snip]the client holds all of the information to pick up the transaction where it left off.[/snip] Have you considered the security implications of this? How d

[snip]the client holds all of the information to pick up the transaction where it left off.[/snip] Have you considered the security implications of this? How do you check to see if your transaction data wasn't maliciously modified by the client?

kls 16y ago
The first part of any security is to figure out what truly need to be protected and focus your efforts on securing those points. That being said the vast majority of web apps have a very small surface of information that someone would look to exploit mainly being credit cards and to a lesser extent personal information. But session is not the solution to fixing that problem, it is merely, again curing the symptom; the cure is to build your web application so that it solicits, transmits uses and disposes of credit card information in a single state transfer. Further if you have a sign up where credit info will be stored you should be using a solution that provides you with a proxy of the numbers collected and not the actual number itself. None of this is fixed by session rather session just allows you to design patterns that take jirations to bolt onto HTTP. As for the transaction data being modified by the client, whether you transmit entire state or snippet of state you have the same issue, at some point if the client is comprised they are comprised you can't secure the client you can only assume that all clients are hostile, session does not fix that fact. In the end, with session based auth, web developers post a form over an SSL connection and receive a proxy ID for that session. If someone hijacks that proxy they become that user, in statless auth you POST some auth info over SSL, if someone hijacks the token they become that user. Session does not make a web application more secure. It just helps developers not think through the ramifications of their design choices. Worse yet it gives developers a false sense of security in which they feel that the information is protected by being in session on the server side, when in fact session hijacking is trivial.

kls 16y ago

The first part of any security is to figure out what truly need to be protected and focus your efforts on securing those points. That being said the vast majority of web apps have a very small surface of information that someone would look to exploit mainly being credit cards and to a lesser extent personal information. But session is not the solution to fixing that problem, it is merely, again curing the symptom; the cure is to build your web application so that it solicits, transmits uses and disposes of credit card information in a single state transfer. Further if you have a sign up where credit info will be stored you should be using a solution that provides you with a proxy of the numbers collected and not the actual number itself. None of this is fixed by session rather session just allows you to design patterns that take jirations to bolt onto HTTP. As for the transaction data being modified by the client, whether you transmit entire state or snippet of state you have the same issue, at some point if the client is comprised they are comprised you can't secure the client you can only assume that all clients are hostile, session does not fix that fact. In the end, with session based auth, web developers post a form over an SSL connection and receive a proxy ID for that session. If someone hijacks that proxy they become that user, in statless auth you POST some auth info over SSL, if someone hijacks the token they become that user. Session does not make a web application more secure. It just helps developers not think through the ramifications of their design choices. Worse yet it gives developers a false sense of security in which they feel that the information is protected by being in session on the server side, when in fact session hijacking is trivial.