-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Encryption won't help. The problem isn't the user having the
information that's in the URLToken. It's having users (perhaps
inadvertently) giving that info to someone else in the form of a
link. Encrypting the data doesn't make any difference in that case
since it's always going to be decrypted by the server anyways.
Here's a real world example of where passing URLTokens in the URL can
be dangerous:
(Note: We don't use URLTokens in the URL. The reason they were in
the URL in the following case was because CFLOCATION will add the
URLToken by default unless you set addtoken="no")
We have a What's New page on our site that allows our site admins to
paste in a URL to go with the news item. When our admins want to
announce a new section of the site, they find the page in their
browser, copy the URL, and paste it into the What's New form to be
added to the database. Once, one of our admins copied a URL that had
her URLToken in it (from a CFLOCATION call). When users clicked on
that URL, they assumed the admin's CFTOKEN & CFID. CFAS was kind
enough to automatically set a permanent cookie in their browser for
that identity. So from that date forward, every user who had clicked
on that link was using the same CFID & CFTOKEN values.
So what you ask? Whenever our admin logged into the site, ALL OF THE
USERS who had ever clicked on that link automatically assumed all of
her session variables. The net result was that anyone who clicked
that link was able to access the site without logging in AND as an
administrative account. Since sessions only timeout after 20 minutes
of no-activity for that URLToken, the constant site traffic on that
URLToken was enough to keep the session active pretty much all the
time.
It took us quite a while to notice that, and it wasn't fun to clean
up. We had to manually purge our CFTOKENS database store, reboot,
and then go to the admin's house to clear the cookies on all of her
browsers so she got a new URLToken.
We've since gone through the site to make sure every CFLOCATION has
addtoken="no". We've also educated all of our admins so they'll
manually trim the URLToken off before pasting a URL.
So back to your question... If you use the URLToken in the URL, be
aware that any time a user bookmarks the URL, shares it w/ a friend
via cut & paste, etc. you run the risk of inadvertent session
sharing.
Hope that was informative...
Best regards,
Zac Bedell
> -----Original Message-----
> From: Chris Montgomery [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 20, 2000 4:55 PM
> To: Cf-Talk
> Subject: Any Security Concerns Here? Passing Token in URL [CF-Talk]
>
>
> Howdy,
>
> When passing a URLtoken (e.g., #session.URLtoken#) in the URL to
> maintain state on public sites, are there any real security
> concerns? I've seen reference to this in a couple of places, but
> never
> an explicit
> explanation on what the real security implications might be. Would
> encrypting the URLtoken be better?
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOcktPAraVoMWBwRBEQJlLwCcDaiZuKUqk2eyP/ByiOrLEBP2o+YAn3US
FF8nWlDlpRTN7UYBa7kbRf6J
=kR68
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
