Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17476 > unrolled thread

Ecommerce site - how?

Back to article view | Back to comp.lang.php

Contents

  Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-25 05:42 -0700
    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-25 15:30 +0200
      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-25 16:03 +0200
      Re: Ecommerce site - how? gordonb.y152t@burditt.org (Gordon Burditt) - 2017-06-26 05:43 -0500
        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 17:12 +0200
          Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-26 17:54 +0200
            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:40 +0200
              Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:42 +0200
                Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 23:14 +0200
                  Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-27 00:28 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:48 +0200
                  Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:56 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 12:27 +0200
                      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:15 +0200
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 22:01 +0200
                          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:07 +0200
                  Re: Ecommerce site - how? Gordon Burditt <gordon@hammy.burditt.org> - 2017-06-30 17:08 -0500
          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 18:29 +0200
            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:17 +0200
              Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 13:34 -0400
                Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 20:11 +0200
                  Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:31 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 22:29 +0200
                      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:19 +0200
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 11:24 +0200
                          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:43 +0200
                            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 23:09 +0200
                              Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:12 +0200
                            Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 21:10 -0400
                  Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 16:32 -0400
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:30 +0200
                      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 08:38 -0400
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 17:47 +0200
                          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 12:16 -0400
                            Re: Ecommerce site - how? gordonb.bytf1@burditt.org (Gordon Burditt) - 2017-06-29 18:16 -0500
                              Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-29 20:41 -0400
                                Re: Ecommerce site - how? gordonb.99a3p@burditt.org (Gordon Burditt) - 2017-06-29 23:39 -0500
                                  Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 07:28 -0400
                                    Re: Ecommerce site - how? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-06-30 13:48 +0000
                                    Re: Ecommerce site - how? gordonb.gcghn@burditt.org (Gordon Burditt) - 2017-06-30 16:15 -0500
                                      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 22:35 -0400
                              Re: Ecommerce site - how? Richard Damon <Richard@Damon-Family.org> - 2017-06-29 23:46 -0400
          Re: Ecommerce site - how? gordonb.d2wed@burditt.org (Gordon Burditt) - 2017-06-29 17:32 -0500
    Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-27 10:58 -0700
      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 15:34 -0400
      Re: Ecommerce site - how? gordonb.4psc7@burditt.org (Gordon Burditt) - 2017-06-30 16:55 -0500
        Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-07-01 03:03 -0700
          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:30 -0400
          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:34 -0400

Page 1 of 3  [1] 2 3  Next page →

#17476 — Ecommerce site - how?

I'd like to know how an Ecomm site works. Like, how is a shopping cart built up? When you "add to cart", it has to lay a cookie on your HD right? This is used to identify you on the server, right? What does this cookie look like? eg. what=what inside the cookie file? And then, there'll be a line inside a SQL DB or whatever on the server, containing that value (whatever was inside the cookie), and containing whatever they're shopping - am I right about all this?

Also, how does a site identify you before you sign in? Like, there are plenty sites where you can go there, and start adding to cart without signing up! (obviously a BIG draw of the site!). If it's id'ing you by IP address - what happens if you log off your internet connection, and somebody else logs on, and gets your IP? (assuming you're getting your IPs by DHCP). Will they then get your cart if they go to that site???!! This is NOT very impossible - around here, there are only a few major shopping sites which Everyone goes to - the scenario above COULD be happening!! Is there any way to prevent it? (short of forcing the user to sign in??)


Thanks.

[toc] | [next] | [standalone]

#17477

Bit,

> What does this cookie look like? eg. what=what inside the cookie file?

All that the cookie needs to contain is a unique session number (to both
identify the current connection as well as connect the entries in that
database you mentioned with you).

> Also, how does a site identify you before you sign in?

There is no need to 1) actually sign in* 2) identify _you_ **

*which is only "needed" to track-and-profile you.

** see above :-|

Its only when you want to the goods to be send to you you will need to
provide them *some* kind of identifying data -- otherwise they will have no
clue where to send it to :-) .  Even the payment methoud could be anonymous
(think gift cards).

> If it's id'ing you by IP address - what happens if you log off your
> internet connection, and somebody else logs on, and gets your IP?

Nothing.

The IP *PLUS* the unique value identify the shopper -- and that unique value
gets discarded as soon as you drop the connection (and the PHP session is
terminated).

> Is there any way to prevent it? (short of forcing the user to sign in??)

I suggest you read up on the above mentioned "PHP session".

Regards,
Rudy Wieser


-- Origional message:
<bit-naughty@hotmail.com> schreef in berichtnieuws
d2223e3b-f44c-4ef7-b55a-94e012d85a95@googlegroups.com...
I'd like to know how an Ecomm site works. Like, how is a shopping cart built
up? When you "add to cart", it has to lay a cookie on your HD right? This is
used to identify you on the server, right? What does this cookie look like?
eg. what=what inside the cookie file? And then, there'll be a line inside a
SQL DB or whatever on the server, containing that value (whatever was inside
the cookie), and containing whatever they're shopping - am I right about all
this?

Also, how does a site identify you before you sign in? Like, there are
plenty sites where you can go there, and start adding to cart without
signing up! (obviously a BIG draw of the site!). If it's id'ing you by IP
address - what happens if you log off your internet connection, and somebody
else logs on, and gets your IP? (assuming you're getting your IPs by DHCP).
Will they then get your cart if they go to that site???!! This is NOT very
impossible - around here, there are only a few major shopping sites which
Everyone goes to - the scenario above COULD be happening!! Is there any way
to prevent it? (short of forcing the user to sign in??)


Thanks.

[toc] | [prev] | [next] | [standalone]

#17478

On 06/25/17 15:30, R.Wieser wrote:
> Bit,
> 
>> What does this cookie look like? eg. what=what inside the cookie file?
> 
> All that the cookie needs to contain is a unique session number (to both
> identify the current connection as well as connect the entries in that
> database you mentioned with you).

The session id do not need to be used in database, I don't see much of
point of storing anything in the database until the user decides to pay.


>> If it's id'ing you by IP address - what happens if you log off your
>> internet connection, and somebody else logs on, and gets your IP?

Using IP as an identification is a bad idea, just think of someone using
their mobile phone, those will have a proxy ip number, which means that
quite a lot of users at the same time has the same ip.

As earlier pointed out, a session will be unique, see
http://php.net/manual/en/book.session.php for more information and do
not use setcookie() nor setrawcookie() as in those cases the data is
stored in the browser and the data has to be seen as tampered.


<removed garbage text>


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17479

> Its only when you want to the goods to be send to you you will need to
> provide them *some* kind of identifying data -- otherwise they will have no
> clue where to send it to :-) .  Even the payment methoud could be anonymous
> (think gift cards).
> 
>> If it's id'ing you by IP address - what happens if you log off your
>> internet connection, and somebody else logs on, and gets your IP?
> 
> Nothing.
> 
> The IP *PLUS* the unique value identify the shopper -- and that unique value
> gets discarded as soon as you drop the connection (and the PHP session is
> terminated).

Some shoppers are behind a proxy which may change the outside IP
address for every HTTP transaction.  Thus:  1 main page + 100 images
= 101 differrent IP addresses.  Navigate somewhere and they get a
few more dozen IP addresses.  Anything trying to use the IP address
as part of the identifier won't work (you probably get an empty
cart just after putting something in it, every darn time).  I believe
AOL is one ISP that did this.  Few web sites want to lock out a lot
of customers from buying stuff from their site.

Using the IP only is idiotic.  Using an IP plus the session cookie
locks out a small part of the user base (those behind proxies that
use a changing outside IP address).  Using a session cookie without
the IP works, if nobody can listen in on the conversation (but
that's what https: is for, isn't it?) Logging the IP (along with
the date, time, and TIME ZONE) for security reasons is often good
for criminal investigations after fraud is discovered.  So is keeping
track of the address where you shipped it and the method of payment.

Some shopping carts last a lot longer than one session.  Usually
this requires logging in.  The store gets to track you but they try
to also make the user experience worth more than the tracking is
scary, say by making suggestions in line with your interests.  Amazon
might do this by suggesting, if I just ordered a Green Toyota,
suggest that I buy Blue and Yellow Toyotas to go with them.  Sometimes
they do hit the mark, with, say, related books or suggesting I buy
batteries or accessories to go with what I just ordered recently.

Sometimes a site will allow you to save your shopping cart and get
it back later, without requiring a login.  This might request the
user's email address and a name provided by the user.  It may or
may not check the email address IS an email address.  If you use
such a site, make sure that the list name you give it isn't very
guessable.

On Amazon, for example, I might have something in my shopping cart
for months before accumulating enough items to make it worth an
order.  The shopping cart is tied to my account so the same shopping
cart will appear on my computer, my Kindle, and my cell phone, and
changes made in one appear in the others.  I don't know whether
there is any intra-account privacy, but I doubt it.  Consider a
husband and wife sharing the same account and the same credit card.
Husband might look up (wife's) past orders to get her clothing sizes
for an anniversary present, and just happen to spot her order for
his anniversary present.  Meanwhile, she logs in to check on her
order status, thinking it's the latest order and spots his order,
spoiling the surprise.  I don't think the site knows whose orders
are whose.

Some E-commerce sites allow you to order without setting up an
account (although most will encourage you to do so, and if you do
you won't have to keep re-entering shipping addresses and other
info).  During the ordering process, the session cookie tracks
what's yours vs. someone else.  When you finish ordering, they
encourage you to print the invoice for future reference.  That page
usually contains a link, or an invoice number, or something that
you can use to track your order (possibly by calling Customer Service
as well as using the web site) long after you've dropped the session.
They gave you *something* that can be tied to an entry in their
database.  Maybe it's an invoice number, maybe it's a temporary
customer number.  Whether or not you can you can see someone else's
order by decrementing the invoice number by 1 is a different issue.
If you leave the piece of paper you printed around where your little
brother can find it and type it into a browser, don't expect privacy
from him.

>> Is there any way to prevent it? (short of forcing the user to sign in??)
> 
> I suggest you read up on the above mentioned "PHP session".

> I'd like to know how an Ecomm site works. Like, how is a shopping cart built
> up? When you "add to cart", it has to lay a cookie on your HD right? 

Whether or not the cookie ever hits your HD is debatable, and depends
on how the site is coded.  Cookies may be set to last only for the
session (although those that want to track you will make it last
longer).  It may stay in browser memory during the session and go
away when the browser is closed (without ever hitting the hard disk)
if the session isn't closed earlier.  So, if you lose electrical
power, you probably lose the shopping cart.

If you have to log in, the shopping cart can be attached to your
account, not the session.  Assuming you can remember your login
information, you can get the cart back.

> This is
> used to identify you on the server, right? What does this cookie look like?

There is usually no useful information in a session cookie without
being able to reference the server's database.  It's a bunch of
random bits, often encoded as a big number or a bunch of numbers
and letters.  You won't find your credit score, weight, medical
history, address, phone number, credit card number, or retinal eye
pattern in there, although the session cookie *might* allow someone
access to your account - and depending on what the account is for
(your medical insurance, perhaps?), some of that info might be in
there.  Of particular danger is the guy using the same computer at an
"Internet cafe" after you do, when you forget to close the browser.


> eg. what=what inside the cookie file? 

A bunch of random numbers.  

> And then, there'll be a line inside a
> SQL DB or whatever on the server, containing that value (whatever was inside
> the cookie), and containing whatever they're shopping - am I right about all
> this?

There's a big distinction between what's IN the cookie (even if
encrypted) and what's IN the database on the server.  Remember, the
user himself can tamper with cookies.   He can't tamper with the
session record pointed at by the session cookie, unless the server
code lets him (e.g. he can add and delete things on the list, but
not change prices, not change other people's lists, and not buy
negative quantities of items).

On a VERY poorly coded site, the user can set a cookie for
"is_logged_in" to "yes", and this will fool the site into thinking
he logged in.  You can't do that with session variables unless you
can get the session cookie of an active session.


> Also, how does a site identify you before you sign in? 

Maybe they DON'T.  Maybe they don't even try.  Some sites don't
even let you sign in if they just contain information to be made
public.  But if you complete an order, you will usually need to
fork over (a) a method of payment, and (b) a shipping address.  Gift
cards can provide an anonymous method of payment (although maybe
not from your government), and if you download a digital file
(software, music, video, etc. that you are purchasing) instead of
having them ship it on DVD, you don't need to give them a shipping
address.

How does a (telephone) call center identify you before they ask you
for your account number?  (You may not even have one (yet) - maybe
you want to buy something for the first time.)  He's the customer
calling in on THIS phone line (e.g. line 27).  That's all they need
to talk to the customer.  No, they don't need caller ID either -
although sometimes they use it if the call gets dropped when talking
over weak cell phone signals, and sometimes they match it against
their database to bring up the customer's account quicker, but
they're supposed to verify that this guess is correct before giving
out private information or making changes.

If the telephone call center is giving out information, not taking
orders, they do not necessarily have to get your identification at
all.  Consider, for example, the Internal Revenue Service help line
(in the USA).  They answer questions about tax laws and how to fill
out forms.  They may ask for more detail about your situation
relevant to the tax law and your question.  They don't go looking
at past tax returns.  They don't ask for your name unless they need
to research something and call you back later.  As far as I know,
you can't get yourself audited just by asking stupid questions, but
don't admit crimes anyway.

> Like, there are 
> plenty sites where you can go there, and start adding to cart without 
> signing up! (obviously a BIG draw of the site!). If it's id'ing you by IP 

If it's id'ing you by IP alone, it's going to screw up badly, and
some AOL customers can expect to lose the shopping cart about every
time they click on the page.  This is where session cookies INSTEAD
OF IP come in.

It *IS* possible that someone could capture your session cookie and
try to use it.  In a family situation, your little brother says
"it's my turn to use the computer" and tries to go back to the site
you were looking at.  If you didn't clear the browser cache and
history, he may be able to do that.  If he works for your ISP, snooping
is possible.  Use https:.  


> address - what happens if you log off your internet connection, and somebody 
> else logs on, and gets your IP? (assuming you're getting your IPs by DHCP).

UNIX systems can have multiple users at the same time, and that's
a worse situation:  several, dozens or hundreds of users with the
same IP *AT THE EXACT SAME TIME*.  (TCP connections are uniquely
identified by the 2 endpoint IP addresses and the 2 endpoint part
numbers.  In the case being discussed, only the client port number
is different).  And maybe most of them browsing the same site.
Networks with browser proxies give you an even worse problem: entire
business offices, or entire universities, or possibly even entire
small countries, using *ONE* or a small number of IPs to the outside
world, with possibly hundreds of sessions to Amazon *simultaneously*
on that one IP.  Even a single Windows system can have the same
site open twice on two different tabs.


> Will they then get your cart if they go to that site???!! This is NOT very
> impossible - around here, there are only a few major shopping sites which
> Everyone goes to - the scenario above COULD be happening!! Is there any way
> to prevent it? (short of forcing the user to sign in??)

Let's suppose that the session key is a 64-bit number (and it could
easily be much bigger - the smallest available in PHP seems to be
128 bits).  You have to guess the session key before the user using
it logs out (once the database deletes the record containing the
session key, there's no session info to steal, and the server will
probably ask the user to log in or give them an empty shopping
cart).  Suppose you can make one guess every microsecond (given the
speed of the Internet, especially to residential homes, this is way
optimistic.  The time required to guess half of the session cookies
will be larger than a quarter of a million years.  Are you really
worried about someone finding about about the porn you ordered that
far in the future?  If 128 bits are used, that gives plenty of time
for the dinosaurs to re-evolve and die out many times.

What would be the consequences if someone DID get your cart?  It
doesn't have your name on it.  They got someone's list and they
don't know whose.  And what would they do with that info?  It might
be annoying if someone added something to it and you didn't notice,
or ordered and thereby cleared the list.  I'd worry a lot more about
them getting my credit card number.

[toc] | [prev] | [next] | [standalone]

#17480

Gordon,

> Some shoppers are behind a proxy which may change the
> outside IP address for every HTTP transaction. Thus:  1 main
> page + 100 images = 101 differrent IP addresses.

Thats no problem at all, as long as the IP from which the webpages are
requested does not change.

Provided that the e-commerce website does not have some kind of
anti-leeching active ofcourse (disallowing requests for additional content
(like product images) not present on the webpage thats currently viewed).

> Using an IP plus the session cookie locks out a small part of
> the user base (those behind proxies that use a changing outside
> IP address)

I think you misunderstood when those IPs do actually change ...

> Some shopping carts last a lot longer than one session.  Usually
> this requires logging in

With your described multiple different IPs within (something which the user
percieves as) a single session that won't work either.

TL;DR:
You have brought up a problem (which I think does not exist, because you
most likely misunderstood what happens), but have not spend a single letter
at trying to decribe a known or possible solution for it. :-(

Regards,
Rudy Wieser

P.s.
I'm not the OP :-)


-- Origional message:
Gordon Burditt <gordonb.y152t@burditt.org> schreef in berichtnieuws
PcqdnRTWK6vXeM3EnZ2dnUU7-X3NnZ2d@posted.internetamerica...
> > Its only when you want to the goods to be send to you you will need to
> > provide them *some* kind of identifying data -- otherwise they will have
no
> > clue where to send it to :-) .  Even the payment methoud could be
anonymous
> > (think gift cards).
> >
> >> If it's id'ing you by IP address - what happens if you log off your
> >> internet connection, and somebody else logs on, and gets your IP?
> >
> > Nothing.
> >
> > The IP *PLUS* the unique value identify the shopper -- and that unique
value
> > gets discarded as soon as you drop the connection (and the PHP session
is
> > terminated).
>
> Some shoppers are behind a proxy which may change the outside IP
> address for every HTTP transaction.  Thus:  1 main page + 100 images
> = 101 differrent IP addresses.  Navigate somewhere and they get a
> few more dozen IP addresses.  Anything trying to use the IP address
> as part of the identifier won't work (you probably get an empty
> cart just after putting something in it, every darn time).  I believe
> AOL is one ISP that did this.  Few web sites want to lock out a lot
> of customers from buying stuff from their site.
>
> Using the IP only is idiotic.  Using an IP plus the session cookie
> locks out a small part of the user base (those behind proxies that
> use a changing outside IP address).  Using a session cookie without
> the IP works, if nobody can listen in on the conversation (but
> that's what https: is for, isn't it?) Logging the IP (along with
> the date, time, and TIME ZONE) for security reasons is often good
> for criminal investigations after fraud is discovered.  So is keeping
> track of the address where you shipped it and the method of payment.
>
> Some shopping carts last a lot longer than one session.  Usually
> this requires logging in.  The store gets to track you but they try
> to also make the user experience worth more than the tracking is
> scary, say by making suggestions in line with your interests.  Amazon
> might do this by suggesting, if I just ordered a Green Toyota,
> suggest that I buy Blue and Yellow Toyotas to go with them.  Sometimes
> they do hit the mark, with, say, related books or suggesting I buy
> batteries or accessories to go with what I just ordered recently.
>
> Sometimes a site will allow you to save your shopping cart and get
> it back later, without requiring a login.  This might request the
> user's email address and a name provided by the user.  It may or
> may not check the email address IS an email address.  If you use
> such a site, make sure that the list name you give it isn't very
> guessable.
>
> On Amazon, for example, I might have something in my shopping cart
> for months before accumulating enough items to make it worth an
> order.  The shopping cart is tied to my account so the same shopping
> cart will appear on my computer, my Kindle, and my cell phone, and
> changes made in one appear in the others.  I don't know whether
> there is any intra-account privacy, but I doubt it.  Consider a
> husband and wife sharing the same account and the same credit card.
> Husband might look up (wife's) past orders to get her clothing sizes
> for an anniversary present, and just happen to spot her order for
> his anniversary present.  Meanwhile, she logs in to check on her
> order status, thinking it's the latest order and spots his order,
> spoiling the surprise.  I don't think the site knows whose orders
> are whose.
>
> Some E-commerce sites allow you to order without setting up an
> account (although most will encourage you to do so, and if you do
> you won't have to keep re-entering shipping addresses and other
> info).  During the ordering process, the session cookie tracks
> what's yours vs. someone else.  When you finish ordering, they
> encourage you to print the invoice for future reference.  That page
> usually contains a link, or an invoice number, or something that
> you can use to track your order (possibly by calling Customer Service
> as well as using the web site) long after you've dropped the session.
> They gave you *something* that can be tied to an entry in their
> database.  Maybe it's an invoice number, maybe it's a temporary
> customer number.  Whether or not you can you can see someone else's
> order by decrementing the invoice number by 1 is a different issue.
> If you leave the piece of paper you printed around where your little
> brother can find it and type it into a browser, don't expect privacy
> from him.
>
> >> Is there any way to prevent it? (short of forcing the user to sign
in??)
> >
> > I suggest you read up on the above mentioned "PHP session".
>
> > I'd like to know how an Ecomm site works. Like, how is a shopping cart
built
> > up? When you "add to cart", it has to lay a cookie on your HD right?
>
> Whether or not the cookie ever hits your HD is debatable, and depends
> on how the site is coded.  Cookies may be set to last only for the
> session (although those that want to track you will make it last
> longer).  It may stay in browser memory during the session and go
> away when the browser is closed (without ever hitting the hard disk)
> if the session isn't closed earlier.  So, if you lose electrical
> power, you probably lose the shopping cart.
>
> If you have to log in, the shopping cart can be attached to your
> account, not the session.  Assuming you can remember your login
> information, you can get the cart back.
>
> > This is
> > used to identify you on the server, right? What does this cookie look
like?
>
> There is usually no useful information in a session cookie without
> being able to reference the server's database.  It's a bunch of
> random bits, often encoded as a big number or a bunch of numbers
> and letters.  You won't find your credit score, weight, medical
> history, address, phone number, credit card number, or retinal eye
> pattern in there, although the session cookie *might* allow someone
> access to your account - and depending on what the account is for
> (your medical insurance, perhaps?), some of that info might be in
> there.  Of particular danger is the guy using the same computer at an
> "Internet cafe" after you do, when you forget to close the browser.
>
>
> > eg. what=what inside the cookie file?
>
> A bunch of random numbers.
>
> > And then, there'll be a line inside a
> > SQL DB or whatever on the server, containing that value (whatever was
inside
> > the cookie), and containing whatever they're shopping - am I right about
all
> > this?
>
> There's a big distinction between what's IN the cookie (even if
> encrypted) and what's IN the database on the server.  Remember, the
> user himself can tamper with cookies.   He can't tamper with the
> session record pointed at by the session cookie, unless the server
> code lets him (e.g. he can add and delete things on the list, but
> not change prices, not change other people's lists, and not buy
> negative quantities of items).
>
> On a VERY poorly coded site, the user can set a cookie for
> "is_logged_in" to "yes", and this will fool the site into thinking
> he logged in.  You can't do that with session variables unless you
> can get the session cookie of an active session.
>
>
> > Also, how does a site identify you before you sign in?
>
> Maybe they DON'T.  Maybe they don't even try.  Some sites don't
> even let you sign in if they just contain information to be made
> public.  But if you complete an order, you will usually need to
> fork over (a) a method of payment, and (b) a shipping address.  Gift
> cards can provide an anonymous method of payment (although maybe
> not from your government), and if you download a digital file
> (software, music, video, etc. that you are purchasing) instead of
> having them ship it on DVD, you don't need to give them a shipping
> address.
>
> How does a (telephone) call center identify you before they ask you
> for your account number?  (You may not even have one (yet) - maybe
> you want to buy something for the first time.)  He's the customer
> calling in on THIS phone line (e.g. line 27).  That's all they need
> to talk to the customer.  No, they don't need caller ID either -
> although sometimes they use it if the call gets dropped when talking
> over weak cell phone signals, and sometimes they match it against
> their database to bring up the customer's account quicker, but
> they're supposed to verify that this guess is correct before giving
> out private information or making changes.
>
> If the telephone call center is giving out information, not taking
> orders, they do not necessarily have to get your identification at
> all.  Consider, for example, the Internal Revenue Service help line
> (in the USA).  They answer questions about tax laws and how to fill
> out forms.  They may ask for more detail about your situation
> relevant to the tax law and your question.  They don't go looking
> at past tax returns.  They don't ask for your name unless they need
> to research something and call you back later.  As far as I know,
> you can't get yourself audited just by asking stupid questions, but
> don't admit crimes anyway.
>
> > Like, there are
> > plenty sites where you can go there, and start adding to cart without
> > signing up! (obviously a BIG draw of the site!). If it's id'ing you by
IP
>
> If it's id'ing you by IP alone, it's going to screw up badly, and
> some AOL customers can expect to lose the shopping cart about every
> time they click on the page.  This is where session cookies INSTEAD
> OF IP come in.
>
> It *IS* possible that someone could capture your session cookie and
> try to use it.  In a family situation, your little brother says
> "it's my turn to use the computer" and tries to go back to the site
> you were looking at.  If you didn't clear the browser cache and
> history, he may be able to do that.  If he works for your ISP, snooping
> is possible.  Use https:.
>
>
> > address - what happens if you log off your internet connection, and
somebody
> > else logs on, and gets your IP? (assuming you're getting your IPs by
DHCP).
>
> UNIX systems can have multiple users at the same time, and that's
> a worse situation:  several, dozens or hundreds of users with the
> same IP *AT THE EXACT SAME TIME*.  (TCP connections are uniquely
> identified by the 2 endpoint IP addresses and the 2 endpoint part
> numbers.  In the case being discussed, only the client port number
> is different).  And maybe most of them browsing the same site.
> Networks with browser proxies give you an even worse problem: entire
> business offices, or entire universities, or possibly even entire
> small countries, using *ONE* or a small number of IPs to the outside
> world, with possibly hundreds of sessions to Amazon *simultaneously*
> on that one IP.  Even a single Windows system can have the same
> site open twice on two different tabs.
>
>
> > Will they then get your cart if they go to that site???!! This is NOT
very
> > impossible - around here, there are only a few major shopping sites
which
> > Everyone goes to - the scenario above COULD be happening!! Is there any
way
> > to prevent it? (short of forcing the user to sign in??)
>
> Let's suppose that the session key is a 64-bit number (and it could
> easily be much bigger - the smallest available in PHP seems to be
> 128 bits).  You have to guess the session key before the user using
> it logs out (once the database deletes the record containing the
> session key, there's no session info to steal, and the server will
> probably ask the user to log in or give them an empty shopping
> cart).  Suppose you can make one guess every microsecond (given the
> speed of the Internet, especially to residential homes, this is way
> optimistic.  The time required to guess half of the session cookies
> will be larger than a quarter of a million years.  Are you really
> worried about someone finding about about the porn you ordered that
> far in the future?  If 128 bits are used, that gives plenty of time
> for the dinosaurs to re-evolve and die out many times.
>
> What would be the consequences if someone DID get your cart?  It
> doesn't have your name on it.  They got someone's list and they
> don't know whose.  And what would they do with that info?  It might
> be annoying if someone added something to it and you didn't notice,
> or ordered and thereby cleared the list.  I'd worry a lot more about
> them getting my credit card number.
>
>

[toc] | [prev] | [next] | [standalone]

#17481

On 26.06.2017 at 17:12, R.Wieser wrote:

>> Some shoppers are behind a proxy which may change the
>> outside IP address for every HTTP transaction. Thus:  1 main
>> page + 100 images = 101 differrent IP addresses.
> 
> Thats no problem at all, as long as the IP from which the webpages are
> requested does not change.
> 
> Provided that the e-commerce website does not have some kind of
> anti-leeching active ofcourse (disallowing requests for additional content
> (like product images) not present on the webpage thats currently viewed).
> 
>> Using an IP plus the session cookie locks out a small part of
>> the user base (those behind proxies that use a changing outside
>> IP address)
> 
> I think you misunderstood when those IPs do actually change ...
> 
>> Some shopping carts last a lot longer than one session.  Usually
>> this requires logging in
> 
> With your described multiple different IPs within (something which the user
> percieves as) a single session that won't work either.
> 
> TL;DR:
> You have brought up a problem (which I think does not exist, because you
> most likely misunderstood what happens), but have not spend a single letter
> at trying to decribe a known or possible solution for it. :-(

Of course, there are problems if you try to identify the user of an
e-commerce site by IP.  And yes, using a PHP session instead is usually
the appropriate solution.  *Extremly* simplified:

  function addToCart($product)
  {
      if (session_id() === '') session_start();
      $_SESSION['products'][] = $product;
  }

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17485

Christoph,

>And yes, using a PHP session instead is usually the appropriate
> solution.  *Extremly* simplified:

*Over* simplified I'm afraid.   What you put down there (remembering the IDs
of the selected products) can be done by using cookies.

... which would, in this simplified case, even be preferrable, as than the
user can stop, and restart shopping (even days later) whenever they want
(which is not possible using a basic PHP session).

The idea is to, when the PHP session is created, store the clients IP and
check it with the stored one on subsequent usages*.   While it certainly is
possible to (even without attempting to do so) hijack an IP, sending the
correct session-ID with it is a whole other ballgame.  Especially when done
over SSL.

*I just realized thats its quite a long time ago that I learned that
"trick", its rather possible later PHP version do this standard.  Are they ?

Regards,
Rudy Wieser


-- Origional message:
Christoph M. Becker <cmbecker69@arcor.de> schreef in berichtnieuws
oirani$2jp$1@solani.org...
> On 26.06.2017 at 17:12, R.Wieser wrote:
>
> >> Some shoppers are behind a proxy which may change the
> >> outside IP address for every HTTP transaction. Thus:  1 main
> >> page + 100 images = 101 differrent IP addresses.
> >
> > Thats no problem at all, as long as the IP from which the webpages are
> > requested does not change.
> >
> > Provided that the e-commerce website does not have some kind of
> > anti-leeching active ofcourse (disallowing requests for additional
content
> > (like product images) not present on the webpage thats currently
viewed).
> >
> >> Using an IP plus the session cookie locks out a small part of
> >> the user base (those behind proxies that use a changing outside
> >> IP address)
> >
> > I think you misunderstood when those IPs do actually change ...
> >
> >> Some shopping carts last a lot longer than one session.  Usually
> >> this requires logging in
> >
> > With your described multiple different IPs within (something which the
user
> > percieves as) a single session that won't work either.
> >
> > TL;DR:
> > You have brought up a problem (which I think does not exist, because you
> > most likely misunderstood what happens), but have not spend a single
letter
> > at trying to decribe a known or possible solution for it. :-(
>
> Of course, there are problems if you try to identify the user of an
> e-commerce site by IP.  And yes, using a PHP session instead is usually
> the appropriate solution.  *Extremly* simplified:
>
>   function addToCart($product)
>   {
>       if (session_id() === '') session_start();
>       $_SESSION['products'][] = $product;
>   }
>
> --
> Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17488

On 06/26/17 19:40, R.Wieser wrote:
> Christoph,
> 
>> And yes, using a PHP session instead is usually the appropriate
>> solution.  *Extremly* simplified:
> 
> *Over* simplified I'm afraid.   What you put down there (remembering the IDs
> of the selected products) can be done by using cookies.

Which would be possible to tamper and give another attack vector on the
site. And can cause some browser to get issues if the data amount is too
big as when you are ordering many different things at the same time.


> ... which would, in this simplified case, even be preferrable, as than the
> user can stop, and restart shopping (even days later) whenever they want
> (which is not possible using a basic PHP session).

Session cookie can have a long lifespan too, so the user could come back
and continue with what is stored in the session.


> The idea is to, when the PHP session is created, store the clients IP and
> check it with the stored one on subsequent usages*. 

And this can just lead to issues which we already pointed out. This is a
technique used in the early days of internet but didn't work out too
well and didn't give any extra security.


> While it certainly is
> possible to (even without attempting to do so) hijack an IP, sending the
> correct session-ID with it is a whole other ballgame.  Especially when done
> over SSL.

There are other methods which are more used nowadays, when the request
will come from the users browser, but a request orchestrated by a third
party, far less work than spoofing IP which ain't too difficult.

If you are interested in learning take a look at OWASP.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17491

J.O.

> Which would be possible to tamper ...

Absolutily.

Just one question: how would he person who is shopping at the moment benefit
from altering the article codes of the products he has selected himself ?

> ... and give another attack vector

Pray tell, I'm rather interrested in hearing how changing product-id "X"
into "Y" can be exploited.

> Session cookie can have a long lifespan too, so the user could come
> back and continue with what is stored in the session.

Depending on what you mean with "sesssion cookie" here I can agree, but as
easily disagree with you.

As you have complained about how easy it would be to "attack" data stored in
a cookie I'm going to assume hat you ment a "session cookie" as in a cookie
which holds nothing more than a session-ID (correct me if I'm wrong)..

Yes, both a cookie and thus the a session ID stored in it can live for the
longest time (depending on the lifetime the website has defined for the
cookie-data ofcourse -- which, for a shopping cart of an e-commerce site,
will be rather short), but the PHP session its referring to will be
destroyed shortly after you leave the server, making that stored ID rather
worthless.

And although resuming a *shopping* session will be possible, it certainly
will not be done by using that session-ID.  hint: logging in.

> And this can just lead to issues which we already pointed out.

You guys did ?    I must have missed it somehow, I wonder how ...  /s

So, quotes and/or links, or it didn't happen.  And by the way, If you come
up with stuff I already responded to you definitily loose the game. :-)

> There are other methods which are more used nowadays, when the
> request will come from the users browser, but a request orchestrated
> by a third party, far less work than spoofing IP which ain't too
difficult.

Vagueness all around I'm afraid.  I can go in quite a number of directions
with that, which is definitily *not* a good starting point (read: I'm not
prepared to waste my time with guessing which of those directions you might
mean/be going).

> If you are interested in learning take a look at OWASP.

Nope, not interrested in learning.  No sirree, not at all! /s

I just took a quick look at that site (www.owasp.org).   The first thing I
noticed was iframes and JS, both to external sites.   For a fricking
*security* minded site.  Don't make me laugh please.  Idiots.

Regards,
Rudy Wieser




J.O. Aho <user@example.net> schreef in berichtnieuws
erd6dvFhfi0U1@mid.individual.net...
> On 06/26/17 19:40, R.Wieser wrote:
> > Christoph,
> >
> >> And yes, using a PHP session instead is usually the appropriate
> >> solution.  *Extremly* simplified:
> >
> > *Over* simplified I'm afraid.   What you put down there (remembering the
IDs
> > of the selected products) can be done by using cookies.
>
> Which would be possible to tamper and give another attack vector on the
> site. And can cause some browser to get issues if the data amount is too
> big as when you are ordering many different things at the same time.
>
> > ... which would, in this simplified case, even be preferrable, as than
the
> > user can stop, and restart shopping (even days later) whenever they want
> > (which is not possible using a basic PHP session).
>
> Session cookie can have a long lifespan too, so the user could come back
> and continue with what is stored in the session.
>
> > The idea is to, when the PHP session is created, store the clients IP
and
> > check it with the stored one on subsequent usages*.
>
> And this can just lead to issues which we already pointed out. This is a
> technique used in the early days of internet but didn't work out too
> well and didn't give any extra security.
>
> > While it certainly is
> > possible to (even without attempting to do so) hijack an IP, sending the
> > correct session-ID with it is a whole other ballgame.  Especially when
done
> > over SSL.
>
> There are other methods which are more used nowadays, when the request
> will come from the users browser, but a request orchestrated by a third
> party, far less work than spoofing IP which ain't too difficult.
>
> If you are interested in learning take a look at OWASP.
>
> --
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17492

On 26.06.2017 at 23:14, R.Wieser wrote:

> Yes, both a cookie and thus the a session ID stored in it can live for the
> longest time (depending on the lifetime the website has defined for the
> cookie-data ofcourse -- which, for a shopping cart of an e-commerce site,
> will be rather short), but the PHP session its referring to will be
> destroyed shortly after you leave the server, making that stored ID rather
> worthless.

Consider to read up on session.cookie_lifetime
(<http://php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime>).

>> If you are interested in learning take a look at OWASP.
> 
> Nope, not interrested in learning.  No sirree, not at all! /s
> 
> I just took a quick look at that site (www.owasp.org).   The first thing I
> noticed was iframes and JS, both to external sites.   For a fricking
> *security* minded site.  Don't make me laugh please.  Idiots.

Consider to take a second stab at it – for your and your readers sake.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17496

Christoph,

> Consider to read up on session.cookie_lifetime
>
(<http://php.net/manual/en/session.configuration.php#ini.session.cookie-life
time>).

I did you one better: I double-checked my knowledge of it by taking a peek
at the RFC for it. :-)

> Consider to take a second stab at it - for your and your readers sake.

Nope.   First off, I have a considerable problem with dealing with "do as I
say, not as I do" people/environments. Secondly, I am definitily not willing
to go on a wild goosehunt to figure out which part could/would be applicable
(to the problem at hand or otherwise) (the CSRF attack mitigation promently
displayed on their front page definitily isn't).  So, either I get a "this
is what I'm talking about" reference, or its a no-go (also, I have no use
for it -- which makes it even less interresting). Sorry.

Regards,
Rudy Wieser


-- Origional message:
Christoph M. Becker <cmbecker69@arcor.de> schreef in berichtnieuws
ois1r3$jv8$1@solani.org...
> On 26.06.2017 at 23:14, R.Wieser wrote:
>
> > Yes, both a cookie and thus the a session ID stored in it can live for
the
> > longest time (depending on the lifetime the website has defined for the
> > cookie-data ofcourse -- which, for a shopping cart of an e-commerce
site,
> > will be rather short), but the PHP session its referring to will be
> > destroyed shortly after you leave the server, making that stored ID
rather
> > worthless.
>
> Consider to read up on session.cookie_lifetime
>
(<http://php.net/manual/en/session.configuration.php#ini.session.cookie-life
time>).
>
> >> If you are interested in learning take a look at OWASP.
> >
> > Nope, not interrested in learning.  No sirree, not at all! /s
> >
> > I just took a quick look at that site (www.owasp.org).   The first thing
I
> > noticed was iframes and JS, both to external sites.   For a fricking
> > *security* minded site.  Don't make me laugh please.  Idiots.
>
> Consider to take a second stab at it - for your and your readers sake.
>
> --
> Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17494

On 06/26/17 23:14, R.Wieser wrote:
> J.O.
> 
>> Which would be possible to tamper ...
> 
> Absolutily.
> 
> Just one question: how would he person who is shopping at the moment benefit
> from altering the article codes of the products he has selected himself ?

it don't have to benefit the shopper, it can benefit a third party.

>> ... and give another attack vector
> 
> Pray tell, I'm rather interrested in hearing how changing product-id "X"
> into "Y" can be exploited.

Thought of sending more than just product id, the code that is on the
e-commerce site may have a flaw which makes it possible to send a value
not usually stored in the cookie to make the site to do something else,
for example "admin=true" and the user may suddenly be the administrator
of the whole site.


>> Session cookie can have a long lifespan too, so the user could come
>> back and continue with what is stored in the session.
> 
> Depending on what you mean with "sesssion cookie" here I can agree, but as
> easily disagree with you.
> 
> As you have complained about how easy it would be to "attack" data stored in
> a cookie I'm going to assume hat you ment a "session cookie" as in a cookie
> which holds nothing more than a session-ID (correct me if I'm wrong)..
> 
> Yes, both a cookie and thus the a session ID stored in it can live for the
> longest time (depending on the lifetime the website has defined for the
> cookie-data ofcourse -- which, for a shopping cart of an e-commerce site,
> will be rather short), but the PHP session its referring to will be
> destroyed shortly after you leave the server, making that stored ID rather
> worthless.

The session cookie do not automatically get "destroyed" just for you
leave a site, it live the set life span it has, some sites uses a short
life span and other a long. Depending on your browser settings, you can
let the cookie survive a close down of the browser.


> And although resuming a *shopping* session will be possible, it certainly
> will not be done by using that session-ID.  hint: logging in.

Hint: no login needed as long as you visit the site before the session
cookie expires.



>> If you are interested in learning take a look at OWASP.
> 
> Nope, not interrested in learning.  No sirree, not at all! /s
> 
> I just took a quick look at that site (www.owasp.org).   The first thing I
> noticed was iframes and JS, both to external sites.   For a fricking
> *security* minded site.  Don't make me laugh please.  Idiots.

JavaScript and iframes don't automatically make a page insecure, if you
do follow the guidelines at OWASP then your page will has less risks of
normal vulnerabilities, no matte how your site is generated.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17497

J.O.

> it don't have to benefit the shopper, it can benefit a third party.

As I already said, how ?

> Thought of sending more than just product id, the code that is on
> the e-commerce site may have a flaw which makes it possible to
> send a value not usually stored in the cookie to make the site to do
> something else,

Ah, the "lets not answer the question, but trum up some other problems"
method.  Nope, rejected.   Explain how changing the product IDs in such a
cookie benefits anyone, or admit defeat (in this regard).

After that I'm open to hearing about which other kinds of data you also want
to shuttle around in cookies, and how that could be exploited (to which my
answer would most likely be to not send those to the user, but use a PHP
session and store them in there. :-) )

> The session cookie do not automatically get "destroyed" just for you
> leave a site, it live the set life span it has, some sites uses a short
> life span and other a long.

Gee... Do I hear an echo ?   Yes, it must be, as that is exactly what I
explained in my previous message. :-)

Read that part again bub, and than you can maybe acknowledge that having a
cookie with a session ID on *your* computer does not mean that the PHP
session will still be available on *their* computer (but its good enough to
track you :-) )

> Hint: no login needed as long as you visit the site before the
> session cookie expires.

Wrong.  See above.

And you're funny: you already told me that the contents of a cookie are easy
to alter (even by a third party), but you *still* think its a good idea to
accept it to authenticate you when you reconnect (with a different IP...) to
the site.   Make up you mind bub, either the cookie contents are secure, or
they aren't.  You can't have it both ways.

> JavaScript and iframes don't automatically make a page insecure,

True.  Its just the 90% of all other cases which could cause a problem. :-)

> if you do follow the guidelines at OWASP then your page will has less
> risks of normal vulnerabilities

"less risk" and "normal vunerabilities".  You really sound like some (scum)
marketoid there, selling snake oil.  :-(

Regards,
Rudy Wieser


-- Origional message:
J.O. Aho <user@example.net> schreef in berichtnieuws
eread9FnlrfU1@mid.individual.net...
> On 06/26/17 23:14, R.Wieser wrote:
> > J.O.
> >
> >> Which would be possible to tamper ...
> >
> > Absolutily.
> >
> > Just one question: how would he person who is shopping at the moment
benefit
> > from altering the article codes of the products he has selected himself
?
>
> it don't have to benefit the shopper, it can benefit a third party.
>
> >> ... and give another attack vector
> >
> > Pray tell, I'm rather interrested in hearing how changing product-id "X"
> > into "Y" can be exploited.
>
> Thought of sending more than just product id, the code that is on the
> e-commerce site may have a flaw which makes it possible to send a value
> not usually stored in the cookie to make the site to do something else,
> for example "admin=true" and the user may suddenly be the administrator
> of the whole site.
>
>
> >> Session cookie can have a long lifespan too, so the user could come
> >> back and continue with what is stored in the session.
> >
> > Depending on what you mean with "sesssion cookie" here I can agree, but
as
> > easily disagree with you.
> >
> > As you have complained about how easy it would be to "attack" data
stored in
> > a cookie I'm going to assume hat you ment a "session cookie" as in a
cookie
> > which holds nothing more than a session-ID (correct me if I'm wrong)..
> >
> > Yes, both a cookie and thus the a session ID stored in it can live for
the
> > longest time (depending on the lifetime the website has defined for the
> > cookie-data ofcourse -- which, for a shopping cart of an e-commerce
site,
> > will be rather short), but the PHP session its referring to will be
> > destroyed shortly after you leave the server, making that stored ID
rather
> > worthless.
>
> The session cookie do not automatically get "destroyed" just for you
> leave a site, it live the set life span it has, some sites uses a short
> life span and other a long. Depending on your browser settings, you can
> let the cookie survive a close down of the browser.
>
> > And although resuming a *shopping* session will be possible, it
certainly
> > will not be done by using that session-ID.  hint: logging in.
>
> Hint: no login needed as long as you visit the site before the session
> cookie expires.
>
> >> If you are interested in learning take a look at OWASP.
> >
> > Nope, not interrested in learning.  No sirree, not at all! /s
> >
> > I just took a quick look at that site (www.owasp.org).   The first thing
I
> > noticed was iframes and JS, both to external sites.   For a fricking
> > *security* minded site.  Don't make me laugh please.  Idiots.
>
> JavaScript and iframes don't automatically make a page insecure, if you
> do follow the guidelines at OWASP then your page will has less risks of
> normal vulnerabilities, no matte how your site is generated.
>
> --
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17502

On 06/27/17 12:27, R.Wieser wrote:
> J.O.
> 
>> it don't have to benefit the shopper, it can benefit a third party.
> 
> As I already said, how ?

Selective reading don't give the answer, I know you like to ignore
things that contradicts your world.

>> Thought of sending more than just product id, the code that is on
>> the e-commerce site may have a flaw which makes it possible to
>> send a value not usually stored in the cookie to make the site to do
>> something else,
> 
> Ah, the "lets not answer the question, but trum up some other problems"
> method.  Nope, rejected.   Explain how changing the product IDs in such a
> cookie benefits anyone, or admit defeat (in this regard).
> 
> After that I'm open to hearing about which other kinds of data you also want
> to shuttle around in cookies, and how that could be exploited (to which my
> answer would most likely be to not send those to the user, but use a PHP
> session and store them in there. :-) )
> 
>> The session cookie do not automatically get "destroyed" just for you
>> leave a site, it live the set life span it has, some sites uses a short
>> life span and other a long.
> 
> Gee... Do I hear an echo ?   Yes, it must be, as that is exactly what I
> explained in my previous message. :-)

Not at all, you wrote:

"but the PHP session its referring to will be
destroyed shortly after you leave the server, making that stored ID
rather worthless."

which is just bs.


> And you're funny: you already told me that the contents of a cookie are easy
> to alter (even by a third party), but you *still* think its a good idea to
> accept it to authenticate you when you reconnect (with a different IP...) to
> the site.   Make up you mind bub, either the cookie contents are secure, or
> they aren't.  You can't have it both ways.

For example tracking IP will not protect you against CSRF, it may
protect against session cookie hijacking, but there are more modern
methods to counter that.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17506

J.O.

> Selective reading don't give the answer,

And your selective answering is anything better ?

> I know you like to ignore things that contradicts your world.

How many direct questions and remarks you have found wise to ignore do you
want me to show you ?

Or in other words, you're nothing more than the pot which calls the kettle
black. :-D

> > Gee... Do I hear an echo ?   Yes, it must be, as that is exactly what I
> > explained in my previous message. :-)
>
> Not at all, you wrote:
>
> "but the PHP session its referring to will be
> destroyed shortly after you leave the server, making that stored ID
> rather worthless."
>
> which is just bs.

And you said "some sites uses a short life span and other a long.".  Explain
to me how thats different from "will be destroyed shortly after you leave
the server".    Are you trying to bitch about an ammount of time that you
do, *cannot* know shit about ?  Really ?

And mark my word, you will refuse to respond to this too -- although now
I've said you would you cannot do other than to prove me wrong.   Which is
ofcourse exactly the result I want.  Or is it ? :-D

> it may protect against session cookie hijacking

As I have already mentioned earlier (but you deemed it opportune to ignore
it at that time): I highly doubt it, as both the cookie and the CSRF
"secretly stored as part of a form element" data are send at the same time,
in the same request (just at different locations, one in the header, one as
part of the URI or trailing post-data).  What would stop anyone from
capturing and using them ?    Care to explain ?   If you can that is ..

And no, I do not expect you will even *try*.   Not anymore.

Regards,
Rudy Wieser


-- Origional message:
J.O. Aho <user@example.net> schreef in berichtnieuws
erfi4sFq2sU1@mid.individual.net...
> On 06/27/17 12:27, R.Wieser wrote:
> > J.O.
> >
> >> it don't have to benefit the shopper, it can benefit a third party.
> >
> > As I already said, how ?
>
> Selective reading don't give the answer, I know you like to ignore
> things that contradicts your world.
>
> >> Thought of sending more than just product id, the code that is on
> >> the e-commerce site may have a flaw which makes it possible to
> >> send a value not usually stored in the cookie to make the site to do
> >> something else,
> >
> > Ah, the "lets not answer the question, but trum up some other problems"
> > method.  Nope, rejected.   Explain how changing the product IDs in such
a
> > cookie benefits anyone, or admit defeat (in this regard).
> >
> > After that I'm open to hearing about which other kinds of data you also
want
> > to shuttle around in cookies, and how that could be exploited (to which
my
> > answer would most likely be to not send those to the user, but use a PHP
> > session and store them in there. :-) )
> >
> >> The session cookie do not automatically get "destroyed" just for you
> >> leave a site, it live the set life span it has, some sites uses a short
> >> life span and other a long.
> >
> > Gee... Do I hear an echo ?   Yes, it must be, as that is exactly what I
> > explained in my previous message. :-)
>
> Not at all, you wrote:
>
> "but the PHP session its referring to will be
> destroyed shortly after you leave the server, making that stored ID
> rather worthless."
>
> which is just bs.
>
> > And you're funny: you already told me that the contents of a cookie are
easy
> > to alter (even by a third party), but you *still* think its a good idea
to
> > accept it to authenticate you when you reconnect (with a different
IP...) to
> > the site.   Make up you mind bub, either the cookie contents are secure,
or
> > they aren't.  You can't have it both ways.
>
> For example tracking IP will not protect you against CSRF, it may
> protect against session cookie hijacking, but there are more modern
> methods to counter that.
>
> --
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17509

On 06/27/17 22:01, R.Wieser wrote:

>>> Gee... Do I hear an echo ?   Yes, it must be, as that is exactly what I
>>> explained in my previous message. :-)
>>
>> Not at all, you wrote:
>>
>> "but the PHP session its referring to will be
>> destroyed shortly after you leave the server, making that stored ID
>> rather worthless."
>>
>> which is just bs.
> 
> And you said "some sites uses a short life span and other a long.".  Explain
> to me how thats different from "will be destroyed shortly after you leave
> the server". 

You state yours as if it's the fact that the session cookie expires
after you leave a site, which you browser has no concept of, for if you
was right, then when you pay on your e-commerce site and are redirected
to the payment provider, then when you return back to the e-commerce
site your session would have expired.

Just for someone can set a cookie lifespan to a short period, do not
mean that everyone does that and usually you set a lifespan that you
know the customers will be able to finish their shopping before it
expires (don't forget that people sometimes want to read about the
product before adding it).


>> it may protect against session cookie hijacking
> 
> As I have already mentioned earlier (but you deemed it opportune to ignore
> it at that time): I highly doubt it, as both the cookie and the CSRF
> "secretly stored as part of a form element" data are send at the same time,
> in the same request (just at different locations, one in the header, one as
> part of the URI or trailing post-data).  What would stop anyone from
> capturing and using them ?
The thing that used is random, so if you do not know what the random
data is, then it's more difficult to "capture".

PS. CSRF != cookie hijacking

[toc] | [prev] | [next] | [standalone]

#17520

> Pray tell, I'm rather interrested in hearing how changing product-id "X"
> into "Y" can be exploited.

If I am the vendor of product "Y", and a significant number of
people don't notice the change from "X" to "Y", it can benefit me
in increased sales.  Whether it's worth the trouble, or the risk
of getting caught is another issue.

[toc] | [prev] | [next] | [standalone]

#17482

On 06/26/17 17:12, R.Wieser wrote:
> Gordon,
> 
>> Some shoppers are behind a proxy which may change the
>> outside IP address for every HTTP transaction. Thus:  1 main
>> page + 100 images = 101 differrent IP addresses.
> 
> Thats no problem at all, as long as the IP from which the webpages are
> requested does not change.

In Gordon's example it changes with each request, this could be a user
using tor network to do their shopping (which ain't wise, but that's
another story and another news group).


>> Using an IP plus the session cookie locks out a small part of
>> the user base (those behind proxies that use a changing outside
>> IP address)
> 
> I think you misunderstood when those IPs do actually change ...

I have seen corporate networks where you have multiple exit points, but
one internal proxy, depending on how the proxy is setup, for example for
load balancing the traffic, then you don't keep the same IP over a
session, the same applies for tor-network too. Also users switching from
one wifi connection to another may change IP too.


>> Some shopping carts last a lot longer than one session.  Usually
>> this requires logging in
> 
> With your described multiple different IPs within (something which the user
> percieves as) a single session that won't work either.

As long as you only relay on the session cookie, it don't matter how
many times the user changes IP as many times as they wish. The issue is
only if you look at session cookie plus IP, when those users will not be
able to finish their shopping.


<removing repost of the entire post that can already read in message
PcqdnRTWK6vXeM3EnZ2dnUU7-X3NnZ2d@posted.internetamerica as there ain't
any point in keeping anything that you don't reply to>


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17483

J.O.,

> In Gordon's example it changes with each request, this could be
> a user using tor network to do their shopping

While that is possible*, the problem is than knowingly created by the
user**, and not the website.   As such its upto the users (maybe together
with the tor network maintainers) to find a solution for it.

*though the client (read: his webbrowser) can, and normaly does request to
keep the HTTP connection open, so that it does not need to spend time on
setting up before and tearing down after each request + answer.

**I really do *not* want to know what kind of "shopping" you're doing when
you think you need tor for to obsfucate it. :-)

Regards,
Rudy Wieser


-- Origional message:
J.O. Aho <user@example.net> schreef in berichtnieuws
ercr2hFf9c6U1@mid.individual.net...
> On 06/26/17 17:12, R.Wieser wrote:
> > Gordon,
> >
> >> Some shoppers are behind a proxy which may change the
> >> outside IP address for every HTTP transaction. Thus:  1 main
> >> page + 100 images = 101 differrent IP addresses.
> >
> > Thats no problem at all, as long as the IP from which the webpages are
> > requested does not change.
>
> In Gordon's example it changes with each request, this could be a user
> using tor network to do their shopping (which ain't wise, but that's
> another story and another news group).
>
>
> >> Using an IP plus the session cookie locks out a small part of
> >> the user base (those behind proxies that use a changing outside
> >> IP address)
> >
> > I think you misunderstood when those IPs do actually change ...
>
> I have seen corporate networks where you have multiple exit points, but
> one internal proxy, depending on how the proxy is setup, for example for
> load balancing the traffic, then you don't keep the same IP over a
> session, the same applies for tor-network too. Also users switching from
> one wifi connection to another may change IP too.
>
>
> >> Some shopping carts last a lot longer than one session.  Usually
> >> this requires logging in
> >
> > With your described multiple different IPs within (something which the
user
> > percieves as) a single session that won't work either.
>
> As long as you only relay on the session cookie, it don't matter how
> many times the user changes IP as many times as they wish. The issue is
> only if you look at session cookie plus IP, when those users will not be
> able to finish their shopping.
>
>
> <removing repost of the entire post that can already read in message
> PcqdnRTWK6vXeM3EnZ2dnUU7-X3NnZ2d@posted.internetamerica as there ain't
> any point in keeping anything that you don't reply to>
>
>
> --
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17484

On 6/26/2017 1:17 PM, R.Wieser wrote:
> J.O.,
> 
>> In Gordon's example it changes with each request, this could be
>> a user using tor network to do their shopping
> 
> While that is possible*, the problem is than knowingly created by the
> user**, and not the website.   As such its upto the users (maybe together
> with the tor network maintainers) to find a solution for it.
>

The same thing can happen for anyone using a common router.  AOL users,
for instance, can have this problem.  So can users at large companies
who use multiple routers running in parallel between the users and the
internet.

It could even happen at my home where I have only one router because I
have a dynamic address.  That address can change at any time and I don't
track when the lease runs out.

> *though the client (read: his webbrowser) can, and normaly does request to
> keep the HTTP connection open, so that it does not need to spend time on
> setting up before and tearing down after each request + answer.
> 

It only stays open long enough to complete the current request.  For
instance, the browser requests a page.  In that page are images and
links to other files such as css and javascript, which also need to be
loaded to fully satisfy the request.  The browser keeps the connection
open long enough to load all of these additional files, then closes the
connection.  It does NOT hold a connection open while you go to lunch
while leaving your browser open.

> **I really do *not* want to know what kind of "shopping" you're doing when
> you think you need tor for to obsfucate it. :-)
> 
> Regards,
> Rudy Wieser
> 

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web