know when user tries to access php file

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

Threaded View
is there a way to detect if a user tries to access a php file?

For instance, db.config.php is called in many php pages but should
never actually be open directly.  Is there a way to know if someone
tried to open it directly?

Also, i want to learn more about securing php/MySQL pages any good
resources I should start with?

Thank you,


Re: know when user tries to access php file

Daniel wrote:
Quoted text here. Click to load it

The point is that there should no way to do that. If you put it outside  
of the web root, there is no URL for it. So lesson 1: put everything  
that should be internal in a non-accessible place.

Quoted text here. Click to load it

I do not know of any resources on the net, but I found this book very  
useful: "Innocent Code" (see /)

The above book explains a lot about injection of all sorts, and gives  
you a nice primer on web standards and how they can be abused.

There is a general advice that you should restrict any access to what  
you need to allow. This is a broad topic (involving rights on file  
systems, databases, etc, and how to use them), but if you take a good  
look at your site/server(s), it should not be that hard to see what can  
be done.

You might off course google for some specific kinds of attack:
- injection (sql injection is the classroom example, but mail injection  
is alas also very popular)
- cross-site scripting
- session fixation and session highjacking.

Good luck!

Re: know when user tries to access php file

Quoted text here. Click to load it

Dikkie is right in that you shouldn't worry about detecting it -- you
should worry about preventing it.  Putting things that shouldn't be
directly accessed outside the webroot is excellent advice.

As an additional measure, many applications will prevent direct access
to include files by requiring some constant to be defined -- and then
only defining it inside pages that should be directly accessed.  For

//This is an include file called foo.php that should not be accessed
    exit('Nothing to see here. Move along.');

//More code inside foo.php

//This is a file called bar.php that should be directly accessed
define('APPLICATION', true);

//More code inside bar.php

So, if foo.php is called directly it will die.  However, if bar.php is
called it will first define the APPLICATION constant and, when foo.php
is included, it won't die.

Make sense?

Re: know when user tries to access php file

Quoted text here. Click to load it

google for  "web application security consortium"
yes follow dikkie's advice, use mysql users and permissions, so the
app only has the rights to tables and databases that it needs. these
questions have been answered many times in this forum over the years,
but it is a vast subject which is all about following standards and
best best practise when coding, and understanding how to abuse your
code. If you accept user input do you check that it is what it should
be, before using it. Do you update your software. Do you get lazy and
think - oh that will work, i'll do the security later. Are your
deadlines imposing, do you have someone to check over your code once
its written to see bugs.
Unfortunately there will always be bugs and vulnerabilities in one's
code. It's inevitable somewhere between death and taxes, so what can
go wrong when they gain access.
And finally, you arent that big a target, I've personally never been
pick pocketed, I keep a fairly close eye on my stuff when im in the
capital (and so think Im pretty safe), but if i'm targetted Im sure
i'll be easy pickings - they are professionals after all. Just dont be
the low hanging fruit with the half open handbag you sling behind you
as you walk the crowded streets.

Re: know when user tries to access php file

Daniel wrote:
Quoted text here. Click to load it


security and PHP, some concepts that may help searching/googling:
- filepermissions of the files in use on your webapplication.
(extra important on most 'shared hostings' environments.
- php.ini (and phpinfo() function)
Try to get a good general idea of the settings in here.
Be sure to have register_globals OFF.
- Database: Make a new user for each database you create.
You might consider to create a read-only user, so IF your application  
has some gaping hole, the cracker cannot modify your data.
You can maybe create a full-access user for the admin part of the  
Most databases let you create a fine structure for users, even to the  
- Receiving Formdata (SQL Injection, headerinjection for email)
SQL injection:
Scrubbing formdata is very important, since it is often the easiest way  
to comprimise a system.
Simply expect the data posted by clients to be harmfull, and take all  
precautions needed.
eg: If you receive text, be sure you escape (or filter out) all naughty  
characters before using the data in a database query.
If you expect an interger, make sure it IS an interger, eg:
$myPostedInt = (int)$_POST["myPostedInt"];

When you use stuff like 'tell-a-friend' or other emailfunctionality,  
make it 100% sure all formfields contain the data you expect. It is easy  
to add more headers to the email, so bad guys can use your  
emailfunctionality as a spamgateway.

- .htaccess
If you use apache and have AllowOverride for this host (which can be  
very handy), be sure you understand the implications. If more people  
have access to the system, eg to upload images, they can also place a  
possibly harmfull .htaccess file in some directory and a php file,  
allowing them to override your php.ini settings.

- Session hijacking
Understand how sessions work. If some bad guy gets a hold of a  
PHPSESSID, (s)he can use the session of another person (eg adminrights).

Just a few pointers. I hope this covers most popular exploits.

Good luck.

Erwin Moller

Quoted text here. Click to load it

Site Timeline