July 30th, 2002, 01:38 AM
>>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?
And you know I mean that.
July 31st, 2002, 01:40 PM
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:
$func = function_name_from_input_or_database;
$obj = object_name_from_input_or_database;
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:
Hope this helps someone avoid the mistakes I made.
August 1st, 2002, 06:49 PM
August 2nd, 2002, 01:45 AM
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.
August 2nd, 2002, 02:16 AM
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.
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).
August 2nd, 2002, 02:46 AM
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?
August 2nd, 2002, 07:42 AM
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.
August 2nd, 2002, 01:21 PM
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.
August 4th, 2002, 07:31 PM
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.
August 4th, 2002, 09:08 PM
Possible but not reliable since it is up to browser whether or not to send referrer. Plus, it can be easily spoofed.
And you know I mean that.
August 4th, 2002, 10:28 PM
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.)
August 4th, 2002, 10:52 PM
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.
And you know I mean that.
August 5th, 2002, 03:58 AM
(With apologies to JeffCT for piggybacking his thread one more time,)
Well, that ain't necessarily true, either. It's close, but if it were completely accurate, .HTACCESS would be much more than just a band-aid.
If the server is set up correctly, .HTACCESS files are not (barring some unforeseen bug) inherently weak. It's some of the corner cases, where the simple view stated by Onslaught above (and earlier by AlCapone) doesn't hold, that cause the headaches. So, you should prefer to restrict the setup to the main server configuration as much as possible.
Be aware that *NIX does not use levels of access, by the way. You can give write access without giving read access, which is sometimes useful. This can be one of the corner cases, but there are others.
Hmm. I should point out that it's necessary to correctly specify access both from the system point of view and from the server point of view.
Anyway, if you can use .HTACCESS files but can't set the server configuration, go ahead and use them. It makes for good practice, and it raises the wall a bit.
I'm half inclined to think that it's okay using the .php extension to hide the contents of non-source data that you want hidden, _if_ that's all you have. But it is not reliable, and if .HTACCESS controls are available, .HTACCESS should probably be given control instead.
In addition to server setup issues, if the version of php is old and unpatched, the .php extension may be only protection against the casual visitor. There is a known bug, and there are known exploits for the bug.
With the .HTACCESS controls, you can completely deny access to a specific file type, or completely deny access to all file types except, say, .html and .php. That means you can specify that some file types will simply never be accessible, interpreted or otherwise, by someone typing the file's URI into a browser. You can also divide your personal home directory into sub-directories for serving html, sub-directories for serving php, and sub-directories that are not served at all, which is even better.
But you should test the results, just to make sure the main server setup doesn't defeat you.
One thing to remember when specifying the access for a directory, you usually want to deny directory listing access. A directory devoted to download is an exception, of course.
How do you learn all these cool settings? Download apache, get it running on your own personal machine as a private network of one machine (http://127.0.0.1 or http://localhost) and start messing around. Just don't forget to shut apache down before you dial in to your isp.
If you're not too careless, you can develop your pages on your own machine and only upload what works. Developing on your own machine leaves you some more options for backup, too.
August 5th, 2002, 04:08 AM
It's an interesting thought, but you're right that it would require encryption and some fancy playing with keys. Could be done, server side, with the present technology.
Thinking casually about this, it sounds like it would look a lot like sessions without cookies. You end up tracking your users in the URL, since that's how you would set the URL of the referring page. Sounds like more work than it's worth.
August 5th, 2002, 05:26 AM
>>You can give write access without giving read access
Can it be done? You bet. Is this the case on most host? Not just no, but hell no.
>>How do you learn all these cool settings? Download apache,
>>get it running on your own personal machine as a private
>>network of one machine and start messing around
This is my personal favorite - do you really think that we do not have apache installed on local box and that all we do is based on some shared host somewhere? If so, then until you start making reasonable posts I will try to withhold from further commenting on this issue.
jrees, we are going in circles here - it is obvious that neither you nor me is going to change his mind, so let's stop hitting each other's tail and start doing something productive.
And you know I mean that.