Viewing PHP source -- security, preventing hacking

[djr33]

I'm working at getting into php and done some fun stuff already. I love how easy to use the language is and how many possibilities there are... any text based language that can create images, send emails and handle forms is pretty cool.

if you're curious, I'm working on my forum/filmmaking website, thebrb.com.

Anyway,
as I've been working on this, I've been trying to hack my own stuff for security risks, and I think I found a way that might work (to hack).

Since php can usually include secret info, like passwords or database connection info, it seems that the source code is crucial to not be accessible.

As I'm sure you know, the server interprets the php code and sends pure html back to the browser on viewing a page, so the source is secure. The same goes with right-click-save-as on a link to a php file.

But what about using php to hack into php source.

You could use php to grab the file, using maybe file() or filegetcontents(), then movefile() (that's not the right command, I can't remember right now) to save it to your own server, and there you go.
That would give you direct access to the source.

I haven't tried it yet, but plan to try to hack some of my own stuff tomorrow using that to see if it works.

Do you guys know:
1. if there are more security measures setup to prevent this.
2. of any other ways to hack/get the source code, and how to prevent this.

I mean... you can save a quicktime movie to your harddrive. .php is just a file as well... there must be some way to get around the protection and view the code...

Thanks.

[mwinter]

I love how easy to use the language is and how many possibilities there are... any text based language that can create images, send emails and handle forms is pretty cool.

As a language, I think it's pretty poor, but yes it certainly is useful.

Since php can usually include secret info, like passwords or database connection info, it seems that the source code is crucial to not be accessible.

Yes, that certainly can be true.

As I'm sure you know, the server interprets the php code and sends pure html back to the browser on viewing a page, so the source is secure.

Indeed.

But what about using php to hack into php source.

You could use php to grab the file, using maybe file() or filegetcontents(), then movefile() (that's not the right command, I can't remember right now) to save it to your own server, and there you go.

You seem to be implying that you'd want to use PHP on one server to access the source of some file on another. That isn't possible. There would still be a HTTP request, so the remote server would process the PHP code as normal, returning a HTML document (or whatever it's supposed to do).

It certainly is possible to write badly designed code that would allow one of your own PHP scripts to hack yourself. However, general security considerations should avoid this problem; namely, to never trust user input (even things that seem fixed like the value of a select element).

I mean... you can save a quicktime movie to your harddrive. .php is just a file as well... there must be some way to get around the protection and view the code...

No, there isn't. A QuickTime movie isn't considered special by the server. It just sees it as some data to be sent to the client. The same goes for other media types, like text files (including HTML), images, and compressed files.

Server-side languages, like PHP, are different. The server doesn't usually deal with the content of these files directly. Instead, it uses handlers (either modules running within the server or separate processes) to open, process, and return the results of the code. The server doesn't even get a chance to look at the content of the file.

Mike

[Twey]

Regarding those general security considerations: validate all user input, and never let it be executed without extensive checking. shell_exec() calls, or saving to anything that could later be executed (like a native executable or a PHP or Perl script) should be avoided like the plague, except where absolutely necessary. Usually, it isn't.

As a language, I think it's pretty poor

As with any language, that depends on the uses to which it's put, and how it's put to those uses A well-written PHP script can still be superior to a poorly-written C program.

[djr33]

Interesting.
This seems to make sense but also seems like you could somehow get to the file before it is interpreted.
If you're right, which you probably are, then that's a lot simpler for security reasons.

For anything that would have user input of any level of security risk, I'd be sure to include passwords of some sort to validate who is on the page.

Thanks, guys.

[Twey]

This seems to make sense but also seems like you could somehow get to the file before it is interpreted.

You could, but not without access to the server filesystem via some means other than the webserver.

For anything that would have user input of any level of security risk, I'd be sure to include passwords of some sort to validate who is on the page.

You miss the point. You should validate the input anyway, whether you think you trust the person or not. Besides, what'd you do for public services?

[djr33]

You could, but not without access to the server filesystem via some means other than the webserver.

...and php doesn't have any other means to access other php pages, nor does asp, html, or anything of the like. (?) Ok, good to know.

whether you think you trust the person or not.

A majority of this would be more myself. And if not, it would be for people that I do trust and would probably have the passwords to everything anyway (I'm working with a few people on the website, kinda a group effort).

Besides, what'd you do for public services?

As above, most of this would be for editing the pages, adding new pages, etc.
You'd need passwords to deal with that stuff.
Aside from that though, I will have to look into validating and such for public things...

Any tips there?

[Twey]

...and php doesn't have any other means to access other php pages, nor does asp, html, or anything of the like. (?) Ok, good to know.

Server-side languages such as PHP and ASP do, but a well-written script will never allow the user access to these commands, and will severely limit what can be done with them when they do need to be used by validating input.

A majority of this would be more myself. And if not, it would be for people that I do trust and would probably have the passwords to everything anyway (I'm working with a few people on the website, kinda a group effort).

And when someone cracked this password? The best approach to security is the "layered" approach: you don't rely entirely on one level of security. For example, should someone crack the small webserver I run on this home PC for personal stuff, they would find themselves in what's known as a "chroot jail:" a small environment in which they can't really do much. If they were to then manage to break out of that, they'd still lack the permissions to access any important files. If they somehow managed to elevate themselves to a position that allowed them access to said important files, my security needs some serious work However, they'd also still be unable to touch my sensitive files (passwords, credit card details, bank numbers, and the like) which are stored on an encrypted partition. That's four layers of security. If you take the approach "hah, no-one's ever going to break my first layer, so I won't bother making the rest secure" then, I fear, you're doomed to be cracked

[djr33]

As for having multiple levels of security, I find it kinda funny that you're suggesting I have like 5 levels of security because 'they might guess the password', when that very password (or another, no matter) would get them into the ftp. Heh
I will look into it though... never can be too careful


So... one more thought on this.

the include() and require() functions get pages and put them into the html of the outputted php page. So... from what I've seen, you can use a php page within the include and get it to function with it.... meaning you can use variables, functions, etc. from page to page.

So... doesn't that mean that its someting more than just using outputted html?

[Twey]

I find it kinda funny that you're suggesting I have like 5 levels of security because 'they might guess the password', when that very password (or another, no matter) would get them into the ftp.

Which should also have many levels of security , and would also (theoretically) be more secure since you wouldn't share the FTP password with so many people. Besides, it's not necessarily a case of guessing the password; there are often ways around the password script that the webmaster has overlooked.

never can be too careful

Precisely.

the include() and require() functions get pages and put them into the html of the outputted php page. So... from what I've seen, you can use a php page within the include and get it to function with it.... meaning you can use variables, functions, etc. from page to page.

Only with local files. If you include("/var/www/mysite.com/htdocs/includeone.php"), it will read in the PHP code and include into the calling page as PHP. However, if you include("http://www.mysite.com/includeone.php"), PHP will obtain the page contents via the webserver, which only releases the HTML, and only HTML will be included.

[mwinter]

As a language, I think it's pretty poor

As with any language, that depends on the uses to which it's put, and how it's put to those uses A well-written PHP script can still be superior to a poorly-written C program.

You seem to misunderstand. I'm was referring to the language itself; it's syntax, grammar, built-in features (not extensions), etc.

Though it's very C-like, and now increasingly Java-like (with the PHP 5 class syntax), it's vastly inferior as a language to both. A few examples:

• Apparent lack of forward-thinking in design. For example, character access within strings used to be performed using square brackets. These were deprecated in PHP 4, and braces were introduced in their place. In PHP 5.1, this new style has (apparently) been deprecated (and will be removed in PHP 6), and the old style will be reintroduced. I don't have PHP 5.1 to check, though, but it was discussed and agreed by the PHP developers.
• The foray into OO with PHP 4 was poor: it didn't enforce encapsulation through access controls (everything was public), and static members was a mess. PHP 5 improved this, but it still lacks rudimentary features from other languages like nested classes.
• The constructor syntax was also poorly thought out, producing the two different forms we now have.
• Scope is a joke, resulting in thousands of pre-defined constants, classes, and functions that are all global.
• Nested functions are impossible.
• The naming scheme for built-in functions is muddled. For example, most array functions are prefixed with 'array_', but not all are.
• Function- and class-names can appear in different forms: htmlentities, array_walk, DirectoryIterator.
• There are unnecessary aliases for several functions.
• The Zend engine has some irritating parsing limitations, such that it can be necessary to create temporary variables just to work around them. For example:
  
  

  class A {
    public function __construct() {}
  
    public function method() {}
  }
  
  class B {
    public static function newInstance() {
      return new B();
    }
  
    public function method() {}
  
    private function __construct() {}
  }
  
  (new A())->method();  /* Parse error
                         *
                         * Must be:
                         *   $a = new A();
                         *   $a->method();
                         */
  
  B::newInstance()->method();  /* OK, oddly enough */

I'd much rather use a more refined language (like C++ or Java), but PHP is (and will probably remain) the most popular.

Mike