Sessions , sql injection, misc attack defense

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

Threaded View
Reading the Sessions vs Cookies thread has made me realize that my
knowledge against php based attacks is very thin.

Upto now my use of php has been personal, if someone hacked my site i
would look at what they did and work around it.

So I have learned to watch incoming requests that access unwanted data (
mainly to protect the host because for some reason php could open the
passwords file )

Now I decided to spend what time I can on a project I hope will become
of some use to other people, I am concerned about attacks.

Rather then continue coding blindly , although fun , I am stopping and
beginning to check current code for flaws.

I am aware of some info is available ( via goolge ) , but many here are
experts that do realworld solutions so I come to ask

Oh great oracle  of php, What defensive measures do you take on
session hijacking , sql injection , and other such nasty things?

what internet sources do you look at?
what tools / methods do you use for testing?

the current syem logs  uri, useagents, ip addresses , sessionsid's , the
usename that is in use ,page loaded  and a timestamp.

I was thinking of using such data to help track movements ,how can such
data be of practical use in preventing attacks ?

I'm not asking people to look at code, i'm asking for some help on where
to go and some general pointers

regards trookat

If you want to look a current running engine its
no souce yet as i'm having trouble deciding what kind of license would
best suit such a thing.

Re: Sessions , sql injection, misc attack defense

trookat schreef:
Quoted text here. Click to load it

Hi mortal coder,

People with some sense of modesty, like myself, might be scared to
answer when you start like that. ;-)

Ok, how to protect against: session hijacking and sql injection.

**logging errors**
First: your logging activities are surely a good idea. It indeed can
help you figure out later how the attack worked.
For my bigger projects I store nowadays the following when I get an
error/notice/warning/etc by means of a custom errorhandler:
1) URL called
2) Contents of $_POST, $_GET, and $_SESSION
3) the error

I store them in a database with timestamp along with things you
described under here: ip, useragent, etc.

That approach makes it easy to reproduce such an error.
Most crack/hack attacks on your application will produce errors in the
process, so this is your first place to investigate.

**SQL Injection**
Once you know how to do SQL injection yourself, taking precautions is easy.
I only do the following to prevent it:
Assuming my data comes from an untrusted source ($_POST, $_GET):
1) When I expect a string of characters, simply put the string through
the appropriate function. (eg, for mysql: mysql_real_escape_string).
(Personally I always use a database abstractionlayer (ADODB), and so I
use its convenient functions to do that.)

2) If you expect an integer: Cast it to an integer.
eg: You expect a value for userid:
$receivedUserID = (int)$_POST["userid"];

That is about it. I never needed anything more in my project to protect
against SQL Injection.

** Session hijacking**
The easiest way to protect against sessionhijacking is regenerating a
new  PHPSESSID every request.
So suppose your URL hols the sessionid, like this:
That results in a page.
But while PHP processed that request, it changed the PHPSESSID.
So if somebody copies/paste that URL and sends it to somebody else, the
PHPSESSID is stale.

This is NOT 100% sure, since the man-in-the-middle (somebody
eavesdropping on the networktraffic) can still see the new sessionid in
the response from the server.
But it helps a lot against stupid visitors that send the URL to other

You can find ways to regenerate your SESSIONid at
Also Google gave me this, and it looks like a good introduction:

Quoted text here. Click to load it

I do it myself.
You, as developer of the site, should try to break your application.
Try things like this:
Look at the HTML your PHP scripts give back.
Can you find ways to change the values of the formelements (or GET) and
break your application?
Mind that only generating an error is not bad (But NEVER show the errors
in a production environment. Just send the visitor to a page where you
say: "Sorry, we encountered an error").
But try to look for ways to let the form send values that do things that
are not allowed.
Imagine a form that let the visitor update his address.
A bad example:
<form action="..." method="POST">
<input type="hidden" name="userid" value="42">
First name: <input type="text" name="firstname" value="trookat">
<input type="submit" value="Update my stuff">

If your script takes these values and updates the database from the
passed userid in the form, you have a problem.
WHat happens if I change that value from 42 (your id) to 55 (another
users id)?

This problem is easily solved, but I just wanted to give you an example
of mistakes you can make, even if you avoid SQL Injection.

Quoted text here. Click to load it

It won't prevent an attack. However, it can help you find out how a
cracker wrecked your site after it has been done. SO you know where the
holes are.

Quoted text here. Click to load it

If you like the spirit of free software, try GPL licence.
If you do, send my regards to Richard Stallman. ;-)

Good luck,
Erwin Moller

"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

Re: Sessions , sql injection, misc attack defense

Erwin Moller wrote:
Quoted text here. Click to load it

thank you for your excellent reply ,

I'll make use of the things i haven't already covered and hopefully
some, newbies  will gleam some idea that even someone ( like me) ,that
has been doing php for a couple of years ,can benefit from asking about
  things that one thinks he knows about, but finds out that he should be
doing more.

as for the license biz, I've always leaned towards gpl , its just
understanding the difference  between version 2 and 3 . and choosing one.

regards trookat.

Re: Sessions , sql injection, misc attack defense

On Mon, 08 Dec 2008 19:57:56 +0900, wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it

This page will be of service to you:


Also, see section 14 in GPLv3, "Revised Versions of this License.":


$email = str_replace('sig.invalid', '', $from);

Re: Sessions , sql injection, misc attack defense

On Mon, 08 Dec 2008 11:24:52 +0100, wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

It's worth noting that implementing sessions via session cookies is
just as susceptible to man-in-the-middle attacks.

The surest way to pevent man-in-the-middle attacks is by implementing
SSL, which should always be done for environments in which sensitive
data is sent between the client and server.

Quoted text here. Click to load it

I think to security-conscious people like yourself (me, too,
incidentally), this is obviously a bad move.  However, I don't think
it's general enough knowledge to common users how session IDs work,
or even that they exist.  I wouldn't expect (my) grandmother to find
and strip out the SID from a URI before sending it to someone, for
example.  I wouldn't regard her as "stupid", though.


Quoted text here. Click to load it

Thanks for posting this, Erwin, I also found very informative, and
will gladly refer friends to this post in the future.

$email = str_replace('sig.invalid', '', $from);

Re: Sessions , sql injection, misc attack defense

Erwin Moller wrote:
Quoted text here. Click to load it
Thanks for this post. Highly informative!

Re: Sessions , sql injection, misc attack defense

Quoted text here. Click to load it

First, I read a book ("Innocent Code" by Sverre Huseby) on website
security. I know this is cheating for an oracle. ;)

Quoted text here. Click to load it

For unit tests, my own library. For acceptance tests (and you can do
injection tests with it if you like), Selenium.

I hope to prevent session highjacking by using the
session_regenerate_id() function with every change in permissions. Off
course, using SSL and secure cookies does help. I use SSL for anything
that needs it.

For SQL injection, I have one extra trick, which I call "session
hashes". It came from the idea that I never wanted to send any database
ID to the client. You could imagine that a bank account ID in a dropdown
field for instance, is easily changed. It does not matter to know the
other values in the BankAccount table to have the money deducted from
someone else's account if the ID is not checked. As I am human, I
foresaw that such checks could fail to be present in my code. So I
wanted to be sure _beforehand_ that IDs could only be the ones I would
accept. This is where the session hashes come in.
I create hashes (well, session-dependent random codes actually, that are
guaranteed to be unique) for any database ID or otherwise sensitive
choice value. When I populate a dropdown or hidden field, I set the
value to such a hash (and store the hash in the session). When I read
the posted values, I look up the submitted hash in the session and
substitute the ID.
If the lookup fails, that means that either the submit data was tampered
with, or that the session has expired. So I log it (it could be my own
coding fault also, so I would want to know about it) and redirect to the
log-in page.

Best regards,
Willem Bogaerts

Application smith
Kratz B.V. /

Re: Sessions , sql injection, misc attack defense

Willem Bogaerts wrote:
Quoted text here. Click to load it

Thanks for your apply , the information you have provided will help
regards trookat

Site Timeline