Page 5 - [Everyone] Must read Security Notes

I haven't really read this whole thread, but I kinda want to get something cleared up

is this right?
1) there are cookies which are stored until the expiration date
2) there are sessions which:
a) uses cookies that expires when closes browser (is that right?) and
b) uses the PHPSESSID var through the url and doesn't use cookies and stores the data on the server.

I sometimes get all confused...

1) yeah

2) Right: Read on:

Sessions 'remember' their state either by checking a cookie, or by using an ID hash (PHPSESSID)

If transparent_session_id is set, then PHP will use the latter if cookies arent supported. Personally, i dont like cookies and try not to use them, but some ppl just hate the URL being cluttered up with the long and messy session ID.

Hope this sheds some light


.pd

I have just read the "A Study In Scarlet" article, and i think Shaun Clowes has some vaild points. One thing he emphisises is the problems caused by php's versatility combined with flawed code, such as his example of:

If it is possible to set $libdir, this would allow attackers to use http and ftp paths in $libdir, by default, and execute their own code.

My thoughts about powerful (and potentially dangerous) behaviours (ftp/http in file paths, file upload, etc) is that perhaps php should be more cautious, and by default dissallow them, and allow them on a per file basis. Perhaps this could be done by adding a config tag to php pages e.g.:

Im not 100% sure but i think you can change some settings on the php.ini for each php program, like set_time_limit()

You should check out also the security improvements in php 4.1, which mainly are just small changes to help writing secure code.

i.e. turn register_globals off, and use the _GET and _POST globals, etc (I used to use the HTTP_GET_VARS etc, though it was so nasty..)

.pd

HTTP_GET_VARS and HTTP_POST_VARS is horrible but would help security, especially that of begginers, or rushed developers! Perhaps it would be better if we could specify a list of get, post and cookie vars to make global in each file?

Maybe a better solution would be to attack the source of the problem, rather than change the language.

Maybe php should make more use of warnings, and warn people that a variable may be used without ever being set, so code like:



would throw an error like:
Warning: line xxx, $auth may not have been set.

I remember somthing like this in java, which came in really usefull.

Perhaps it should do this on a per file basis (including any included files), as an include file with:

could be executed on it's own.

One solution i came up with relating to the problem of include files containing dodgy code like above, was to put the code in the included file in a function, that way it couldnt be run on it's own!

Actually, PHP does this. One of the most important things to do when developing PHP is to do it with the error level set to max (E_ALL).

As for HTTP_*_VARS, check out the changelog for the 4.1 release, some important changes there.

Most of the issues from this article can be dealt with fairly easily, and with the 4.1 release the PHP developer group has taken steps towards educating newbies at an early stage.

Correct me if i'm wrong, but php warns if it has come across a variable which HAS NOT been defined. It doesnt warn that your code WOULD ALLOW a variable to be undefined. There is a big difference here. Imagine an included library file, and the code in this file may assume that you will always have set a variable from the code that is including it. This would be open to abuse by a hacker accessing the library file directly supplying their own value for that variable. If you run this in php, because that variable is set every time the library file reaches it, it wont throw any warnings (assuming you dont run the library file on its own!). I am suggesting that it should warn of this type of problem.

it's important to note that even though they're "deprecating" register_globals, the thing that lets you skip using the HTTP_*_VARS arrays, they're not removing it. in fact, they state that they won't remove it in the forseeable future (i think) because there's so much code out there that's dependant on it.

so, it'll still be possible to write code with register_globals on. now, i'm confused (having not read this whole thread) as to why that's a bad thing *in and of itself*. it's quite possible to write code that's secure while still using register_globals as a matter of convenience. before taking an action based on user input there should be checks against the database and/or session to ensure that the action can be taken by the current user, and other checks to make sure all required information is present and accounted for in the request. if that was offtopic or redundant, you can ignore it and make fun of me behind my back.

also, why is it so important to develop with max warning level? i can't believe how annoying it is to always get a warning when i call a function with fewer parameters than it declares, for example.

One point to developing with the max warning level is that you (the developer) catches all possible bugs while it is still in the development stage.
You know how to deal with/correct warnings and errors as they occur, but you users most of the time will not.
If you catch more possible break points, there will be that many less in your script when the user is using it.

yeah, but that's what QA people are for. sometimes I actually like working in an office environment

back to the point, which was that I don't see why that's going to help me write more secure code. I could write something like what pezzer did a few posts back, but that wouldn't generate an error because it's perfectly legal in php to use an unset variable in a conditional. that's one of the things I like about php- it bends over backwards to allow me to write code fast and dirty, if I so choose.

imho what it comes down to is this: php makes it more difficult to write so-called "correct" or "secure" code, or whatever, i.e. never using unset variables and such unsecure things, and less difficult to hack in a feature that your customers want and do it faster than anybody else. One time I did a huge project in jsp/servlets, and man do I hate maintaining that sonuvabitch. a project built with php lets me get in, make a change, and get done so I can get on to more important things like wasting time browsing forums . if I do something wrong, so be it. but if I'm just a little careful I can avoid doing hugely stupid things, security-wise, while still adding features quickly.

I think that is part of the point behind the register_globals being off and using HTTP_*_VARS. 1)You don't have to re-invent the wheel as far as checking where it came from & 2)You are forced to be a little more secure in the process.

Hey,

I don't fully understand why using the HTTP_*_VARS is more secure. Can't a hacker use the HTTP_*_VARS just as well as he could use the variables generated with register_globals on?
What makes it more secure, other than having to type a few more characters?

Eclipce

Eclipse:

As far as I know you cannot make your own counterfeits of $HTTP_*_VARS in the same way you could do that with globals.

I do not believe this will work:

http://example.com/script.php?HTTP_POST_VARS[blah]=blah

Someone may want to try that to verify.

However if all you did was use the variable blah with register_globals on, you could provide your own setting for blah like this:

http://example.com/script.php?blah=12345



merkinmuffley:

I don't know if I would say PHP makes it moer difficult to write secure code. I haven't had any problems doing that. I would say that certain over-used features in PHP (blame the tutorials maybe) make it easy to create unsecure programs. It's not necessarily difficult to write secure programs. You just have to know what to avoi.d

Verified. What you will end up with is

$HTTP_GET_VARS["HTTP_GET_VARS"][blah] = "blah";

So you can never hijack values in the "top-level" array called $HTTP_GET_VARS. But this changes nothing. Even with register_globals on, query string values can not replace a variable whose value has been set in the script, anyway.

As always, the real issue is "what exactly are you doing with the GET vars?" I agree to some extent with the others: if you are doing something insecure with variables from the GET array, without carefully checking their value first, you are just asking for trouble, and this applies with or without globals registered.

For example, in item 3, in your (JeffCT) first post in this thread (3. Try not to use input variables as globals. ), you mention how it is possible for a user to fake a POST variable with a simple GET variable. So your solution is to check the actual HTTP_POST_VARS array. This might make a difference to the casual hacker toying with the URL string, but anyone who really knows HTTP knows that you can initiate a POST request from a number of tools, even Telnet, if you want. Thus this distinction really makes no difference to the determined hacker.

The only answer is to follow good practice, and use constants for things that ARE constants, and explicitly check all user input: enough said.

So is there any good reason not to register globals?

Well, for large-scale development, with different programmers working on different modules, it is easy to see how the issue of code integrity and cleanness can come up. If you allow any old GET or POST variable to become a regular variable, you can "pollute the global namespace", to the point where code just gets unwieldy, or a developer might get careless and use variables without considering their source. So IMHO, not registering globals is more a matter of good code management, and preventing the occasional "Ooops" than security.