Page 8 - [Everyone] Must read Security Notes

>>And it should be pointed out that nothing very important
>>should be put on those sites, anyway.
Would you provide definition of 'very important'? Surely, amazon or ebay will not host there, and so shouldn't any more or less respectable eshop or any other kind of site that get personal information. But the thing is that they don't. Who does use shared hosts, however, is those people who are either just learning or do not think their info is worth $100mo+$for pro, and that is totally fine. Not mentioning that shared hosts *can* be configured to be failry secure.

>>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.
It is indeed, but I still stand strong on my opinion that vast majority of visitors here aren't professionals or at least not in this field. Those who do make buck or two find themselvs in positions where they ought to learn sec stuff or they will be out of business.

>>But .HTACCESS doesn't need to be avoided. It's a good way to
>>get familiar with the syntax and concepts of configuration, anyway.
That is correct, but why should one jump head first using as main security shield something he has little or no idea about? Or even something that he just started learning/using?

>>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.
If someone figures out a way to write an .HTACCESS file on a site they will also find way to read a .php file.

>>Joe or Jo Developer should practice the best security he or she
>>knows, and ought to be learning as much as possible.
And my purpose of coming here is to help them out. What's yours?

I'm going to add to this, because it seems like the only one of these (excellent) points that hasn't been elaborated on. This example comes from a project I revisited after reading this thread a few times.

I used eval() when I had:
1) an unknown function to run on a given object,
2) a function to run on an unknown object, or
3) both- unknown function, unknown object.
This resulted in code that went something like this:

yikes. I thought that I couldn't write this directly in PHP, so I had to build a string that looked like what I wanted to do, then eval() it... wrong! To avoid using eval() when working with unknown objects or functions, you have to remember that PHP supports both variable variables, and variable functions. The above should have been written like:

Since $obj has a string representing the name of some object in scope, $$obj is that object. Furthermore, if the string in $func is a valid method of $obj's class, PHP will attempt to evaluate that method. This also works for regular functions.

From the manual:
http://www.php.net/manual/en/functi...e-functions.php
http://www.php.net/manual/en/langua...es.variable.php

Hope this helps someone avoid the mistakes I made.

Maybe you should

Wrong answer.

The only people who are going to configure those servers are the people who own them, or someone they hire.

Wait. There's a "joke" going around that the best sysad is the guy who owns the back door.

If there is no motivation, those servers are going to continue to be open to attack and/or already taken over. Security is everyone's business.

If letting it get in the wrong hands could directly or indirectly cost me more than a day's work or a day's pay, I would not put it on a server I couldn't secure myself:

Passwords, ID numbers, account numbers, birthdates, names of real people in many cases, ...

And if I were going to bother password protecting a site, I would not keep a password file in any directory a browser could see. Even if I were just playing around, I would warn the visitors against re-using important information in their passwords.


And if they can be, they should be, I'd say.

So why not encourage them to learn before they go out of business?

And why not encourage them to learn? Instead of JeffCT saying things like, "Hide it in a file with the .php extension." I would prefer he said something like, "You can sort-of hide the contents of files by giving them a .php extension, but don't rely on this trick too much."

That ain't exactly true.


Ditto.

I've seen a lot of un-trained people who can write a little HTML get pressed into jobs because professionals aren't available. I've seen a lot of "pros" who rely on the .php extension, and it seems to work the first time, so they never learn to do it right.

I've also seen a lot of people who don't realize that, with search engines available, whatever they put on the web is at least as much available to the public as what gets scrawled on the wall beside the public telephone (or in the public restrooms).

Yeah, yeah...okay...we got it. Every server should be properly configured and it's our responsibility to do so.

Can we just get back to specific security issues, please, and how to avoid/eliminate them?

---John Holmes...

That ain't exactly true. [/quote]
Sorry, I just have to comment on this one...

This is true, if someone can create a .htaccess file on your site and not have legitimate access, it is just as easy to create a php file that has a view source function connected to a get string, or exec/passthru etc, etc in it.

Anyway, as SepodatiCreations said, let's get back to the topic. If you would like to write your own thread about how to properly configure a server, go for it.

A handy way to avoid people posting their own form to you is when validating the input, validate $_SERVER['HTTP_REFERER'] to make sure the input isn't coming in the back door.

Possible but not reliable since it is up to browser whether or not to send referrer. Plus, it can be easily spoofed.

This whole HTTP_REFERER thing has me thinking: why can't there be a non-spoofable way to check the referer? Maybe some sort of temporary key delivered to the form, and checked upon submission -- maybe tied in with the session key, so that it could never be spoofed, or at least, spoofing would be a real pain. Even better yet would be some sort of RFC for POST operations in general that would do something with SSL keys to force a referer.

At the very least, you could set a session in the form, and then check it upon submission, so that the spoofer would always have to at least go to the trouble of loading the form, accepting the cookie, etc... to start spoofing. Also, don't allow more than a few submissions from the same IP address/[browser footprint] within a short time.

But in the end, you still have to assume that you could receive any value into your form handler, so it wouldn't be a final security measure, but at least it could reduce troublesome "submission-bot" traffic.
(In 2000, the company I was working for had an old CGI script for free classified ad submissions. I started seeing dramatic load on the server occasionally, so I checked once at peak activity. There were literally over a hundred instances of the script running. All coming from the same place. I tracked it down to some internet marketing^H^H^H^Hspam firm who was selling space on our website, and running a script to fill up our system with thousands of ads a day.)

racymor has a point there that one can make non-spoofable referer value, but it just won't fly too high. As far as I can remember, they allowed people to disable ref. value because of this security-privacy rush some years ago, and it just won't make it nowadays. At least not public and not forced.

And I think as to registration spam, the way major portals do is fine by me (random picture with word/numbers on it), although I do wonder how long it'll take for someone to write algorithm that analyzes pictures.