37

I have a php website where everything is in the public_html\ folder, including an includes folder with config and classes. I told my developer to move it away from public folder but he said there is no risk as files are php files and even if someone types in browser the

www.example.com/includex/config.php

all they will get is a blank page.

Is that correct? Is there no way someone can download a php file and see whats inside, even if hacker logs into my server somehow to download the file or include it in a php file on his server using XSS?

blong
  • 359
  • 1
  • 3
  • 9
Petja Zaichikov
  • 471
  • 1
  • 4
  • 3
  • 1
    Its correct provided the php settings are correct which is easy enough to verify. There are tons of resources which explain what settings features should be enabled and disabled when using PHP and the values certain settings should be ( i.e. timeout, file uploads, ect ) – Ramhound May 07 '13 at 22:40
  • 2
    XSS is client side, there is no way in which this could ever be used to read source code on the server. ever. If you think this is possible you need to lean more about XSS, this is a very serious venerability and not understanding the basics of this venerability is **extremely dangerous**. – rook May 07 '13 at 23:19
  • 1
    It's relatively easy to make a configuration mistake that will temporarily disable PHP execution, so why take the risk ? For any decent app the only thing that needs to reside in the public folder is an `index.php` that bootstraps the app/framework and assets such as images or stylesheets. Everything else should be one directory above that is not accessible from the outside. –  May 08 '15 at 20:59

6 Answers6

22

In order to read PHP code you need a directory traversal vulnerability. file_get_contents() or other file system functions that are exploitable.

SQL Injection under mysql can be used to read source code. For example:

select load_file("/var/www/index.php")

To combat this make sure file_privs are disabled for the MySQL user account used by PHP. If display_errors = on in your php configuration then an attacker can obtain the path to your web root, and use sql injection or directory traversal to read source code.

Using FTP means that source code is transmitted in plain text. Use SFTP, and make sure you have a strong password -- or better yet, set up an RSA key.

Be careful of backup files, sometimes editors will create index.php~ or index.php.orig files which can discovered using forced browsing.

Community
  • 1
rook
  • 46,916
  • 10
  • 92
  • 181
13

In addition to server-side vulnerabilities of all varieties, leaked FTP passwords are also a significant concern. There is a class of client-side infections that harvest your saved FTP passwords from programs like CuteFTP, FileZilla, and DreamWeaver, sending the login credentials to an attacker. This is very common. I've personally seen hundreds, maybe thousands of cases where this has happened. And typically, the person who unknowingly leaked the passwords is someone who no longer needs to have them anyway.

And if you're wondering whether an attacker will actually dig through your configuration files looking for passwords, the answer is unambiguously "yes". Typically it's one of the very first things an attacker will do, within minutes of compromising a new machine.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 2
    FTP means that source code is transmitted in plain text... why does FTP still exist? – rook May 08 '13 at 02:19
  • 2
    @Rook Gopher still *exists*. FTP will always exist. The question is why people still use it. And the answer probably has to do with the fact that SFTP requires a shell account (or rssh, etc) an isn't supported on Windows. – tylerl May 08 '13 at 02:30
  • Searching through config files for hardcoded passwords is seriously the easiest way to priv-esc and pwn networks... – NULLZ May 08 '13 at 03:08
  • @tylerl For files you intend to distribute publicly there's no major drawback. Also, the encryption required for SFTP can become a bottleneck if you have a fast enough network connection and a slow/busy enough CPU. – user3490 May 08 '13 at 12:44
  • 1
    @user3490 The encryption overhead is approximately zero on modern hardware. In fact, SFTP is dramatically faster than ancient FTP on most workloads because there is no additional per-file connection overhead. – tylerl May 08 '13 at 18:20
4

There are two possible ways that an attacker would be able to read this file as text, rather than execute it.

  1. If your web server is misconfigured, then the php might not be executed. You obviously need to have php installed and running server-side, as well as have a web server in place that supports this. If, for some reason, something goes wrong with your php installation, then it is theoretically possible to download the php file "raw." This, however, is unlikely.

  2. If there is an LFI (local file inclusion) vulnerability in this script (or any other dynamic pages on the site), it is possible to display a file that is located on the web server. See the Wikipedia page on file inclusion vulnerabilities to see what this would look like.

As an aside, it's worth noting that in order to use PHP files at all, they need to be reachable by a browser. There's no way to "hide" the page, unless you have another script executing it elsewhere.

dshaw
  • 845
  • 5
  • 11
  • 1
    An LFI can **never** be used to read PHP code because an LFI would execute that PHP code. – rook May 07 '13 at 23:20
  • 1
    @Rook The LFI vulnerability would typically be in another file (or piece of PHP code). – Jeff Ferland May 07 '13 at 23:27
  • @Jeff Ferland an LFI could be used to read /etc/passwd or some text file or xml config file, but if you use an LFI to include a PHP file that file will be executed, not displayed. There for an LFI could never be used to download PHP source code. – rook May 07 '13 at 23:29
  • I guess, that instead of LFI you mean AFD (Arbitrary File Download). – p____h May 08 '13 at 01:28
  • 1
    @Rook - LFI is entirely possible. Imagine e.g a script that serves images as a file stream (say to add cache headers on the fly e.t.c.), but doesn't do any form of input parameter or actual content check, it just assumes it's some image type and adds relevant MIME type to response headers, if at all (such scripts are often used to make images downloadable, for example, so the MIME type would be static). – TildalWave May 08 '13 at 02:12
  • @TildalWave that is true for any remote code execution exploit, and this was not mentioned. – rook May 08 '13 at 02:14
  • @Rook - LFI of the nature `include($_GET['var'])` would execute the code. However, you can also have something along the lines of `echo file_get_contents($_GET['var'])`, which would echo back arbitrary files. – dshaw May 10 '13 at 00:09
  • @dshaw I think this was covered more clearly in my post. In general directory traversal in all functions except include/require lead to source code disclosure. – rook May 10 '13 at 01:01
3

Leaked FTP passwords are all very common and are one of the most common ways that source files are removed, malware installed on the developers websites is very common and recently develops gave began witnessing spear phishing attacks against them in an attempt for hackers to gain intellectual property.

One of the not so common ways and from what I'm aware of is only known by a certain amount of people, but if you develop your website on the Linux webserver where the website is being hosted onthen you may have a problem as some editing software will store backups of edited files hidden from the developers view e.g.

Login.php~

This file because it is not run by the webserver can be accessed by entering

This would reveal the source of of the backup login.php file to prevent against this you would either have to develop your code of site and upload it to the server or make sure that there are no backup files stored in a directory that the public have access to.

Source: 2600 magazine

What happens if an attacker was able to access

databaseConnection.php~

Then your really up s*** creek

Bratislava Bob
  • 31
  • 1
0

As others answered, this shouldn't be possible. However, you can't say that there's absolutely no way for an attacker to read your PHP source code.

For example, there may be a vulnerability that allows an attacker to view files in the web server, including raw PHP code. Or an attacker may be able to discover your FTP password, which also could be done in many ways, including man-in-the-middle attacks and social engineering. There are many possibilities. Below, I've listed some vulnerabilities that could allow it, but bottom line is, just having PHP files in the public_html folder absolutely shouldn't be a risk for itself.

A download.php file which takes a GET/POST parameter with the name of the file to download, and doesn't filter user input correctly, could make it possible to download the raw code of a file on the site, through accessing an address like this: http://www.example.com/files/download.php?file=../index.php. See this.

Another example: if there's a vulnerability that allows an attacker to execute code on your server, such as Local/Remote File Inclusion, File Upload Vulnerabilities, and others, it might also be possible for him to run code that allows him to read your PHP source code.

mds
  • 119
  • 4
0

As long as things are setup correctly on the server, PHP files should be registered as scripts and the web server should have them interpreted by PHP when requested and only display the results of that interpretation.

That said, any number of issues can result in files being exposed. Some of these issues can also expose data regardless of if they are in a public folder or not. It is always important to make sure your server is properly configured to only allow the requests you need allowed. This reduces the surface area available to attack and helps avoid possible bug related issues that could result in a breach.

Is it a good idea to have a config file in a public folder? As long as the server is configured not to give out the file without processing it, it probably isn't much less secure than any other spot on the system. There is the small chance of a bug in the web server being used to prevent execution by the scripting engine, but the more likely attacks are attacks that would come from some other direction like SQL, FTP or some code injection where being in a private folder would be equally exposed.

That said, the flip side of the question is why not put it somewhere else. The most secure option would be to put it someplace that only the user that the web site's PHP instance runs as can access and deny access to the file from any other mechanism (such as the FTP user or any other publicly used users.) This is rather difficult to configure and manage however, so a decision has to be made if the additional security is necessary or not.

It's a toss up on which is best. It's a lot of extra work to manage all the paths, permissions and users to maintain that level of security. On the flip side, as long as the server is kept patched and properly configured, you should only be vulnerable to zero day exploits that attack at a very low level and can be safe against pretty much all common attacks, even with the config file in the public folder.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110