|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: http-equiv
excite.comDate: Tue Nov 13 2001 - 14:12:01 CST
On Thu, 8 Nov 2001 11:37:18 -0800, Baron Samedi wrote:
> We have just covered this issue which is pretty wide-spread outside of
.NET
> as part of the OWASP project. http://www.owasp.org It is part of the
primary
> attack components http://www.owasp.org/projects/cov/ look for Privacy
> Violations - Browser cache
> http://www.owasp.org/projects/cov/owasp-pv-bc-1.htm
>
> I am still amazed at the amount of sites that still use GET requests for
> form submission as well leaving the parameters in the browser history!
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.
Unless you have set your browser to clear the temp after each session (not
default), anyone could very well root around the temp.
Ever sniffed around the temp files of a common computer at the business
center of a deluxe hotel. You'd be amazed what's in there.
>
> -----Original Message-----
> From: http-equiv
excite.com [mailto:http-equiv
excite.com]
> Sent: Wednesday, November 07, 2001 10:08 AM
> To: vuln-dev
securityfocus.com
> Subject: .NET Passport: WALLET SERVICE
>
>
> This is a little out of our realm, but it sure looks suspicious:
>
> Microsoft has this so-called .NET initiative. Purpose is unclear at this
> time, but one seemingly nifty feature is the WALLET SERVICE. On the
> surfacethis looks like a good, simple idea and could possibly be boiled
down
> to nothing more than an "auto form filler" or even an extension of the IE
> browser AutoComplete feature which "fills in the blanks".
>
> It seems the idea is that as a passport member you register for the
WALLET
> SERVICE. You input your details including name, address, telephone
number,
> your credit card details including number etc. You then save this and
> continue on your merry way. The idea is that should you happen upon an
> online retailer offering the latest and greatest, you simply "add to the
> basket" that item and select "checkout".
>
> The online retailer as a member or whatever the affiliation with the .NET
> initiative is, has a "PASSPORT EXPRESS PURCHASE" button at the final
> "checkout" phase. What happens is:
>
> you click the "passport express purchase" button, it takes you to the
> PASSPORT login page. You login and there are your details (name, address,
> credit card number etc. etc.). You then select continue, a "transferring
> information" short-time span window is revealed, then magically you
arrive
> at the online retailer's final "checkout" phase, with all your details
> filled in. You review it and press "purchase" and that is it. Purchase
> successful.
>
> What appears suspicious is that out of 15 randomly selected .NET Passport
-
> Directory of Sites participants, 12 of these "checkout" phase pages are
> easily accessible from the browser's temp files with the forms filled in
and
> all details in the clear. Name, address, tel.no., credit number etc. The
> remaining 3 either directly transferred this sensitive information into
> their databases and only left the name and address and order revealed on
the
> html page (and in the cache) or they revealed the credit card number but
hid
> some if not most of the credit card numbers.
>
> It seems that because the final "checkout" phase data is being
automatically
> filled in before it is rendered by the browser, when it is, not only is
the
> entire page cached but so is the sensitive data.
>
> Normally one would navigate to the final "checkout" manually, arrive at
the
> final stage, fill in the forms manually and press send. The data is
> automatically sent and that information is not cached. And if there is an
> error, the page will return with the sensitive data removed and you would
> fill it in again. It looks like the .NET Passport: WALLET SERVICE fills
in
> the sensitive data before it is passed to the browser, so once it
"arrives"
> and is rendered, everything is cached including sensitive data.
>
> Again, this is a little out of our realm. Somebody in this field had
better
> take a very close look at it.
>
> http://www.passport.com/Directory/
>
> The 12 random sites out of 15, ranged from small retailers, to some
> extremely large retailers. Possibly they are not aware of the
> "miss-integration" of this .NET Passport: WALLET SERVICE. Those same
sites,
> if you navigate manually to the "checkout" phase and fill in the
sensitive
> data manually, appear to function normally i.e. the page with the
sensitive
> data is not cached locally.
>
> It definitely does not like right.
>
> Tested with IE6.0. with and without the "do not save encrypted pages to
> disk" enabled.
>
>
> ---
> http://www.malware.com
>
>
>
>
>
>
>
>
>
>
> _______________________________________________________
> Send a cool gift with your E-Card
> http://www.bluemountain.com/giftcenter/
>
>
>
--- http://www.malware.com_______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]