Mad idea but it might just work

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Aaron

  • Posts: 356
Re: Mad idea but it might just work
« Reply #17, on March 8th, 2012, 11:43 PM »
SFTP is quite nice though, isn't it? Assuming we're talking SSH-FTP here. The only problem with it is that most shared webhosts don't offer SSH and thus no SSH-FTP, heh.
"The entire British Empire was built on cups of tea … and if you think I'm going to war without one, mate, you're mistaken."

Norodo

  • Oh you Baidu, so randumb. (60 sites being indexed at once? Jeez)
  • Posts: 469
Re: Mad idea but it might just work
« Reply #18, on March 9th, 2012, 12:00 AM »
I can't think of any webhosts that don't offer SSH. I know Dreamhost and GoDaddy does, and so does Nearlyfreespeech.

I'm sure there are some, but I'd think they are fewer than you seem to think.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mad idea but it might just work
« Reply #19, on March 9th, 2012, 12:45 AM »
Yes, I was talking SFTP in the truest sense of SSH-FTP (as opposed to FTPS), and it's a *much* more sane approach (none of this virtual path crap), but you're right, most shared hosts don't offer it, ironically they'd be the ones who would best benefit from having it available.

The whole fundamental problem that is attempting to be solved here is how to, essentially, secure files that are intended to be executed within something that's conceptually the sandbox of user permissions without having to have them owned by the webserver and without having to have them worry about umasks or anything else; if it is conceptually the same as uploading via FTP it will inherit your account and so on - this is primarily FOR shared hosts.

Eh, I've gone back over the FTP class in SMF/Wedge, and I think I'm going to end up doing the same thing, the whole shebang manually, because I can't rely on any of the easier methods. Though I'm not quite sure whether I should attempt to use IPv4 first and only then fail over to IPv6 if that doesn't work, or attempt IPv6 first and try and catch what happens after.
Quote from Norodo on March 9th, 2012, 12:00 AM
I can't think of any webhosts that don't offer SSH. I know Dreamhost and GoDaddy does, and so does Nearlyfreespeech.

I'm sure there are some, but I'd think they are fewer than you seem to think.
I stand corrected as far as GoDaddy and DreamHost are concerned, having just double checked that (since I couldn't believe they'd use a proper protocol for all standard customers)

I guess I'm just very sceptical as far as these things are concerned, simply because I've seen too many people burned in the past.

The problem then to deal with is how to get people to understand about SFTP credentials, because I doubt most people have heard of it, and just for fun, there's also FTPS which is a very different thing all together.
Posted: March 9th, 2012, 12:06 AM

I'd also note that it does rule out 000webhosting.com who only offers a single FTP account for the free service, which is what most of their forum customers tend to use.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mad idea but it might just work
« Reply #20, on March 9th, 2012, 09:03 AM »
BTW... We still need to have write access for plenty of folders -- attachments, avatars, media gallery, and obviously the cache folder. Wouldn't this defeat your idea of security entirely...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mad idea but it might just work
« Reply #21, on March 9th, 2012, 09:28 AM »
Sure, the attachments, avatars,and the gallery folders are at risk from files being overwritten/corrupted, but they're theoretically safe against PHP being dumped in them and executed - because there's an .htaccess ruleset against PHP execution from those folders.[1]

The cache is a trickier one but the entire cache folder is marked as inaccessible to outside PHP calling, which means the risk then becomes against the cache files themselves being abused, but since they're regenerated regularly, that's not as much of a deal, especially if the core files are never made world-writable, because the cache files will be owned by the webserver user - while all other files should be owned by the user.

The problem is with uploaded PHP files. As it stands currently, they will not be owned by the user, which makes them a risk. Sure, we can prevent people people calling PHP files directly[2] but the fact remains that they won't be owned by the user whose account it is and will be vulnerable to attack from other users on shared hosts.

Even if they're then made 644, they're *still* vulnerable because they're owned by the webserver user and anyone else can still get to the files to modify them. My proposal should negate that risk entirely, especially since it should also provide no reason for people to make anything higher than 644/755 (bearing in mind that those permissions then apply to the account holder not the webserver user)
 1. I also note that IIS and nginx are not accounted for, however I figure anyone using those will probably ask for details of what they need to do and we can deal with that on a case by case basis.
 2. I don't know why I haven't thus far actually, I did put in a protection against people trying to download archives from there.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mad idea but it might just work
« Reply #22, on March 9th, 2012, 10:26 AM »
Quote from Arantor on March 9th, 2012, 09:28 AM
Sure, the attachments, avatars,and the gallery folders are at risk from files being overwritten/corrupted, but they're theoretically safe against PHP being dumped in them and executed - because there's an .htaccess ruleset against PHP execution from those folders.
Really...? Isn't it just about PHP files, not other files containing PHP or whatever?
Also, these folders have a redirection through an index.php file, which I can tell you they do execute... :^^;:
Hmm, lemme see... /cache/ doesn't redirect to the root, my bad. It just treats it as a 404 error (i.e. no redirection in the address bar but we do get the homepage.)
Quote
The cache is a trickier one but the entire cache folder is marked as inaccessible to outside PHP calling, which means the risk then becomes against the cache files themselves being abused, but since they're regenerated regularly, that's not as much of a deal,
They're only regenerated if a component has been modified -- which is very likely in beta, but unlikely after that. Also, I do have plans to add a setting to disable component modification detections -- because it takes time, not much mind you, but it still adds weight to the server that they may not want to bear on each page load when they don't need to...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mad idea but it might just work
« Reply #23, on March 9th, 2012, 11:00 AM »
Quote
Really...? Isn't it just about PHP files, not other files containing PHP or whatever?
The odds of attachments being modified is slim, but should not be ruled out. It's one of those things that is a necessary risk.
Quote
Also, these folders have a redirection through an index.php file, which I can tell you they do execute...
index.php will when it's called in a DirectoryIndex capacity (i.e. /cache/ or /cache/data/ only) but actual .php files otherwise should be neutered by this in /cache/.htaccess:
Code: [Select]
<Files *.php>
Order Deny,Allow
Deny from all
</Files>

But it's not protected on IIS or nginx.
Quote
It just treats it as a 404 error (i.e. no redirection in the address bar but we do get the homepage.)
That's because any requests made are caught by the 404 handler. That's still not a risk in itself though.
Quote
They're only regenerated if a component has been modified -- which is very likely in beta, but unlikely after that.
Hmm, that's a valid vector - but I was thinking more of the PHP side, wherein everything in /cache/data is rebuilt periodically.