Good security methods?

**Malcolm Dew-Jones** · Aug 11 '05, 09:05 PM

Re: Good security methods?

guitarromantic@ gmail.com 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_st ring($_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_st ring($_REQUEST[id]) # this eg tested
$Hid = htmlspecialchar s($_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_st ring($id_parame ter);
$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.

**JDS** · Aug 12 '05, 01:15 AM

Re: Good security methods?

On Thu, 11 Aug 2005 13:22:03 -0700, guitarromantic wrote:
[color=blue]
> 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?[/color]

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.

later...

[1] http://engineering.jhu.edu

[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+Orac le or
whatever), but still, it is a wonder that all this stuff works so well and
so fast.

--
JDS | jeffrey@go.away .com
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

**ZeldorBlat** · Aug 12 '05, 04:55 AM

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) {
if(!isset($_REQ UEST[$name]))
return null;
return htmlspecialchar s($_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.

**felixp7@yahoo.com** · Aug 12 '05, 07:25 AM

Re: Good security methods?

guitarromantic@ gmail.com wrote:[color=blue]
> Bear in mind that only
> trusted and approved staff can access submission forms in the first
> place.
>[/color]
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.

**Peter Fox** · Aug 12 '05, 10:25 AM

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:....?order ref=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="publicdet ails.php?empno= 1423527365">Fre d Smith</a>
<a href="publicdet ails.php?empno= 5276928065">Sal ly 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
purposes.)

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="publicdet ails.php?resp=1 423527365">Fred Smith</a>
but now you have done (simplifying) something like
$responsearray['1423527365']='empno=66&acti on=payrise';

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
peterfox@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

**Tim Van Wassenhove** · Aug 16 '05, 02:15 PM

Re: Good security methods?

On 2005-08-11, guitarromantic@ gmail.com <guitarromantic @gmail.com> wrote:[color=blue]
> 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
> place.[/color]

Might want to read http://phpsec.org/projects/guide/

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be >

Good security methods?

Good security methods?

Comment

Comment

Comment

Comment

Comment

Comment