[PHP] SOLVED Re: [PHP] using cookies

2004-05-10 Thread David T-G
Hi, all --

...and then David T-G said...
% 
% I guess I need a primer on cookie usage.  I've read the manual regarding
[snip]

All has become clear, or at least only murky :-)

I was having trouble wrapping my head around how to start cookies (a la
sessions) and then check to see if I had a cookie on the browser machine
to log in a user automatically, since setcookie() looked to be the only
way to do anything and that wipes anything that may be there.

Richard was kind enough to clarify that the browser will automatically
send the cookie, even without asking, the next time the visitor comes to
the site, so I can immediately check $_COOKIE['mycookie'] without having
to call setcookie() to instantiate things.

Now to put it all into practice, but I see my cookie in the browser cache
file and it gets setn back to me when I return.  Yay! :-)


HTH & Thanks again & HAND

:-D
-- 
David T-G
[EMAIL PROTECTED]
http://justpickone.org/davidtg/  Shpx gur Pbzzhavpngvbaf Qrprapl Npg!



pgp0.pgp
Description: PGP signature


Re: [PHP] using cookies

2004-05-09 Thread Richard Harb
-Original Message-
From: David T-G
Sent: Sunday, May 9, 2004, 6:09:06 AM
> Hi, all --

> I guess I need a primer on cookie usage.  I've read the manual regarding
> setcookie and have gone back to look at everything having to do with
> cookies on this list in the past few months (it seems that I'm not the
> only one with some troubles, but most of them appear to have been having
> sent some HTML output before trying to set a cookie).

> I want to check to see if the user has my cookie to then log him in
> automatically, and if he doesn't then I show the login screen and he logs
> in and then I set the cookie if the box is checked.

> Of course, $_COOKIE is set, so I have to check for my cookie name.  Even
> something as simple as

>   $_COOKIE['test'] = 'tested';

Under normal circumstances you don't need to do that (unless you know
what you are doing - but it will not set a cookie on the client side,
it only modifies your superglobal variable for as long as the script
runs. I guess I'm once again stating the obvious).


> followed by a load of the page and a print doesn't show it.

> Do I only call setcookie if the cookie isn't set, or do i call it every
> time I load the page to initialize it?  Once I set it, how do I read it?

Once you setcookie() you can optionally give it something on its way:
like name, value, expire time/date, etc.

You could for example set a cookie to expire in half an hour - i.e.
for a session. It might make sense to refresh that cookie on every
page request, so that a session timeout will be postponed on each
refresh.

If you omit the expire time, it will be valid until the end of the
session (browser closes) - see the docs.


How do you get your cookie back?

If your visitor has a browser that allows cookies and you already sent
him one (or more) before, he will automatically transmit it to you as
part of the HTTP request headers. PHP does its magic and places the
values received into that Superglobal $_COOKIE (as well as $_REQUEST)
for you to play with...

So, if that array is empty that could mean two things:
1) you didn't send any cookie before (either because you already sent
your headers and thus have a f***up in your code or because the
visitor hasn't been to your page before)
2) the visitor does not allow cookies - too bad.


I guess that's all there is to it. Someone correct me or add to that
:)


> Does anyone have any pointers to a basic tutorial?

I didn't use any other page except the obvious one ...
http://www.php.net/manual/en/function.setcookie.php

I hope that answers at least part of what you were looking for ...

Richard

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] using cookies

2004-05-08 Thread David T-G
Hi, all --

I guess I need a primer on cookie usage.  I've read the manual regarding
setcookie and have gone back to look at everything having to do with
cookies on this list in the past few months (it seems that I'm not the
only one with some troubles, but most of them appear to have been having
sent some HTML output before trying to set a cookie).

I want to check to see if the user has my cookie to then log him in
automatically, and if he doesn't then I show the login screen and he logs
in and then I set the cookie if the box is checked.

Of course, $_COOKIE is set, so I have to check for my cookie name.  Even
something as simple as

  $_COOKIE['test'] = 'tested';

followed by a load of the page and a print doesn't show it.

Do I only call setcookie if the cookie isn't set, or do i call it every
time I load the page to initialize it?  Once I set it, how do I read it?
Does anyone have any pointers to a basic tutorial?


TIA & HAND

:-D
-- 
David T-G
[EMAIL PROTECTED]
http://justpickone.org/davidtg/  Shpx gur Pbzzhavpngvbaf Qrprapl Npg!



pgp0.pgp
Description: PGP signature


Re: [PHP] Using cookies

2003-10-21 Thread John Nichel
Jason Wong wrote:

> On Wednesday 22 October 2003 08:37, John Nichel wrote:
> 
>>Oh sure, figure out a way to circumvent this.  What the hell are you
>>trying to do, help people here?  hehe
> 
> 
> Your fault for crowning him king ;-)
> 

I knew that would come back to bite me.

-- 
By-Tor.com
It's all about the Rush
http://www.by-tor.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Jason Wong
On Wednesday 22 October 2003 08:37, John Nichel wrote:
> Oh sure, figure out a way to circumvent this.  What the hell are you
> trying to do, help people here?  hehe

Your fault for crowning him king ;-)

-- 
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
A farm in the country side had several turkeys, it was known as the
house of seven gobbles.
*/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- "Chris W. Parker" <[EMAIL PROTECTED]> wrote:
> > Not a good method. If I get on your site and see my cookie has the
> > value 241757219 in it, I just need to subtract one from the number
> > and revisit your site. Now I'm the user who registered before me.
> > Using the rand() or uniqid() method above means I have to guess an
> > entire random number / character sequence, which is going to be
> > harder (or nearly impossible). 
> 
> But that would require that you register immediately after the person
> before you. Then you could compare the two numbers and figure out what
> the base number is, but that seems REALLY unlikely.
> 
> Can you explain it a little different maybe?

Well, never underestimate the persistence of the bad guys. They will try for
hours and hours to guess a session ID, and if yours are sequential, they're
much easier to guess than if they are random. This actually follows along the
"no security through obscurity" rule.

In addition to this, there are many other ways session IDs can be disclosed to
the bad guy. So, eliminate the chances of a guess, but don't just stop there.

Hope that helps.

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Jason Wong
On Wednesday 22 October 2003 08:47, Chris W. Parker wrote:

> on Tuesday, October 21, 2003 5:30 PM said:
> > Not a good method. If I get on your site and see my cookie has the
> > value 241757219 in it, I just need to subtract one from the number
> > and revisit your site. Now I'm the user who registered before me.
> > Using the rand() or uniqid() method above means I have to guess an
> > entire random number / character sequence, which is going to be
> > harder (or nearly impossible).
>
> But that would require that you register immediately after the person
> before you. Then you could compare the two numbers and figure out what
> the base number is, but that seems REALLY unlikely.

If I understand the original proposition correctly it doesn't really matter. 
You just make up some 'random' ids around the range of your own and you'll 
get to login as someone else.

-- 
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
Mason's First Law of Synergism:
The one day you'd sell your soul for something, souls are a glut.
*/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- "John W. Holmes" <[EMAIL PROTECTED]> wrote:
> > > So let's say the first user comes along and is given the userid 1.
> > > We then create their random id by adding 241757219 to their userid.
> > > We get a random id of 241757220. Then within the login page I can
> > > subtract 241757219 from their random id and get their userid.
> > >
> > > Since the userid will always be unique (auto-incrementing) it
> > > stands to reason that the random id (using the method above) will
> > > also always be unique while at the same time not making any sense
> > > to a potential attacker. (It could even be made more complicated
> > > but use the same method.)
> > >
> > > How does that sound?
> > 
> > Sure. Since a potential 'hacker' doesn't know your base number, it 
> > would be pretty secure.
> 
> Not a good method. If I get on your site and see my cookie has the
> value 241757219 in it, I just need to subtract one from the number
> and revisit your site. Now I'm the user who registered before me.
> Using the rand() or uniqid() method above means I have to guess an
> entire random number / character sequence, which is going to be harder
> (or nearly impossible).

John makes a good point (of course). In addition to this, however, you should
also try to take steps to ensure that a guessed ID is less likely to work for
the bad guy. Depending on the obscurity of the session ID alone isn't enough if
that's the only thing a bad guy needs to be able to impersonate one of your
users. Cookie vulnerabilities, client-side caches, bookmarks, and other things
can cause the session ID to be disclosed.

Each request that a client sends likely has some information that can help in
this regard. Although you should never depend on information gathered from the
TCP/IP layer, it is safe to depend on the consistency of certain HTTP headers.
For example, if a user agent identifies itself as "Mozilla/5.0 (compatible;
Chris's badass Galeon browser) Linux/2.4" in one request, it is pretty safe to
assume that it will identify itself as such in future requests as well. If a
future request, using the same session ID, identifies itself as "Mozilla/5.0
(Joe Schmoe's lamass IE browser) Windows SA", does it makes sense to resume the
session without question? It doesn't make sense to me.

If a browser accepts gzip encoding now, will the same browser accept it in the
future? There is a lot of information you can use to make impersonation a
little more challenging for the bad guys, and every little bit helps.

Just as a friendly note, IE alters the value of the "Accept" header in the same
session, depending on whether the user clicks a link or clicks refresh. This is
annoying behavior, but it demonstrates the risk in taking this technique too
far. You don't want to enforce a restriction that impacts the good guys.

Hope that helps.

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread John W. Holmes
Chris W. Parker wrote:

John W. Holmes 
on Tuesday, October 21, 2003 5:30 PM said:

Not a good method. If I get on your site and see my cookie has the
value 241757219 in it, I just need to subtract one from the number
and revisit your site. Now I'm the user who registered before me.
Using the rand() or uniqid() method above means I have to guess an
entire random number / character sequence, which is going to be
harder (or nearly impossible). 


But that would require that you register immediately after the person
before you. Then you could compare the two numbers and figure out what
the base number is, but that seems REALLY unlikely.
Can you explain it a little different maybe?
I only have to register once to see what kind of data you're storing in 
the cookie. If you're just relying on that number, all I have to do is 
change it to become another user. I don't need to know about your "base 
number" or anything, just send another number and see what happens.

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP] Using cookies

2003-10-21 Thread Chris W. Parker
John W. Holmes 
on Tuesday, October 21, 2003 5:30 PM said:

> Not a good method. If I get on your site and see my cookie has the
> value 241757219 in it, I just need to subtract one from the number
> and revisit your site. Now I'm the user who registered before me.
> Using the rand() or uniqid() method above means I have to guess an
> entire random number / character sequence, which is going to be
> harder (or nearly impossible). 

But that would require that you register immediately after the person
before you. Then you could compare the two numbers and figure out what
the base number is, but that seems REALLY unlikely.

Can you explain it a little different maybe?



Chris.

--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread John Nichel
John W. Holmes wrote:

Chris W. Parker wrote:
Here's a thought:

How about adding an abitrary number (let's say 241757219) to every users
userid and then storing that number as the random id?
So let's say the first user comes along and is given the userid 1. We
then create their random id by adding 241757219 to their userid. We get
a random id of 241757220. Then within the login page I can subtract
241757219 from their random id and get their userid.
Since the userid will always be unique (auto-incrementing) it stands to
reason that the random id (using the method above) will also always be
unique while at the same time not making any sense to a potential
attacker. (It could even be made more complicated but use the same
method.)
How does that sound?

Sure.  Since a potential 'hacker' doesn't know your base number, it 
would be pretty secure.


Not a good method. If I get on your site and see my cookie has the value 
241757219 in it, I just need to subtract one from the number and revisit 
your site. Now I'm the user who registered before me. Using the rand() 
or uniqid() method above means I have to guess an entire random number / 
character sequence, which is going to be harder (or nearly impossible).

Oh sure, figure out a way to circumvent this.  What the hell are you 
trying to do, help people here?  hehe

--
By-Tor.com
It's all about the Rush
http://www.by-tor.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread John W. Holmes
John Nichel wrote:

Chris W. Parker wrote:

John Nichel 
on Tuesday, October 21, 2003 3:50 PM said:
1. Create a random ID and store it with the users record in the db.
2. If the user chooses to be remembered, stick the random ID into a
cookie.
3. When a user hits a login page, look for the cookie and retrieve it if
it exists.
4. Query the db to find out which user that number belongs to.
5. Fill in the form with that users login name.
How do you protect against duplicates OR how do you create your random
ID?


I just use php's rand() function to generate a 10 digit random number 
Using uniqid() in conjunction with rand() gives you an even better 
random "number", although it's larger, at 32 characters. It's basically 
a similar method to how the session ID is created and you shouldn't get 
any duplicates (especially if you're cleaning up old info).

Here's a thought:

How about adding an abitrary number (let's say 241757219) to every users
userid and then storing that number as the random id?
So let's say the first user comes along and is given the userid 1. We
then create their random id by adding 241757219 to their userid. We get
a random id of 241757220. Then within the login page I can subtract
241757219 from their random id and get their userid.
Since the userid will always be unique (auto-incrementing) it stands to
reason that the random id (using the method above) will also always be
unique while at the same time not making any sense to a potential
attacker. (It could even be made more complicated but use the same
method.)
How does that sound?

Sure.  Since a potential 'hacker' doesn't know your base number, it 
would be pretty secure.
Not a good method. If I get on your site and see my cookie has the value 
241757219 in it, I just need to subtract one from the number and revisit 
your site. Now I'm the user who registered before me. Using the rand() 
or uniqid() method above means I have to guess an entire random number / 
character sequence, which is going to be harder (or nearly impossible).

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread John Nichel
Chris W. Parker wrote:
John Nichel 
on Tuesday, October 21, 2003 3:50 PM said:
The
only thing I store in a cookie is a userid and a randomly generated
number, and that's only if the site is to have a 'remember me'
function so you don't have to login everytime.  Even in these cases,
I still make the user verify his/her password before changing the
account.  Everything else is in the session data.


Great idea about the 'remember me' thing. Right now I'm using the
username (I'm bad!!) and I want to see if I understand what you're doing
correctly.
1. Create a random ID and store it with the users record in the db.
2. If the user chooses to be remembered, stick the random ID into a
cookie.
3. When a user hits a login page, look for the cookie and retrieve it if
it exists.
4. Query the db to find out which user that number belongs to.
5. Fill in the form with that users login name.
How do you protect against duplicates OR how do you create your random
ID?
I just use php's rand() function to generate a 10 digit random number 
when a user chooses to be remembered, and I save that as well as the 
userid (not username...db id) in 2 seperate cookies...also in a temp 
table in the database.  Then if the user comes back, I can check for 
those two cookies, get the values, check the temp db table, and if all 
is good, they're logged in.  Duplicates aren't a problem, since even if 
rand() generated the same 10 digit number for two different people, 
their user id's will always be different.

Here's a thought:

How about adding an abitrary number (let's say 241757219) to every users
userid and then storing that number as the random id?
So let's say the first user comes along and is given the userid 1. We
then create their random id by adding 241757219 to their userid. We get
a random id of 241757220. Then within the login page I can subtract
241757219 from their random id and get their userid.
Since the userid will always be unique (auto-incrementing) it stands to
reason that the random id (using the method above) will also always be
unique while at the same time not making any sense to a potential
attacker. (It could even be made more complicated but use the same
method.)
How does that sound?

Sure.  Since a potential 'hacker' doesn't know your base number, it 
would be pretty secure.

--
By-Tor.com
It's all about the Rush
http://www.by-tor.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread John W. Holmes
Marek Kilimajer wrote:

John W. Holmes wrote:

You're not even allowed to use persistant cookies in public government 
sites unless you get permission from the Secretary of the Defense.

Hi, this is interesting. Can you post the guidelines?

Quote: This policy will be clarified to make clear that "persistent 
cookies" (i.e., those that can be used to track users over time and 
across different web sites) are authorized only when there is a 
compelling need to gather the data on the site; appropriate technical 
procedures have been established to safeguard the data; and the 
Secretary of Defense has personally approved use of the cookie.

Link: http://www.defenselink.mil/nii/org/cio/doc/cookies.html

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- Marek Kilimajer <[EMAIL PROTECTED]> wrote:
> John W. Holmes wrote:
> > 
> > You're not even allowed to use persistant cookies in public
> > government sites unless you get permission from the Secretary of
> > the Defense.
> 
> Hi, this is interesting. Can you post the guidelines?

I've never heard of the exception John mentioned, but I've had to work under
these guidelines. I'm not positive where the cookie restriction is mentioned (I
only remember not being able to use persistent cookies), but there's a good
chance it is in here:

http://www.section508.gov/

Hope that helps.

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Eugene Lee
On Tue, Oct 21, 2003 at 04:48:13PM -0500, Joseph Bannon wrote:
: 
: I think it's the responsibility of whomever is holding the key (ie, the
: username and password). When a user logs into my site, I put their
: username and password in a cookie. I then check those cookies to allow
: them access to membership only parts of the site. It is thus their
: responsibility to keep people from accessing the cookies on their
: machine. If I don't put the username and password on their machine and
: just use a session id, now the responsibility is in my hands.

Saying that the responsibilty to maintain the secrecy of such cookie
data lies in the hands of whoever hold the cookie is not possible.
Cookie data gets transferred in every HTTP request, and hops through
several routers before it reaches its final destination.  That's a lot
of extra machines that you say is responsible for keeping your cookie
data secret.  That's silly, and it will never happen.  The developer
sets the cookie.  And the responsibility lies with the developer (or
with the developer's employer).

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Marek Kilimajer
John W. Holmes wrote:
You're not even allowed to use persistant cookies in public government 
sites unless you get permission from the Secretary of the Defense.

Hi, this is interesting. Can you post the guidelines?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread John Nichel
John W. Holmes wrote:
Marco Tabini wrote:

Joseph Bannon wrote:

I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
responsibility to keep people from accessing the cookies on their
machine. If I don't put the username and password on their machine and
just use a session id, now the responsibility is in my hands.


What the hell kind of logic is that? So now it depends on what kind of 
data you put in the cookie for it to be your responsibility? You are 
definetly not a lawyer. :)

Neither am I mind you, but I think you should be held responsible for 
any data that's stored in a cookie. There should not be any sensitive 
data in cookies. Now, what's sensitive can be debated, but I'm sure it 
includes the username and password.
Tis why I would never store a password in a cookie.  You might be able 
to talk me into storing the username, but never the password.  The only 
thing I store in a cookie is a userid and a randomly generated number, 
and that's only if the site is to have a 'remember me' function so you 
don't have to login everytime.  Even in these cases, I still make the 
user verify his/her password before changing the account.  Everything 
else is in the session data.

Data in cookie = bad

IMHO, by storing the user's name and password in a cookie, you may be 
exposing that information to unnecessary risks by letting it go back 
and forth continuously on the Net (assuming, of course, that you're 
not under SSL and/or are using some encryption mechanism) and possibly 
someone could argue that you did not take the necessary steps to 
protect the user's data in an efficient way.


Second that. The method you're using now is horrible; there's no reason 
to ever store usernames and passwords in cookies. You're exposing this 
information for every request. At least if you're using a "session id" 
instead of the actually data, only that session can be hijacked, instead 
of the entire account.

You're not even allowed to use persistant cookies in public government 
sites unless you get permission from the Secretary of the Defense.

Damn Secretariesalways in my way. :)

--
By-Tor.com
It's all about the Rush
http://www.by-tor.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread Nicholas Robinson

If we're into analogies, how about a cookie containing username/password being 
much the same as leaving the keys to the house under your doormat? If someone 
knows that this is a common practice, they can find them and gain access to 
your house.

As I understand it (and I am not a lawyer) the laws in the UK (esp. Data 
Protection Act 1998 and the Computer Misuse Act) would place the 
responsibility with the site provider if cookies or 
authorisation/authentication mechanisms enable unauthorised access to 
information directly or indirectly - rather than the end user. In the case of 
personal data, the provider would be deemed to have failed to take adequate 
steps to protect the data from unauthorised disclosure. In other cases, it 
would probably render a successful prosecution of hacking more difficult.

Nick

On Tuesday 21 Oct 2003 11:10 pm, Chris Shiflett wrote:
> --- Marco Tabini <[EMAIL PROTECTED]> wrote:
> > IMHO, by storing the user's name and password in a cookie, you may be
> > exposing that information to unnecessary risks by letting it go back
> > and  forth continuously on the Net (assuming, of course, that you're
> > not under SSL and/or are using some encryption mechanism) and possibly
> > someone could argue that you did not take the necessary steps to protect
> > the user's data in an efficient way.
>
> I agree completely with this. If you are exposing someone's access
> credentials over the Internet for every single transaction (potentially
> many times for every page), your neglect would probably outweigh the fact
> that you didn't intentionally hand a third party any information. That's
> just my perspective, of course.
>
> In the case of cookies in general, I don't think it's as clear as any of
> the analogies used so far. The typical user probably doesn't realize you
> are setting or reading cookies. And, since the developer understands this
> while the user doesn't, it seems risky that the developer can know about
> potential vulnerabilities without alerting the user. I always assumed those
> legal disclaimers said stuff like, "You could die from using this site.
> Your death is not our responsibility. Browse at your own risk." Well, maybe
> not that extreme, but you get the idea. :-)
>
> Of course, if you don't store sensitive data in the cookies, there's not a
> big concern anyway.
>
> I should mention that the law doesn't always agree with me, so it's never
> safe to assume it does. I'm just saying what makes sense to me. :-)
>
> Chris
>
> =
> My Blog
>  http://shiflett.org/
> HTTP Developer's Handbook
>  http://httphandbook.org/
> RAMP Training Courses
>  http://www.nyphp.org/ramp

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread John W. Holmes
Marco Tabini wrote:
Joseph Bannon wrote:

I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
responsibility to keep people from accessing the cookies on their
machine. If I don't put the username and password on their machine and
just use a session id, now the responsibility is in my hands.
What the hell kind of logic is that? So now it depends on what kind of 
data you put in the cookie for it to be your responsibility? You are 
definetly not a lawyer. :)

Neither am I mind you, but I think you should be held responsible for 
any data that's stored in a cookie. There should not be any sensitive 
data in cookies. Now, what's sensitive can be debated, but I'm sure it 
includes the username and password.

IMHO, by storing the user's name and password in a cookie, you may be 
exposing that information to unnecessary risks by letting it go back and 
forth continuously on the Net (assuming, of course, that you're not 
under SSL and/or are using some encryption mechanism) and possibly 
someone could argue that you did not take the necessary steps to protect 
the user's data in an efficient way.
Second that. The method you're using now is horrible; there's no reason 
to ever store usernames and passwords in cookies. You're exposing this 
information for every request. At least if you're using a "session id" 
instead of the actually data, only that session can be hijacked, instead 
of the entire account.

You're not even allowed to use persistant cookies in public government 
sites unless you get permission from the Secretary of the Defense.

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- Marco Tabini <[EMAIL PROTECTED]> wrote:
> IMHO, by storing the user's name and password in a cookie, you may be 
> exposing that information to unnecessary risks by letting it go back
> and  forth continuously on the Net (assuming, of course, that you're
> not under SSL and/or are using some encryption mechanism) and possibly
> someone could argue that you did not take the necessary steps to protect 
> the user's data in an efficient way.

I agree completely with this. If you are exposing someone's access credentials
over the Internet for every single transaction (potentially many times for
every page), your neglect would probably outweigh the fact that you didn't
intentionally hand a third party any information. That's just my perspective,
of course.

In the case of cookies in general, I don't think it's as clear as any of the
analogies used so far. The typical user probably doesn't realize you are
setting or reading cookies. And, since the developer understands this while the
user doesn't, it seems risky that the developer can know about potential
vulnerabilities without alerting the user. I always assumed those legal
disclaimers said stuff like, "You could die from using this site. Your death is
not our responsibility. Browse at your own risk." Well, maybe not that extreme,
but you get the idea. :-)

Of course, if you don't store sensitive data in the cookies, there's not a big
concern anyway.

I should mention that the law doesn't always agree with me, so it's never safe
to assume it does. I'm just saying what makes sense to me. :-)

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Marco Tabini
Joseph Bannon wrote:
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
responsibility to keep people from accessing the cookies on their
machine. If I don't put the username and password on their machine and
just use a session id, now the responsibility is in my hands.
J.

The responsibility is in your hands as far as the consequence of your 
actions are concerned. If *your* server gets hacked into and someone 
steals all the usernames and passwords, you're in trouble because you 
let that happen.

If your customer discloses his or her information to a third party, 
either voluntarily or by mistake, the responsibility is theirs, unless 
you accept in your agreement with them to take responsibility for their 
mistakes (which, incidentally, is essentially what you do when you open 
a credit card merchant account).

IMHO, by storing the user's name and password in a cookie, you may be 
exposing that information to unnecessary risks by letting it go back and 
forth continuously on the Net (assuming, of course, that you're not 
under SSL and/or are using some encryption mechanism) and possibly 
someone could argue that you did not take the necessary steps to protect 
the user's data in an efficient way.

But, then again, I'm not a lawyer, so take what I'm saying with a HUGE 
grain of salt :-)

Cheers,

Marco

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP] Using cookies

2003-10-21 Thread Joseph Bannon
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
responsibility to keep people from accessing the cookies on their
machine. If I don't put the username and password on their machine and
just use a session id, now the responsibility is in my hands.

J.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Using cookies

2003-10-21 Thread Chris W. Parker
Chris W. Parker <>
on Tuesday, October 21, 2003 2:35 PM said:

> Actually it's more like the bank storing your money in a safe with
> glass walls.
> 
> Sure the bank "stored" it, and stored it "securely" (it was behind
> glass wasn't it?) but someone could easily break the glass and steal
> all the money.

Ok wait. Maybe it's not like that because in my example I say the bank
stored the money when in fact the bank gave it to the customer to hold
onto.

I can't come up with a good example that is congruous with the real
world and virtual world as well so may I suggest that a disclaimer be
added to the EULA?

"There are flaws in certain web browsers that can allow a 3rd party to
see the contents of the cookies on your cookie. By using this site you
agree to not hold The Company responsible for data that is stolen from
your computer via the security flaws in certain web browsers."

Now I'm definitely no lawyer and my verbiage may be terribly flawed, but
that might help in clearing The Company of liability. I don't know.

(I'm just trying to cover up the mistake of my example. :P )


Chris.

--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Marco Tabini
Actually it's more like the bank storing your money in a safe with glass
walls.
Sure the bank "stored" it, and stored it "securely" (it was behind glass
wasn't it?) but someone could easily break the glass and steal all the
money.
The argument from the customer would be "The company I put my trust in
did not take all the precautions possible to protect me and I think they
misrepresented the security of my data. If they had told me there are
flaws in my browser that could allow the leaking of my information I
would not have signed up in the first place."
Whether or not that's a good reason for a judge to rule on behalf of a
customer is another thing. But I just thought I should try to clarify.


Chris.

Sorry, but your comparison doesn't hold together--perhaps we should drop 
banks altogether and actually talk about computers :-)

Once the cookie is on the user's browser, it is in the hands of the 
user. I, or my company, have no control over what happens at that point. 
It is the user's responsibility--because he or she now holds that 
data--to handle it properly.

Cheers,

Marco

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP] Using cookies

2003-10-21 Thread Chris W. Parker
Marco Tabini 
on Tuesday, October 21, 2003 1:31 PM said:

> But if the browser causes the information to leak, we did not share
> (or disclose) it--the user did, through action or inaction (e.g.: not
> patching his or her browser).
> 
> Your bank won't share your money with anybody else, but if you take
> the money out and someone robs you outside the branch, they're not
> going to refund you...

Actually it's more like the bank storing your money in a safe with glass
walls.

Sure the bank "stored" it, and stored it "securely" (it was behind glass
wasn't it?) but someone could easily break the glass and steal all the
money.

The argument from the customer would be "The company I put my trust in
did not take all the precautions possible to protect me and I think they
misrepresented the security of my data. If they had told me there are
flaws in my browser that could allow the leaking of my information I
would not have signed up in the first place."

Whether or not that's a good reason for a judge to rule on behalf of a
customer is another thing. But I just thought I should try to clarify.



Chris.

--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Marco Tabini
Chris Shiflett wrote:
--- Marco Tabini <[EMAIL PROTECTED]> wrote:

However, we do not share the contents of our cookies with any third
party, under any circumstances.


I'm no lawyer, but that seems like a risky statement. There are many
circumstances that can cause the contents of the cookies you set to be
disclosed to third parties. It seems like the definition of "sharing" would
come under scrutiny in these situations, which doesn't seem like much defense
to me.
Well "sharing" implies a will to disclose--so if we unvoluntarily 
disclose information we don't "share" it with anyone.

I suppose you're safe as long as you don't willingly or intentionally share
this information yourself, but browser vulnerabilities (such as those found in
IE 4.0, 5.0, 5.5, and 6.0) can allow anyone to view the contents of any cookie.
But if the browser causes the information to leak, we did not share (or 
disclose) it--the user did, through action or inaction (e.g.: not 
patching his or her browser).

Your bank won't share your money with anybody else, but if you take the 
money out and someone robs you outside the branch, they're not going to 
refund you...

Cheers,

Marco

I doubt I'm telling you anything you don't know, but maybe I'm saying something
that someone doesn't know. :-)
Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- Marco Tabini <[EMAIL PROTECTED]> wrote:
> However, we do not share the contents of our cookies with any third
> party, under any circumstances.

I'm no lawyer, but that seems like a risky statement. There are many
circumstances that can cause the contents of the cookies you set to be
disclosed to third parties. It seems like the definition of "sharing" would
come under scrutiny in these situations, which doesn't seem like much defense
to me.

I suppose you're safe as long as you don't willingly or intentionally share
this information yourself, but browser vulnerabilities (such as those found in
IE 4.0, 5.0, 5.5, and 6.0) can allow anyone to view the contents of any cookie.

I doubt I'm telling you anything you don't know, but maybe I'm saying something
that someone doesn't know. :-)

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Chris Shiflett
--- John Taylor-Johnston <[EMAIL PROTECTED]> wrote:
> Can someone recommend a good URL on cookies and security issues
> please? I can program them, but am told I'm putting others at risk,
> forcing people to use cookies on my site.

I have a free chapter about cookies from HTTP Developer's Handbook on my site,
and it gives some information on security and privacy concerns:

http://shiflett.org/books/http-developers-handbook/chapters/11

Hope that helps.

Chris

=
My Blog
 http://shiflett.org/
HTTP Developer's Handbook
 http://httphandbook.org/
RAMP Training Courses
 http://www.nyphp.org/ramp

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Marco Tabini
We use a standard disclaimer:

2. Use of Cookies
Like many websites, we use cookies to maintain certain information about 
you while you are visiting our website. However, we do not share the 
contents of our cookies with any third party, under any circumstances. 
Should we allow a third party to provide advertisement through our 
website or through our magazine, please be advised that we are not 
responsible for their use of cookies, and that we do not normally have 
access to the information that they store in their cookies.

That has kept our users at bay, but we admittedly cater to a technical 
audience...

Cheers,

Marco

John Taylor-Johnston wrote:
Can someone recommend a good URL on cookies and security issues please?
I can program them, but am told I'm putting others at risk, forcing people to use 
cookies on my site.
--
John Taylor-Johnston
-
Université de Sherbrooke:
http://compcanlit.ca/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP] Using cookies

2003-10-21 Thread Joseph Bannon

It's your site isn't it? -lol

J



-Original Message-
Nothing much. Been receiving flack about forcing people into cookies.
Much misunderstood info about cookies. I need an URL to pass on for
extra reading, as rebuttal.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread John Taylor-Johnston
Nothing much. Been receiving flack about forcing people into cookies. Much 
misunderstood info about cookies. I need an URL to pass on for extra reading, as 
rebuttal.

"Chris W. Parker" wrote:

> John Taylor-Johnston 
> on Tuesday, October 21, 2003 11:40 AM said:
>
> > Can someone recommend a good URL on cookies and security issues
> > please? I can program them, but am told I'm putting others at risk,
> > forcing people to use cookies on my site.
>
> I guess it depends on what you're storing in the cookie. What are you
> storing right now? Maybe there's an alternative?
>
> --
> Don't like reformatting your Outlook replies? Now there's relief!
> http://home.in.tum.de/~jain/software/outlook-quotefix/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using cookies

2003-10-21 Thread Curt Zirzow
* Thus wrote John Taylor-Johnston ([EMAIL PROTECTED]):
> Can someone recommend a good URL on cookies and security issues please?
> I can program them, but am told I'm putting others at risk, forcing people to use 
> cookies on my site.
> 

Being online is a risk, or even crossing the street is a risk (I
almost got hit by a car yesterday.)  Any specific type of risk you
have in mind?

googling for 'cookie secuirty' yields some general information.


Curt
-- 
"My PHP key is worn out"

  PHP List stats since 1997: 
  http://zirzow.dyndns.org/html/mlists/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Using cookies

2003-10-21 Thread Chris W. Parker
John Taylor-Johnston 
on Tuesday, October 21, 2003 11:40 AM said:

> Can someone recommend a good URL on cookies and security issues
> please? I can program them, but am told I'm putting others at risk,
> forcing people to use cookies on my site. 

I guess it depends on what you're storing in the cookie. What are you
storing right now? Maybe there's an alternative?


--
Don't like reformatting your Outlook replies? Now there's relief!
http://home.in.tum.de/~jain/software/outlook-quotefix/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Using cookies

2003-10-21 Thread John Taylor-Johnston
Can someone recommend a good URL on cookies and security issues please?
I can program them, but am told I'm putting others at risk, forcing people to use 
cookies on my site.

--
John Taylor-Johnston
-
Université de Sherbrooke:
http://compcanlit.ca/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using Cookies Securely

2003-06-01 Thread Evan Nemerson
Again, "It's not perfect, but I don't think anyone has come up with a better 
way."

It's called session hijacking, and it is a great reason to use SSL. However, 
there's still the issue of cross-site scripting, which can really only be 
prevented by smarter coding.

Even then there are issues. For example, holes in ie's SSL capabilities 
(including a current, unpatched vulnerability- well okay it was patched but 
M$ managed to re-introduce it in more recent patches...), permit undeteted 
MITM attacks.


On Saturday 31 May 2003 05:56 am, Dustin Mitchell wrote:
> On Fri, May 30, 2003 at 11:01:26PM -0700, Evan Nemerson wrote:
> > Send a session ID to the user in a cookie, then lookup that ID in a
> > database on the server. It's extremely difficult to guess random session
> > ID's (don't just increment them!), and if you have a session timeout,
> > you're pretty much set.
>
> That's true, and it is what most people do, but if you think about it the
> session ID is then functionally equivalent to a crypt'd password for the
> duration of your session; that is, either one allows you access to the
> site. So if you were worried about folks sniffing an encrypted password and
> using it to log in, you should be equally worried about folks sniffing a
> session ID and using *it* to log in.
>
> Dustin


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using Cookies Securely

2003-05-31 Thread Dustin Mitchell
On Fri, May 30, 2003 at 11:01:26PM -0700, Evan Nemerson wrote:
> Send a session ID to the user in a cookie, then lookup that ID in a database 
> on the server. It's extremely difficult to guess random session ID's (don't 
> just increment them!), and if you have a session timeout, you're pretty much 
> set.

That's true, and it is what most people do, but if you think about it the
session ID is then functionally equivalent to a crypt'd password for the
duration of your session; that is, either one allows you access to the site.
So if you were worried about folks sniffing an encrypted password and using
it to log in, you should be equally worried about folks sniffing a session ID
and using *it* to log in.

Dustin

-- 

  Dustin Mitchell
  [EMAIL PROTECTED]/[EMAIL PROTECTED]
  http://people.cs.uchicago.edu/~dustin/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using Cookies Securely

2003-05-31 Thread Evan Nemerson
Send a session ID to the user in a cookie, then lookup that ID in a database 
on the server. It's extremely difficult to guess random session ID's (don't 
just increment them!), and if you have a session timeout, you're pretty much 
set.

It's not perfect, but I don't think anyone has come up with a better way

The way it's been explained to me, this is how PHP's sessions work, but I have 
not personally verified this. So I think it's okay to put semi-sensitive data 
in the session array (you shouldn't ever store really sensitive data). Check 
first though.




On Friday 30 May 2003 10:29 pm, Monty wrote:
> I see some posts here that say storing a username or encrypted password in
> a cookie is not secure. If so, then what's a more secure way to allow users
> to be "remembered" using a cookie so that they don't have to log in every
> time they come to the site? What do you store in the cookie to authenticate
> against?
>
> Monty

-- 

Perl - the only language that looks the same before and after RSA encryption.

-Keith Bostic


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Using Cookies Securely

2003-05-31 Thread Justin French
The short answer is that if you're worried about security, don't store a uid
and pwd in a cookie on the client... banks don't do it, for example.

It's also common for the uid to be remembered, but not the pwd.

>From what I can see happening on the "big sites", you give the user the
option to be remembered or not, and you advise them against it if they're on
a shared/public computer, or even remotely care about security and privacy.

Handling log-ins and cookie sending under SSL would also help.


Justin


on 31/05/03 4:29 PM, Monty ([EMAIL PROTECTED]) wrote:

> I see some posts here that say storing a username or encrypted password in a
> cookie is not secure. If so, then what's a more secure way to allow users to
> be "remembered" using a cookie so that they don't have to log in every time
> they come to the site? What do you store in the cookie to authenticate
> against?
> 
> Monty
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Using Cookies Securely

2003-05-31 Thread Monty
I see some posts here that say storing a username or encrypted password in a
cookie is not secure. If so, then what's a more secure way to allow users to
be "remembered" using a cookie so that they don't have to log in every time
they come to the site? What do you store in the cookie to authenticate
against?

Monty


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] using cookies

2002-11-23 Thread Chris Shiflett
--- Ken Nagorski <[EMAIL PROTECTED]> wrote:

> I have never used cookies before, however I am trying to
> implement them to make things a little more secure. Rather
> than passing a sql statement via a hidden input tag I am
> setting a cookie.

I think someone else already mentioned this, but let me emphasize
that this is a terrible idea and definitely does not make things a
little more secure.

The best analogy I can think of for a cookie would be handing out
name tags to people who visit your site. Imagine that you write the
following SQL on someone's name tag:

select * from foo where unique_id='12345'

This helps you distinguish them from the next person who may have a
unique identifier of 23456. While this might work for those who play
by the rules, you are placing a tremendous amount of trust in these
people. What if someone erased what you wrote on their name tag,
replacing it with this:

delete from foo

If you were to trust this person's name tag the next time you saw
them, you would delete all of the data from that table.

In addition to this, hidden form variables are just as bad. It is a
different method, but you are still basically sending something to
the client and just trusting the client to return exactly what you
sent. Placing so much trust in the client is never a good idea.

I would recommend abandoning these methods for anything that you, as
you say, are wanting to make more secure. Look into using sessions
instead. When you use sessions, the only sensitive data you trust the
client to return to you is PHPSESSID. While there are some dangers
associated with this trust, it is a more tolerable risk. When you set
a session variable, it is kept safely on the server, so it is at
least much less convenient for an attacker to alter this data,
because only you can do that.

I hope this helps you get started down the right path. There are
methods you can use to further mitigate the risk of trusting the
client's PHPSESSID, but that can be discussed later.

Chris

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP] using cookies

2002-11-23 Thread Rich Gray
Try the system() or passthru() functions...

Rich
-Original Message-
From: Paul Marinas [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2002 13:09
To: Rich Gray
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [PHP] using cookies



dose anyone how to send a "ping" in local network

thanks

Paul Marinas
Technical Support
RDS Craiova


Phone:  +402-51-410-194
Mobile: +407-22-451-439
Fax:+402-51-416-579
www.rdsnet.ro
.

Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this
message (or responsible for delivery of the message to such person), you may
not copy or deliver this message to
anyone. In such a case, you should destroy this message and kindly notify
the sender by reply e-mail.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP] using cookies

2002-11-23 Thread Paul Marinas

dose anyone how to send a "ping" in local network

thanks

Paul Marinas
Technical Support
RDS Craiova


Phone:  +402-51-410-194
Mobile: +407-22-451-439
Fax:+402-51-416-579
www.rdsnet.ro
.

Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this
message (or responsible for delivery of the message to such person), you may
not copy or deliver this message to
anyone. In such a case, you should destroy this message and kindly notify
the sender by reply e-mail.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP] using cookies

2002-11-23 Thread Rich Gray
Ken

Do *not* use hidden form statements or cookies to store any SQL this is
extremely dangerous and a relatively simple hack could destroy your database
completely!

By all means use hidden form fields to store row ID values but your PHP
scripts should treat all user input data via $_GET/$_POST/$_COOKIE/$_FILES
as hostile and you should be rigorous in validating that data coming into
your script is as you would expect...

Having said that it seems your server has magic_quotes_gpc() switched on -
this automatically escapes all incoming data that could upset a SQL query
i.e. the quotes - you can remove them by using stripslashes() or switch off
magic quotes in your php.ini file. But I would repeat *don't* continue down
the path you are going unless you like being hacked!

HTH
Rich
-Original Message-
From: Ken Nagorski [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2002 11:52
To: [EMAIL PROTECTED]
Subject: [PHP] using cookies


Hi there,

I have never used cookies before, however I am trying to implement them to
make things a little more secure. Rather than passing a sql statement via a
hidden input tag I am setting a cookie. This works fine except that when I
look at the sql after it is pulled from the cookie everything is escaped,
for instance.

SELECT * FROM inventory WHERE name='Watches'
  would become
SELECT manufacturer FROM inventory WHERE name=\'Watches\'

This is a problem cause trying to use preg_replace doesn't seem to work. I
get an error saying that the delimeter must not be a \. What a bummer. I am
a little stuck. I will take any suggestions. Maybe I am just going about
things the wrong way. *** Shrug ***

Thanks
Ken




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP] using cookies

2002-11-23 Thread Ken Nagorski
Hi there,

I have never used cookies before, however I am trying to implement them to
make things a little more secure. Rather than passing a sql statement via a
hidden input tag I am setting a cookie. This works fine except that when I
look at the sql after it is pulled from the cookie everything is escaped,
for instance.

SELECT * FROM inventory WHERE name='Watches'
  would become
SELECT manufacturer FROM inventory WHERE name=\'Watches\'

This is a problem cause trying to use preg_replace doesn't seem to work. I
get an error saying that the delimeter must not be a \. What a bummer. I am
a little stuck. I will take any suggestions. Maybe I am just going about
things the wrong way. *** Shrug ***

Thanks
Ken




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP] using cookies and flash problem

2002-05-12 Thread Deadsam

I'm having a problem with using cookies and flash, I'm new to php so it's
more then likely my coding, I have a forum made from flash/php/mysql, and
I'm trying to use cookies for the username and password so they dont have to
log in, I have manage to create the cookies no problem, its the rest thats
wrong, I'll post the code to read the cookies:
 0) {
//Loop through all the cookies...
foreach($HTTP_COOKIE_VARS as $cookieName => $cookieValue){
//output name and value
print "$cookiename=$cookieValue&";
}
} else {
//otherwise out no cookies
print "&userStatus=you are not logged in";
}
?>

In flash I used a loadVariableNum("http://www.deadsam.com/cookiescript.php";,
this, "POST");

I keep getting errors with this.
If anyone has an answer to this I'd appreciate it very much.
Thank you in advance
Deadsam



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Using Cookies

2001-03-10 Thread Yasuo Ohgaki

It seemed I thought it should work at least. But it does not on PHP4.0.4pl1.

Try following code

');
  }

  print('The user is ' . $user . '');
  print('The password is ' . $pw . '');
  if (empty($cookieuser)) {
print('No cookie was set...will set one');
  } else {
print('Cookie user name: ' . $cookieuser . '');
  }
  echo(''."\n");
  print_r($HTTP_COOKIE_VARS);
  echo(''."\n");

?>

FYI:
You better to set error reporting to E_ALL. You didn't enclose array index.
E_ALL will be very helpful to find type AND to write better code. I don't
recommend to use short tag. Use 
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2001 1:59 AM
Subject: [PHP] Using Cookies


> This is a test script so I can get an understanding of Cookies.  What am
> I missing with this?  $cookieuser never gets a value.
>
>$user   = $HTTP_GET_VARS[user];
>   $pw = $HTTP_GET_VARS[pw];
>   $cookieuser = $HTTP_COOKIE_VARS[user];
>   if (!$cookieuser) {
> setcookie("user", $user, time() + 864000);
> print("Setting a cookie");
>   }
>
>   print("The user is " . $user . "");
>   print("The password is " . $pw . "");
>   if (empty($cookieuser)) {
> print("No cookie was set...will set one");
>   } else {
> print("Cookie user name: " . $cookieuser . "");
>   }
> ?>
>
>
>
> --
> Todd Cary
> Ariste Software
> [EMAIL PROTECTED]
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP] Using Cookies

2001-03-10 Thread Todd Cary

This is a test script so I can get an understanding of Cookies.  What am
I missing with this?  $cookieuser never gets a value.

");
  }

  print("The user is " . $user . "");
  print("The password is " . $pw . "");
  if (empty($cookieuser)) {
print("No cookie was set...will set one");
  } else {
print("Cookie user name: " . $cookieuser . "");
  }
?>



--
Todd Cary
Ariste Software
[EMAIL PROTECTED]



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]