Viewing PHP source -- security, preventing hacking

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.

Quote:

---

Originally Posted by djr33

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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).

Quote:

---

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

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.

Quote:

---

Originally Posted by Mike

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.

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

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.

Quote:

---

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).

Quote:

---

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?

Quote:

---

...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.

Quote:

---

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 :)

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?

Quote:

---

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.

Quote:

---

never can be too careful

---

Precisely.

Quote:

---

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.

Quote:

---

Originally Posted by Twey

Quote:

---

Originally Posted by Mike

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:
  
  
  Code:

  ---

  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

Quote:

---

Originally Posted by Mike

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

---

Ah, yes. In that case I'll agree.
Were the two grammatical errors in that sentence deliberate irony? :)

Quote:

---

Originally Posted by Twey

Were the two grammatical errors in that sentence deliberate irony? :)

---

LMAO. :D Thankfully I don't do it so often on Usenet. At least I have the opportunity to edit my posts, here.

Mike

Should hope so :)

Twey, those are some very good points.
For a bit more info about my situation, a main part of my site is a forum and the other forum administrators and I have the passwords for the ftp as well as other things... and would have the passwords for anything that I add.
I just played with stuff a bit more, and I'm really happy to have figured out an easy make to make things more secure. We have an admin control panel as part of the forum (this wasn't coded by me, obviously... it's IPB) and that is totally secure, as far as I can see. I'm putting all of my custom stuff in there right now and using the same verification stuff that it uses... basically checking for an 'admin session ID' and that is checked out by complex code that will either display or not display the pages I'm adding. (the individual pages won't function.... display an error, unless you have a verification code from the page they're included on)

The include thing makes sense now. Glad to know it :) Thanks.


Mike, though I really have no way to respond to the techincal aspects of what you just said, I will point out the major advantage of php:
C++/C/whatever is NOT net based. It has to be on your computer, probably as an .exe or whatever.
Java, while it can be net based (or local, as an .exe), requires plugins and other annoying things. It may have more options and be 'better', but its also a compatibility issue. In fact, one of my computers won't run java. I've tried to install it, but it just won't work. I figure if I can't view my own stuff, then I can't assume others will.
PHP on the other hand is completely server side-- it outputs html. If you have ANY browser, it's compatible with PHP.

In short, php works for what i'm doing. It's pretty easy to get used to, and I like it. Sure, its confusing at times, but isn't all programming?

Quote:

---

Originally Posted by djr33

C++/C/whatever is NOT net based.

---

It doesn't need to be...

Quote:

---

It has to be on your computer [...]

---

...and no, it doesn't.

I could write a C program (or any other language that can perform stream I/O) that conforms to the CGI/1.1 specification and point Apache to it. When a visitor requests the appropriate resource, the server will execute that program and return its output to that visitor. This is precisely what (CGI) PHP does, except you (the PHP developer) don't need to be particularly aware of it.

Though what I just described is perfectly feasible, especially as there is guaranteed to be a prewritten CGI framework somewhere for many languages (though one would use Servlets with Java, not CGI), it would be difficult to deploy in many situations. Most hosts don't permit their customers to make the configuration changes that would be necessary.

Quote:

---

If you have ANY browser, it's compatible with PHP.

---

You don't seem to understand how browsers and PHP interact. As I mentioned in a previous post, the server doesn't deal with PHP directly, and neither do browsers. The server envokes third-party code - either the PHP CGI executable, or ISAPI module - that executes the PHP script on its behalf. The PHP interpreter then returns the result of the script to the server, which in turn sends it to the browser. As far as the latter is concerned, it's a completely transparent process.

Mike

Quote:

---

it would be difficult to deploy in many situations.

---

which is precisely why php is better. You type php, it works. no need to reconfigure the server.

Quote:

---

Quote:

---

If you have ANY browser, it's compatible with PHP.

---

You don't seem to understand how browsers and PHP interact.

---

I do, which is precisely why I said

Quote:

---

If you have ANY browser, it's compatible with PHP.

---

I don't mean that they are actually compatible, but that they don't need to be.
With java, the browser needs to be compatible. With php, there is no issue... it sends the browser html.

Quote:

---

You type php, it works. no need to reconfigure the server.

---

Sorry, but that's complete and utter rubbish :) In most popular *n?x distributions, yes, all you have to do is use your package manager to pull down Apache and mod_php. However, the utter nightmare I had trying to work out how to get PHP working on someone's Windows machine here on the forums...

Quote:

---

I don't mean that they are actually compatible, but that they don't need to be.

---

Bad phrasing, I fear. But you're right, if that's what you meant.

Quote:

---

With java, the browser needs to be compatible. With php, there is no issue... it sends the browser html.

---

Any server-side CGI script will send the browser HTML. I don't think you quite understand the uses of Java: applets (which you seem to be thinking of) are only one usage. It can also be used to write stand-alone programs, that have nothing to do with the web browser. One of these can be executed on the server in the same manner as any other CGI program, which will return HTML, which can be sent to the browser. See Mike's:

Quote:

---

Originally Posted by Mike

(or any other language that can perform stream I/O)

---

Java is capable of performing stream operations; therefore, it can be used to write a CGI program. In fact, Java provides several different methods of doing this besides being used as a plain CGI program; the developer can also (in an appropriate environment) use servlets , a seperate API designed to replace CGI, and JSP, a PHP-like method of embedding class output in an HTML page.

It would be just as hard if not harder to install another language. My host (and MANY others) have php setup for us right from the beginning. Nothing to deal with there.

well... I don't know that much about other uses of java.

Anyway... there are obviously ways to do this. I'm just saying php is easier than those, if for nothing else than not having to set it up.... at least in my particular situation, with a host that already does it.
Whatever... use another language if you want.
Not trying to say its bad too... they MAY be better.
Just not as convenient.

to sorta get closer to the original question. Is there a way to protect php source files from being read from the php server?

For example lets say you have your index in the root directory and a plugins directory. You want to give particular people access to modify plugins but not to the index. Whats to stop them from reading the index file in and getting the source.

Is there any way to stop this? If there is no way to change the permissions or something on the file all i can think of is overriding all of the file opening commands to exclude the files you want to protect. However this is flawed and crap anyways.

Please advise :D
Any help appreciated :D

Ha. This thread is old. But now I can answer the questions. "...circle is now complete" :p


Anyway...

With a standard configuration, no. PHP has a certain level of access, and that's it.
You might be able to configure your server differently, though.
Are you running your own server or on a hosting site? Ask your host if possible.

Really, giving access to the PHP code at all on the site is a bad idea.

The only way it would make any sense would be to have them submit a form that would verify the contents of the new PHP then update it or, even better, have a human take a look ;)
Remember, though, that there are lots and lots of ways, once any direct access to the script is allowed, to get around any potential blocks.

It's possible to have the scripts owned by different users, with permissions set up so that the one can't read the other or write to a webserver directory with incorrect permissions. Something like:

Code:

---

drwx------    apache apache    www/
  drwx------    apache apache    main/
  drwxr-x--- otheruser apache modules/

---

You then just have to work out a way to stop Apache reading PHP files owned by apache in the modules directory... As djr33 said, even with this allowing untrusted users PHP access opens up too many potential holes to really be a feasible option.

rm_dir('../'); :p

Sorry, I assumed that would be default: modified listing.