8

In order to get PHP to run I had to enable Includes on Apache webserver. No one can actually see my .php files because when they're fetched by the server they're rendered and the client sees just css/html/whatever. It might just highlight my newness with PHP.

Is it possible for someone to break the PHP-rendering part of my server such that clients would be able to see my .php code when they request a page?

And if this can happen, what are some preventative measures I can take to ensure my commercial code stays closed-source?

Again, this might not even be a real concern, but I'd love to know.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
sova
  • 5,468
  • 10
  • 40
  • 48
  • If your webserver is properly configure no, there is not a single chance of that happening. – Prix Apr 11 '11 at 02:46
  • Also see http://stackoverflow.com/questions/3939020/how-to-protect-php-file-with-htaccess-from-downloading-with-php5-crashed/3939074#3939074 – deceze Apr 11 '11 at 02:49
  • 1
    Have you attempted to work with Apache's if/else `IfModule` yet? IE ` ... render the page` else give error doc instead? – bob-the-destroyer Apr 11 '11 at 03:01

6 Answers6

7

As others have said, a misconfigured web server that treats .php files as plain text will happily serve up your source code.

Most frameworks (both public or in-house) these days, however, keep very little php code in a web-accessible area. Typically, there's a single index.php file in the document root, which includes and calls code in other files that are wholly outside the document root.

Usually, you'll have something like this:

/path/to/proj/            <-- your project root
/path/to/proj/application <-- holds most of your appication code
/path/to/proj/lib         <-- third-party libraries go here
/path/to/proj/public      <-- your web server uses this as the document root.
/path/to/proj/public/index.php   <-- single point of entry into your applicaiton.  all requests are routed through here.
/path/to/proj/public/images      <-- static resources, like images, also live under the docroot.

Rewrite rules are typically used to marshall any requests through the one public index.php file.

With a setup like this, if your webserver were to become misconfigured in a way that would cause it to transmit your code, you'd be pretty much covered. The only leak would be your index.php file, which is probably a couple of include/require statements, and single function/method call. Nothing sensitive at all.

Look at the standard Zend Framework or Symfony (or any framework, really), file layout, for a clearer picture.

timdev
  • 61,857
  • 6
  • 82
  • 92
6

There are two ways for this to happen:

  1. A misconfigured web server that doesn't execute PHP files. This has nothing to do with the user triggering an error.
  2. Running customized debugging features that display errors with code on screen. For example, if you use a third party framework, it may automatically do that. The user could possibly trigger something like this.

To help prevent any of these situations from causing problems:

  • Do not embed any sensitive information (e.g., passwords) into your source files. Instead, include them from files that live outside the web root. So if your source becomes visible, nobody will be able to access that private data.

  • Do not display errors on screen in production. A database password could show up in the exception thrown.

  • Be sure to disable any development/debug settings on production.

Matthew
  • 47,584
  • 11
  • 86
  • 98
4

is it possible for someone to break the PHP-rendering part of my server such that clients would be able to see my .php code when they request a page?

This can only happen when the web server software has been misconfigured to not process .php files as PHP. There is no user-triggerable way for this to happen.

The few times that this has happened in the past on high-profile sites have been configuration errors and typos, like failing to properly open the <?php tag, thus exposing the rest of the code in that one file.

Charles
  • 50,943
  • 13
  • 104
  • 142
1

No. PHP code on a correctly-configured will not output itself, unless you tell it to. (Misconfigured servers that don't know that they should be executing .php files will probably just output them as plain text. In this case, you would be in trouble.)

You'd only need to watch for this in rare situations — for example, when you are fetching of the contents of a file and outputting it to the user, you could add a check that the file being fetched is not your PHP code.

But in 99 of the 100 cases, you don't need to worry about this.

Jon Gauthier
  • 25,202
  • 6
  • 63
  • 69
1

This isn't really a normal concern but writing/using insecure PHP (and other software for that matter) could leave holes. For PHP it's important to use defensive programming like escape SQL queries that include any user provided input. Strip special characters (htmlentities() helps but isn't always enough) and be security minded in what you allow people to enter that effects your code and databases directly.

Jake
  • 2,471
  • 15
  • 24
1

I'd say it really depends on the security of the server itself, if it became vulnerable to attacks there's a chance your codes may be compromised as well.

As for PHP being exposed it's also on the server settings, in the past I've seen people asking why they are seeing their PHP code displayed on the web page which is caused by using the short-hand tag <? which is by default not usually enabled to servers causing PHP to be displayed.

tradyblix
  • 7,439
  • 3
  • 25
  • 29