Page 2 - [Everyone] Must read Security Notes

I'd just like to say that I found this a usefull reminder, and I'd like to thank you for taking your time posting it. (I wouldn't know 50% of what I know today if it wasn't for this board)

Am still totaly clueless when it comes to apache security though, but any info is always welcome

A couple of good articles:

http://linux.oreillynet.com/pub/a/l...securities.html

http://www.onlamp.com/pub/a/php/200.../php_admin.html

http://www.onlamp.com/pub/a/linux/2...securities.html

Why can't I use $HTTP_SESSION_VARS with my authentification ?

If someone comes from another server (with admin variable set in his session), then his session variable isn't valid anymore on my server (I tought so, till now ). A new session is generated on my page (with new vars) and he cann't break in.

I am new in this stuff, plizz explain this to me

hi,

check this.


i found it here.
pretty interesting !!!
jd

Actually, this "can" be changed (on Apache) at least..

here's a "simple" yet effective solution, that makes sure "any" file
you are using on the Apache server (that is PHP) is sent to the
PHP interpreter..

such as ".inc" files..

basically, I simply added an AddType line to my .htaccess file, which tells Apache to pass .inc files through PHP.

AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .inc

-------------------------------------------------------------------------------
So, in my case, if you call one of my .inc files... you will most likely get "nothing" but a blank a browser window.. (this depends on the include file, of course.. if the includes does some type of "execution" - then whatever output is delivered.. )
-------------------------------------------------------------------------------

In short, "if your on Apache, and your host allows "overrides".. then you can set up an htaccess file and establish this type of thing.

Call it a security feature if you wish, to me "it" just makes sense.

I think it's actually a bennie of Apache.. allows you to pretty much use an file extension as a PHP document.. This "isn't recommened!".. i.e. you don't want to set up .htm or .html as an PHP file extension.. you "could" be wasting server processes.

I do recommend checking with your provider before implementing, 1 - they may have some restrictions.
2 - they may "already" have this set.
3 - they may not have Allow Override enabled.

I must admit.. after reading this post, I just "smiled".. going he he.. I know that.. I know that.. I know that .. "cool" more security minded than I thought

Maybe this comes from authoring Perl scripts for so long.. Frankly, I've seen "too" many Perl scripts have "major" wholes in them.. probably the most infamous one (as of late) has been thrid parties exploiting a hole in the "famous" formmail.pl script.. which, did not prevent third parties from using it to send email remotely...

i.e. with FormMail.pl you could pass a query string to it, and it would send email.. so unscroupulous spammers can use your formmail script to send spam...

I've also worked most of this out before, both in my code, and others, and this seems a fairly good guide.

I think JeffCT makes a very good point about the script security being a bigger risk that the webserver's security bugs. I think this has been proven to be the case in the last couple of years, with the biggest security botch ups shown in the media, haveing been discovered by people with very little knoledge of hacking, and mostly by changing things in the url query string.

One of the biggest problems i have come accross is where sites check usernames and passwords, and then give a list of orders etc, and these can be viewed/edited by clicking on them. Although these often check that you are a valid user of the system, they quite often neglect to check if the order you are trying to view is yours! eg you get links to:
www.test.com/order.php?id=1234
www.test.com/order.php?id=5678
and you type:
www.test.com/order.php?id=4321
(which isnt your's)and it works!

Also, another method i have used for including files, is to only take the filename, and not the extension, so:


this is fine, unless you are including files with .php,asp,etc extensions!

Yeah I know. But that's not practical and I don't recommend anyone does that. Why? If you plan on running it on any servers other than your own, you should assume people aren't going to edit their .htaccess or httpd.conf just for your program when all you need to do is rename it to .php or .php3. I can't honestly see any reason why you would have to name it .inc, you don't get any benefit from doing that as opposed to .php or .php3.

There's a workaround for one of my other points, the global variables one. You can turn those off in PHP. But *always* assume your users are going to have the default configuration. Don't setup your own special workarounds in your PHP configuration or web server configuration - not everyone will hae those. Just write careful PHP code to being with.

a security issue related to your topic #6--

IF someone directly codes a database connection in a Dreamweaver Template file or Library Item, AND uploads the template or library item files to the server, the php will be readable as plain text in the source, because the files have a .dwt or .lbi file extension and aren't parsed.

So, if you use dreamweaver and php, check your site for uploaded Template files. Any thing in them you don't want seen? then remove them from the server.

Dreamweaver will upload the Templates folder if you choose "upload dependant files" or syncronize the entire site.

macromedia has been made aware of this, and the behavior of Dreamweaver 5 will be changed somehow when it comes to uploading templates and library items.

I don't get it

It still think that the right way to do it, is to use session variables : Your solution whit checking pass and username everytime is time and server consuming. I will agree to check it every time, if you convince me that there is a posibility to break in my script

I know that session work with cookies, but aren't sessions made for such problems ? How can this be overriden ? Answer plizzz .... I need to know if my scripts using sessions are secure (I can't sleep at nights because of that discussion )

Messner

Good point, I woule recommend sessions instead.
(the original article was updated)

That about server resources wasn't meant in abslolute values.

My point is, if you have two equally secure options and one is faster then the other, then you should go for the faster one .

But my question that still bothers me a lot is:

Is my script using authenthication check as desribed above secure or not ?

After thinking about it, i cant see any problems (but there may well be) with storing the logged-in variable in a session var.

However:
1. there is the overall problem with sessions, that they are hijackable, by another user using the same session id from the same or another machine. although the effort involved with this would probably be equivilent to that required to snoop the username/password.
2. remember that when using sessions that the session data is stored in a file. On a system with many users, a properly indexed database may even respond quicker than session functions.
3. depending on the isp's setup, a shared server will probably use the same tmp directory to store session files, so anyone with access to the system may be able to view your session data!

Ofcourse security of a site is only as good as it's weakest point. If you are sending the username and password through unencrypted http requests, then they are prone to snooping (and caching - i have used so many sites that think i'm already logged in as someone else, because i access them through a proxy server).

Another point here, is that you cant get round the problem of snooping etc by checking ip addresses. my current internet connection uses dynamic (hidden) proxy servers. And there are more than one, and my requests go through different ones for each request, giving the webserver varying ips for me.

for some of my includes that come from the url:
page.php?page=page1

i try to make the actual file name harder to guess or different.

in my directory of include files for example:
blah_page1.php
blah_page2.php

and no one can see the files in this dir (hopefully).

and the code could be like:



like someone said, the .php does restrict the file somewhat. also having a directory set in the include() can limit the files included, and files before that dir can't be accessed (right?)

Can anyone see any problems with the following security model for communication between 2 systems through http requests?

system 1 and system 2 both know the password, which is never passed through a http request.

system1 requests a unique id from system2. system2 generates an id, stores this id in a database, and returns it to system1.

system 1 then can either:
1. perform a request to do somthing (such as delete entrys) by an http request, passing the unique id and a password that is formed by :

or
2. pass some data by an http request, passing the unique id and the data that is encrypted using a key that is formed by :


Upon either of these requests being made, system 2 will only allow requests to be made if the unique id is in the database, and will delete this id after the request has been made.

I believe that in the first instance:
-someone cant get the password from a request.
-they also cant reuse the password/unique id from that request because they will no longer be valid

In the second instance:
-the cant obtain the password from the request.
-they cant reuse the uniqueid for another type of request.
-they cant make a fake request by obtaining another unique id, because they wont be able to encrypt the data with the right key (assuming the data is validated on system 2)
-they cant decrypt the data being passed because they only know half the encryption key.

Ofcourse at any time, anyone can obtain a unique id. however i cant see a way of them obtaining the secret password to go with it to do anything, without getting into either of the stytems to obtain the password stored in the php file, and if they manage this then they will have access to the information on those systems, so the security system is no longer of concern!

Nope, that actually won't stop anything

If you use ../ the in filename it assumes you mean the directory above the current one. So if the path to include was something like:

/home/jeffct/public_html/include/$page

They could set $page to:

../../../../../etc/passwd

And if they didn't know how high your directory was they could just do something like this:

../../../../../../../../../../../../../../../../../../etc/passwd

Just to make sure I was all the way at the root directory.

Now, putting .php onto the end of $page does limit what can be included, but then any PHP file on the server could be included. If the server had something like anonymous FTP then someone could simply upload the code they want included and call it from your script.