Hold on, PHP doesn't have a single functioning Zip manipulation library that is current and can be used for browsing?
 | The way it's meant to be |
Dragooon
- I can code! Really!
-
-
- polygon.com has to be one of the best sites I've seen recently.
- Posts: 1,841
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Not browsing how I want it, no.
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
Dragooon
- I can code! Really!
-
-
- polygon.com has to be one of the best sites I've seen recently.
- Posts: 1,841
So you don't got a solution ATM or you're writing your own? I still am not completely sure why you're avoiding a tmp folder extraction, I understand it's most probably security reasons and that files can be left behind and be accessed directly from HTTP posing a security risk.
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Oh, I got a solution. I found a zip extraction library, but that it needs some clean up. Like using a proper __construct method, stripping dozens and dozens and dozens of lines of stupid and useless comments (like // ------ Return, just before a return statement) and general cleanliness stuff.
That and the fact that I've already stripped 55KB off the original 199KB by cleaning the code up.
OK, here's the underlying logic.
* The core Wedge files and folders should never be writable by the webserver under normal circumstances. The single greatest reason for things being hacked is files being writable when they shouldn't be, on a shared server. Thus, the files not being owned or typically writable prevents that from being the case.
* We don't have a temp folder anywhere in the Wedge installation for this reason, and I'm loathe to make one for the above - doubly so when it's directly accessible via user-side HTTP. Given how much hassle SMF has with its temp folder being added/removed, I want to avoid it entirely.
* This means any temp file is going to be in the system temp folder - where the upload is going to go anyway. But the system temp folder is writable by any user. As a result, anything that goes through there is potentially open to contamination. Once stuff is extracted, it's pushed via S/FTP to the plugins folder where it is essentially live. As such it absolutely has to be as safe as it can be - and everything I can do to prevent contamination on the shared server, the better.
* The other problem with system temp folders is that you can't guarantee the lifetime of any file. Limiting it to just the uploaded zip file is one step to protecting that.
I don't think I'm being particularly paranoid, or suffering from NIH[1], but this is the weakest part of the system and short of just dropping it and forcing everyone to upload manually (which as I stated does also prevent things like updates being handled well), it's a no-go.
Note that even without the zip component, I'd still need to do a lot of the same for things like handling smileys, the same deal with uploading via S/FTP is going to be the case.
That and the fact that I've already stripped 55KB off the original 199KB by cleaning the code up.
OK, here's the underlying logic.
* The core Wedge files and folders should never be writable by the webserver under normal circumstances. The single greatest reason for things being hacked is files being writable when they shouldn't be, on a shared server. Thus, the files not being owned or typically writable prevents that from being the case.
* We don't have a temp folder anywhere in the Wedge installation for this reason, and I'm loathe to make one for the above - doubly so when it's directly accessible via user-side HTTP. Given how much hassle SMF has with its temp folder being added/removed, I want to avoid it entirely.
* This means any temp file is going to be in the system temp folder - where the upload is going to go anyway. But the system temp folder is writable by any user. As a result, anything that goes through there is potentially open to contamination. Once stuff is extracted, it's pushed via S/FTP to the plugins folder where it is essentially live. As such it absolutely has to be as safe as it can be - and everything I can do to prevent contamination on the shared server, the better.
* The other problem with system temp folders is that you can't guarantee the lifetime of any file. Limiting it to just the uploaded zip file is one step to protecting that.
I don't think I'm being particularly paranoid, or suffering from NIH[1], but this is the weakest part of the system and short of just dropping it and forcing everyone to upload manually (which as I stated does also prevent things like updates being handled well), it's a no-go.
Note that even without the zip component, I'd still need to do a lot of the same for things like handling smileys, the same deal with uploading via S/FTP is going to be the case.
| 1. | Not Invented Here syndrome |
Dragooon
- I can code! Really!
-
-
- polygon.com has to be one of the best sites I've seen recently.
- Posts: 1,841
Doesn't this problem by definition extend to attachments and AeMe uploads as well?
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Yes, of course it does.
But for attachments and AeMe uploads, at least there is a layer of insulation. It's not executing that code directly, or at least it shouldn't be. (And there are .htaccess rules to prevent files being requested directly and to prevent PHP execution)
It's one of the long-standing issues in PHP and web server design. In the truly separated spaces, single site on a VPS for example, this wouldn't be a risk because you wouldn't have other users to contend with (only flaws in your running applications stack, but that's a given) - we're dealing with the state of play on a shared server, where by definition there are tons of other users on a server, all of whom have the ability to access those files by definition - they have to be writable by a user who isn't the file owner.
The difference, ultimately, is that attachments are other uploads are a calculated and considered acceptable risk. They shouldn't be called directly, nor executed, so the risk that they get malware or similar is actually small - there's not a significant payoff in compromising those files.
But if you can compromise live PHP on a site, it's going to try to compromise anything else on the server - there's a payoff in doing it.
But for attachments and AeMe uploads, at least there is a layer of insulation. It's not executing that code directly, or at least it shouldn't be. (And there are .htaccess rules to prevent files being requested directly and to prevent PHP execution)
It's one of the long-standing issues in PHP and web server design. In the truly separated spaces, single site on a VPS for example, this wouldn't be a risk because you wouldn't have other users to contend with (only flaws in your running applications stack, but that's a given) - we're dealing with the state of play on a shared server, where by definition there are tons of other users on a server, all of whom have the ability to access those files by definition - they have to be writable by a user who isn't the file owner.
The difference, ultimately, is that attachments are other uploads are a calculated and considered acceptable risk. They shouldn't be called directly, nor executed, so the risk that they get malware or similar is actually small - there's not a significant payoff in compromising those files.
But if you can compromise live PHP on a site, it's going to try to compromise anything else on the server - there's a payoff in doing it.
OK, so progress has been surprisingly slow on this given the dozens of KB of code that's had to be written thus far. But progress is happening. So far we've got through uploading, through validation of the plugin being a valid, unpackable zip and dealing with duplicates.
Now we're up to getting FTP details, and most of the handling for that is done, even down to attempting to find the right FTP path with a less than pretty method (but, hopefully, reasonably reliable)
All WIP of course but I thought you might like some screenshots.
Now we're up to getting FTP details, and most of the handling for that is done, even down to attempting to find the right FTP path with a less than pretty method (but, hopefully, reasonably reliable)
All WIP of course but I thought you might like some screenshots.
📎 upload_plugin_1.png - 32.76 kB, 939x622, viewed 125 times.
📎 upload_plugin_2.png - 14.18 kB, 942x290, viewed 125 times.
📎 upload_plugin_3.png - 31.68 kB, 917x614, viewed 134 times.
MultiformeIngegno
-
-
- Posts: 1,337
Just great!! :))
Powerbob
-
-
- Posts: 151
Looks good, like it :lol:
My Alpha test site; http://www.pplb.net/wedge/index.php
agent47
-
- Now I see the changes you're talking about.
- Posts: 115