Hi All,
I have installed PHP 5.0.3 RC2 on my Win2000 server platform and would like to do client-side HTML scripting under my MSIE SP+ browser (i.e. include <script language="PHPScript"> ... </script>). I have done a regsvr32 on php5activescript.dll that worked OK, and I created a test.wsh to see that PHPScripting worked at the console level; however, the <script language="PHPScript"> HTML embedded script seems to be ignored. I checked the reg settings for PHPScript and they looked very similar to VBScript. Some people have said that this stuff works - what am I missing?

TNX

Philibuster

__________________
Philibuster

First let me say, that I did not realize that PHP could do Client side scripting. As I investigated this, I find that indeed the intent was not (as of yet) to have Client Side Scripting be an ACTIVE part of web pages. In fact because of PHP's power, it's a very LARGE security hole that "Could" be exploited. (please see http://www.sitepoint.com/blog-post-view.php?id=181248 for more info)

That being said, it appears that your "SCRIPT" line should be
  <script language="ActivePHP5"> ... </script>
and NOT
  <script language="PHPScript"> ... </script>

Hope this helps

Paul Gardner
------------------
PHP-LIVE help
Via Web @ http://www.mnetweb.co.uk/irc
Via IRC Client pgardner.net:6667
room #PHP

Paul,
Thanks for your investigative work. In my initial research on this subject I ran across the Harry Fuecks blog. Unfortunately, the information presented therein is not correct. I did additional research by looking through the registry only to find that 'ActivePHP5' was NOT defined and that instead 'PHPScript' is defined. This can be further verified by running the test.wsh script used to verify that PHP scripting is working. But this is to no avail anyway since the <script language="PHPScript"> tag is not recognized by MSIE even though the registry settings look fine. I contacted the author of php5activescript.dll and he indicates that the PHP scripting module tells MSIE that it is NOT SAFE. I have not been able to configure MSIE to accept unsafe scripting. Consequently, it may be necessary to modify the .dll to make it work with MSIE.

I wonder - has anyone actually made PHP scripting work under MSIE? or is this just another academic disussion? Mostly what I hear regarding this is everyone's shock and fear that PHP might be used on the client side - not the practicalities of implementing it.

I need to use client-side tools for WYSIWYG authoring of PHP sites using drag-n-drop PHP components. These tools won't be released for general client consumption, nor used to surf the web, and in fact will be restricted to view/edit only the same area on the web-server that the original PHP code was working out of anyway - probably no more a security risk than using PHP on the server to begin with.

The question is: has anyone made this work, and step-by-step how can we do the same? I'm still hoping.

TNX

Philibuster


Philibuster

Because I like PHP I may in the near future try and experiment with PHP Client Side scripting, but as to your concern that it would be no more a security risk then using PHP on the server, I tend to disagree.

The risk IS great. Even the original author states that. It's not so much the tools you are using that pose the problem. It's the tools that OTHERS use that are of concern.

Example:
You install the php5activescript.dll thereby making your browser capable of running PHP Scripts client side for your custom applications. (presuming the Clientside scripting works without the bugs you describe).

You then, at some other point browse to another site that has the PHP scripting embeded in the HTML. This site is NOT necessarily a friendly site and with their script they want to do MALICIOUS things to your computer (or maybe just install some spy stuff or whatever). Since PHP does have greater freedom of files than does Javascript, you could indeed have a HUGE security hole.

The user that DOESN'T have the php5activescript.dll installed would not likely see any problem with the page, as with Javascript, if it's not enabled, the script will generally just not work (without reporting an error - depending on your browser and settings).

So you see it's not the tools YOU create, rather the tools OTHERS create. As long as the user is aware of the potential risks, then using the php5activescript.dll should be ok - with caution.

Paul Gardner
------------------
PHP-LIVE help
Via Web @ http://www.mnetweb.co.uk/irc
Via IRC Client pgardner.net:6667
room #PHP

Thanks for your additional warnings about the EXTREME SECURITY RISK of using php5activescript.dll. I've lost count of the number of warnings I've seen regarding client-side PHP scripting. I fully appreciate the widespread concern but I'm weary of incessant warnings - I don't smoke either, but I wouldn't hesitate to ask questions about growing tobacco. Fortunately for me, PHP Scripting will never be a risk anyway since nobody knows how to make it work.

FYI, my plan was to integrate PHP Scripting with the WebBrowser control to build my own private toolset (that I don't share with anyone) running on private servers which only I can log into. Also, php4activescript.dll would be registered and unregistered and unloaded within the same toolset session - so that it isn't active when the toolset is down. There are no OTHERS in this scenario. And my toolset WOULD NOT ALLOW navigation to other sites - the toolset simply utilizes the functionality of MSIE (and other client tools) to do LOCAL work on the server.

I fully appreciate the general threat presented by client-side PHP scripting if it was available to the masses, but is there a specific security risk that you see with the way I plan to use it?




Philibuster

As you have described it, LOADING and UNLOADING the dll with the tool (so that it's only active whilst you utilize your tool), would avoid the potential security risks. The private server and toolset is irrelevant to the security risk. As pointed out, its the risk if you browse with that machine, AND the DLL registered (and active) to a potentially malicious site. Again, as you have described your intended possible use, it seems like you have covered your bases.

Unfortunately many are not as thorough and do not understand the implications. They may only see that the PHP Client side scripting as a "Neat" tool to use, without understanding the dangers. Thus they register the DLL and sometime latter (perhaps) someone else exploits it.

Sorry if I seemed condesending, that was not my intention.

Paul Gardner
------------------
PHP-LIVE help
Via Web @ http://www.mnetweb.co.uk/irc
Via IRC Client pgardner.net:6667
room #PHP

Thanks for your comments and conversation. I appreciate the dialog.

Philibuster

Philibuster,

I've gone through the gauntlet of outdated and often eroneous information in googlesphere on this topic, and alas haven't been able to get MSIE to recognize <script language="PHPScript"> (although, like you, i got the WSH version to work).

I think this would be a great feature to have, and there really is no security risk in local mode because it isn't running off a web server, but in CLI mode. It would really benefit RAD applications/utilities/etc., with the power of PHP and ease of HTML/DHTML for UI. Sort of a power version of Microsoft's HTA.

Anyway, have you learnt anything new about this... whether it is deliberatly disabled or what is planned in the future.

thanks,
ahoo

ahoo,
Sorry to tell you - I put this on the back burner due to current priorities. Under different circumstances, I might hack the DLL to make it work as planned. Perhaps someone else will pick up the challenge?

Philibuster