使用 PHP 作为 Javascript 文件 - 安全性？

发布于 2024-08-04 20:47:14 字数 228 浏览 7 评论 0原文

在 javascript include 中使用 php 文件而不是 .js 文件有什么问题？

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

显然，我将解决并插入注册全局问题等，但是是否还有其他可能出现的漏洞？考虑到将有超过 100,000 人查看启用此脚本的页面。

原文

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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

嘿嘿嘿 2024-08-11 20:47:14

不会，服务器会像解析任何其他 PHP 文件一样解析它。

该文件将通过 HTTP 请求检索，与任何其他网页完全相同。
如果您将其包含在

就浏览器而言，它只是 javascript - 它不知道它是由 PHP 生成的，因此无需考虑任何额外内容。

只要你不留下将 javascript 注入到文件中的方法，就可以了。只是一定要确保不信任输入并转义输出。

回复收藏 0 原文

烟凡古楼 2024-08-11 20:47:14

是否还会出现其他漏洞？

在 PHP 本身中，将值输出到 JavaScript 需要与输出到 HTML 不同的编码方案。如果你做得不对，你就会面临同样类型的跨站点脚本问题，就像你在生成 HTML 的 PHP 中未能使用 htmlspecialchars() 一样：

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

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

这两种情况都会给你带来如果您的名称包含撇号或反斜杠，则会出现问题。这是 addslashes() 可以真正成为正确的事情的少数几个地方之一！

另外您应该知道 JavaScript 文件可以包含在

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

最后，您将不得不应对缓存。如果您的数据高度动态，您需要在脚本响应上设置无缓存标头，以便浏览器不会缓存它。另一方面，对于不经常更改的数据，您需要处理过期、etag 和 if-modified-since/not-modified 标头，以便浏览器可以更有效地缓存；如果您可以帮助的话，您不希望有 100,000 个人一次又一次地获取脚本，从而导致服务器负载。

正确处理缓存可能会非常痛苦，如果处理错误，就会产生奇怪的结果。

总而言之，这就是为什么将 PHP 模板化为 JavaScript 通常不受欢迎。对于大部分脚本是静态的并且必须添加的数据量较小的典型用法，通常最好将该数据模板化到 HTML 中，或者在关联元素的属性中，或者将其隐藏在注释中可以从 DOM 读取，或者通过包含内联

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

回复收藏 0 原文

~没有更多了~