代码之家 › 专栏 › 技术社区 › Alec

包含站点逻辑的安全和javascript文件

security jquery javascript

Alec · 技术社区 · 14 年前

现在,像jquery这样的javascript库比以往任何时候都更流行,.js文件开始包含越来越多的站点逻辑。它如何从何处提取数据/信息,如何处理这些信息,等等。这不一定是件坏事,但我想知道这可能是一个安全问题的扩展。

当然,使用PHP或其他语言在后端仍然会进行真正的数据处理,关键是要确保在这一点上不会发生不需要的事情。但只要看看网站的.js(它非常依赖jquery),它就能告诉一个人,作为一个开发人员,可能比你更想知道。尤其是现在每个浏览器都有一个相当广泛的Web开发环境或附加组件。即使对于一个操作DOM的新手来说也不再是什么大不了的事情了。一旦你发现了代码的存在,以及你如何通过编辑DOM来影响它,“乐趣”就开始了。

所以我主要关心的是:

我不希望每个人都能看到一个.js文件,并能准确地(或者更确切地说,在很大程度上)看到我的网站、Web应用程序或CMS是如何工作的,它有什么,它做什么,它怎么做,等等。
我担心通过“公开”这些信息,那些比我聪明得多的人会想出一种方法来操纵DOM,以影响他们现在知道站点使用的javascript函数,可能会绕过我实现的后端检查(因此错误地假设它们足够好)。

我已经为不同的部分使用了不同的.js文件,例如Web应用程序。但总有一些东西必须在全球范围内可用,有时这其中包含的内容超出了我想公开的范围。既然都“在外面”,谁又会说他们找不到其他的文件呢?

我有时会看到大量没有换行符的javascript。类似于紧凑的jquery文件。我确信有一些应用程序或技巧可以将普通的.js文件转换为一个长字符串。但是,如果它能做到这一点,那么把它变回更易读的东西(除了节省空间之外,这样做毫无意义)难道不容易吗?

最后,我考虑是否可以检测.js文件的请求是否来自站点本身(通过将脚本包含在HTML中),而不是直接下载。也许通过使用Apache的modrewrite来阻止后者,可以在HTML中使用.js文件,但是当有人试图访问它时,它被阻止了。

你对此有何看法?我反应过度了吗?我应该尽可能多地拆分JS,还是只需要花费更多的时间来三重检查(后端)脚本,并包括更多的检查来防止伤害?或者,是否有一些最佳实践可以限制javascript及其包含的所有信息的暴露?

5 回复 | 直到 14 年前

ceejayoz 14 年前

如果设置正确的话,javascript中的任何内容都不应该是安全风险。试图访问在javascript文件中找到的Ajax端点应该检查用户的权限,如果没有正确的权限,则会失败。

如果你做了一些破坏的事情,比如打电话给类似的人,让别人查看你的javascript只是一个安全风险。 /ajax/secret_endpoint_that_requires_no_authentication.php ,在这种情况下,您的问题不是不安全的javascript,而是不安全的代码。

我有时会看到大量没有换行符的javascript。类似于紧凑的jquery文件。我确信有一些应用程序或技巧可以将普通的.js文件转换为一个长字符串。但是,如果它能做到这一点,那么把它变回更易读的东西(除了节省空间之外,这样做毫无意义)难道不容易吗?

这通常是缩小(以减少带宽使用),而不是模糊。它很容易可逆。有一些模糊技术会使所有变量和函数名变得无用,比如“aa”、“bb”等,但只要付出足够的努力,它们是可逆的。

最后,我考虑是否可以检测.js文件的请求是否来自站点本身(通过将脚本包含在HTML中),而不是直接下载。也许通过使用Apache的modrewrite来阻止后者,可以在HTML中使用.js文件,但是当有人试图访问它时,它被阻止了。

这是可能的,但它很容易被任何半能干的攻击者解决。 底线: 发送给非特权用户的浏览器不应曾经敏感数据。

Pointy 14 年前

当然,您应该花更多的时间检查后端脚本。您必须像攻击者是您站点上的关键开发人员之一一样处理安全问题,而这个开发人员完全知道所有事情的工作原理。网站中对数据库有影响的每一个URL都必须受到保护,以确保每个参数都在允许的约束范围内:用户只能更改自己的数据,只能在合法范围内进行更改,只能在允许更改的状态下进行更改等等。这些都与什么无关。t您的javascript看起来像或者是否有人可以阅读它,而jquery与这个问题完全无关(除非您做的都是错误的)。

记住:对您的站点的HTTP请求可以来自任何地方,并且可以由宇宙中的任何一个软件启动。您无法控制这一点,也无法对客户机可以加载哪些页面进行任何限制。不要费心“引用”检查,因为值可能被伪造。不要依赖JavaScript中的数据清理例程,因为可以绕过这些例程。

Andy Hume 14 年前

好吧,你想这些是对的。这是Web应用程序开发中一个非常重要和被误解的领域。

在我看来,答案是肯定的。可以创建更多的安全问题,仅仅是因为(正如您指出的)攻击向量增加了。从根本上讲,与传统(非JS)Web应用程序相比,没有太大的变化,同样的最佳实践和方法也能很好地为您提供服务。例如,注意SQL注入、缓冲区溢出、响应拆分等…你只是有更多的地方需要注意。

就脚本本身而言,跨域安全问题可能是最普遍的。研究并学习如何特别避免XSS攻击,以及CSRF攻击。

Javascript模糊处理通常不是出于安全原因而执行的,您可以很容易地对其进行逆向工程。人们这样做,部分是为了保护知识产权,但主要是为了减少代码下载的重量。

我推荐O'Reilly出版的克里斯托弗·威尔斯的书,书名为“保护Ajax应用程序”。

rook 14 年前

有免费软件可以 JavaScript Obfuscation . 虽然没有安全,但默默无闻。这并不能防止对您的系统的所有攻击。这确实使它变得更加困难,但对于其他人来说,也不可能撕掉你的javascript并使用它。

还有客户端信任的问题。通过在客户机端拥有大量的逻辑,客户机有权选择要执行的操作。例如,如果您在JavaScript中转义引号以防止SQL注入。黑客将编写利用代码来构建自己的HTTP请求,完全绕过转义例程。

TamperData 和 FireBug 通常被黑客用来深入了解Web应用程序。

单独的javascript代码罐头其中存在漏洞。一个很好的例子是 DOM Based XSS . 尽管我承认这不是一种常见的XSS类型。

Ken Penn 14 年前

这是比利·霍夫曼的一本关于Ajax安全的书:

http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1266538410&sr=1-1