Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Session security with cookies |
|---|---|
| Date: | Sun, 9 Dec 2007 12:16:43 -0000 |
I don't see what keeping any of the cookie attributes secret buys you. I only see the need to make sure the integrity of the packet is the same, and to authenticate that the data came from the server.
Hiya Aaron, You are absolutely correct; it is all about the integrity of the data. The goal of the exercise is to ensure that the transaction data can not be tampered with. Some data is user defined (i.e. ItemQuantity) and some is not (i.e. ItemPrice etc). If the latter values only ever exist server side, and are then simply displayed to the client, you avoid the tampering problem entirely. In fact, once you look closely, there is no logical requirement to place any data at all in a cookie and pass it between the client and server. Aside from the need to protect its integrity, it is also a performance hog; thousands of extra useless bytes that get shifted between client and server with every request. In the example you have given, most of the inputs into the MAC are available to the user, and the remaining ones are available to the developers/sysadmins. Anyone who has the full set, can roll their own cookies and buy items for whatever they please. KAPOW! BIFF! This particular problem is completely avoided by keeping all the transaction data server side, in a session table. As an aside, the subject of tying sessions to server/client addresses etc has been covered off many times before; it suits some environments, but many apps that try and implement this break in the real world. Many corporates/ISPs use transparent proxy clusters that load balance clients and change the source IP dynamically mid-session. Many Hosting environments use web server clusters, which also have the same issue but at the opposite end. Martin... ------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F -------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Defining scope of web application pentest, Paul Johnston |
|---|---|
| Next by Date: | burp suite v1.1 released, PortSwigger |
| Previous by Thread: | Re: Cryptographically Generated Cookies, Jamie Riden |
| Next by Thread: | Re: Session security with cookies, Eduardo Tongson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |