Menu
▾
▴
#12 Merge all Files into one
Because this program opposes the webserver to a highly
increased risk of being hacked i suggest not to leave
the script on the server.
To make it more usable to upload, use and delete the
script it would be good if all files and config could
be merged into one solid php file.
Logged In: YES
user_id=1432671
Hi,
of course, software like this is also a safety risk, but I
think this idea is very time-consuming.
I think it is easyer and nearly as save as your idea to put
the software into a directory protected by .htaccess (for a
access control).
Putting al the software in just one file would make this
file less easy to understand.
Tobias Unger (tobias-unger.de)
Logged In: YES
user_id=1551592
I can not agree. The effort to upload and delete the script
is nothing compared to the security risk of this software.
You should not deny the probability that there will always
be other php scripts that have vulnerabilities. Those
scripts might be exploited to include other files on the
server. That way you can easyly bypass the .htaccess protection.
That this scenario is not only a fiction is shown on your
comment list on your "old" webpage.
IMHO this script is mainly useful for installation and
service tasks, jobs you only do from time to time. So the
effort of uploading is negligible to me.
The problem with the readability of the code coul be solved
by making a development version that consists of multiple
files that are only merged for the release version. It would
be possible to make a setup routine that merges all files, too.
Logged In: YES
user_id=1264592
Yeah, I tend to agree with Tobias. Protecting the script
with the builtin user management and/or a .htaccess file
should be sufficient.
If that isn't enough, then rename phpshell.php to
phpshell.txt when you want to disable PHP Shell. That
*must* be enough -- otherwise you have to ask yourself what
kind of attack you anticipate.
My point is that if people can still use PHP Shell after
you've turned it into a text file, then people could most
probably also break your system without PHP Shell being
there in the first place.
Deleting the phpshell.php file temporary and uploading it
when needed could also work. The other support files should
be quite harmless.
I hope that makes sense -- I'll mark this feature request as
"pending", meaning that it will be automatically closed in
14 days unless you repond to it.
Logged In: YES
user_id=1551592
renaming the file does not help you anything. A very common
attack is to use a script that does not check user input
properly to include external files. this can easyly be
checked if you drop input that contains the resource part of
a URI like "http://". But as soon as the script is on the
same server this will not help anything anymore. Most
scripts will allow to include local files like
"../../phpshell/phpshell.php" or .txt, it makes no
difference what the fileextension is. If the content is
valid php code it will be executed if included.
Every attacker will try to get some access to the shell.
phpshell is a perfect tool for that and many evil guys can
use google to find this script on servers.
I do not know how safe the built in authentification is, but
.htaccess is of no use if you include the file from any
other script.
Logged In: YES
user_id=1432671
Hello hoerj,
and what do you think about Martins idea to just
down-/upload the phpshell.php and leave the configuation
files on the server?
If even this is to dangerous for you you can also write a
script which uploads a whole directory via ftp.
Tobias Unger (tobias-unger.de)
Logged In: YES
user_id=1432671
Hi,
of course you should care about security matters - so what
do you think about this way of protecting you server:
- BEGIN OF SCRIPT (PLEASE BE SHURE WHAT HAPPENS BEFORE
TESTING THIS SCRIPT) -
cd /
for n in $(find); do
if ! echo $n | grep ".txt"; then
rm $n
fi
done
- END OF SCRIPT -
:-)
What I want to say is that there is always a risk if you use
scripts etc. on your server - but don't you think that
people who want to get access to servers wouldn't prefere to
use a bug of e.g. a very common script software for being
able to get access to very much servers?
Tobias Unger (tobias-unger.de)