NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > PHP Discussion Digest> 2003-05

php-general Digest 31 May 2003 00:35:19 -0000 Issue 2088

php-general-digest-helplists.php.net
Date: Fri May 30 2003 - 19:35:19 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 31 May 2003 00:35:19 -0000 Issue 2088

Topics (messages 149550 through 149621):

Re: Can we use one PHP.INI directive to set the other?
149550 by: Ananth Kesari

Sessions can be dangerous
        149551 by: George Whiffen
        149552 by: Mike Morton
        149557 by: Wim Paulussen
        149563 by: Erik S. LaBianca - Quonic
        149564 by: Justin French
        149567 by: Rasmus Lerdorf

Re: Suggestion of webpage about search engines
149553 by: ruusvuu.whitney.dns2go.com
149592 by: Ryan A

Re: "Email This Story" and "Print" Functions
149554 by: Michael Geier
149555 by: Justin French

Re: mail function problem
149556 by: Michael Geier

php + java in winxp platform, reload dont work~
149558 by: Jason Chan

Re: strip_tags() Quandry....
        149559 by: Carl Furst
        149562 by: Noah
        149565 by: Carl Furst

Re: PHP 4.3.2 released
149560 by: Andrew Scott
149566 by: Justin French

Passing page referrer on as variable
149561 by: Mallen Baker
149568 by: Kevin Stone

CR in MySQL?
        149569 by: Brian Dunning
        149570 by: Dan Joseph
        149571 by: David Grant
        149573 by: Dan Joseph
        149575 by: David Grant
        149577 by: Dan Joseph
        149586 by: Narayana Reddy Gari, Ramki (MED)

reserver variable names
149572 by: Lee Doolan
149574 by: Kevin Stone

preg_match array question
        149576 by: Daniel J. Rychlik
        149578 by: David Grant
        149579 by: Chris Cook
        149581 by: Ralph
        149591 by: Daniel J. Rychlik
        149594 by: Ralph
        149596 by: Daniel J. Rychlik
        149603 by: Ralph
        149606 by: Daniel J. Rychlik

Cookies Probelm,
        149580 by: Haseeb Iqbal
        149582 by: Jay Blanchard
        149583 by: Haseeb Iqbal
        149584 by: Jay Blanchard
        149585 by: Catalin Trifu

Assignment operator questions
149587 by: Andrew D. Luebke
149588 by: Joe Stump

Best Practices in Directory Layout?
149589 by: motorpsychkill
149597 by: Jim Lucas

Re: \n outputs \r\n ??
149590 by: Michael Isaacs

Problem with DB2 on Linux?
149593 by: Scott Fletcher

Adding graphics library
149595 by: Todd Cary
149610 by: ef

static vars question
        149598 by: Martin Helie
        149599 by: Steve Keller
        149605 by: Martin Helie
        149607 by: Steve Keller
        149608 by: Martin Helie
        149611 by: Steve Keller
        149617 by: Ernest E Vogelsinger
        149620 by: Martin Helie

array count() oddity
149600 by: Guru Geek
149602 by: Kevin Stone

XPath and Namespaces
149601 by: andre.varney.apollis.com

Help about these algorithm methods
149604 by: o_j_p_p.icnet.com.ve
149615 by: olinux

Re: Variables not being past
149609 by: John Zimmerman

How to secure a download ?
149612 by: Vincent M.
149616 by: Evan Nemerson

What's wrong with this code??
        149613 by: Beauford
        149614 by: Jennifer Goodie
        149618 by: Ernest E Vogelsinger
        149619 by: Beauford

Code Help Please
149621 by: [-^-!-%-

Administrivia:

To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

Thanks. I too thought so, but still wanted to find out if there is a way
out.

Regards,
Ananth.

>>> "Catalin Trifu" <catalinisp-software.de> 5/30/2003 12:39:44 AM
>>>
Hi,

Simply put: it doesn't work; you have to put it by hand there,
or use the ini_set function in all PHP scripts you need.

Cheers,
Catalin

"Ananth Kesari" <hyananthanovell.com> wrote in message
news:sed5dd36.065prv-mail25.provo.novell.com...
> Hi,
>
> Can we use one PHP.INI directive to set the other?
>
> What I mean is like this:
>
> Let's say I have:
> upload_tmp_dir = sys:/php/temp
> in the PHP.INI file.
>
> Now I want to set the same value into the open_basedir directive
like:
> open_basedir = ".;sys:/php/temp"
>
> Here, I do not want to hard code "sys:/ptp/temp", but I want this
> to be read off from the upload_tmp_dir directive of PHP.INI file.
> Something to this effect:
> open_basedir = ".;$upload_tmp_dir"
>
> The above doesn't work.
>
> Can something like this be done and if yes, how?
>
> Thanks,
> Ananth.
>

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

attached mail follows:

Dear All,

There doesn't seem to be much discussion of the disadvantages and long
term dangers of using php "sessions". So let's redress the balance:

1. Heterogeneous Code Environments
php session data is not easily accessible from non-php code e.g.
Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies,
hidden posts, get variables, or data stored in a structured database
table, (i.e. one column per variable), is easily accessible from other
code.

The implication is that sessions may suit you fine as long as only php
is used on your site. However, if your site matures and you ever want
or need to use another language for some pages, it will be hard for
those pages to access data stored in sessions. On the other hand, if
the data had been stored in an well-established industry standard
format, you should have no problems.

2. Provably Secure Authentication Data

Hopefully we all know by now that the best way to safely authenticate
for access control is to make sure the username/password is checked
every time either by your script, your webserver or a trusted third-party.

However, I have the feeling some session users are tempted to simply
authenticate in one script and store a "logged in" or username flag in
the session without the username/password having been re-validated.

It's not a complete disaster if you do this, which probably means lots
of people do it! But this is only as secure as the session_id key. I
don't doubt that session_ids are generated with a high-quality random
number generator and should be suitably uncrackable.

However, the crackability/vulnerability of a username/password schema is
very well understood. Can we really say that the
vulnerability/crackability of a session_id is as well understood?

What happens if, and I'm sure it's a remote chance, there is ever a bug
in the session-key generation that stops them being so random so a
"session_id" crack becomes not just possible but real easy!

Usernames/passwords just don't have that kind of vulnerability, and the
vulnerabilities they do have are well known.

3. Independent Audit of Server Stored Data

Procedures for independently verifying the data stored on a server in a
SQL RDBMs are well established. It is easy to query the database schema
to see what columns are defined. It is easy to verify that the data
actually held in a column is as expected. In general it is easy to
prove and verify what data is held e.g. to prove Data Protection
compliance or Bank/Credit Card requirements, (no storage of cvv2 for
example).

It is intrinsically much harder to prove that the contents of php
session data are compliant. You need to write a php script to unpack
the session data. That means proving that that script itself is safe.
Even after you've unpacked the session data, you still have to make
sense of it. Different sessions may hold different numbers of
differently named variables. But that's not all, the same variable may
hold data in different formats in different sessions!

Practically you have some pretty complex processes to prove what data
you have stored and to verify that you have stored what you thought
you'd stored!

All in all, php sessions are NOT going to be popular with data auditors.
Once again, that may not matter to you now, but down the line it could
become a BIG issue.

4. State-ful Designs

My personal concern about sessions, is more about the design issues.
What worries me is that sessions may be used to try and re-create
client/server style "state" when the most distinctive advantage of the
internet, (and the key to its astounding success), is that it is
fundamentally state-less.

What this means, is that the internet is based on the principle that
every request is entirely self-contained and independent of any other
request. There is for example, absolutely and explicitly, no guarantee
that http requests will be received in chronological order. It is all
strictly about "best effort", and no guarantees. This is why the
internet works: each component does its own job as well as it can
without worrying about what else is happening.

The implication from a design point of view is that you should not be
making any assumptions about what has "gone before" or what "will come
after" your php script runs. The functionality offered, should, as far
as possible, be completely self-contained, with each php script acting
as a "component" in its own right. That means no direct interaction
between the scripts. Interaction should be gated through third-party
standard interfaces such as http or SQL.

The problem with sessions is that they encourage you to break this model
by creating a new set of "super-global" data holding "state"
information. This data is not exchanged through established standards,
but rather, "floats around" in the background, changing the behaviour of
the script but without being clearly externally defined.

If the session data is only concerned with "cosmetic" data such as user
style and colour preferences, this doesn't particularly matter. But if
it holds important or critical data, it does matter. Each script is no
longer a well-defined self-contained component, but more or less
intimately bound up with other scripts that share the same session.

It's worth remembering that there is nothing remotely new about
"state-ful" design. VDUs connected to mainframes are about as state-ful
as you can get. Indeed, the single distinctive feature of the two most
successful software technologies of all time, (the internet and SQL), is
that, (unlike their predecessors), they are both fundamentally
state-less protocols.

5. Reduced Component Reusability

A practical example of the problems of this style of "state-ful" code is
in reduced reusability of the components, (php scripts in this case).
One of the great benefits of the internet's stateless approach is the
tremendous ease with which uri-addressable components can be reused.
For example, a single graphic can be very easily used on any web page,
anywhere, anytime, with no additional effort than making it available on
one web page on one site, once.

Similarily, php scripts which are properly structured components, (e.g.
no significant session data use), can be reused, without code change for
many different purposes. If session data is used, e.g. to pass search
criteria or results data between pages, this flexibility is
significantly reduced.

For example, it's very handy when maintaining data in one table, to be
able to offer direct links to updates of related data. But if the update
form for the related data is coded to expect the details of what it must
update from session data e.g. to have been set from a search/list/select
page, this won't work. So, just because you used sessions, you, (or
someone else), may not be able to offer direct links, (or bookmarks), to
the update page even when the appropriate database keys are already
known. You either have to force the user to duplicate effort by
unnecessary traversing of a new search/list/select or you have to write
new code to handle this new type of request.

On the other hand if the update is coded as a proper component i.e. it
reads the key of the data to be updated from the http request, (GET,
POST or COOKIE), then you can automatically allow it to be accessed from
anywhere without having to always go through some particular
search/list/select sequence.

This is one, among many possible, examples of how, by establishing a
hidden, private, relationship between php scripts, session data
automatically and inevitably reduces the accessibility of the
functionality of the script.

There is a direct parallel in "lower-level" code structures. Over use
of session data is as intrinsically hostile to code re-use as over use
of global data to communicate between distinct functions or objects.
Just as functions and objects should use the "public" interface to
exchange data i.e. arguments/methods/properties, so php scripts should
exchange data via "public" interfaces i.e. http requests, databases etc.

Well, I've convinced myself. Of course, as I don't use sessions I may
have missed something, (or everything). So, please, what have I got wrong?

George

attached mail follows:

Some great points in here George - but it leaves me hanging....

What are the options? If we are not to use a 'state-ful' system, how do you
track users preferences, login/logout states, shopping baskets, and other
items that need sessions or some other type of reliable tracking method?

Not that I am saying sessions are 100% reliaable - they are as good only as
the cookie that is returned, and that is not 100% reliable - but it is the
most reliable method that I am aware of - unless I am missing something :)

So all that you say may be true, but what are the options?

On 5/30/03 10:26 AM, "George Whiffen" <georgewhiffen.net> wrote:

> Dear All,
>
> There doesn't seem to be much discussion of the disadvantages and long
> term dangers of using php "sessions". So let's redress the balance:
>
> 1. Heterogeneous Code Environments
> php session data is not easily accessible from non-php code e.g.
> Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies,
> hidden posts, get variables, or data stored in a structured database
> table, (i.e. one column per variable), is easily accessible from other
> code.
>
> The implication is that sessions may suit you fine as long as only php
> is used on your site. However, if your site matures and you ever want
> or need to use another language for some pages, it will be hard for
> those pages to access data stored in sessions. On the other hand, if
> the data had been stored in an well-established industry standard
> format, you should have no problems.
>
> 2. Provably Secure Authentication Data
>
> Hopefully we all know by now that the best way to safely authenticate
> for access control is to make sure the username/password is checked
> every time either by your script, your webserver or a trusted third-party.
>
> However, I have the feeling some session users are tempted to simply
> authenticate in one script and store a "logged in" or username flag in
> the session without the username/password having been re-validated.
>
> It's not a complete disaster if you do this, which probably means lots
> of people do it! But this is only as secure as the session_id key. I
> don't doubt that session_ids are generated with a high-quality random
> number generator and should be suitably uncrackable.
>
> However, the crackability/vulnerability of a username/password schema is
> very well understood. Can we really say that the
> vulnerability/crackability of a session_id is as well understood?
>
> What happens if, and I'm sure it's a remote chance, there is ever a bug
> in the session-key generation that stops them being so random so a
> "session_id" crack becomes not just possible but real easy!
>
> Usernames/passwords just don't have that kind of vulnerability, and the
> vulnerabilities they do have are well known.
>
> 3. Independent Audit of Server Stored Data
>
> Procedures for independently verifying the data stored on a server in a
> SQL RDBMs are well established. It is easy to query the database schema
> to see what columns are defined. It is easy to verify that the data
> actually held in a column is as expected. In general it is easy to
> prove and verify what data is held e.g. to prove Data Protection
> compliance or Bank/Credit Card requirements, (no storage of cvv2 for
> example).
>
> It is intrinsically much harder to prove that the contents of php
> session data are compliant. You need to write a php script to unpack
> the session data. That means proving that that script itself is safe.
> Even after you've unpacked the session data, you still have to make
> sense of it. Different sessions may hold different numbers of
> differently named variables. But that's not all, the same variable may
> hold data in different formats in different sessions!
>
> Practically you have some pretty complex processes to prove what data
> you have stored and to verify that you have stored what you thought
> you'd stored!
>
> All in all, php sessions are NOT going to be popular with data auditors.
> Once again, that may not matter to you now, but down the line it could
> become a BIG issue.
>
> 4. State-ful Designs
>
> My personal concern about sessions, is more about the design issues.
> What worries me is that sessions may be used to try and re-create
> client/server style "state" when the most distinctive advantage of the
> internet, (and the key to its astounding success), is that it is
> fundamentally state-less.
>
> What this means, is that the internet is based on the principle that
> every request is entirely self-contained and independent of any other
> request. There is for example, absolutely and explicitly, no guarantee
> that http requests will be received in chronological order. It is all
> strictly about "best effort", and no guarantees. This is why the
> internet works: each component does its own job as well as it can
> without worrying about what else is happening.
>
> The implication from a design point of view is that you should not be
> making any assumptions about what has "gone before" or what "will come
> after" your php script runs. The functionality offered, should, as far
> as possible, be completely self-contained, with each php script acting
> as a "component" in its own right. That means no direct interaction
> between the scripts. Interaction should be gated through third-party
> standard interfaces such as http or SQL.
>
> The problem with sessions is that they encourage you to break this model
> by creating a new set of "super-global" data holding "state"
> information. This data is not exchanged through established standards,
> but rather, "floats around" in the background, changing the behaviour of
> the script but without being clearly externally defined.
>
> If the session data is only concerned with "cosmetic" data such as user
> style and colour preferences, this doesn't particularly matter. But if
> it holds important or critical data, it does matter. Each script is no
> longer a well-defined self-contained component, but more or less
> intimately bound up with other scripts that share the same session.
>
> It's worth remembering that there is nothing remotely new about
> "state-ful" design. VDUs connected to mainframes are about as state-ful
> as you can get. Indeed, the single distinctive feature of the two most
> successful software technologies of all time, (the internet and SQL), is
> that, (unlike their predecessors), they are both fundamentally
> state-less protocols.
>
>
> 5. Reduced Component Reusability
>
> A practical example of the problems of this style of "state-ful" code is
> in reduced reusability of the components, (php scripts in this case).
> One of the great benefits of the internet's stateless approach is the
> tremendous ease with which uri-addressable components can be reused.
> For example, a single graphic can be very easily used on any web page,
> anywhere, anytime, with no additional effort than making it available on
> one web page on one site, once.
>
> Similarily, php scripts which are properly structured components, (e.g.
> no significant session data use), can be reused, without code change for
> many different purposes. If session data is used, e.g. to pass search
> criteria or results data between pages, this flexibility is
> significantly reduced.
>
> For example, it's very handy when maintaining data in one table, to be
> able to offer direct links to updates of related data. But if the update
> form for the related data is coded to expect the details of what it must
> update from session data e.g. to have been set from a search/list/select
> page, this won't work. So, just because you used sessions, you, (or
> someone else), may not be able to offer direct links, (or bookmarks), to
> the update page even when the appropriate database keys are already
> known. You either have to force the user to duplicate effort by
> unnecessary traversing of a new search/list/select or you have to write
> new code to handle this new type of request.
>
> On the other hand if the update is coded as a proper component i.e. it
> reads the key of the data to be updated from the http request, (GET,
> POST or COOKIE), then you can automatically allow it to be accessed from
> anywhere without having to always go through some particular
> search/list/select sequence.
>
> This is one, among many possible, examples of how, by establishing a
> hidden, private, relationship between php scripts, session data
> automatically and inevitably reduces the accessibility of the
> functionality of the script.
>
> There is a direct parallel in "lower-level" code structures. Over use
> of session data is as intrinsically hostile to code re-use as over use
> of global data to communicate between distinct functions or objects.
> Just as functions and objects should use the "public" interface to
> exchange data i.e. arguments/methods/properties, so php scripts should
> exchange data via "public" interfaces i.e. http requests, databases etc.
>
>
>
> Well, I've convinced myself. Of course, as I don't use sessions I may
> have missed something, (or everything). So, please, what have I got wrong?
>
>
>
> George
>

--
Cheers

Mike Morton

****************************************************
*
* Tel: 905-465-1263
* Email: mikewebtraxx.com
*
****************************************************

"Indeed, it would not be an exaggeration to describe the history of the
computer industry for the past decade as a massive effort to keep up with
Apple."
- Byte Magazine

Given infinite time, 100 monkeys could type out the complete works of
Shakespeare. Win 98 source code? Eight monkeys, five minutes.
-- NullGrey

attached mail follows:

George,

Having created an invoicing system using php , I very clearly understand the
advantage the session construction holds : the information is maintained on
the server, rather than floating around in cyberspace between the client and
server each and every time you exchange information.
If you want to use hidden input you need to set up a secure link each and
every time you transfer the o so important username/password combination.
Furthermore , the session data is not that difficult to access with another
program as long as you can capture the session-id, which you can.
All in all , I did not yet come across a better system to get something
working in a manageable and secure way.
You could go a step further and mimick the session_data management via a
database interface if your data quality is such an important issue, but then
again, make sure you have a foolproof system to make logging in into the
database secure !
Nobody forces you to use the session system and if you want to shy away from
it , it is your choice, but I am a little bit afraid that your lenghty email
about session insecurity will be meaningfull only for the core PHP
developers/auditors.

Wim

-----Oorspronkelijk bericht-----
Van: George Whiffen [mailto:georgewhiffen.net]
Verzonden: Friday, May 30, 2003 4:27 PM
Aan: php-generallists.php.net
Onderwerp: [PHP] Sessions can be dangerous

Dear All,

There doesn't seem to be much discussion of the disadvantages and long
term dangers of using php "sessions". So let's redress the balance:

2. Provably Secure Authentication Data

However, the crackability/vulnerability of a username/password schema is
very well understood. Can we really say that the
vulnerability/crackability of a session_id is as well understood?

What happens if, and I'm sure it's a remote chance, there is ever a bug
in the session-key generation that stops them being so random so a
"session_id" crack becomes not just possible but real easy!

Usernames/passwords just don't have that kind of vulnerability, and the
vulnerabilities they do have are well known.

3. Independent Audit of Server Stored Data

Practically you have some pretty complex processes to prove what data
you have stored and to verify that you have stored what you thought
you'd stored!

All in all, php sessions are NOT going to be popular with data auditors.
Once again, that may not matter to you now, but down the line it could
become a BIG issue.

4. State-ful Designs

5. Reduced Component Reusability

Well, I've convinced myself. Of course, as I don't use sessions I may
have missed something, (or everything). So, please, what have I got wrong?

George

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

attached mail follows:

Wim

While I do see the usefullness of sessions, I have to disagree with you
on the security aspect. A session ID is just as vulnerable to sniffing
as is a username / password combination. The only security you gain from
using it instead is that it's value is time limited. If your application
reallys needs all that security, you'd better be using a secure
transport, period.

The session might even be worse, because, for instance, if you're using
the files session handler, another user of your system may be able to
easily read the current sessions id's from the temp folder, and hijack
an authenticated session, even if it were encrypted.

As george stated, there is also always the chance that the session_id
generator is NOT secure, in which case you're really up the proverbial
creek.

You're right, however, in that storing all the "state" information on
the server is a good thing. Why pollute your html with hidden fields, or
mangle the heck out of your urls. I DO believe that maintaining state is
a necessity when attempting to write "Applications" on the web, instead
of just "web pages".

--erik

Wim Paulussen wrote:

>George,
>
>Having created an invoicing system using php , I very clearly understand the
>advantage the session construction holds : the information is maintained on
>the server, rather than floating around in cyberspace between the client and
>server each and every time you exchange information.
>If you want to use hidden input you need to set up a secure link each and
>every time you transfer the o so important username/password combination.
>Furthermore , the session data is not that difficult to access with another
>program as long as you can capture the session-id, which you can.
>All in all , I did not yet come across a better system to get something
>working in a manageable and secure way.
>You could go a step further and mimick the session_data management via a
>database interface if your data quality is such an important issue, but then
>again, make sure you have a foolproof system to make logging in into the
>database secure !
>Nobody forces you to use the session system and if you want to shy away from
>it , it is your choice, but I am a little bit afraid that your lenghty email
>about session insecurity will be meaningfull only for the core PHP
>developers/auditors.
>
>Wim
>
>
>-----Oorspronkelijk bericht-----
>Van: George Whiffen [mailto:georgewhiffen.net]
>Verzonden: Friday, May 30, 2003 4:27 PM
>Aan: php-generallists.php.net
>Onderwerp: [PHP] Sessions can be dangerous
>
>
>Dear All,
>
>There doesn't seem to be much discussion of the disadvantages and long
>term dangers of using php "sessions". So let's redress the balance:
>
>1. Heterogeneous Code Environments
>php session data is not easily accessible from non-php code e.g.
>Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies,
>hidden posts, get variables, or data stored in a structured database
>table, (i.e. one column per variable), is easily accessible from other
>code.
>
>The implication is that sessions may suit you fine as long as only php
>is used on your site. However, if your site matures and you ever want
>or need to use another language for some pages, it will be hard for
>those pages to access data stored in sessions. On the other hand, if
>the data had been stored in an well-established industry standard
>format, you should have no problems.
>
>2. Provably Secure Authentication Data
>
>Hopefully we all know by now that the best way to safely authenticate
>for access control is to make sure the username/password is checked
>every time either by your script, your webserver or a trusted third-party.
>
>However, I have the feeling some session users are tempted to simply
>authenticate in one script and store a "logged in" or username flag in
>the session without the username/password having been re-validated.
>
>It's not a complete disaster if you do this, which probably means lots
>of people do it! But this is only as secure as the session_id key. I
>don't doubt that session_ids are generated with a high-quality random
>number generator and should be suitably uncrackable.
>
>However, the crackability/vulnerability of a username/password schema is
>very well understood. Can we really say that the
>vulnerability/crackability of a session_id is as well understood?
>
>What happens if, and I'm sure it's a remote chance, there is ever a bug
>in the session-key generation that stops them being so random so a
>"session_id" crack becomes not just possible but real easy!
>
>Usernames/passwords just don't have that kind of vulnerability, and the
>vulnerabilities they do have are well known.
>
>3. Independent Audit of Server Stored Data
>
>Procedures for independently verifying the data stored on a server in a
>SQL RDBMs are well established. It is easy to query the database schema
>to see what columns are defined. It is easy to verify that the data
>actually held in a column is as expected. In general it is easy to
>prove and verify what data is held e.g. to prove Data Protection
>compliance or Bank/Credit Card requirements, (no storage of cvv2 for
>example).
>
>It is intrinsically much harder to prove that the contents of php
>session data are compliant. You need to write a php script to unpack
>the session data. That means proving that that script itself is safe.
>Even after you've unpacked the session data, you still have to make
>sense of it. Different sessions may hold different numbers of
>differently named variables. But that's not all, the same variable may
>hold data in different formats in different sessions!
>
>Practically you have some pretty complex processes to prove what data
>you have stored and to verify that you have stored what you thought
>you'd stored!
>
>All in all, php sessions are NOT going to be popular with data auditors.
> Once again, that may not matter to you now, but down the line it could
>become a BIG issue.
>
>4. State-ful Designs
>
>My personal concern about sessions, is more about the design issues.
>What worries me is that sessions may be used to try and re-create
>client/server style "state" when the most distinctive advantage of the
>internet, (and the key to its astounding success), is that it is
>fundamentally state-less.
>
>What this means, is that the internet is based on the principle that
>every request is entirely self-contained and independent of any other
>request. There is for example, absolutely and explicitly, no guarantee
>that http requests will be received in chronological order. It is all
>strictly about "best effort", and no guarantees. This is why the
>internet works: each component does its own job as well as it can
>without worrying about what else is happening.
>
>The implication from a design point of view is that you should not be
>making any assumptions about what has "gone before" or what "will come
>after" your php script runs. The functionality offered, should, as far
>as possible, be completely self-contained, with each php script acting
>as a "component" in its own right. That means no direct interaction
>between the scripts. Interaction should be gated through third-party
>standard interfaces such as http or SQL.
>
>The problem with sessions is that they encourage you to break this model
>by creating a new set of "super-global" data holding "state"
>information. This data is not exchanged through established standards,
>but rather, "floats around" in the background, changing the behaviour of
>the script but without being clearly externally defined.
>
>If the session data is only concerned with "cosmetic" data such as user
>style and colour preferences, this doesn't particularly matter. But if
>it holds important or critical data, it does matter. Each script is no
>longer a well-defined self-contained component, but more or less
>intimately bound up with other scripts that share the same session.
>
>It's worth remembering that there is nothing remotely new about
>"state-ful" design. VDUs connected to mainframes are about as state-ful
>as you can get. Indeed, the single distinctive feature of the two most
>successful software technologies of all time, (the internet and SQL), is
>that, (unlike their predecessors), they are both fundamentally
>state-less protocols.
>
>
>5. Reduced Component Reusability
>
>A practical example of the problems of this style of "state-ful" code is
>in reduced reusability of the components, (php scripts in this case).
>One of the great benefits of the internet's stateless approach is the
>tremendous ease with which uri-addressable components can be reused.
>For example, a single graphic can be very easily used on any web page,
>anywhere, anytime, with no additional effort than making it available on
>one web page on one site, once.
>
>Similarily, php scripts which are properly structured components, (e.g.
>no significant session data use), can be reused, without code change for
>many different purposes. If session data is used, e.g. to pass search
>criteria or results data between pages, this flexibility is
>significantly reduced.
>
>For example, it's very handy when maintaining data in one table, to be
>able to offer direct links to updates of related data. But if the update
>form for the related data is coded to expect the details of what it must
>update from session data e.g. to have been set from a search/list/select
>page, this won't work. So, just because you used sessions, you, (or
>someone else), may not be able to offer direct links, (or bookmarks), to
>the update page even when the appropriate database keys are already
>known. You either have to force the user to duplicate effort by
>unnecessary traversing of a new search/list/select or you have to write
>new code to handle this new type of request.
>
>On the other hand if the update is coded as a proper component i.e. it
>reads the key of the data to be updated from the http request, (GET,
>POST or COOKIE), then you can automatically allow it to be accessed from
>anywhere without having to always go through some particular
>search/list/select sequence.
>
>This is one, among many possible, examples of how, by establishing a
>hidden, private, relationship between php scripts, session data
>automatically and inevitably reduces the accessibility of the
>functionality of the script.
>
>There is a direct parallel in "lower-level" code structures. Over use
>of session data is as intrinsically hostile to code re-use as over use
>of global data to communicate between distinct functions or objects.
>Just as functions and objects should use the "public" interface to
>exchange data i.e. arguments/methods/properties, so php scripts should
>exchange data via "public" interfaces i.e. http requests, databases etc.
>
>
>
>Well, I've convinced myself. Of course, as I don't use sessions I may
>have missed something, (or everything). So, please, what have I got wrong?
>
>
>
>George
>
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>

attached mail follows:

on 31/05/03 1:26 AM, George Whiffen (georgewhiffen.net) wrote:

> 1. Heterogeneous Code Environments
> php session data is not easily accessible from non-php code e.g.
> Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies,
> hidden posts, get variables, or data stored in a structured database
> table, (i.e. one column per variable), is easily accessible from other
> code.
>
> The implication is that sessions may suit you fine as long as only php
> is used on your site. However, if your site matures and you ever want
> or need to use another language for some pages, it will be hard for
> those pages to access data stored in sessions. On the other hand, if
> the data had been stored in an well-established industry standard
> format, you should have no problems.
>
> 2. Provably Secure Authentication Data
>
> Hopefully we all know by now that the best way to safely authenticate
> for access control is to make sure the username/password is checked
> every time either by your script, your webserver or a trusted third-party.
>
> However, I have the feeling some session users are tempted to simply
> authenticate in one script and store a "logged in" or username flag in
> the session without the username/password having been re-validated.
>
> It's not a complete disaster if you do this, which probably means lots
> of people do it! But this is only as secure as the session_id key. I
> don't doubt that session_ids are generated with a high-quality random
> number generator and should be suitably uncrackable.
>
> However, the crackability/vulnerability of a username/password schema is
> very well understood. Can we really say that the
> vulnerability/crackability of a session_id is as well understood?
>
> What happens if, and I'm sure it's a remote chance, there is ever a bug
> in the session-key generation that stops them being so random so a
> "session_id" crack becomes not just possible but real easy!
>
> Usernames/passwords just don't have that kind of vulnerability, and the
> vulnerabilities they do have are well known.

Maybe I'm missing something, but generally speaking, session id's are
transmitted in plain text via either the URL, or via a cookie (neither of
which is usually under SSL) so I don't see why you're paying so much
attention to "cracking" or "hijacking" session ids... it is, to my
knowledge, really easy to find out someone's session id, and similarly easy
to hijack it.

What's the option other than storing a value like "logged in"??? Storing
the uid and pwd on the client side is a no-no, and storing them in the
session in no more secure that storing "logged in" since the session can be
hijacked.

My preference is to re-ask the user for a password before:

a) changing a password
b) doing anything secure (like changing passwords, transferring funds,
altering private information, etc etc)

which is the ONLY reinforcement that is secure (ask them, then ask them
again later).

I don't really get your point. Yes, sessions can be unsecure, but so can
$_GET variables in the wrong hands.

> 3. Independent Audit of Server Stored Data
>
> Procedures for independently verifying the data stored on a server in a
> SQL RDBMs are well established. It is easy to query the database schema
> to see what columns are defined. It is easy to verify that the data
> actually held in a column is as expected. In general it is easy to
> prove and verify what data is held e.g. to prove Data Protection
> compliance or Bank/Credit Card requirements, (no storage of cvv2 for
> example).
>
> It is intrinsically much harder to prove that the contents of php
> session data are compliant. You need to write a php script to unpack
> the session data. That means proving that that script itself is safe.
> Even after you've unpacked the session data, you still have to make
> sense of it. Different sessions may hold different numbers of
> differently named variables. But that's not all, the same variable may
> hold data in different formats in different sessions!
>
> Practically you have some pretty complex processes to prove what data
> you have stored and to verify that you have stored what you thought
> you'd stored!
>
> All in all, php sessions are NOT going to be popular with data auditors.
> Once again, that may not matter to you now, but down the line it could
> become a BIG issue.

As long as an user-supplied data is appropriately validated before storing
in sessions, I cannot see a way for the user to harm the session data, or to
store bad data. Isn't the the whole point of storing JUST a session ID on
the client machine (either in URL or cookie) and the data server-side,
rather than storing all data client-side????

If a user indicates a preference for a blue background, and I validate the
data that states this (sent to the script via POST or GET) before storing it
as a session var, then I can't see where the danger lies... only PHP scripts
have access to session data, and only a validated, expected data should be
added to the session.

> 4. State-ful Designs
>
> My personal concern about sessions, is more about the design issues.
> What worries me is that sessions may be used to try and re-create
> client/server style "state" when the most distinctive advantage of the
> internet, (and the key to its astounding success), is that it is
> fundamentally state-less.
>
> What this means, is that the internet is based on the principle that
> every request is entirely self-contained and independent of any other
> request. There is for example, absolutely and explicitly, no guarantee
> that http requests will be received in chronological order. It is all
> strictly about "best effort", and no guarantees. This is why the
> internet works: each component does its own job as well as it can
> without worrying about what else is happening.
>
> The implication from a design point of view is that you should not be
> making any assumptions about what has "gone before" or what "will come
> after" your php script runs. The functionality offered, should, as far
> as possible, be completely self-contained, with each php script acting
> as a "component" in its own right. That means no direct interaction
> between the scripts. Interaction should be gated through third-party
> standard interfaces such as http or SQL.
>
> The problem with sessions is that they encourage you to break this model
> by creating a new set of "super-global" data holding "state"
> information. This data is not exchanged through established standards,
> but rather, "floats around" in the background, changing the behaviour of
> the script but without being clearly externally defined.
>
> If the session data is only concerned with "cosmetic" data such as user
> style and colour preferences, this doesn't particularly matter. But if
> it holds important or critical data, it does matter. Each script is no
> longer a well-defined self-contained component, but more or less
> intimately bound up with other scripts that share the same session.
>
> It's worth remembering that there is nothing remotely new about
> "state-ful" design. VDUs connected to mainframes are about as state-ful
> as you can get. Indeed, the single distinctive feature of the two most
> successful software technologies of all time, (the internet and SQL), is
> that, (unlike their predecessors), they are both fundamentally
> state-less protocols.

Huh? A session ID is a value passed around in the URL or via a cookie to
maintain state. That is, separate scripts on a server can recognise and
differentiate two different browsers/sessions/users.

Assigning server-side session variables to that session ID means that from
one request to another, a php script can determine what's been done in the
past... this might be something insignificant, like remembering a colour
preference, or it might be remembering a number of items that the user
wishes to purchase.

All this is done via http (page requests and passing the session id around),
with the data stored server side in a flat file, or in memory, or yes, even
in an SQL database.

How else would you propose my script remember your shopping list other than:

- cookies (laughable)
- extremely long URLs and hidden POST variables
- asking you to write it down on a piece of paper and remind my script later

Regardless of whether you feel the internet should have state, or should not
is pointless... the fact is, there are internet applications which require
state...

If it is possible to maintain state (with, for example, a session id which
identifies the browser/user, and relates this back to data stored server
side) via http, then I would say that the internet *CAN* have state.

> 5. Reduced Component Reusability
>
> A practical example of the problems of this style of "state-ful" code is
> in reduced reusability of the components, (php scripts in this case).
> One of the great benefits of the internet's stateless approach is the
> tremendous ease with which uri-addressable components can be reused.
> For example, a single graphic can be very easily used on any web page,
> anywhere, anytime, with no additional effort than making it available on
> one web page on one site, once.
>
> Similarily, php scripts which are properly structured components, (e.g.
> no significant session data use), can be reused, without code change for
> many different purposes. If session data is used, e.g. to pass search
> criteria or results data between pages, this flexibility is
> significantly reduced.
>
> For example, it's very handy when maintaining data in one table, to be
> able to offer direct links to updates of related data. But if the update
> form for the related data is coded to expect the details of what it must
> update from session data e.g. to have been set from a search/list/select
> page, this won't work. So, just because you used sessions, you, (or
> someone else), may not be able to offer direct links, (or bookmarks), to
> the update page even when the appropriate database keys are already
> known. You either have to force the user to duplicate effort by
> unnecessary traversing of a new search/list/select or you have to write
> new code to handle this new type of request.
>
> On the other hand if the update is coded as a proper component i.e. it
> reads the key of the data to be updated from the http request, (GET,
> POST or COOKIE), then you can automatically allow it to be accessed from
> anywhere without having to always go through some particular
> search/list/select sequence.
>
> This is one, among many possible, examples of how, by establishing a
> hidden, private, relationship between php scripts, session data
> automatically and inevitably reduces the accessibility of the
> functionality of the script.
>
> There is a direct parallel in "lower-level" code structures. Over use
> of session data is as intrinsically hostile to code re-use as over use
> of global data to communicate between distinct functions or objects.
> Just as functions and objects should use the "public" interface to
> exchange data i.e. arguments/methods/properties, so php scripts should
> exchange data via "public" interfaces i.e. http requests, databases etc.

A session is no more than recognising a browser/user/session via a http
request, and relating it to information stored on the server (files, memory,
databases), giving a form of state.

The only danger lies in people hijacking session ids.

> Well, I've convinced myself. Of course, as I don't use sessions I may
> have missed something, (or everything). So, please, what have I got wrong?

I think the key point you're missing is that a session id is just a way of
differentiating between two users/browsers/sesssions. Rather than passing
multitudes of data around in a URL (easy to spoof), Cookie (easy to spoof)
or POST variable (also easy to spoof) and letting anyone fiddle with it, all
we do is pass around a unique identifier, which relates this session back to
data stored on the server in a file, memory or a database.

Rather than constantly having to revalidate and check user-supplied data
from URLs and cookies, you check it once, then assign it to the session.

I'm not sure what you'd use sessions for, but me, I like to remember if a
user is logged in, what their preferences are for language and dates and the
like, what items they want to buy, etc etc... passing a value like "logged
in" around in a URL, cookie or POST var page after page after page is just
ludicrous... more than anything else, it gives the user opportunity to alter
the value (requiring another check, and opening up security holes the size
of the grand canyon).

I'd recommend you actually create a small app which uses sessions, and get
to know them, THEN come up with a list of complaints... it's nothing more
than http requests, GET variables (or cookies), and server-stored data all
related to each other.

Coupled with a smart programmer who knows how to check/validate data, I
haven't seen any flaws in PHPs implementation of sessions.

You are aware that you could write your own session handling code?

You are also aware that every major shopping site (let's start with the
obvious, amazon.com) uses state to remember what you want to buy??? Some
sites do it client-side (cookies -- shudder) and others do it server-side
with an identifier passed around in the URL or a cookie (commonly referred
to as sessions).

It's late, so I hope I'm being clear, and giving you the information you
need.

Justin

attached mail follows:

On Fri, 30 May 2003, George Whiffen wrote:
> 1. Heterogeneous Code Environments
> php session data is not easily accessible from non-php code e.g.
> Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies,
> hidden posts, get variables, or data stored in a structured database
> table, (i.e. one column per variable), is easily accessible from other
> code.

For anything beyond a trivial application, you are going to be writing
your own backend save_handler anyway, so I don't really see how this is an
issue. If you don't want to write your own save_handler (which is really
really easy) you can always just set "session.serialize_handler = wddx" in
your php.ini file and you will have the data stored in a standard XML
format instead. This format is very accessible from non-PHP code.

> 2. Provably Secure Authentication Data
>
> Hopefully we all know by now that the best way to safely authenticate
> for access control is to make sure the username/password is checked
> every time either by your script, your webserver or a trusted third-party.
>
> However, I have the feeling some session users are tempted to simply
> authenticate in one script and store a "logged in" or username flag in
> the session without the username/password having been re-validated.

Sure, but this isn't really specific to sessions. I would say this is
related to any cookie a developer might create. There is always the
temptation to not include the auth headers on each page and just toss the
logged in user id into the cookie. This is obviously a bad idea, but I
wouldn't necessarily attribute this to an inherent danger in sessions.

Again, see point 1. Any real usage of sessions is going to need a custom
save_handler most likely written against a real database. You simply
cannot go beyond a trivial single-server web-app without doing so and the
facilities in the php session support for doing this is good.

The boat has long since sailed on this one. People need and want to
maintain state. You can't build any sort of shopping-cart style site
without them.

> 5. Reduced Component Reusability
>
> ...
>
> On the other hand if the update is coded as a proper component i.e. it
> reads the key of the data to be updated from the http request, (GET,
> POST or COOKIE), then you can automatically allow it to be accessed from
> anywhere without having to always go through some particular
> search/list/select sequence.

I tend to distinguish between the human interface to an app and the
machine interface. Trying to put them both into the same interface tends
to make them cumbersome for both sides. Often the human interface is just
a thin layer on top of an underlying machine interface and it is at the
machine interface that you have your reusability and transparency. In a
properly designed architecture, the session layer is simply part of the
human interface and really doesn't affect the reusability of your base
machine interface.

-Rasmus

attached mail follows:

C'mon! You built this site - don't lie and say you 'found' it!

Quoting l <l.pcentrum.cz>:

> I found one small site (designed in php of course:)) what care about
> registration on search engines and search engine optimalization here:
>
> http://submit.prolidi.net/en/
>
> I found some of the information very helpful, so I send it to you.
>
> L.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:

Liar Liar,
This is your site......I recognize the english/spelling mistakes.

-Ryan

----- Original Message -----
From: "l" <l.pcentrum.cz>
To: <php-generallists.php.net>
Sent: Friday, May 30, 2003 2:24 PM
Subject: [PHP] Suggestion of webpage about search engines

attached mail follows:

the Print this Story really doesn't have anything to do with PHP, if you
are referring to actually sending the page to a printer (see Javascript)

if you are storing your articles in a DB, simply pull the info out and
create a mailbody for the Email this Story function.

On Fri, 2003-05-30 at 02:36, Jeffrey L. Fitzgerald wrote:
> Thanks to Kevin, Monty and the others who helped with my earlier post...
>
> Anyone have experience with PHP based "Email This Story" and "Print This
> Story" functions?? I am looking to add these along with a digital postcard
> mailer.
--
Michael Geier <mgeiercdmsports.com>

attached mail follows:

on 30/05/03 6:36 PM, Jeffrey L. Fitzgerald (mailgroupsjlfx.com) wrote:

> Thanks to Kevin, Monty and the others who helped with my earlier post...
>
> Anyone have experience with PHP based "Email This Story" and "Print This
> Story" functions?? I am looking to add these along with a digital postcard
> mailer.

"Email this story" is a way of someone emailing the contents of a page, OR
the URL of the page (more common) to a friend.... so all you need to do is
know what page they're trying to email, collect the sender and recipient
email address', and send a URL & short message with mail(). Look in the
$_SERVER array for some values which will tell you the current URL & query
string.

"Print this page" can be as simple as an alternate style sheet, or a
simplified way of presenting data on a page, which is printer-friendly.

If you're pulling your main content out of databases or flat files, then it
should be relatively easy to set a value in the URL ($_GET array) which
toggles between a complex (regular) page layout, and a simple (print)
layout.

Think it through.

Justin

attached mail follows:

changing the value in the php.ini file is not the ideal option, as it
screws things up for all of users/scripts on the server.

you could use ini_set() for the script to change the sendmail_path var
for that script.

you could use a mail class that does alot of the grunt work for you
(Manuel Lemos normally posts some classes from his site, however I use
PHPMailer (http://phpmailer.sourceforge.net) and have never looked back.

On Fri, 2003-05-30 at 03:26, David Grant wrote:
> Bersani Francesco wrote:
>
> > Hi, I have a problem with the "mail" function; it always sends mails
> > assuming in the "from" field the user "apachemyserver.mydomain".
> > I tried to override it with this code:
> >
> > ----------------
> > <?
> > $email = "accountdomain.it";
> > $subject = "prova invio mail ";
> > $message = "parappaaaaaaaaaaa ";
> > $headers = "From:webmastermyDomain.it\nReply-To:webmastermyDomain.it";
> >
> > mail($email, $subject, $message, $headers);
> >
> > ?>
> > ------------------
> >
> > It doesn't work...
> >
> > Can anybody help me ?
>
>
> Take a peek into php.ini to change the default value.
>
> Note that you should seperate mail headers with \r\n.
>
> Regards,
>
> David
>
>
> --
> David Grant
> Web Developer
>
> david.grantwiredmedia.co.uk
> http://www.wiredmedia.co.uk
>
> Tel: 0117 930 4365, Fax: 0870 169 7625
>
> Wired Media Ltd
> Registered Office: 43 Royal Park, Bristol, BS8 3AN
> Studio: Whittakers House, 32 - 34 Hotwell Road, Bristol, BS8 4UD
>
> Company registration number: 4016744
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> **********************************************************************
--
Michael Geier <mgeiercdmsports.com>

attached mail follows:

Dear all,

i installed java jdk 1.4 and php 4.3.2
i tried to use java in php

i edited the php.ini as follows

[Java]
extension=php_java.dll
java.class.path = c:\php\extensions\php_java.jar
java.home = C:\j2sdk1.4.1_01
java.library = C:\j2sdk1.4.1_01\jre\bin\server\jvm.dll
java.library.path = c:\php\extensions

and test it with following codes and it works (the code copy from php.net)
<?php
// get instance of Java class java.lang.System in PHP
$system = new Java('java.lang.System');

// demonstrate property access
 print 'Java version='.$system->getProperty('java.version').' ';
 print 'Java vendor=' .$system->getProperty('java.vendor').' ';
 print 'OS='.$system->getProperty('os.name').' '.
 $system->getProperty('os.version').' on '.
 $system->getProperty('os.arch').' ';

  // java.util.Date example
  $formatter = new Java('java.text.SimpleDateFormat',
                        "EEEE, MMMM dd, yyyy 'at' h:mm:ss a zzzz");

print $formatter->format(new Java('java.util.Date'));

however the problem is when i first run this page in IE, it works
i click the reflesh button, it works
but if i closed the IE, and load the page in a new broswer,
it show "Fatal error: Unable to create Java Virtual Machine"
i have to restart the apache server to get it work again, so what is going on?

Jason

attached mail follows:

As you can guess, I'm more a fan of the regular expressions myself being
primarily a PERL head. However, PHP string functions are useful and
convenient (like trim() for example), and they don't require you to know the
in's and out's of regexps which can look like gobbledygook, be very
confusing, and sometimes very difficult to use if you don't really know how
they work. If you can get them to work, they are very powerful. However
getting them to work can require some serious tweaking.

I think the main thing when deciding which to use is how much control you
want over what is done to your string. Using a PHP function can lead to
precarious results sometimes if you don't know exactly what they do
(nl2br(), for example, you have to be sure that ALL of your 's are to
occur right before a "\n", this isn't always the case). They also don't
afford as much flexibility in some cases as regular expressions do
(str_replace for replacing multiple spaces, for example).

If it's something simple that you know a PHP function can take of, use it.
If not, use regexps. They may take a bit more tweaking, but in the long run
are much more flexible and a lot more powerful.

Carl.

-----Original Message-----
From: Noah [mailto:noahnewminddesign.com]
Sent: Thursday, May 29, 2003 11:03 PM
To: CPT John W. Holmes; Carl Furst
Cc: php-generallists.php.net
Subject: Re: [PHP] strip_tags() Quandry....

Hey John; Hey Carl.

I've heard this debate before; i.e. regular expressions vs. PHP string
formatting functions.

The problem I'm dealing with will require, I believe, a combination of
preg_replace(), str_replace(), strstr(), and str_pos().

To my limited knowledge, there is no way to remove white space with PHP
string functions; when I use strip_tags on a block of html text, whitespace
results; thus the need for preg_replace().

The rest can most likely be taken care of with PHP string functions,
although I'm running into a few headaches with user errors; i.e. when a
coach types up his/her team roster and mistakenly adds extra spaces between
fields (e.g. player height = 6' 2" instead of 6' 2"), or roster fields do
not match up with our roster table fields (e.g. one team roster has a field
for player's favorite professional athlete) -- in these cases it may be that
I'll need to use regular expressions to crawl through roster string data
looking for word boundaries and the like.

I'm new to regular expressions to say the least -- just took the dive in
yesterday; much to learn.......

If either of you feel like elaborating on the pros and cons of regular
expressions vs. PHP string functions, let me know.

--Noah

----- Original Message -----
From: "CPT John W. Holmes" <holmes072000charter.net>
To: "Carl Furst" <cfurstintracommunities.org>; "Noah"
<noahnewminddesign.com>
Cc: <php-generallists.php.net>
Sent: Thursday, May 29, 2003 10:18 AM
Subject: Re: [PHP] strip_tags() Quandry....

> Yes, no problem! Glad it worked out. you may wish to actually study the
> perlre man page on perl.com. This goes into the most details and talks
about
> how PERL actually EXTENDS shell regular expressions significantly and
> excellent resource that I have used many many times.
>
> I figure since PHP regexps are perl compatible, might as well go to the
> source, no?
>
> My other suggestion is that if you are taking this HTML and putting into a
> database, especially MySQL you should scrub for pipes, nulls and slashes,
> hackers can exploit user input to open a tty or shell or even access user
> files like /etc/passwd and mess wid ya.... here are a few regexps that do
> that

While I agree that regexp are powerful and useful, the examples you gave are
better suited to using str_replace(), trim(), or nl2br() calls rather than a
regular expression.

Also, about the "warning" for inserting data into a database... try not to
scare people to much. If you have

column = '$value'
or
column = "$value"

in your query, as long as you've run addslashes on $value to escape single
quotes in the first case and double quotes in the second, there's no
vulnerabilities.

If you have

column = $column

then you BETTER make sure that $column is a number and only a number. When
you put unquoted (unquoted within the actual SQL, not PHP) values into your
SQL, that's when you open yourself up to vulnerabilities if you're not
validating that the value is only a number.

> For pipes:
> preg_replace('/\|/g','',$html_string);
> For nulls:
> Preg_replace('/\0/g','',$html_string);
> For slashes
> preg_replace('/\//g','',$html_string); # to be clearer, you can use s!\/!
> g; just so you can see where the regexp begins and ends.

str_replace('|','',$html_string);
etc...

> Some other useful ones for data like the stuff you're doing:
> Spaces at the beginning:
> /^\s/
> spaces at the end:
> /\s$/

trim()

> tags into \n
> preg_replace('!\<br\>!', "\n", $string);

nl2br();

---John Holmes...

attached mail follows:

Exactly, Carl.

The HTML team data I'm dealing with comes in myriad formats -- nothing is
uniform as each school presents their team data differently, not to mention
potential inconsistencies (e.g. users mistakenly entering multiple spaces
between fields and the like) within each format.

For the most part I intend to rely on regular expressions for this job,
although I'm a little wary -- regexp syntax is tres bizarre ;--)

Thanks for the clues; ultraedit.com has a great regexp tutorial........

Enjoy the spring/summer,

--Noah

----- Original Message -----
From: "Carl Furst" <cfurstintracommunities.org>
To: "Noah" <noahnewminddesign.com>
Cc: <php-generallists.php.net>
Sent: Friday, May 30, 2003 7:44 AM
Subject: RE: [PHP] strip_tags() Quandry....

If it's something simple that you know a PHP function can take of, use it.
If not, use regexps. They may take a bit more tweaking, but in the long run
are much more flexible and a lot more powerful.

Carl.

Hey John; Hey Carl.

I've heard this debate before; i.e. regular expressions vs. PHP string
formatting functions.

The problem I'm dealing with will require, I believe, a combination of
preg_replace(), str_replace(), strstr(), and str_pos().

To my limited knowledge, there is no way to remove white space with PHP
string functions; when I use strip_tags on a block of html text, whitespace
results; thus the need for preg_replace().

I'm new to regular expressions to say the least -- just took the dive in
yesterday; much to learn.......

If either of you feel like elaborating on the pros and cons of regular
expressions vs. PHP string functions, let me know.

--Noah

While I agree that regexp are powerful and useful, the examples you gave are
better suited to using str_replace(), trim(), or nl2br() calls rather than a
regular expression.

Also, about the "warning" for inserting data into a database... try not to
scare people to much. If you have

column = '$value'
or
column = "$value"

in your query, as long as you've run addslashes on $value to escape single
quotes in the first case and double quotes in the second, there's no
vulnerabilities.

If you have

column = $column

str_replace('|','',$html_string);
etc...

> Some other useful ones for data like the stuff you're doing:
> Spaces at the beginning:
> /^\s/
> spaces at the end:
> /\s$/

trim()

> tags into \n
> preg_replace('!\<br\>!', "\n", $string);

nl2br();

---John Holmes...

attached mail follows:

OH yeah, it takes a little while to get the gist of how to use them, you
should also Google "Perl Regular Expressions" see what turns up. The perlre
man page is very detailed which is good but you might find some other useful
tricks that PHP functions or the Perlre manpage may not cover, like checking
for valid email addresses, or even phone numbers (which is a tricky little
#$%^#). Is there a PHP function that checks emails? That would be neat.

Carl Furst
System Developer
Vote.com
50 Water St.
South Norwalk, CT. 06854
203-854-9912 x.231

-----Original Message-----
From: Noah [mailto:noahnewminddesign.com]
Sent: Friday, May 30, 2003 2:04 PM
To: Carl Furst
Cc: php-generallists.php.net
Subject: Re: [PHP] strip_tags() Quandry....

Exactly, Carl.

For the most part I intend to rely on regular expressions for this job,
although I'm a little wary -- regexp syntax is tres bizarre ;--)

Thanks for the clues; ultraedit.com has a great regexp tutorial........

Enjoy the spring/summer,

--Noah

If it's something simple that you know a PHP function can take of, use it.
If not, use regexps. They may take a bit more tweaking, but in the long run
are much more flexible and a lot more powerful.

Carl.

Hey John; Hey Carl.

I've heard this debate before; i.e. regular expressions vs. PHP string
formatting functions.

The problem I'm dealing with will require, I believe, a combination of
preg_replace(), str_replace(), strstr(), and str_pos().

To my limited knowledge, there is no way to remove white space with PHP
string functions; when I use strip_tags on a block of html text, whitespace
results; thus the need for preg_replace().

I'm new to regular expressions to say the least -- just took the dive in
yesterday; much to learn.......

If either of you feel like elaborating on the pros and cons of regular
expressions vs. PHP string functions, let me know.

--Noah

While I agree that regexp are powerful and useful, the examples you gave are
better suited to using str_replace(), trim(), or nl2br() calls rather than a
regular expression.

Also, about the "warning" for inserting data into a database... try not to
scare people to much. If you have