Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Anyone Have Experience with IPV6, Apache, and PHP

1 view
Skip to first unread message

Datesfat Chicks

unread,
Nov 5, 2009, 8:36:57 PM11/5/09
to
What format is the IP address in as Apache passes it to PHP?

I'm writing a web-based application that will do some basic IP security
checks (to be sure that the session hasn't shifted IP too badly), etc., but
hard to plan for IPV6 if I don't know what a typical string will be like.

With IPV4, it is just n.n.n.n.

What will PHP see when used on an IPV6 installation?

Thanks, Datesfat

Jerry Stuckle

unread,
Nov 5, 2009, 9:43:44 PM11/5/09
to

This information comes from the web server. PHP will see whatever the
web server passes it. I would expect that to be standard IPV6 notation,
but you'll have to ask the web server people.

Keep in mind that using IP's for security is NOT reliable. The IP can
change at any time, and many different people can be using the same IP
concurrently.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

Datesfat Chicks

unread,
Nov 5, 2009, 10:01:46 PM11/5/09
to
"Jerry Stuckle" <jstu...@attglobal.net> wrote in message
news:hd02h5$h0d$1...@news.eternal-september.org...

> Datesfat Chicks wrote:
>> What format is the IP address in as Apache passes it to PHP?
>>
>> I'm writing a web-based application that will do some basic IP security
>> checks (to be sure that the session hasn't shifted IP too badly), etc.,
>> but hard to plan for IPV6 if I don't know what a typical string will be
>> like.
>>
>> With IPV4, it is just n.n.n.n.
>>
>> What will PHP see when used on an IPV6 installation?
>>
>> Thanks, Datesfat
>
> This information comes from the web server. PHP will see whatever the web
> server passes it. I would expect that to be standard IPV6 notation, but
> you'll have to ask the web server people.
>
> Keep in mind that using IP's for security is NOT reliable. The IP can
> change at any time, and many different people can be using the same IP
> concurrently.

Well, OK, what I'd be doing is issuing unpredictable cryptographic hashes as
session identifier cookies. Since they come from Whirlpool (the
cryptographic hash function), that would be 512 bits of hash.

Anyone guessing a session identifier would be a statistical LONG shot.
2**(-512) is a really small number.

Is that enough security?

Just to make it a bit beefier, I was going to restrict in a mild form by IP,
too. In IPV4, I'd say that if the first 24 bits are the same, good enough,
i.e. a mask of 255.255.255.0.

Other security suggestions? What else should I do?

Is a 512-bit session identifier enough?

Thanks, Datesfat

Jerry Stuckle

unread,
Nov 5, 2009, 10:26:21 PM11/5/09
to

Why go to all that trouble? PHP's session identifier is a long string
with is just as hard to guess. And if you're concerned about security,
you should be using a secure protocol.

Datesfat Chicks

unread,
Nov 5, 2009, 10:48:04 PM11/5/09
to
"Jerry Stuckle" <jstu...@attglobal.net> wrote in message
news:hd0510$1tv$1...@news.eternal-september.org...

Secure protocol? Such as???

Datesfat

Curtis Dyer

unread,
Nov 6, 2009, 12:12:51 AM11/6/09
to
On 05 Nov 2009, "Datesfat Chicks" <datesfa...@gmail.com>
wrote:

> "Jerry Stuckle" <jstu...@attglobal.net> wrote in message
> news:hd0510$1tv$1...@news.eternal-september.org...
>> Datesfat Chicks wrote:
>>> "Jerry Stuckle" <jstu...@attglobal.net> wrote in message
>>> news:hd02h5$h0d$1...@news.eternal-september.org...
>>>> Datesfat Chicks wrote:

<snip>

>> Why go to all that trouble? PHP's session identifier is a long
>> string with is just as hard to guess. And if you're concerned
>> about security, you should be using a secure protocol.
>
> Secure protocol? Such as???

See: <http://en.wikipedia.org/wiki/Transport_Layer_Security> (often
still referred to as SSL).

--
Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

C. (http://symcbean.blogspot.com/)

unread,
Nov 6, 2009, 6:21:30 AM11/6/09
to
On Nov 6, 3:01 am, "Datesfat Chicks" <datesfat.chi...@gmail.com>
wrote:
> "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message

> >
> > Keep in mind that using IP's for security is NOT reliable.  The IP can
> > change at any time, and many different people can be using the same IP
> > concurrently.
>
> Well, OK, what I'd be doing is issuing unpredictable cryptographic hashes as
> session identifier cookies.  Since they come from Whirlpool (the
> cryptographic hash function), that would be 512 bits of hash.
>
> Anyone guessing a session identifier would be a statistical LONG shot.
> 2**(-512) is a really small number.
>
> Is that enough security?
>

No, but its sufficient for the purposes of generating a session
identifier.

> Just to make it a bit beefier, I was going to restrict in a mild form by IP,
> too.  In IPV4, I'd say that if the first 24 bits are the same, good enough,
> i.e. a mask of 255.255.255.0.
>

This will come back and bite you on the bum. As Jerry says, its
irrelevant to who the client is. Checking for changes in the user-
agent string and the browsers Accept headers values is a better of
finger-printing your client, but still a VERY long way from being
foolproof.

> Other security suggestions?  What else should I do?
>

All the usual ones:

Apply good software engineering practices
Read and learn
Use SSL
Escape any output at the point where it leaves your PHP code, using
the right method for the receiving end.
Limit the max post size on your webserver
Generate new session ids when when someone authenticates or presents
an expired one
Use HTTP-Only and secure flags on session cookies
Use tokens to identify CSRF
etc

C.

C. (http://symcbean.blogspot.com/)

unread,
Nov 6, 2009, 6:22:10 AM11/6/09
to
On Nov 6, 3:48 am, "Datesfat Chicks" <datesfat.chi...@gmail.com>

wrote:
> "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message
> >
> > Why go to all that trouble?  PHP's session identifier is a long string
> > with is just as hard to guess.  And if you're concerned about security,
> > you should be using a secure protocol.
>
> Secure protocol?  Such as???
>
> Datesfat


!!!!!!!!!!


Datesfat Chicks

unread,
Nov 6, 2009, 8:18:39 AM11/6/09
to
"Curtis Dyer" <dye...@gmail.com> wrote in message
news:hd0b8i$k59$3...@news.eternal-september.org...

> On 05 Nov 2009, "Datesfat Chicks" <datesfa...@gmail.com>
> wrote:
>
>> "Jerry Stuckle" <jstu...@attglobal.net> wrote in message
>> news:hd0510$1tv$1...@news.eternal-september.org...
>>> Datesfat Chicks wrote:
>>>> "Jerry Stuckle" <jstu...@attglobal.net> wrote in message
>>>> news:hd02h5$h0d$1...@news.eternal-september.org...
>>>>> Datesfat Chicks wrote:
>
> <snip>
>
>>> Why go to all that trouble? PHP's session identifier is a long
>>> string with is just as hard to guess. And if you're concerned
>>> about security, you should be using a secure protocol.
>>
>> Secure protocol? Such as???
>
> See: <http://en.wikipedia.org/wiki/Transport_Layer_Security> (often
> still referred to as SSL).

Fair enough, but that doesn't seem wholly relevant to my question of whether
session IDs are enough.

SSL will only prevent eavesdropping and server-spoofing attacks.

If someone gets a current session ID (maybe a computer has been
virus-infected and transmits these elsewhere in real time), they could still
connect to my server from anywhere.

Maybe I'm just having a slow morning and not "getting it".

Datesfat

Datesfat Chicks

unread,
Nov 6, 2009, 8:23:06 AM11/6/09
to
"C. (http://symcbean.blogspot.com/)" <colin.m...@gmail.com> wrote in
message
news:2901c94b-64de-4ae9...@t2g2000yqn.googlegroups.com...

Is the max post size a security threat? Just curious?

>Generate new session ids when when someone authenticates or presents
>an expired one

Thanks, good idea. I would have reused the old one after they provided a
valid password. OK.

>Use HTTP-Only and secure flags on session cookies

I don't understand that statement. I thought cookies only had "domain" and
"expiry" attributes.

>Use tokens to identify CSRF

What is CSRF? I don't understand that statement.

>etc

Any books I should read?

Thanks, Datesfat.

Captain Paralytic

unread,
Nov 6, 2009, 8:30:04 AM11/6/09
to
On 6 Nov, 13:23, "Datesfat Chicks" <datesfat.chi...@gmail.com> wrote:
> "C. (http://symcbean.blogspot.com/)" <colin.mckin...@gmail.com> wrote in
> messagenews:2901c94b-64de-4ae9...@t2g2000yqn.googlegroups.com...
http://lmgtfy.com/?q=CRSF

"Álvaro G. Vicario"

unread,
Nov 6, 2009, 8:41:00 AM11/6/09
to
Datesfat Chicks escribi�:

I'm not familiar with IPv6 but I presume that, in the end, IPv6
addresses are only integers just as IPv4 addresses are, no matter how
they're represented as strings. So a sensible approach could be to get
the numeric representation and work with it.

There's a function that seems to do so, although my current PHP setup
won't allow me to test it:

http://php.net/inet_pton

It returns a string but I guess it's only because PHP can't hold such
large integers in its native type. A database field that's able to store
128 bits of data should do the trick.

In any case, the Wikipedia is always a good place to do some preliminary
research:

http://en.wikipedia.org/wiki/Ipv6#Addressing


--
-- http://alvaro.es - �lvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programaci�n web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

Datesfat Chicks

unread,
Nov 6, 2009, 9:49:36 AM11/6/09
to
"Captain Paralytic" <paul_l...@yahoo.com> wrote in message
news:8792ef4e-a70d-41c2...@d5g2000yqm.googlegroups.com...

>
> >Use tokens to identify CSRF
>
> What is CSRF? I don't understand that statement.
>
>http://lmgtfy.com/?q=CRSF

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Got it, thanks.

I also found the use of tokens in the wikipedia article, which would have
been my next question.

Only remaining question is whether there are any good books I should be
reading ...

All interesting. I never would have thought of a CSRF attack.

Datesfat

Jerry Stuckle

unread,
Nov 6, 2009, 11:54:41 AM11/6/09
to

The only way to protect against any possible scenario is to not place
your server on the internet at all. Even banks and health care
providers (which are subject to strict privacy laws in the U.S.) don't
use ip addresses because they don't work.

For instance, let's say you have a corporate proxy server. Everyone
behind that server (maybe 1,000 users) will have the same external IP
address (the one of the server). And every incoming request will
potentially come through a different port.

Now a larger company which has multiple proxies in a round robin
configuration. Each request may not only come from a different port,
but a different IP address.

Some ISP's work as above, also.

Or if your user has a dynamic IP, that IP can change whenever the lease
expires.

Finally, if someone else does get the session id, if they're behind that
proxy, they can get access to the user's session anyway.

The bottom line is - trying to use the ip address and/or port number for
security is a waste of time and will only serve to annoy your users.

0 new messages