Results 1 to 9 of 9
  1. #1
    Join Date
    Dec 2001
    Posts
    86

    * protecting php scripts impossible?!?!

    Well, seeing how anyone can simply pico /home/myname/script.php I decided to search for a solution .. I read about php wrapping so I asked my provider if they allowed it, this was the response:

    "Unfortunately because this is a shared hosting environment, enabling phpwrap could allow a hacker to potentionally access any file on our server if one of our customers were to write insecure code. Because we cannot trust that all of our users will use secure php scripts, wrappers are disabled by default (this is also the Cpanel default and we have to use what Cpanel uses). Changing the php configuration could also break other users scripts who are currently on the server.

    There is a way around this though. You can chmod 640 scriptname "


    Hmm ..that's what he says. However if I chmod the script 640, Its unusable through the web .. I get an error message ..

    Other than shelling out $2k for zend encoder, is there absolutely nothing we can do to protect our scripts from other users? I cant have just every user be able to pico my scripts and grab all the passwords and what not ... is there no solution to my problem? Why do I get the feeling that most people don't even know that any user can pico their scripts when I talk to them? PLEASE HELP!!!!


  2. #2
    Join Date
    Nov 2001
    Posts
    857
    You can use this....

    http://www.ioncube.com/encoder/index.php

    It cost you a few cents for each file that you encode. If you do use that there is also a library that the server owner will have to put on the server and add one line to php.ini telling it where that library / so file is..

    After that you are good to go...

    Regards,
    Michael
    <?
    header("Location: http://www.hostevolve.com/");
    ?>

  3. #3
    Join Date
    Jul 2001
    Location
    Troy, Missouri USA
    Posts
    1,299

  4. #4
    Join Date
    Apr 2002
    Location
    Philadelphia
    Posts
    2,277
    sitekeeper,

    I think he wanted other options

  5. #5

    I'm seriously thinking...

    of making a daemon that takes a username / password as an argument when it's run, and then detaches, leaving open a tcp/udp/whatever socket... which would act as a passthrough to a server which was trusted to store source code...

    so, in essence, to use your 'protected' helloworld.php you would connect to a socket, and request helloworld.php from the remote 'secure' server... the daemon would then eval it, and give back the appropriate output...

    in this way the code would never have to touch a public web server, just be transmitted once over the internet (once per time the daemon was run, of course) and then kept in memory...

    the drawbacks for this kind of a script are obvious, but its a very do-able concept....

  6. #6
    Join Date
    Jan 2002
    Location
    Kuwait
    Posts
    679
    Regarding any encoder software, encoders encode the script's syntax. It doesn't encode any literals (like password written as strings).

    Now, I've already provided a solution to this particular problem on the technical issues forum before. You can find it here:

    http://www.webhostingtalk.com/showth...t=PHP+password

    I'm very interested in discussing any other solutions to this problem.
    Ahmad Alhashemi
    PHP, Apache, C, Python, Perl, SQL
    18 related BrainBench certificates

  7. #7
    Join Date
    Jan 2002
    Location
    Kuwait
    Posts
    679

    Re: I'm seriously thinking...

    Originally posted by apokalyptik
    of making a daemon that takes a username / password as an argument when it's run, and then detaches, leaving open a tcp/udp/whatever socket... which would act as a passthrough to a server which was trusted to store source code...

    so, in essence, to use your 'protected' helloworld.php you would connect to a socket, and request helloworld.php from the remote 'secure' server... the daemon would then eval it, and give back the appropriate output...

    in this way the code would never have to touch a public web server, just be transmitted once over the internet (once per time the daemon was run, of course) and then kept in memory...

    the drawbacks for this kind of a script are obvious, but its a very do-able concept....
    OK, now your programs connects to the server, and the server give it the script. How can you be sure that the calling program is trusted to get the code?

    There are already more elegant solutions to this problems, like the solution I provided above, or the Apache2 solution.
    Ahmad Alhashemi
    PHP, Apache, C, Python, Perl, SQL
    18 related BrainBench certificates

  8. #8
    Join Date
    Dec 2001
    Posts
    86
    Thanks for those suggestions Ahmad, but I don't think either works in my case as I am just a user on a shared environment .. I cant make those mods, especially not apache2

    If I encoded my files using zend encoder would the passwords still be viewable ? Whats the point if they would ..

  9. #9
    Join Date
    Jan 2002
    Location
    Kuwait
    Posts
    679
    The point is that the code is protected. The purpose of the encoders is to protect your rights in the code, so, for example, you can prevent others from removing part of your code that checks for the existance of a valid license file.

    To make it more clear, assume that you have two files: config.php, which contains the passwords, and index.php which does include's config.php and use the password variable to connect to the databases server.

    What will prevent anybody from writing his own PHP file that will include your config.php file and print the password variable instead of using it to connect to a database?

    As for the suggested solutions, you can contact your host about placing your MySQL username and password in the httpd.conf, given that the file is not readable by all users on the system.
    Ahmad Alhashemi
    PHP, Apache, C, Python, Perl, SQL
    18 related BrainBench certificates

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •