February 9th, 2002, 11:42 AM
February 18th, 2002, 02:26 AM
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?
One point I didn't see covered
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.
holy, er, moly
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.
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?
July 19th, 2002, 11:22 PM
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: email@example.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...
(sorry for dredging up the old thread, too, but it is good reading!)
-- Cigars, whiskey and wild, wild women. --
July 19th, 2002, 11:52 PM
wasnt this thread sticky once? how come its not anymore? btw, thanks for the warning on the mail bug.
July 26th, 2002, 07:08 AM
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:
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.
July 26th, 2002, 07:29 AM
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.
July 26th, 2002, 08:21 AM
>>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.
And you know I mean that.
July 26th, 2002, 09:47 PM
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.
July 29th, 2002, 04:56 AM
Who is going to configure those servers?
It's not that hard. It's few enough lines it could be copied out by hand and kept with, for instance, the pictures that were scanned into the site, worst comes to worst.
And why should we all wait for all the other guys to fix theirs? Every properly configured site is one less place for the script kiddies to play.
Understanding the file extensions is an important thing, yes. Abusing the file extensions is useful when you can't do anything else. But there is a better way.
July 29th, 2002, 06:18 AM
Looking through what you wrote, it seems that your whole point can be summed up right here:
To which I say, "just say no."
If it costs anything, the ISP had better be giving better service than that.
But, if someone simply MUST use the free sites, I suppose the advice about abusing file extensions to raise the wall a little beyond the rank amateurs level is good. But if we're going to be calling something "applying a band-aid", just which is "applying a band-aid"? And it should be pointed out that nothing very important should be put on those sites, anyway.
And then you say this:
Your "average Joe Developer" had better _get_ the qualifications to think of basic security issues, or he had better _not_ be developing for anything but a hobby. Basic configuration _is_ a basic developer issue.
Hmm. If the only configuration available is the .HTACCESS files, I'll acknowledge that you probably want to use the extension ".inc.php"idea as a little additional insurance. But .HTACCESS doesn't need to be avoided. It's a good way to get familiar with the syntax and concepts of configuration, anyway. Also, using the file system to organize your files is a good habit, and portable from server to server.
And keeping notes is also a good habit, although you may want to keep the notes off-line if .HTACCESS is the limit of configuration available. Not for what goes into .HTACCESS, of course. If somebody gets around .HTACCESS, they've got that much of your configuration anyway. If you did keep your notes on-line, you'd want to give those files an extension like .text.php, too, to use all the protection you can get from the server settings.
And you have to realize, if someone figures out a way to write an .HTACCESS file on a site that respects the .HTACCESS files, they may be able to quickly override the server settings concerning the .php extension. That depends on how tight the server has been set up.
So, of course, you don't want anything really valuable or important (including password files) on a site where you have that little control. (Did I say that twice? Good.)
Joe or Jo Developer should practice the best security he or she knows, and ought to be learning as much as possible.