RE: [PHP] help create community newbie guide to security

[Chris Shiflett]

--- Jay Blanchard <[EMAIL PROTECTED]> wrote:
> [snip]
> If you code properly, you could get away with turning register_globals
> on, but this requires you to be very careful when thinking about the
> logic of your code.
> [/snip]
> 
> I really do hate to see the misconception about register globals
> continue.

I'm not sure why you consider this a misconception, since the guy that
posted that is correct. If you want to make such a claim, you should show
some code where it is impossible for a developer to reach the same level
of security with register_globals enabled.

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] help create community newbie guide to security

[Jay Blanchard]

[snip]
If you code properly, you could get away with turning register_globals
on, but this requires you to be very careful when thinking about the
logic of your code.
[/snip]

I really do hate to see the misconception about register globals
continue. The bottom line is variable handling, especially where
variables are passed via the GET form method (which places key=value
pairs in the URL, making them highly visible). All variables should be
tested for improper formation (with rg ON or OFF) if these variables
arrive from an outside source. Consider the example

http://www.yourserver.com/login.php?authorized=true

If rg is on the value of $authorized == "true"
If rg is off the value of $_GET['authorized'] == "true"

In this case the programmer will be testing (either one) for "true", and
placing login information in the URL is just bad form.

The real problem comes with things like SQL injection (Much too much
info for this e-mail, I suggest some searching and reading, Google is
your friend). Consider the following URL

http://www.yourserver.com/login.php?username=hi'%20OR%201=1--

This not only returns true (which should log the user in) but also might
return the complete list of usernames. It doesn't matter whether rg is
on or off if no validation is done on the variables being passed.

With register globals off the programmer is given an advantage, that
advantage being the knowledge of the origin of the variable. If it is in
the $_GET array we know where it came from. Likewise with the other
predefined variable arrays. 

What should you do? Initialize all variables. If variables arrive via an
outside source (with rg ON you could call you variables names dependent
upon the form method, such as name="getUserName" which becomes
$getUserName) validate them properly before use and reject them if
wrong.

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

RE: [PHP] help create community newbie guide to security

[Andre Volmensky]

[snip]
> All these responses and nobody has said anything about 
> register_globals?

heh, I guess you're right.

Feel free to elaborate on what you mean for those of us that don't know
what's up with register_globals. 
[/snip]

Well it's all at http://www.php.net/register_globals for anyone that
wants any in depth information about register_globals.

But basically, if you write your code improperly it can lead to security
holes in your web app. There are some good examples on the PHP website.
But register_globals will just enable or disable someone passing a
variable directly to your script. For example, someone could just send a
variable to your script to get around a poorly coded authentication
algorithm.

Eg, http://your-host.com/login.php?authorized=true 

With register_globals turned off, it is not really possible for someone
to pass variables to your script without you allowing it. You HAVE to
specify which variables are going to be passed from a form etc. 

If you code properly, you could get away with turning register_globals
on, but this requires you to be very careful when thinking about the
logic of your code.

Hope this helps.

- Andre

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

RE: [PHP] help create community newbie guide to security

[Chris W. Parker]

Andre Volmensky 
on Wednesday, November 12, 2003 2:17 PM said:

> All these responses and nobody has said anything about
> register_globals? 

heh, I guess you're right.

Feel free to elaborate on what you mean for those of us that don't know
what's up with register_globals.



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] help create community newbie guide to security

[Chris Shiflett]

--- Pablo Gosse <[EMAIL PROTECTED]> wrote:
> [snip] It might be best to not try and definitely declare what counts as
> foreign data, because it's a sort of "everything else" type of thing. If
> it doesn't originate within the PHP script itself, it is foreign.[/snip]
> 
> What about data from a database which is retrieved within the PHP
> script? Would you consider this type of data to be internal (since it is
> being accessed within php) or external (since the database is external
> to php)?

It depends on how the data ended up there. :-)

If there are other systems accessing the database that might be able to
insert data, I would definitely consider this data foreign unless I was
the author of those other systems. If it is only my software that can
access the database, I would rely on my own habits of always validating
data prior to insertion.

For various reasons, some people might find that it makes more sense to
validate their data after they retrieve it from the database and only
worry about preventing SQL injection attacks when filtering data prior to
insertion. For these people, the data in the database is just as foreign
as when it entered the system through whatever other means.

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] help create community newbie guide to security

[Andre Volmensky]

[snip]
Hmmm... ok so that's all I can think of. I think it'd be a really great
thing for the community if this list was corrected and added too in a
detailed way (such as I've tried to do here).

Looking forward to all the responses.
[/snip]

All these responses and nobody has said anything about register_globals?

- Andre

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

RE: [PHP] help create community newbie guide to security

[Pablo Gosse]

[snip] It might be best to not try and definitely declare what counts as
foreign data, because it's a sort of "everything else" type of thing. If
it doesn't originate within the PHP script itself, it is foreign.[/snip]

What about data from a database which is retrieved within the PHP
script? Would you consider this type of data to be internal (since it is
being accessed within php) or external (since the database is external
to php)?

Cheers,
Pablo

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

RE: [PHP] help create community newbie guide to security

[Chris Shiflett]

--- "Chris W. Parker" <[EMAIL PROTECTED]> wrote:
> My original thinking was that I wouldn't be using the session id as I
> would the unique identifier because of point #2 (you shouldn't store the
> session id on the client). But since you point out that storing the
> session id is a necessary evil (if I understand you correctly) I see
> that it would be ok to forget about generating another unique identifier
> and just use the session id instead.

Yes, I consider it a necessary evil. The propogation of the session
identifier is the greatest challenge we face when trying to provide a
secure session management mechanism.

> Well then let met ask this: Is an SSL login option something you
> personally setup by default as part of your regular login routine or
> would you only create one if the client requested/had a need for it?

Not to avoid the question, but it really depends. :-)

If someone is logging in to gain access to some technical documentation
that I don't want to be public, and if their password was generated by my
system (so there is no risk of it being important data to the user), then
I would probably not bother with SSL. The risk (unauthorized access to a
document) isn't too big of a deal. This is all based on my (or the
client's) perception of the risk involved. Greater risk warrants more
expensive safeguards.

If the customer is logging in to their online banking system, there had
better be some SSL. :-)

> > I would say any data that originates from any external source should
> > be treated as tainted data until it can be properly verified via data
> > filtering.
> 
> Ok so then that means I forgot about $_COOKIE (which you mention a
> little later in your email).

What about data you obtain via an XML feed? What about an email message
you check with a Web-based mail client? It might be best to not try and
definitely declare what counts as foreign data, because it's a sort of
"everything else" type of thing. If it doesn't originate within the PHP
script itself, it is foreign.

> In your article from php|arch (http://www.phparch.com/sample.php?mid=16)
> the first of your 5 points in protecting against XSS is to use
> htmlentities(), strip_tags(), and utf8_decode() when filtering your
> data. Would using all three of these protect against everything?

I mention using functions like those to help with your filtering logic.
The point is to try your best to use native PHP functions whenever
possible. When you write your own, you have to factor in the possibility
of an error creating a security vulnerability. This is certainly possible
with the native functions, but it is much less likely.

The more important point is to only allow data that you feel is safe
rather than to try and prevent data you feel is unsafe. You mentioned this
in an earlier email.

> If not, can you give an example of what data can be passed, put through
> those filtering functions, and still cause problems? (For understanding
> sake.)

Hmmm, not off the top of my head.

However, I think the important perspective is to try and avoid battles of
creativity. If you place yourself in such a battle with every potential
attacker in the world, you will probably lose. Yes, example exploits are
fantastic for demonstrating the need for certain preventive measures, but
don't take the approach of trying to prevent specific exploits. Adopting
secure programming practices is much safer and can prevent attacks you may
have not even thought of.

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] help create community newbie guide to security

[Chris W. Parker]

Chris Shiflett 
on Monday, November 10, 2003 8:21 PM said:

> It would probably need to be either very short or very long.

Yes, I would prefer very long so as to be as complete as possible.

>> 2. The session id should not be stored on the client.
> 
> I'm not sure I agree with this. Can you elaborate? Though it can be
> argued that sending the session identifier is a security risk, it is
> the one that is necessary for state (and therefore session)
> management.

Elaborate? Well I was just thinking that this could somehow be used to
impersonate someone. How or why I'm not really sure. That's why I wrote
the email instead of hauling off to write an article (most of which
would be misinformed without having a better understanding).

>> 3. A unique identifier should be created for the user when the user
>> logs in. This unique identifier should not be based on the user's
>> name, password, id, or session id.
> 
> What is the difference between the session and unique identifiers?

Well I guess there isn't one now that you've asked that question.

My original thinking was that I wouldn't be using the session id as I
would the unique identifier because of point #2 (you shouldn't store the
session id on the client). But since you point out that storing the
session id is a necessary evil (if I understand you correctly) I see
that it would be ok to forget about generating another unique identifier
and just use the session id instead.

>> 6. The login page should be done over HTTPS. (Sounds like a good idea
>> but is this necessary? Is this killing a mouse with a jackhammer?)
> 
> It depends on the amount of risk that is acceptable. Requests for
> non-SSL URLs are sent in the clear and are vulnerable to things such
> as sniffing, man in the middle attacks, and other similar attacks.
> 
> Yahoo offers the user a choice between SSL and non-SSL logins, and
> they default to non-SSL. Some sites describe the choice as secure
> versus fast.

Well then let met ask this: Is an SSL login option something you
personally setup by default as part of your regular login routine or
would you only create one if the client requested/had a need for it?

>> 7. All input received via $_POST and/or $_GET should be thoroughly
>> filtered
> 
> I would say any data that originates from any external source should
> be treated as tainted data until it can be properly verified via data
> filtering.

Ok so then that means I forgot about $_COOKIE (which you mention a
little later in your email).

>> 10. Use htmlentities() on data that will be put through a SQL query
>> to prevent XSS attacks. http://php.net/htmlentities
> 
> This is a nice suggestion. While htmlentities() cannot be guaranteed
> to defend against all XSS vulnerabilities, I would bet that most XSS
> vulnerabilities are due to a complete lack of filtering logic.

In your article from php|arch (http://www.phparch.com/sample.php?mid=16)
the first of your 5 points in protecting against XSS is to use
htmlentities(), strip_tags(), and utf8_decode() when filtering your
data. Would using all three of these protect against everything? If not,
can you give an example of what data can be passed, put through those
filtering functions, and still cause problems? (For understanding sake.)

> Hope that helps.

Sure does, thanks.


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] help create community newbie guide to security

[Lowell Allen]

> Lawrence Kennon wrote:
>> For a BBS I would like to let users post links to
>> various resources. They 'post' a message to the BBS
>> via a form and that is stored in a MySQL db, then the
>> content of their 'post' is available to other users on
>> the BBS. Currently I strip out all PHP/HTML with the
>> strip_tags() function. What I would really like to do
>> is allow a limited set of HTML tags (like the anchor
>>  tag) but at the same time implement reasonable protection.
> 
> Get yourself a bbcode parser from phpclasses.org so you can use things
> like [b] [/b], and [url=] [/url], etc. This is safer than trying to deal
> with actual HTML, imo. Then use htmlentities() on the data instead of
> strip_tags(), so the users can actually write something like  and
> not have it stripped.

[snip]

I have a "best practice" question related to this thread. I usually store
data in MySQL without any translation, then use htmlspecialchars() before
displaying as HTML. This works well for a content management system where
administrators are entering data in forms and storing, but perhaps it's not
appropriate for storing information from website visitors. If that
information should be translated before storing, then I'd have some stuff
that needs htmlspecialchars() applied before displaying, and some stuff that
does not.

My question is, are there any disadvantages to always following the
procedure described below?

- Use htmlentities() on everything before storing in the database
- Retrieve and display in cms forms without any translation
- Retrieve and translate mnemonic codes (like [b] [eb] to 
) before displaying as HTML
- Retrieve and use html_entity_decode() if needed for non-HTML use (like for
plain text email), or if I actually *WANT* to use stored HTML code (like for
HTML-formatted email)

TIA

--
Lowell Allen

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

Re: [PHP] help create community newbie guide to security

[John W. Holmes]

Lawrence Kennon wrote:
For a BBS I would like to let users post links to 
various resources. They 'post' a message to the BBS 
via a form and that is stored in a MySQL db, then the 
content of their 'post' is available to other users on 
the BBS. Currently I strip out all PHP/HTML with the 
strip_tags() function. What I would really like to do 
is allow a limited set of HTML tags (like the anchor 
 tag) but at the same time implement reasonable protection.
Get yourself a bbcode parser from phpclasses.org so you can use things 
like [b] [/b], and [url=] [/url], etc. This is safer than trying to deal 
with actual HTML, imo. Then use htmlentities() on the data instead of 
strip_tags(), so the users can actually write something like  and 
not have it stripped.

In regards specifically to the HTML anchor tag , 
are their guidelines for what should, and should not be 
allowed? In other words if I simply allow all of these 
tags (implementing the algorithim you mentioned above) 
are their potential problems with that? Or are there 
specific things I should be looking for with tags?
The problem is with deciding what attributes to allow in tags. If you 
use strip_tags() and decide to use the second parameter to allow  
tags, I can write a  tag that'll execute some 
javascript for me. It's easy enough to stop that on a  tag, but what 
about an  or  tag where you have to allow certain attributes and 
you never know what order they'll be in? That's why a bbcode solution is 
the best, imo, and use htmlentities() on everything else.

--
---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] help create community newbie guide to security

[Chris Shiflett]

--- Adam i Agnieszka Gasiorowski FNORD <[EMAIL PROTECTED]> wrote:
> "Chris W. Parker" wrote:
> > 10. Use htmlentities() on data that will be put through a SQL query to
> > prevent XSS attacks. http://php.net/htmlentities
> 
>   How is it going to interact with MySQL FULLTEXT 
>  search SQL queries, where the characters ">" and "<"
>  are in use as modifiers?

His suggestion was just that, a suggestion. You are the expert of your own
applications, so you know when it is best to follow a suggestion or ignore
it. Guidelines like this are mostly about exposing people to certain ideas
that make them open their eyes. If you understand the risk and can
mitigate it through other means, that is fine.

In your case, it might be best to use something like htmlentities() prior
to displaying the data to a user rather than prior to storage. Some data
filtering is still a good idea, of course, and you might want to consider
the data in the database tainted if your data filtering prior to storage
is incomplete whether by necessity or design.

The most common approach is to cleanse data as soon as possible, but this
isn't always best.

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] help create community newbie guide to security

[Adam i Agnieszka Gasiorowski FNORD]

"Chris W. Parker" wrote:
 
> 10. Use htmlentities() on data that will be put through a SQL query to
> prevent XSS attacks. http://php.net/htmlentities

How is it going to interact with MySQL FULLTEXT 
 search SQL queries, where the characters ">" and "<"
 are in use as modifiers?

-- 
Seks, seksić, seksolatki... news:pl.soc.seks.moderowana
http://hyperreal.info  { iWanToDie }   WiNoNa)   (
http://szatanowskie-ladacznice.0-700.pl  foReVeR(  *  )
Poznaj jej zwiewne kształty... http://www.opera.com 007

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

Re: [PHP] help create community newbie guide to security

[Chris Shiflett]

--- Lawrence Kennon <[EMAIL PROTECTED]> wrote:
> For a BBS I would like to let users post links to various resources.
> They 'post' a message to the BBS via a form and that is stored in a
> MySQL db, then the content of their 'post' is available to other users
> on the BBS. Currently I strip out all PHP/HTML with the strip_tags()
> function. What I would really like to do is allow a limited set of HTML
> tags (like the anchor  tag) but at the same time implement reasonable
> protection.

I prefer htmlentities() to strip_tags() in cases like this, because by
stripping tags, you eliminate the chance that your users can talk about
code. If you use htmlentities() instead, their code will appear exactly as
they typed it. You may not want this, but I thought I'd mention it.

> In regards specifically to the HTML anchor tag , are their guidelines
> for what should, and should not be allowed?

Any tag like anchor is more difficult to deal with, because you have
attributes whose values can be anything. For something like a bold tag, on
the other hand, you can simply replace  with  and do the same
for the closing tag.

With tags like anchor, you want to determine two things:

1. Which attributes you want to allow, stripping all others (or the entire
anchor tag if this rule is broken). For example, you may want to begin by
only allowing href.
2. What the acceptable format is of each of the attributes you allow. For
example, with the href attribute, you probably want to only allow valid
URLs. If you allow anything, someone might be able to use some client-side
scripting trickery to do something you did not intend. It's better to be
safe.

I don't have any sample code to give you, but maybe someone else can pitch
in.

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