You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 12, 2020. It is now read-only.
The starting point index.php and all other files, that are directly called from the web (download.php, getvideo.php and even the css/ folder) shouldn't be directly in the web root folder for security reasons. I would recommend to move them into a public folder, so a web server can be point to this folder and other files/folders like config, src or .git wouldn't be accessible from the web anymore.
I understand that not every server let the user map a domain to a specific folder or that not every user has this technical understanding to configure the web server. It would also break Backward Compatibility for running installations. So my suggestion would be to leave a index.php in the web root that simply redirects the user from example.org/index.php to example.org/public/index.php.
That would keep the running installations and has the same mentioned security issue as example.org/config would still be accessible. But it allows every user to map the domain to the public folder and profit from this security feature.
What do you think about this idea? Are there more things we need to keep in mind?
The text was updated successfully, but these errors were encountered:
I'm open to it, but a bit concerned that we're sacrificing ease-of-use (for the average user who just knows how to upload a folder to his/her web server and not how to point a webroot) for security we might be able to obtain other ways (or don't need).
Hitting config.php directly (example.com/config.php) doesn't actually show anything, does it? Feels like the issue is really that download.php could be manipulated into downloading files you don't want downloaded?
I'm not horribly opposed to the workaround you mention, but is it really a problem we need to solve?
(Open to being told I'm missing key concerns here)
You are right, this isn't a high critical issue. The worst case scenario would be (as you said) that the download.php could download sensitive data. Another point could be the cache folder that could contain data like download history. Or the log files.
This issue also theoretically keeps us from creating a cli tool, but I know that this is out of scope of this project. A cli tool could be created in a separate project, using the library via composer.
On the other way there are many folders that contains only data for the web UI. What do you think about this: We create a public folder an move all files for the web UI (css, js, fonts, ...) into this folder. The index.php and other files will be still in the root folder. But we will also create a index.php in the public file so the user can configure the domain to the public file if he wants. I think this should be possible without much effort and the user can choose the way he wants to use the UI.
For reference: thanks to the controller the index.php and other files have only 3 lines of code. The copy in public/index.php will look like this:
The starting point
index.php
and all other files, that are directly called from the web (download.php
,getvideo.php
and even thecss/
folder) shouldn't be directly in the web root folder for security reasons. I would recommend to move them into apublic
folder, so a web server can be point to this folder and other files/folders likeconfig
,src
or.git
wouldn't be accessible from the web anymore.I understand that not every server let the user map a domain to a specific folder or that not every user has this technical understanding to configure the web server. It would also break Backward Compatibility for running installations. So my suggestion would be to leave a
index.php
in the web root that simply redirects the user fromexample.org/index.php
toexample.org/public/index.php
.That would keep the running installations and has the same mentioned security issue as
example.org/config
would still be accessible. But it allows every user to map the domain to thepublic
folder and profit from this security feature.What do you think about this idea? Are there more things we need to keep in mind?
The text was updated successfully, but these errors were encountered: