Page 7 - [Everyone] Must read Security Notes

A good link which covers many of the points raised (and some new ones, I think) is

Secure Programming in PHP > URL



Sil
URL

What about your arguments about writing portable code? Like developing with register_globals off and checks for magic quotes. Doesn't using that Apache band-aid make it a little more difficult to keep things portable?

Although for the most part MD5 on your password will cover the problem, if there's anything you wouldn't want anyone else to see, make sure not to pass it into the url. Why? Because if one of your users accesses a page with:

and then surfs to another site, if the person on that other site goes through their referer logs, the referer page will offer up the full url including the password!

Surely you'd be better off using 'post' forms to pass passwords rather than 'get' as then it wont be part of the url, and also not to pass it on between pages in the URL string, but use sessions or somthing else instead.

I just read part of http://www.securereality.com.au/studyinscarlet.txt
and gosh this part "got" me, never dawned on me!!:



Now I finally understand why it's important to declare variables! And how this "shortcut" is a security risk and to write code properly requires being even more vigilant than declaring variables would have been whew! Maybe I should take a PHP course? Any in NY?

I dont think this kind of stuff can be learnt. It's the kind of thing you really need to think about, and pick up more easily when working on stuff. These security issues often apply to other languages aswell such as asp and java servlets or jsp pages.

I'd say read (and think about) the whole of this thread, as it covers most issues quite well.

Quote:

6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXTENSION.

If you have a start session include file, by giving it a .php extension is that not a security risk as somebody could start a session simply by calling the php file?

Here's a small security issue I just found out about today. It's called CRLF Injection and can affect mail() and possibly other classes used to send mail.

How is works is that if a user can take your form that sends an email, and send a Subject value like: "This is my subject\nBcc: myemail@myisp.com" then they will get Bcc'd on every email sent out when you use this Subject in mail. One method to do this is to download your form (save as), modify the usual 'text' box into a <textarea> and put in a subject like above. Note that it has to be an actual line feed like in a textarea, just using \n won't work b/c that'll be escaped by magic_quotes.

The To: field in mail() might be vulnerable, too.

I'm thinking that this should be a bug in PHP. I can't think of any reason this should be allowed. I've asked about it on the PHP List, too.

All it boils down to is to continue to validate user input and make sure it's what it's supposed to be. Make sure your To: and Subject: in mail(), don't have any new lines...

---John Holmes
(sorry for dredging up the old thread, too, but it is good reading!)

wasnt this thread sticky once? how come its not anymore? btw, thanks for the warning on the mail bug.

And I am wondering why on earth you have your include files, whatever you've named them, in the part of your file system visible to the web.



Yeah, and then you have to worry about what that code will do when it's parsed stand-alone, like someone else pointed out.

If it's nothing but functions and classes, you may think you're safe, but what about global constants? You really want those visible?

So you really want the definitions accessible to who knows who, for playing around with?

<tongue-in-cheek>Where's the pages you work on? I've no time to play games with them, but I think I could find someone who wants to practice.</tongue-in-cheek>



Portable to what? Surely not M$PWS?



Oh. Good point.

But since when are configuration files not part of the app?

No, I tend to question the qualifications of anyone who can't remember to carry the configuration files along when he moves an app.



What band-aid? That's not a configuration you usually want to have to use, but it is NOT a band-aid.



Let's try some better common sense: The configurations for php and apache which move your include paths out of your public file system are not hard. They work plenty well, and they allow you a lot of options in organizing your apps.

For instance, you can write yourself a note in a file called "FORGET_ME_NOT.IMPORTANT" that contains the paths to all your configuration files (maybe you're using multiple languages?) and other things, like the dlls you're using and where you put them. And you can save that in a directory called, say, "app". And you can have two subdirectories of that called, say, "includes" and "visibles". And you can tell apache to serve "visibles" to the web and you can tell php to use "includes" as your include path:

~/home/webhome/app1/FORGET_ME_NOT.IMPORTANT
~/home/webhome/app1/includes/...
~/home/webhome/app1/visibles/...

Simple? Logical? Easy to take every thing you need with you when you move it? And, best of all, your includes are not only never printed out in anyone's browser, but they aren't accessible to your ordinary hacker, either.



I did. I railed on you. Gently.

Yeesh.

That is a poorly configured server.

Want me to repeat that?

No server should ever be allowed on the web configured like that. If someone can climb the file system like that and get beyond document root, that server is three minutes to 0wn3d.

Rather than waste time pandering to the ill-informed, write up how easy it is to configure a server correctly. I mean, apache comes with an installer for M$Windows now, and the installer asks you where you want the default document root.

Hey, Mac OS X even comes with apache set up right!

No. I don't think your arguments about trying to avoid configurations are valid. Not at all.

>>That is a poorly configured server.
Sadly enough, most shared hosts are that way and not you not anyone else can stop that from happening. The only thing that is left for developers is to develop for the worst possible scenario.

>>If someone can climb the file system like that and get beyond
>>document root, that server is three minutes to 0wn3d.
Care to share how exactly?

>>Rather than waste time pandering to the ill-informed, write up >>how easy it is to configure a server correctly.
Like there isn't enough info on that already. Look, this is not Sepo's or Jeff's job to reinvent the wheel and give out free pro advices - this is no salvation army. This is, however, php forum where quite common security mistakes have been pointed out
>>No. I don't think your arguments about trying to avoid
>>configurations are valid. Not at all..
I am *so* happy that you have dedicated boxes for each and every your client, but so many of us don't, and we have to work with somebody else's configuration files no matter how much wrong they are. Yes, developers do advice their hosts to change things to something better, and more often then not they follow advice, but as I have mentioned before one should hope for the best but code for the worst.
>>And I am wondering why on earth you have your include files,
>>whatever you've named them, in the part of your file system
>>visible to the web.
Good point which probably should be discussed in more details, but for vast majority of config files this is not an issue sicne information that is kept there is more of useranme/password sort of text. So making it .php will do the job just fine.
>>what about global constants? You really want those visible?
What about them? Since when does one echo all the config vars?
>>So you really want the definitions accessible to who knows
>>who, for playing around with?
If it is badly configured shared hosting there really isn't much you can do about it.
>>Portable to what? Surely not M$PWS?
Not portable to hosts that do not allow overriding.
>>No, I tend to question the qualifications of anyone who can't
>>remember to carry the configuration files along when he >>moves an app.
When was the last time you checked the audience this thread was written for? Average Joe Developer *does not* have qualification to think of all the security problems and differences in configurations.

Don't get me wrong, jrees, everyone should speak out on any matter, but it's just that (I think) you are relativetly new to community and don't really see what sort of people we have here.

Until someone properly configures every single one of the hndreds of thousands (or millions?) of servers running PHP I would hardly consider my post not valid.