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,
Daniel
Daniel wrote:
> 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?
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.
>
> Also, i want to learn more about securing php/MySQL pages any good
> resources I should start with?
I do not know of any resources on the net, but I found this book very
useful: "Innocent Code" (see http://innocentcode.thathost.com/)
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!
On Oct 24, 10:42 pm, Daniel
> 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,
>
> Daniel
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.
On Oct 24, 6:33 pm, Dikkie Dik
> Daniel wrote:
> > 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?
>
> 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.
>
>
>
> > Also, i want to learn more about securing php/MySQL pages any good
> > resources I should start with?
>
> I do not know of any resources on the net, but I found this book very
> useful: "Innocent Code" (seehttp://innocentcode.thathost.com/)
>
> 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!
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
example:
//This is an include file called foo.php that should not be accessed
directly
if(!defined('APPLICATION') || !APPLICATION)
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);
require('foo.php');
//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?
Daniel wrote:
> 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?
Hi,
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
application.
Most databases let you create a fine structure for users, even to the
tablelevel.
- 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"];
headerinjection:
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.
Regards,
Erwin Moller
>
> Thank you,
>
> Daniel
>