|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| ||||||||||||||||||||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread |
Rating:
|
Display Modes |
|
#16
|
||||
|
||||
|
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 ![]()
__________________
Saintaw pending. |
|
#17
|
|||
|
|||
|
__________________
The real n-tier system: FreeBSD -> PostgreSQL -> [any_language] -> Apache -> Mozilla/XUL Amazon wishlist -- rycamor (at) gmail.com |
|
#18
|
||||
|
||||
|
Why can't I use $HTTP_SESSION_VARS with my authentification ?
PHP Code:
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 ![]() |
|
#19
|
||||
|
||||
|
hi,
check this. Quote:
i found it here. pretty interesting !!! jd
__________________
_____________________________ d.k.jariwala (JD) ~ simple thought, simple act ~ I blog @ http://jdk.phpkid.org |
|
#20
|
|||
|
|||
|
Re: Security Notes (Everyone should read)
Quote:
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... |
|
#21
|
|||
|
|||
|
internal security vs external security
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: PHP Code:
this is fine, unless you are including files with .php,asp,etc extensions! |
|
#22
|
|||
|
|||
|
Re: Re: Security Notes (Everyone should read)
Quote:
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. ![]() |
|
#23
|
|||
|
|||
|
Important note to users of Dreamweaver
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. |
|
#24
|
||||
|
||||
|
Quote:
It still think that the right way to do it, is to use session variables : PHP Code:
![]() 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 |
|
#25
|
|||
|
|||
|
Re: why not use sessions
Quote:
Good point, I woule recommend sessions instead. (the original article was updated) |
|
#26
|
||||
|
||||
|
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 ? |
|
#27
|
|||
|
|||
|
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. |
|
#28
|
|||
|
|||
|
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: PHP Code:
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?)
__________________
K1 |
|
#29
|
|||
|
|||
|
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 : PHP Code:
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 : PHP Code:
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! |
|
#30
|
|||
|
|||
|
Quote:
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. |
![]() |
| Viewing: Dev Shed Forums > Programming Languages > PHP Development > [Everyone] Must read Security Notes |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|
|