最近关注DOS问题,了解到后端服务在解析构造的超大超多空对象字符串后导致服务端DOS了,那么前端是否也存在因为JSON.parse解析超大超多空对象字符串导致的浏览器拒绝服务呢?
在网上搜索都没有相关讨论,难道浏览器不存在dos问题,或者浏览器的dos问题没有利用价值不值得被关注,特此一问,求各位大佬解惑。
DoS 全称 Denial-of-Service 攻击,翻译成中文是:
拒绝 服务攻击。
另外,服务端易受 DoS 攻击,主要是因为其为了服务,必须被动接收来自网络的请求,给了脚本小子们可乘之机。
客户端偶尔也会遇到一些通过占用应用资源来搞事情的手法,比如 2020 年让很多 iPhone 死机的“微信字符炸弹”,但是微信客户端毕竟不提供 Service
,所以这种攻击不能称为“Denial-of-Service”。
可能由于这种攻击不够频繁,甚至都没人给刻意为之取名。
解析过程在服务端,非常占用服务器资源。可以理解为费时间,费电。占用线程。
但是如果在客户端,它不会影响到服务器,它最多让你个人电脑卡。
你没有正确理解拒绝服务攻击。拒绝服务工具是用大量请求占用目标服务器的资源,使其无法正常工作。
例如,假设有网站 A,日活 50 万人,考虑 30% 的冗余,那么它的服务器至少应该能承受 70 万人的访问。那么我使用 20 万肉鸡发起攻击,服务器的占用就差不多满了。普通用户应该能感受到明显的卡顿。如果我使用 30 万肉鸡发起攻击,如果服务器炸了的话,所有用户都无法正常访问;如果服务器没炸,那么就会有 10 万用户无法正常访问。
攻击对象是服务器而不是客户端。
是的,使用JSON.parse
解析超大JSON字符串确实有可能导致浏览器端的拒绝服务(DoS)攻击,尽管这种情况可能不如后端服务那么常见或容易利用。
JSON.parse
可以处理的数据大小。这意味着开发者需要自行实现逻辑来限制接收到的JSON数据的大小,以防止潜在的DoS攻击。虽然JSON.parse
本身不会导致直接的浏览器DoS漏洞(因为它是一个标准的JavaScript函数,其行为是可预测的),但解析超大JSON字符串可能会成为DoS攻击的一个媒介。因此,开发者应该采取适当的措施来限制和处理传入的数据,以保护应用程序免受潜在的攻击。
使用JSON.parse 解析后端返回的 responseText 报错 报错信息: Uncaught SyntaxError: Unexpected token 'd', "data: {"te"... is not valid JSON
问题内容: 我的长字符串不适合屏幕的宽度。例如。 为了使阅读更容易,我想到了用这种方式编写它- 但是,我意识到第二种方法使用字符串连接,并会在内存中创建5个新字符串,这可能会导致性能下降。是这样吗 还是编译器足够聪明,以至于我只需要一个字符串就可以了?我如何避免这样做? 问题答案: 我意识到第二种方法使用字符串连接,并将在内存中创建5个新字符串,这可能会导致性能下降。 不,不会。由于这些是字符串文
我正在创建一个日志,它由列表中的一个数组组成,数组是每个新条目,列表是日志。以下是我迄今为止试图解决的问题: 我在尝试实现这一点时遇到了很多困难,但现在仍然没有。我试图做的是在数组中使用时间、标题和文本的3个索引空间,然后将这3个组合到列表中,使它们成为列表中的单个元素,因此当我搜索标题时,它们会作为一个组出现。 我试图在声明日志时使用普通字符串列表,但如果不指定要插入的索引,我就无法将数组添加到
下面的电话 返回此错误: "找不到有效的帐户信息组合。" 使用直接从Azure service Bus访问策略上的连接字符串–主键字段复制的连接字符串- endpoint=sb://xxx。服务总线。窗户。净/;SharedAccessKeyName=xxx;SharedAccessKey=xxx;EntityPath=xxx 我需要CloudQueueClient和CloudQueue实例来执行
问题内容: 我有以下Json字符串 我正在尝试解析它并打印出每个名称和值-最简单的方法是什么?我尝试了jQuery.parseJSON但我不知道如何使用它 示例代码会很棒 问题答案: 结果是: jsFiddle示例:http://jsfiddle.net/bradchristie/XtzjZ/1/