常州制作企业网站,深圳h5开发,wordpress nova 汉化,济南浩辰网站建设公司怎么样近期#xff0c;我会结合研发云陆续发布开发安全相关的文章#xff0c;欢迎大家关注#xff01;
Overview
echo json_encode($arr)#xff1a;向一个 Web 浏览器发送了未验证的数据#xff0c;从而导致该浏览器执行恶意代码。
Details
Cross-Site Scripting (XSS) 漏洞…近期我会结合研发云陆续发布开发安全相关的文章欢迎大家关注
Overview
echo json_encode($arr)向一个 Web 浏览器发送了未验证的数据从而导致该浏览器执行恶意代码。
Details
Cross-Site Scripting (XSS) 漏洞在以下情况下发生
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Persistent也称为 StoredXSS不可信赖的数据源通常为数据库或其他后端数据存储而对于 Reflected XSS该数据源通常为 Web 请求。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。 在这种情况下数据通过 builtin_echo() 传送。 传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。
基于 XSS 的攻击手段花样百出几乎是无穷无尽的但通常它们都会包含传输给攻击者的私有数据如 Cookie 或者其他会话信息。在攻击者的控制下指引受害者进入恶意的网络内容或者利用易受攻击的站点对用户的机器进行其他恶意操作。
例 1下面的 PHP 代码片段可根据一个给定的雇员 ID 查询数据库并显式出相应的雇员姓名。 ?php
$con mysql_connect($server,$user,$password);
$result mysql_query(select * from emp where ideid);
$row mysql_fetch_array($result)
echo Employee name: , mysql_result($row,0,name);
?
如果对 name 的值处理得当该代码就能正常地执行各种功能如若处理不当就会对代码的盗取行为无能为力。这段代码暴露出的危险较小因为 name 的值是从数据库中读取的而且显然这些内容是由应用程序管理的。
然而如果 name 的值来自用户提供的数据数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS或 Stored XSS它极其隐蔽因为数据存储导致的间接行为会增大辨别威胁的难度并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
例 2下面的 PHP 代码片段可从一个 HTTP 请求中读取雇员 ID eid并将其显示给用户。
?php $eid $_GET[eid];
? ... ?php echo Employee ID: $eid; ?
如Example 1 中所示如果 eid 只包含标准的字母数字文本此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码则 Web 浏览器就会在显示 HTTP 响应时执行该代码。 起初这个例子似乎是不会轻易遭受攻击的。毕竟有谁会输入导致恶意代码在自己电脑上运行的 URL 呢真正的危险在于攻击者会创建恶意的 URL然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时他们不知不觉地通过易受攻击的网络应用程序将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。 正如例子中所显示的XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。
受害者遭受 XSS 攻击的途径有三种
- 如Example 1 中所示应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用攻击者将危险内容注入到数据存储中而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权或者可以与敏感数据交互这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容攻击者就有可能以该用户的名义执行某些需要特权的操作或者获得该用户个人敏感数据的访问权。
- 如Example 2 中所示系统从 HTTP 请求中直接读取数据并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后便会执行这些内容接下来会将用户计算机中的各种私密信息比如可能包含会话信息的 Cookie传输给攻击者或者执行其他恶意活动。 — 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中随后这些危险数据被当作可信赖的数据回写到应用程序中并储存在动态内容中。
Recommendations
防止 XSS 漏洞的解决方法是确保在适当位置进行验证并设置相关属性以防止漏洞。 由于 XSS 漏洞在应用程序的输出中包含恶意数据时出现因此合乎逻辑的方法是在数据流出应用程序的前一刻对其进行验证。然而由于 Web 应用程序常常会包含复杂而难以理解的代码用以生成动态内容因此这一方法容易产生遗漏错误遗漏验证。
降低这一风险的有效途径是对 XSS 也执行输入验证。 由于 Web 应用程序必须验证所有输入信息以避免其他漏洞如 SQL Injection因此一种相对简单的解决方法是加强应用程序的现有输入验证机制将 XSS 检测包括其中。尽管有一定的价值但 XSS 输入验证并不能取代严格的输出验证。应用程序可能通过共享的数据存储器或其他可信赖的数据源接受输入而该数据存储器所接受的输入源可能并未执行适当的输入验证。因此应用程序不能间接地依赖于该数据或其他任意数据的安全性。这就意味着避免 XSS 漏洞的最佳方法是验证所有进入应用程序以及由应用程序传送至用户端的数据。
针对 XSS 漏洞进行验证最安全的方式是创建一份安全字符允许列表允许其中的字符出现在 HTTP 内容中并且只接受完全由这些经认可的字符组成的输入。例如有效的用户名可能仅包含字母数字字符电话号码可能仅包含 0-9 的数字。然而这种解决方法在 Web 应用程序中通常是行不通的因为许多字符对浏览器来说都具有特殊的含义编码时这些字符必须被视为合法输入例如一个 Web 设计电子公告栏就必须接受其用户提供的 HTML 片段。 更灵活的方法是采用拒绝列表但其安全性较差这种方法在使用输入之前就有选择地拒绝或转义了潜在的危险字符。为了创建这样一个列表首先需要了解对于 Web 浏览器具有特殊含义的字符集。
虽然 HTML 标准定义了哪些字符具有特殊含义许多 Web 浏览器仍会设法更正 HTML 中的常见错误并可能在特定的上下文中认为其他字符具有特殊含义。这就是为何我们不鼓励使用拒绝列表作为阻止 XSS 的方法。卡耐基梅隆大学 (Carnegie Mellon University) 软件工程学院 (Software Engineering Institute) 下属的 CERT(R) (CERT(R) Coordination Center) 合作中心提供了有关各种上下文中认定的特殊字符的具体信息 [1] 在有关块级别元素的内容中位于一段文本的中间 是一个特殊字符因为它可以引入一个标签。 是一个特殊字符因为它可以引入一个字符实体。 是一个特殊字符之所以某些浏览器将其认定为特殊字符是基于一种假设即该页的作者本想在前面添加一个 却错误地将其遗漏了。
下面的这些原则适用于属性值 对于外加双引号的属性值双引号是特殊字符因为它们标记了该属性值的结束。 对于外加单引号的属性值单引号是特殊字符因为它们标记了该属性值的结束。 对于不带任何引号的属性值空格字符如空格符和制表符是特殊字符。
- 与某些特定变量一起使用时是特殊字符因为它引入了一个字符实体。 例如在 URL 中搜索引擎可能会在结果页面内提供一个链接用户可以点击该链接来重新运行搜索。可以将这一方法运用于编写 URL 中的搜索查询语句这将引入更多特殊字符 空格符、制表符和换行符是特殊字符因为它们标记了 URL 的结束。 - 是特殊字符因为它可引入一个字符实体或分隔 CGI 参数。
- 非 ASCII 字符即 ISO-8859-1 编码表中所有大于 127 的字符不允许出现在 URL 中因此这些字符在此环境下被视为特殊字符。
- 在服务器端对在 HTTP 转义序列中编码的参数进行解码时必须过滤掉输入中的 % 符号。例如当输入中出现“%68%65%6C%6C%6F”时只有从输入的内容中过滤掉“%”上述字符串才能在网页上显示为“hello”。 在 SCRIPT /SCRIPT 的正文内
- 如果可以将文本直接插入到已有的脚本标签中则必须过滤掉分号、圆括号、花括号和换行符。 服务器端脚本 如果服务器端脚本会将输入中的感叹号 (!) 转换成输出中的双引号 ()则可能需要对此进行更多过滤。 其他可能出现的情况 如果攻击者以 UTF-7 格式提交了请求则特殊字符“”可能会显示为“ADw-”并可能会绕过过滤。如果输出包含在没有确切指定编码格式的网页中某些浏览器就会设法根据内容自动识别编码此处采用 UTF-7 格式。
在应用程序中确定针对 XSS 攻击执行验证的正确要点以及验证过程中要考虑的特殊字符之后下一个难点就是确定验证过程中处理各种特殊字符的方式。如果应用程序认定某些特殊字符为无效输入那么您可以拒绝任何带有这些无效特殊字符的输入。第二种选择就是采用过滤手段来删除这些特殊字符。然而过滤的负面作用在于过滤内容的显示将发生改变。在需要完整显示输入内容的情况下过滤的这种负面作用可能是无法接受的。 如果必须接受带有特殊字符的输入并将其准确地显示出来验证机制一定要对所有特殊字符进行编码以便删除其具有的含义。
官方的 HTML 规范 [2] 提供了特殊字符对应的 ISO 8859-1 编码值的完整列表。 许多应用程序服务器都试图避免应用程序出现 Cross-Site Scripting 漏洞具体做法是为负责设置特定 HTTP 响应内容的函数提供各种实现方式以检验是否存在进行 Cross-Site Scripting 攻击必需的字符。不要依赖运行应用程序的服务器以此确保该应用程序的安全。
对于任何已开发的应用程序并不能保证在其生命周期中它会在哪些应用程序服务器中运行。由于标准和已知盗取方式的演变我们不能保证应用程序服务器将继续保持同步。 ———————————————— 版权声明本文为CSDN博主「irizhao」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/irizhao/article/details/135644701
防御 标签过滤 事件过滤 敏感字符过滤 设置httponly防止Cookie被获取 内容安全策略CSP 在将不可信数据插入到HTML标签之间时对这些数据进行HTML Entity编码 在将不可信数据插入到HTML属性里时对这些数据进行HTML属性编码 在将不可信数据插入到SCRIPT里时对这些数据进行SCRIPT编码 在将不可信数据插入到Style属性里时对这些数据进行CSS编码
