Good security methods?

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

Threaded View
Hey everyone.

I'm just finishing up writing a basic content management system,
standard stuff really, just pulling info out of a database and allowing
priveliged users to login and post it. I wanted to know: what security
tips can you guys give me for improving it? I've read somewhere that
when using stuff like $_GET['id'] to display a specific row, it's
useful to add code to protect it from sql injections and such? I'm
obviously md5 encrypting passwords and using cookies/sessions to store
user logins. In terms of input validation I'm a little sparse - are
there any that I really need to implement? Bear in mind that only
trusted and approved staff can access submission forms in the first

Finally, are there any drawbacks to using mod_rewrite to change urls
from foo.php?=bar into /foo/bar/ ? Obviously these look better and are
apparently more friendly to search engines, but can it have negative
effects on server load etc?

Thanks very much everyone, this group has really helped me with this
project so far.


Re: Good security methods? wrote:
: Hey everyone.

: I'm just finishing up writing a basic content management system,
: standard stuff really, just pulling info out of a database and allowing
: priveliged users to login and post it. I wanted to know: what security
: tips can you guys give me for improving it? I've read somewhere that
: when using stuff like $_GET['id'] to display a specific row, it's
: useful to add code to protect it from sql injections and such?  

Yse, and its so easy to do there is no excuse not to do it.  It does not  
just avoid "sql injection", it also protects you against unexpected input,  
or just plain honest typos.

At the top of most of my php scripts you will see lines such as

    $id = mysql_escape_string($_REQUEST[id]);

I know I am only using that variable (id) in mysql queries.  If I was
using it for other things then I might escape it differently, or at a
different location in my code such as just before I used it, but right at
the top is easiest, and it helps document the parameters being accepted.

If I used the variable in two ways, and don't change it later then I might
create two pre-escaped copies at the top of my code.

    $Qid = mysql_escape_string($_REQUEST[id])   # this eg tested
    $Hid = htmlspecialchars($_REQUEST[id]);        # this eg not tested

or if you don't like having the multiple copies pre-escaped ready for  
use then do that just before you use them

    $Qid = mysql_escape_string($id_parameter);
    $sql = "select * from T where id = '$Qid';

On the topic, I often find it useful to provide two copies of sql, one to
use and one to display

    # bogus queries, just for e.g.

    $sql = "select * from T where password = '$Qpassword'";
    $SQL = "select * from T where password = '**********'";

    # note:
    # use $sql in query
    # use $SQL in messages


This space not for rent.

Re: Good security methods?

On Thu, 11 Aug 2005 13:22:03 -0700, guitarromantic wrote:

Quoted text here. Click to load it

I use mod_rewrite extensively on my "main"[1] website.  I mean
*extensively*! I find (when everything is working properly on the server,
but that's another story[2]) that mod_rewrite does not appear to adversly
affect performance. For all the shit I have going on[3] to create a single
page, it is a wonder that, even at peak load times, the server can still
spit out a page in under a quarter second.



[2] I had a series of serious serious SERIOUS performance issue events
from March through July of this year.  I could not figure out what the
fsck was going on.  Finally I updated all the software on the server
(Linux/OS stuff plus Apache and MySQL) and presto! no more server issues.  
Wow! Why didn't I update sooner??? (Beacause I am overworked and underpaid?)

[3] mod_rewrite rewrites the URL -- *every* URL -> send to PHP
paginatorizer, go to MySQL database to get meta information, get pae
contents from a file, PHP sews it all together, sptis out an HTML page.  
Pretty normal stuff, really, when you are talking about a dynamic
server-side web system, (say, ASP+IIS+MSQL or JSP+Apache+Oracle or
whatever), but still, it is a wonder that all this stuff works so well and
so fast.

    JDS |

Re: Good security methods?

I like to write some functions to get request data rather than
accessing $_GET and $_POST directly.  That way, if you decide to change
how you escape things, you can change it in one place without having to
go through your code.  You might have something like this:

function getRequestVar($name) {
        return null;
    return htmlspecialchars($_REQUEST[$name]);

Additionally, I also have functions to prepare data before putting it
into a query.  For example, you might have prepNumber, prepText, etc.
that escape any necessary characters, enclose text in quotes, etc. as
well as validate that, for instance, a number is indeed a number.
Again, if you decide to switch to a different database system, you can
just modify these functions to escape things differently without having
to look through all your code.

Re: Good security methods? wrote:
Quoted text here. Click to load it
That doesn't matter, a malevolent visitor could emulate your forms.
You should check whether the user is actually logged in before making
any changes to the database, as well as before displaying sensitive
information. After all, it's only an extra if statement here and there.

Re: Good security methods?

Good security methods depend on understanding
(a) What you're protecting
(b) The threat
/then/ you can judge which tools to use.

(A really excellent general book on this subject is
Security Engineering by Ross Anderson. Pub. Wiley)

Here are two bad things:
1 : customer number 45 looks at customer number 46's data
2 : customer 45 bookmarks or has sent to them a URL in an email or  
passes a URL to somebody else which can be used out of the intended  
context.  (Eg an email: "this is your order reference number to view  
progress click go to http:....?orderref=12345")

These are slightly different things.

If the only 'way in' to our web site is via URL line (ie not using  
cookies) then this means any hacker will have to fiddle with the URL  
request.  So bad thing 1 can now be re-cast as "How can we make it  
difficult for a hacker to misuse the command line to make false  
requests" and bad thing 2 can be re-cast as "how can we detect and  
manage the context of URL requests".

Are random numbers (difficult to guess) for customer IDs enough?
No.  A page might list say employees with a link for details:
<a href="publicdetails.php?empno=1423527365">Fred Smith</a>
<a href="publicdetails.php?empno=5276928065">Sally Jones</a>
So we MUST at the /very least/ disguise the numbers so they can't be  
re-used in privatedetails.php.  (You will understand that in a situation  
where people can look at their own record they may be able to change the  
URL to one of the other numbers quite legitimately used for public  

A /simple/ way is to have a _reversible_ obfuscation function which  
obfuscates differently according to (say) the page on which it is used.  
This can be used to prevent casual hacking but is more security by  
obscurity than proper lock-outs.  (But you can detect experimental  
efforts to fiddle as when the de-obfuscation fails to produce a valid  
result you can be alerted to some fiddling. This might be acceptable in  
a closed user community context.)

A more robust and more complex[1] method is to generate a big random  
number every time you want a URL response and use that as a key to the  
real response kept in a database or session.

The HTML looks the same
   <a href="publicdetails.php?resp=1423527365">Fred Smith</a>
but now you have done (simplifying) something like

What you can do with this depends firstly on the persistence of  
$responsearray and secondly on the persistence of each record.  For  
example here are some things you can do if you're passing URLs in emails
* expire after a given time
* class the user as 'logged in' or take them to their own login with  
user name and other details already present just waiting for password
* if one response from a multiple choice email (eg click on this link to  
confirm or this one to cancel) then not only remove the one chosen but  
also its sibling.

Of course in the above I've only covered one aspect of user input issues  
and even then only at a top level but I hope it gives you something to  
think about.

[1]  It was tricky to write a class to do the job in detail but of  
course those details are hidden in normal use.  I could share it if  
people are interested but (because I've never actually used it in anger,  
and because it is tailored to my ways of working) it would be 100%  
unsupported and not much use to those that want instant gratification.

PETER FOX Not the same since the deckchair business folded
2 Tees Close, Witham, Essex.
Gravity beer in Essex  <

Re: Good security methods?

Quoted text here. Click to load it

Might want to read

Met vriendelijke groeten,
Tim Van Wassenhove <

Site Timeline