On Tue, 13 Nov 2001 14:00:13 -0800 (PST), Marc Slemko wrote: > On Tue, 13 Nov 2001, http-equivat_private wrote: > > > Interesting project, and well understood. However, it seems that the problem > > in this case is actually the .NET Passport toy wallet thing. > > > > If you entertain an online purchase, you go "shopping" and "add to basket" > > etc. You would then go to the "checkout". When you arrive at the "checkout", > > you are met with blank forms which you are expected to fill out (name, > > shipping address, credit card info etc.). Obviously at this time, if you > > rooted around the browser temp file and retrieved this page, the forms will > > be blank and nothing sensitive to revealed. You would then fill in the forms > > with the data and fire away. Hopefully, as you indicate, the data would be > > 'POSTED' and that's the end of that. > > > > But > > > > The wallet gimmick automatically fills in the forms with your sensitive > > data, so one you arrive at the "checkout" the forms are filled in, the > > entire filled in page rendered and cached, and if you root around the > > browser temp file and retrieved the page, obbviously the entire page with > > filled in forms are there for all to see. > > No, it isn't fair to say this is a hole with Passport Wallet. The > exact same thing can happen under "normal" circumstances on many > sites if you fill out some of the information on the form incorrectly, > etc. and the server redisplays the form, with filled out information, > and prompts you to correct the incorrect info. > > The real question is why is the browser saving the page to disk. > This likely amounts to an interaction between the cache control > directives that the browser (IE in this case, I guess) listens to > and what the server sends. You also suggested that it happens even > when you select "do not save encrypted pages to disk" in IE; if > so, that would seem to be a bug in IE. > > The point is there are more cases where caching pages to disk can result > in sensitive information being saved than this, and the website/browser > combination needs to deal with them regardless of if Passport Wallet is > in the picture or not. Passport Wallet just makes it a little more > important to deal with it. Noted. But what if all or most of the .NET Passport affiliates have in fact set their shopping cart up correctly i.e. if a submission is made and an error returns you with the forms blank, the fact that the wallet filled in the form prior to submission is a cause for concern. Had the wallet not been involved, nothing sensitive would be cached. A conscientious and experienced site developer or operator has the site setup exactly as how the OWASP project suggests: Pre-Expire pages, no cache etc. all the 'Countermeasures' and anything else required to make it secure, along comes this wallet toy filling out the blank forms before submission or purchase and filling up the browser cache with all your sensitive data. The customer hasn't even submitted the sensitive data to your secure server yet. Perhaps an apt sentence from the OWASP project's 'Countermeasures' section, which, in our view sums it up precisely: "....and only serve up personal data when needed" http://www.owasp.org/projects/cov/owasp-pv-bc-1.htm Nobody needs the forms to be pre-filled for them. --- http://www.malware.com _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
This archive was generated by hypermail 2b30 : Tue Nov 13 2001 - 16:27:05 PST