views:

76

answers:

2

What are the issues with using a php file instead of a .js file in a javascript include;

<script type='text/javascript' src='myjavascript.php'></script>

Obviously I will go through and plug register globals issues and such, but are there other vulnerabilities that could occur from this? Consider that 100,000+ people will be viewing the page with this script on.

+5  A: 

No, the server will parse it just the same as any other PHP file.

The file will be retrieved by HTTP request exactly the same as any other web page. If you include it with <script> it'll be retrieved via a GET request, but that doesn't prevent a curious user POSTing to it. You need to use the same precautions you would in any other PHP script - no more, no less.

As far as the browser is concerned, it's just javascript - it has no idea it's being generated by PHP, so there are no extras to take into consideration there.

As long as you're not leaving a way to inject javascript into the file you'll be fine. Just be sure to not trust inputs and escape outputs.

Greg
I've already done that in a project, it's handy to customize the JS depending on the user.
Clement Herreman
the server? the browser
Natrium
I understand that it gets parsed (I am currently using this), but I'm just wondering whether or not there would be anything else I need to plug other than basic register globals / injection?
Joel
+1  A: 

are there other vulnerabilities that could occur from this?

In the PHP itself, outputting values to JavaScript requires a different encoding scheme than outputting to HTML. If you don't get it right, you face the same sort of cross-site-scripting issues as if you failed to use htmlspecialchars() in your HTML-generating PHP:

var name= '<?= $name ?>';

<?php
    echo "var name='$name';"
?>

Both of these will give you problems if your names contain apostrophes or backslashes. This is one of the few places where addslashes() can actually be the right thing for once!

Also you should be aware that JavaScript files can be included by a <script> tag on another domain that would normally be denied access to your pages under the JavaScript Same Origin Policy. This opens you up to cross-site-information-leakage attacks if your script includes sensitive user-specific data:

<script src="http://www.targetsite.com/script.php" type="text/javascript"></script>
<script type="text/javascript">
    alert('Ha ha, I know you are logged in to targetsite.com as user '+name);
</script>

Finally, you will have to cope with cacheing. If your data are highly dynamic you'd need to set no-cache headers on the script response so that browsers don't cache it. On the other hand for less often-changing data you'd want to handle expiry, etags and if-modified-since/not-modified headers so that the browser can cache more efficiently; you don't want to have 100,000 people all fetching the script again and again, causing load on your server, if you can help it.

Handling cacheing right can be quite a pain, with weird results when you get it wrong.

Which, taken together, is why PHP templating into JavaScript is generally unpopular. For the typical usage where the bulk of a script is static and the amount of data you have to add small, it is usually better to template that data into the HTML, either in the associated elements' attributes, or by hiding it in a comment that can be read from DOM, or by including an inline <script>.

bobince