1. RE: Security
Re not showing info to the customer:
THE GLITCH STRUCK a feature at Victoriassecret.com that allows customers
to check the status of their orders. Before that feature was turned off on
Friday,
the unique number assigned to each customer was revealed in the Web browser’s
address Window. A browser could simply change the customer number, and in
some cases, pull up another customer’s orders.
Officials at Limited Brands Inc., which owns the Victoria’s Secret chain, shut
down the “order status” feature immediately after receiving a description of the
bug from MSNBC.com.
2. RE: Security
- Posted by munchr at mac.com
Nov 29, 2002
At 11:57 AM 29/11/2002 -0600, Kat wrote Regarding Victoria's Secret.
So how then is a web site supposed to tell their customers apart so
they don't mix up orders, information, etc? Seems like there are only
a few choices.
They can use cookies, which seem like the easiest way. But some
users won't accept those, and will be unable to use the web site.
They can use encrypted URL's, which is going to require either
javascript, activex, or some other form of client side processing.
Again, people are going to be locked out of the web site if they
disallow those technologies, or are unable to find a compatible
web browser.
Or, the web site can use standard form posting, which nearly
every browser I have seen is able to do. But by doing so, they
open themselves to very easy attack, because by changing the
clear text form post, anybody can look at anyone else's information.
So either everybody gets to use the web site, and has to put up
with low security, or a significant number of people are locked out
of the web site in the name of security.
Anybody have ideas on how to prevent information leaks like VS's,
without locking out certain browsers, or security conscious people?
3. RE: Security
I'm just going to use cookies. If people don't trust me to put a cookie on
their site, it's really not my problem.
>
> They can use encrypted URL's, which is going to require either
> javascript, activex, or some other form of client side processing.
> Again, people are going to be locked out of the web site if they
> disallow those technologies, or are unable to find a compatible
> web browser.
>
> Or, the web site can use standard form posting, which nearly
> every browser I have seen is able to do. But by doing so, they
> open themselves to very easy attack, because by changing the
> clear text form post, anybody can look at anyone else's information.
>
> So either everybody gets to use the web site, and has to put up
> with low security, or a significant number of people are locked out
> of the web site in the name of security.
>
> Anybody have ideas on how to prevent information leaks like VS's,
> without locking out certain browsers, or security conscious people?
>
>
>
4. RE: Security
> They can use cookies, which seem like the easiest way. But some
> users won't accept those, and will be unable to use the web site.
I'm just going to use cookies. If a person doesn't trust me enough to use a
cookie during their visit to my website, it's not my problem. :)
5. RE: Security
On 29 Nov 2002, at 14:35, munchr at mac.com wrote:
>
> At 11:57 AM 29/11/2002 -0600, Kat wrote Regarding Victoria's Secret.
>
> So how then is a web site supposed to tell their customers apart so
> they don't mix up orders, information, etc? Seems like there are only
> a few choices.
>
> They can use cookies, which seem like the easiest way. But some
> users won't accept those, and will be unable to use the web site.
>
> They can use encrypted URL's, which is going to require either
> javascript, activex, or some other form of client side processing.
> Again, people are going to be locked out of the web site if they
> disallow those technologies, or are unable to find a compatible
> web browser.
>
> Or, the web site can use standard form posting, which nearly
> every browser I have seen is able to do. But by doing so, they
> open themselves to very easy attack, because by changing the
> clear text form post, anybody can look at anyone else's information.
>
> So either everybody gets to use the web site, and has to put up
> with low security, or a significant number of people are locked out
> of the web site in the name of security.
>
> Anybody have ideas on how to prevent information leaks like VS's,
> without locking out certain browsers, or security conscious people?
Yes, use a large enough number base, and a large enough number in that
base. For instance, if i attach the hidden POST form url with this numeral:
"er6yb2RTGWBD6trerBFSf6t78ERThgneRhnwwww456GWTq456BEFGqw4Y
B9nwrfgbwr673n5yUHb35r56b7tynjtr4678EGF67678mnyuy5678" (base58)
,and i link it in my cgi to the ip block the customer came from, and other info
their browser supplied, how many crackers will be able to guess the next
client's numeral? Building these numerals dynamically in serverside includes
is trival, at least if i don't use *nix.
Kat
PS: or did i use base47 with some extra characters? or base90 with some
missing chars?
6. RE: Security
> Yes, use a large enough number base, and a large enough number in that
> base. For instance, if i attach the hidden POST form url with
> this numeral:
> "er6yb2RTGWBD6trerBFSf6t78ERThgneRhnwwww456GWTq456BEFGqw4Y
> B9nwrfgbwr673n5yUHb35r56b7tynjtr4678EGF67678mnyuy5678" (base58)
> ,and i link it in my cgi to the ip block the customer came from,
> and other info
> their browser supplied, how many crackers will be able to guess the next
> client's numeral?
Can you make any link on the page send the query info (in this case, the
really long ID)? You mention POST and I'm guessing that means you have to
have a form...
7. RE: Security
On 30 Nov 2002, at 23:15, C. K. Lester wrote:
>
> > Yes, use a large enough number base, and a large enough number in that
> > base. For instance, if i attach the hidden POST form url with
> > this numeral:
> > "er6yb2RTGWBD6trerBFSf6t78ERThgneRhnwwww456GWTq456BEFGqw4Y
> > B9nwrfgbwr673n5yUHb35r56b7tynjtr4678EGF67678mnyuy5678" (base58)
> > ,and i link it in my cgi to the ip block the customer came from,
> > and other info
> > their browser supplied, how many crackers will be able to guess the next
> > client's numeral?
>
> Can you make any link on the page send the query info (in this case, the
> really long ID)? You mention POST and I'm guessing that means you have to
> have a form...
Without POST, it's like
<a
href="/nextpage.html?tag="er6yb2RTGWBD6trerBFSf6t78ERThgneRhnwwww
456GWTq456BEFGqw4YB9nwrfgbwr673n5yUHb35r56b7tynjtr4678EGF67678
mnyuy5678">Next Page</a>
I haven't tried this,, i'm not terribly serious about it yet. Using POST would
keep it out of the url windows, but i haven't attempted anything yet that
worked. I suspect it's something in *nix or Apache, because i can't get the
POST vars with the cgi program on the server. Orkim's emails are bouncing.
You might try a form, with everything hidden but the button itself.
Kat
