security question(s)

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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 ?)


Re: security question(s)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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_string() is one possibility).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Quoted text here. Click to load it

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

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.

Site Timeline