August 21st, 2001, 02:41 PM
Re: why not use sessions
That particular tip about validating the login everytime mostly applied to user sessions that weren't based on PHP4's session functions. I am not familiar with session backdoors and security hazards but I do know that if you were to reference $HTTP_SESSION_VARS before calling session_start(); then it could be set to whatever the user wanted.
Edit: The above will not work.. setting logged in status as a session variable is secure as far as I know.
August 24th, 2001, 02:21 PM
Just wanted to bring this back up since I am seeing a lot of new people coming in and asking about writing scripts that go against some of the basic security rules.. I think we need to make sure all PHP programmers are aware of these simple yet deadly mistakes... New programs containing these simple security holes are being released every day....
August 24th, 2001, 03:45 PM
yesterday a friend of mine asked how he could do some login stuff (simply including another file if they were a valid user). i pointed out that someone could just enter that filename, and he seemed suprised that he had made somthing so insecure!
perhaps you ought to rewrite your origional message and some of the replies as an article on secure scripting in php (and other languages).
August 24th, 2001, 03:53 PM
ouch, thankyou all for your posts i have found them extremely eye-opening, especially;
which i have used on many of my earlier projects!
is anyone prepared to discuss the
"admin'--" thing in detail ?
i understand the effect, but dont fully understand an effective way of stopping it,
thanx for reading,
August 24th, 2001, 04:09 PM
That would be a good idea, I wonder if I could actually get ahold of any of the people at devshed. I've emailed them before about writing articles and received no reply.
August 24th, 2001, 06:41 PM
Sorry, sometimes some e-mails slip through when you are as busy as we are.
August 24th, 2001, 06:45 PM
In reply to Jonny's question:
Incase anyone else hadn't got the idea, i'll explain the problem again using another example:
say you have a form that sends a username and password:
and say that your target php script works somthing like:
<input type="text" name="username">
<input type="password" name="password">
Well if you entered bob as the username, and 123 as the password, the resultant value of $query would be:
$query="select from users where username='$username' and password='$password'";
now, what could happen is someone enters anything as the password, and the username as:
select from users where username='bob' and password='123'
so that the value of query becomes:
this is interpreted as:
select from users where username='bob' -- ' and password='123'
as the rest is treated as a comment.
select from users where username='bob'
To solve this problem, simply change the php code to:
thus if someone entered the 'bad' username, it would make a query string:
$query="select from users where username='$username2' and password='$password2'";
the slash after bob is a way of escaping the next character, ie it tells the database that the ' after it is part of the text string, and not the end of it, so the -- is treated as part of the username it is looking for, ie: bob' --
select from users where username='bob\\' -- ' and password='123'
As this entry doesnt exist it wont find anything!
Note that you only need to worry about this if magic_quotes_gpc isnt enabled (which it seems to be on about 50% of servers). if it is enabled then php will do it for you!
Hope this helps!
August 25th, 2001, 07:29 AM
That was a superb post and I think it's something that everyone should definitely read. I've actually saved the whole page to my HDD so I can refer to it in the future.
I think it's very difficult for newbies to understand just how wide open some sites because of silly mistakes, purely because they are still trying to grasp the concepts of server-side scripting.
When I first started with ASP and I found out about using the query string, I used it for near enough everything I could as it was just so convenient. I've totally changed that ever since I built my first security features into my sites and now most things are either hidden in variables that don't need to access the query string, or within encrypted cookies and by using session variables.
Some web site exploits are so unbelievably lame that a 5 year old could get in without any trouble so for those of you who don't think it is that easy, here's an example.
In IIS 3.0, there was a very simple exploit which allowed an attacker to view your ENTIRE source code! How? Too simple to comprehend. Say there was a page on an IIS 3 server called index.php. An attacker could simply type in index%2Ephp and view the ENTIRE source!!! %2E is the hexadecimal value for a full stop.
I hope that demonstrates just how easy some exploits are. That one should be obsolete now, but you never know. That proves another point also. As secure as your scripts are, if the server you are serving them on isn't, it can all be completely fruitless.
All servers should have the latest patches and hotfixes installed on them and you should take the time to secure your scripts in ways like Jeff has suggested. Remember, simplicity isn't necessarily secure.
Great post Jeff
August 26th, 2001, 05:38 PM
Re: Security Notes (Everyone should read)
Newb question... brace yourselves
What does "cat" do in that case?
August 27th, 2001, 11:45 AM
included.php is WORSE than included.inc
6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXNTESION. It became common for
After hearing Rasmus rant about this at a talk last week, I need to chime in with his advice on this. He basically admitted to possibly having started the convention of included.inc files. His statement, however, was that most folks didn't realize that his Apache conf files had the following directive in them.
<Files ~ "\.inc$">
Deny from all
That basically stops everything but his script from being able to access his *.inc files.
He then commented that most folks when they realize that the *.inc files can be sent in the clear as ASCII text, they switch them to *.php files. This doesn't fix the problem. If someone knows your API, they can still use the functions in your included file.
His rule is that if you're going to use included files, they should be outside the docroot or restricted with a Deny from all directive to keep them safe.
Sorry if I didn't make his reasoning clear, but he was pretty adamant on this point.
August 28th, 2001, 03:27 PM
how exactly is someone going to include your include.php file if they don't have their script running on the same server?
August 28th, 2001, 06:22 PM
Hey JeffCT, I read through your list of security possibilities and are good for the new ones at PHP, but I think it was mistake posting it in a forum. If you may be thinking why, well, topics that are posted in one week are gone the next. I haven't check devshed articles on PHP security but I would encourage you to post your thoughts in an article and submit it to devshed, so it has a longer duration of being recognized.
z-lite was here
August 29th, 2001, 10:02 AM
Using API in PHP files
They don't need to be able to include a *.php file to exploit the API. All they'd need to do is call the file directly and pass appropriate variables into it. Rasmus' main point was that *.inc files may be displayed, but *.inc.php files are parsed. Often, running an included set of functions outside the expected scope can result in unexpected consequences.
August 29th, 2001, 10:36 AM
That makes sense now, I see your point. But I thought you were referring to an exploit I was unaware of. That goes back to my original points in the first post. Include files are no more insecure than your regular scripts then.
The fact that you Could accidentally write the include file in such a way that it could be exploited doesn't mean they are "bad" or should be avoided. In that same sense everything PHP would be bad.
My goal with this post is so that you Don't write your script like that.
I should hope someone's include file doesn't look like this:
function blahblah2 ()
But I don't agree with what Rasmus said on the topic (from what I understand). To put your include files out of the docroot to be safe. I say learn to write them correctly and you won't need to. If you follow his advice you might as well put your whole site out of the docroot to be safe :/ What's the difference?
When you write your script/include file, ask yourself "How can I make this script secure?" not "How can I hide this script?"
October 25th, 2001, 06:33 PM