security question(s)

[nancy]

I am new to PHP but have done other programming
can someone please hold my hand and slowly talk me through some simple
security issues?

I have seen in PHP documents that there are 'strip slashes' commands and
so on but I dont understand where the security issues actually are.

i am writing some scripts that will shell out and call different linux
shell programs such as 'ls' or 'grep' or 'sed' and so on and possibly
update a 'mysql' database.

can you tell me at what point in this procedure security is needed and
what exactly as ideally I would like to not hamper anything I send to
grep and so on? In other words I would like any security modification of
my parameters to happen as late in the process as possible.

I am obviously interested in how to stop someone using pipes '||' or
redirecting the output '>' or entering anything that might trigger the
database to think i was getting code or a varialble of some sort - I
think that may just be '$' but dont really know. Are there any actual
strings rather than characters that must be watched for?

can someone explain what point the issues take effect - is it php, or
when php passes the parameters or is it the (eg) 'grep' program itself
that is written to do things that must be prevented or is it linux
itself when it passes the parameters?

and is there anything else I need to watch out for?

can anyone explain in simple terms please (perhaps a security table ?)

nancy

[Gordon Burditt]

Re: security question(s)

>I am new to PHP but have done other programming

>can someone please hold my hand and slowly talk me through some simple
>security issues?

"simple" and "security issues" don't go together.

>I have seen in PHP documents that there are 'strip slashes' commands and
>so on but I dont understand where the security issues actually are.

If you allow user-supplied input on a shell command-line unaltered, you are
asking for trouble. Consider, for example, the search pattern:

`rm -rf /`

and if you stick it into a shell command:

grep "`rm -rf /`" INDEX.txt | pretty_up_index _entries

it's likely to do a lot of damage to your system. One approach to
dealing with this is to quote the string appropriately for the shell
being invoked.

>i am writing some scripts that will shell out and call different linux
>shell programs such as 'ls' or 'grep' or 'sed' and so on and possibly
>update a 'mysql' database.

Also beware of wierdly-formatted stuff that becomes dangerous SQL,
such as entering a user name such as:
george' OR '' LIKE '
substitued into sql that says:
DELETE FROM users where user = '$user'

DELETE FROM users where user = 'george' OR '' LIKE ''
which deletes all the records in users.

>can you tell me at what point in this procedure security is needed and
>what exactly as ideally I would like to not hamper anything I send to
>grep and so on? In other words I would like any security modification of
>my parameters to happen as late in the process as possible.

Security should be designed in as EARLY as possible. Bolting a
very secure vault door onto a building originally intended as a
greenhouse (including its glass walls and rickety screen back door with
no lock) doesn't make a very good bank vault.

>I am obviously interested in how to stop someone using pipes '||' or
>redirecting the output '>' or entering anything that might trigger the
>database to think i was getting code or a varialble of some sort - I
>think that may just be '$' but dont really know. Are there any actual
>strings rather than characters that must be watched for?

What USER-SUPPLIED input is going to be used (especially on the command
line, but worry about the data passed to the command also)? Where?

If you are putting stuff in as a command-line argument, you probably
have to worry about:

- quotes
- shell variable substitutions
- backquote substitutions
- any way to get command terminators (like semicolon, |, ||,
&, &&, etc.) followed by a new command outside quotes

If you pass the input through the PHP function escapeshellarg( )
before putting it on the command line, it should be safe (at least
for reasonably normal UNIX shells).

If you are substituting stuff for use within a quoted string in a
SQL query, you need to make sure it can't get outside the quotes
(mysql_escape_s tring() is one possibility).

>can someone explain what point the issues take effect - is it php, or
>when php passes the parameters or is it the (eg) 'grep' program itself
>that is written to do things that must be prevented or is it linux
>itself when it passes the parameters?

Unchecked user-supplied strings in shell commands are very touchy.
Unchecked user-supplied strings in file names (e.g. passed to PHP
fopen()) are touchy. For example, "../../../../../../../etc/passwd"
is likely to refer to the password file, which someone might download
for cracking or spamming purposes. Unchecked user-supplied strings
in any mail headers you send are very touchy (they can be abused
to spam large numbers of people). Unchecked user-supplied parameters
passed to the PHP eval function are very touchy. Unchecked
user-supplied parameters passed to include() are very touchy,
especially if remote URLs are allowed, and this is used by a number
of viruses. Allowing the user to post articles containing raw
Javascript (or for that matter, even certain HTML) allows that user
to hijack other user's browsers when they view the post.

This list is nowhere near complete.

>and is there anything else I need to watch out for?

TRUST NO ONE.

>can anyone explain in simple terms please (perhaps a security table ?)

Exercise: list all the ways of stealing money out of a state-of-the-art ATM
that requires a smart card with RSA certificates to open the money-loading
compartment.









Think of your answer, then scroll down.































































If even half of your answers are ways to make a fake smart card,
you aren't thinking far enough outside the box.

If you didn't include anything about wrapping a chain around the
ATM, pulling it out of the ground, driving off with it, and then
blowing it open with explosives, you're not thinking far enough
outside the box.

If you didn't include anything about bribing the guy who loads the
machine, you're not thinking far enough outside the box.

If you didn't at least think about whether it is possible to teleport
the ATM away leaving the cash, you're not thinking far enough outside
the box.

If you didn't include anything about stealing what the cash is
backed with, thereby making the cash worthless, you're not thinking
far enough outside the box.