程序员服装安全：分享与学习-跨站点脚本 (XSS)
自 2000 年代初以来，跨站脚本 (XSS) 一直是安全专业人员的麻烦，遗憾的是，几十年过去了，它仍然是最常见的代码级威胁之一。此类软件漏洞已经困扰我们太长时间了，最近发出的警报来自 CISA -作为其 “通过设计安全” 运动的一部分，他们正在寻求一劳永逸地予以阻挠。他们肩负着大规模消除漏洞类别的全球使命，而这种聚焦开发人员驱动的安全性确实可以起到推动作用并有所作为，但这需要智慧企业的承诺，让开发人员为安全方面的成功做好准备。
那么，XSS 到底是什么？
网络浏览器可能是我们访问所有在线精彩内容的门户，但遗憾的是，这并不全是好消息。网络浏览器的固有行为可能是安全漏洞的催化剂。浏览器一开始通常会信任它看到的标记，然后毫无疑问地执行它。除非该功能被用于不愉快的目的，否则一切都很好，花花公子... 当然，攻击者最终找到了利用这种趋势来实现其邪恶目的的方法。
跨站点脚本利用浏览器的信任和用户的无知来窃取数据、接管帐户和破坏网站；这是一个很快就会变得非常丑陋的漏洞。
让我们来看看 XSS 是如何工作的，可以造成什么伤害以及如何防止：
XSS 是如何工作的？
当不受信任的输入（通常是数据）在页面上呈现为输出但被误解为可执行代码时，就会出现 XSS。攻击者可以在输入参数中放置恶意可执行代码（HTML 标签、JavaScript 等），当返回到浏览器时，该输入参数会被执行而不是显示为数据。
如上所述，该漏洞是由于浏览器的核心功能行为而出现的，在这种行为中，很难区分数据和可执行代码。网络的运营模式如下：
- 用户访问网页
- 该页面告诉浏览器要加载哪些文件以及要执行什么
- 浏览器执行页面上的内容，不问任何问题
此功能带来了我们在网络上享受的一些最棒的互动体验。硬币的另一面是，它还导致了代价高昂的漏洞利用和漏洞。
当攻击者将其恶意脚本添加到易受攻击的站点时，毫无疑问会执行该脚本。没有更深入的调查，也没有侦查措施。
XSS 有三种类型：
- 存储的 XSS
- 反射式 XSS
- DOM XSS
存储的 XSS 当攻击者可以将恶意脚本持续存储在应用程序的数据字段（例如存储用户手机号码的字段中）时，就会发生这种情况。然后，每次在应用程序中显示该数据字段时，都会将这个粗略的脚本发送到用户的浏览器。
这种攻击通常出现在论坛网站或评论引擎上。攻击者在评论中输入恶意脚本，bam-每个查看该评论的用户都会在不知不觉中执行该脚本。
反射式 XSS 当用户输入按原样反射回用户浏览器时发生。例如，搜索框在获取搜索结果时向用户显示 “您搜索了...”。
现在，假设搜索是通过将搜索词作为查询参数放在 URL 中来实现的。恶意攻击者可以向受害者发送嵌入在这些完全相同的参数中的恶意脚本的链接，说实话，大多数网络用户几乎不会注意到它。
受害者点击链接并被重定向到钓鱼网站，在那里他/她不知不觉地输入了该网站的密码。他们几乎没有意识到，攻击者刚刚窃取了他们账户的密钥。
DOM XSS 是该漏洞的相对较新的变种。它利用了许多用户界面框架（例如Angular和React）中的复杂模板结构。
这些模板允许动态内容和丰富的 UI 应用程序。如果使用不当，它们可用于执行 XSS 攻击。
所以，你明白了。简而言之，你已经知道了 XSS 的范围。让我们更深入地研究如何破坏性地使用它。
为什么 XSS 这么危险？
XSS 可用于将用户重定向到恶意站点、窃取 Cookie 和搜寻会话数据。基本上，无论JavaScript能做什么，XSS攻击也是有能力的。
以下是三个 XSS 攻击示例：
- 雅虎电子邮件用户 他们的会话 cookie 被偷走了 2015 年使用 XSS。
- 这个 萨米蠕虫 是通过 MySpace 中的 XSS 漏洞分发的。它仍然是有史以来传播最快的恶意软件，在短短20小时内影响了100万用户。
- eBay 允许在产品描述中包含恶意脚本。这导致 XSS 攻击 针对 eBay 用户。
XSS 攻击看似简单而且非常严重。它们可能导致会话、用户凭证或敏感数据被盗。声誉损害和收入减少是这些攻击的主要陷阱。即使只是破坏网站也可能给企业带来不良后果。
但是，XSS 可以像你一样被精明的安全战士击败。修复并不复杂，自从XSS成为常用漏洞以来，该行业已经走了很长一段路。
你可以击败 XSS。
击败 XSS 的关键是了解背景。具体而言，您的用户输入将在其中呈现回客户端以及在何处呈现回客户端的上下文。在 HTML 代码中或 JavaScript 片段中。
如果不必将用户输入发送回浏览器，那就更好了。但是，如果是，则通常应采用HTML编码。对输出进行 HTML 编码将告诉浏览器按原样呈现内容，而不是执行内容。
输入验证也很重要。但是，验证和白名单 不是 万无一失的解决方案。编码更进一步，可以阻止浏览器执行恶意脚本。无论验证和白名单策略中没有发现什么，编码都会起作用。
现在，许多框架都在自动对 HTML 输出进行编码。
角度的， ASP.NET MVC，以及 React.js 是使用默认 HTML 编码的框架。你必须明确告诉这些框架不要通过调用特殊方法进行编码。
大多数其他框架，（即 詹戈 和 春天) 有用于防止 XSS 的标准库，您可以轻松地将其整合到代码中。
最大的挑战是自学分析用户输入进入系统的所有方式，这样你就可以全神贯注。查询参数可以进行攻击，发布参数也可以进行攻击。关注整个应用程序中的数据流，不要信任来自外部的任何数据。
像边境巡逻一样思考。停止每条数据，对其进行检查，如果数据看起来很恶意，则不要允许其进入。然后在渲染时进行编码，确保遗漏的任何不良内容仍然不会造成问题。
执行这些策略，您的用户将免受通过 XSS 的攻击。看一看 OWASP 备忘单 获取更多控制数据的小贴士。
阻止 XSS 并提升您的安全技能。
XSS在OWASP 2017年十大网络安全风险清单中排名第七。它已经存在了一段时间，但如果你不小心，它仍然会出现并导致你的应用程序出现问题。
培训对于开发人员在编写代码时建立安全第一思维非常重要。而且，当使用开发人员正在使用的语言模拟真实应用程序时，这种训练始终是最有效的。考虑到这一点，为什么不看看我们的 学习资源 想了解有关 XSS 的更多信息？之后，你可以开始训练和练习，从而掌握自己的技能。
认为你现在准备好发现和修复 XSS 漏洞了吗？ 挑战自我 在 Secure Code Warrior 平台上。
跨站脚本 (XSS) 利用 BROWSER 的信使和用户的无知来取走数据、接管帐户和破坏者网站；这个漏洞很快，会变得非常快。让我们来看看 XSS 是如何工作的，可以造成什么伤害以及如何防止。
Jaap Karan Singh是一位安全编码布道者，首席辛格和Secure Code Warrior 的共同创始人。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示
Jaap Karan Singh是一位安全编码布道者，首席辛格和Secure Code Warrior 的共同创始人。
自 2000 年代初以来，跨站脚本 (XSS) 一直是安全专业人员的麻烦，遗憾的是，几十年过去了，它仍然是最常见的代码级威胁之一。此类软件漏洞已经困扰我们太长时间了，最近发出的警报来自 CISA -作为其 “通过设计安全” 运动的一部分，他们正在寻求一劳永逸地予以阻挠。他们肩负着大规模消除漏洞类别的全球使命，而这种聚焦开发人员驱动的安全性确实可以起到推动作用并有所作为，但这需要智慧企业的承诺，让开发人员为安全方面的成功做好准备。
那么，XSS 到底是什么？
网络浏览器可能是我们访问所有在线精彩内容的门户，但遗憾的是，这并不全是好消息。网络浏览器的固有行为可能是安全漏洞的催化剂。浏览器一开始通常会信任它看到的标记，然后毫无疑问地执行它。除非该功能被用于不愉快的目的，否则一切都很好，花花公子... 当然，攻击者最终找到了利用这种趋势来实现其邪恶目的的方法。
跨站点脚本利用浏览器的信任和用户的无知来窃取数据、接管帐户和破坏网站；这是一个很快就会变得非常丑陋的漏洞。
让我们来看看 XSS 是如何工作的，可以造成什么伤害以及如何防止：
XSS 是如何工作的？
当不受信任的输入（通常是数据）在页面上呈现为输出但被误解为可执行代码时，就会出现 XSS。攻击者可以在输入参数中放置恶意可执行代码（HTML 标签、JavaScript 等），当返回到浏览器时，该输入参数会被执行而不是显示为数据。
如上所述，该漏洞是由于浏览器的核心功能行为而出现的，在这种行为中，很难区分数据和可执行代码。网络的运营模式如下：
- 用户访问网页
- 该页面告诉浏览器要加载哪些文件以及要执行什么
- 浏览器执行页面上的内容，不问任何问题
此功能带来了我们在网络上享受的一些最棒的互动体验。硬币的另一面是，它还导致了代价高昂的漏洞利用和漏洞。
当攻击者将其恶意脚本添加到易受攻击的站点时，毫无疑问会执行该脚本。没有更深入的调查，也没有侦查措施。
XSS 有三种类型：
- 存储的 XSS
- 反射式 XSS
- DOM XSS
存储的 XSS 当攻击者可以将恶意脚本持续存储在应用程序的数据字段（例如存储用户手机号码的字段中）时，就会发生这种情况。然后，每次在应用程序中显示该数据字段时，都会将这个粗略的脚本发送到用户的浏览器。
这种攻击通常出现在论坛网站或评论引擎上。攻击者在评论中输入恶意脚本，bam-每个查看该评论的用户都会在不知不觉中执行该脚本。
反射式 XSS 当用户输入按原样反射回用户浏览器时发生。例如，搜索框在获取搜索结果时向用户显示 “您搜索了...”。
现在，假设搜索是通过将搜索词作为查询参数放在 URL 中来实现的。恶意攻击者可以向受害者发送嵌入在这些完全相同的参数中的恶意脚本的链接，说实话，大多数网络用户几乎不会注意到它。
受害者点击链接并被重定向到钓鱼网站，在那里他/她不知不觉地输入了该网站的密码。他们几乎没有意识到，攻击者刚刚窃取了他们账户的密钥。
DOM XSS 是该漏洞的相对较新的变种。它利用了许多用户界面框架（例如Angular和React）中的复杂模板结构。
这些模板允许动态内容和丰富的 UI 应用程序。如果使用不当，它们可用于执行 XSS 攻击。
所以，你明白了。简而言之，你已经知道了 XSS 的范围。让我们更深入地研究如何破坏性地使用它。
为什么 XSS 这么危险？
XSS 可用于将用户重定向到恶意站点、窃取 Cookie 和搜寻会话数据。基本上，无论JavaScript能做什么，XSS攻击也是有能力的。
以下是三个 XSS 攻击示例：
- 雅虎电子邮件用户 他们的会话 cookie 被偷走了 2015 年使用 XSS。
- 这个 萨米蠕虫 是通过 MySpace 中的 XSS 漏洞分发的。它仍然是有史以来传播最快的恶意软件，在短短20小时内影响了100万用户。
- eBay 允许在产品描述中包含恶意脚本。这导致 XSS 攻击 针对 eBay 用户。
XSS 攻击看似简单而且非常严重。它们可能导致会话、用户凭证或敏感数据被盗。声誉损害和收入减少是这些攻击的主要陷阱。即使只是破坏网站也可能给企业带来不良后果。
但是，XSS 可以像你一样被精明的安全战士击败。修复并不复杂，自从XSS成为常用漏洞以来，该行业已经走了很长一段路。
你可以击败 XSS。
击败 XSS 的关键是了解背景。具体而言，您的用户输入将在其中呈现回客户端以及在何处呈现回客户端的上下文。在 HTML 代码中或 JavaScript 片段中。
如果不必将用户输入发送回浏览器，那就更好了。但是，如果是，则通常应采用HTML编码。对输出进行 HTML 编码将告诉浏览器按原样呈现内容，而不是执行内容。
输入验证也很重要。但是，验证和白名单 不是 万无一失的解决方案。编码更进一步，可以阻止浏览器执行恶意脚本。无论验证和白名单策略中没有发现什么，编码都会起作用。
现在，许多框架都在自动对 HTML 输出进行编码。
角度的， ASP.NET MVC，以及 React.js 是使用默认 HTML 编码的框架。你必须明确告诉这些框架不要通过调用特殊方法进行编码。
大多数其他框架，（即 詹戈 和 春天) 有用于防止 XSS 的标准库，您可以轻松地将其整合到代码中。
最大的挑战是自学分析用户输入进入系统的所有方式，这样你就可以全神贯注。查询参数可以进行攻击，发布参数也可以进行攻击。关注整个应用程序中的数据流，不要信任来自外部的任何数据。
像边境巡逻一样思考。停止每条数据，对其进行检查，如果数据看起来很恶意，则不要允许其进入。然后在渲染时进行编码，确保遗漏的任何不良内容仍然不会造成问题。
执行这些策略，您的用户将免受通过 XSS 的攻击。看一看 OWASP 备忘单 获取更多控制数据的小贴士。
阻止 XSS 并提升您的安全技能。
XSS在OWASP 2017年十大网络安全风险清单中排名第七。它已经存在了一段时间，但如果你不小心，它仍然会出现并导致你的应用程序出现问题。
培训对于开发人员在编写代码时建立安全第一思维非常重要。而且，当使用开发人员正在使用的语言模拟真实应用程序时，这种训练始终是最有效的。考虑到这一点，为什么不看看我们的 学习资源 想了解有关 XSS 的更多信息？之后，你可以开始训练和练习，从而掌握自己的技能。
认为你现在准备好发现和修复 XSS 漏洞了吗？ 挑战自我 在 Secure Code Warrior 平台上。
自 2000 年代初以来，跨站脚本 (XSS) 一直是安全专业人员的麻烦，遗憾的是，几十年过去了，它仍然是最常见的代码级威胁之一。此类软件漏洞已经困扰我们太长时间了，最近发出的警报来自 CISA -作为其 “通过设计安全” 运动的一部分，他们正在寻求一劳永逸地予以阻挠。他们肩负着大规模消除漏洞类别的全球使命，而这种聚焦开发人员驱动的安全性确实可以起到推动作用并有所作为，但这需要智慧企业的承诺，让开发人员为安全方面的成功做好准备。
那么，XSS 到底是什么？
网络浏览器可能是我们访问所有在线精彩内容的门户，但遗憾的是，这并不全是好消息。网络浏览器的固有行为可能是安全漏洞的催化剂。浏览器一开始通常会信任它看到的标记，然后毫无疑问地执行它。除非该功能被用于不愉快的目的，否则一切都很好，花花公子... 当然，攻击者最终找到了利用这种趋势来实现其邪恶目的的方法。
跨站点脚本利用浏览器的信任和用户的无知来窃取数据、接管帐户和破坏网站；这是一个很快就会变得非常丑陋的漏洞。
让我们来看看 XSS 是如何工作的，可以造成什么伤害以及如何防止：
XSS 是如何工作的？
当不受信任的输入（通常是数据）在页面上呈现为输出但被误解为可执行代码时，就会出现 XSS。攻击者可以在输入参数中放置恶意可执行代码（HTML 标签、JavaScript 等），当返回到浏览器时，该输入参数会被执行而不是显示为数据。
如上所述，该漏洞是由于浏览器的核心功能行为而出现的，在这种行为中，很难区分数据和可执行代码。网络的运营模式如下：
- 用户访问网页
- 该页面告诉浏览器要加载哪些文件以及要执行什么
- 浏览器执行页面上的内容，不问任何问题
此功能带来了我们在网络上享受的一些最棒的互动体验。硬币的另一面是，它还导致了代价高昂的漏洞利用和漏洞。
当攻击者将其恶意脚本添加到易受攻击的站点时，毫无疑问会执行该脚本。没有更深入的调查，也没有侦查措施。
XSS 有三种类型：
- 存储的 XSS
- 反射式 XSS
- DOM XSS
存储的 XSS 当攻击者可以将恶意脚本持续存储在应用程序的数据字段（例如存储用户手机号码的字段中）时，就会发生这种情况。然后，每次在应用程序中显示该数据字段时，都会将这个粗略的脚本发送到用户的浏览器。
这种攻击通常出现在论坛网站或评论引擎上。攻击者在评论中输入恶意脚本，bam-每个查看该评论的用户都会在不知不觉中执行该脚本。
反射式 XSS 当用户输入按原样反射回用户浏览器时发生。例如，搜索框在获取搜索结果时向用户显示 “您搜索了...”。
现在，假设搜索是通过将搜索词作为查询参数放在 URL 中来实现的。恶意攻击者可以向受害者发送嵌入在这些完全相同的参数中的恶意脚本的链接，说实话，大多数网络用户几乎不会注意到它。
受害者点击链接并被重定向到钓鱼网站，在那里他/她不知不觉地输入了该网站的密码。他们几乎没有意识到，攻击者刚刚窃取了他们账户的密钥。
DOM XSS 是该漏洞的相对较新的变种。它利用了许多用户界面框架（例如Angular和React）中的复杂模板结构。
这些模板允许动态内容和丰富的 UI 应用程序。如果使用不当，它们可用于执行 XSS 攻击。
所以，你明白了。简而言之，你已经知道了 XSS 的范围。让我们更深入地研究如何破坏性地使用它。
为什么 XSS 这么危险？
XSS 可用于将用户重定向到恶意站点、窃取 Cookie 和搜寻会话数据。基本上，无论JavaScript能做什么，XSS攻击也是有能力的。
以下是三个 XSS 攻击示例：
- 雅虎电子邮件用户 他们的会话 cookie 被偷走了 2015 年使用 XSS。
- 这个 萨米蠕虫 是通过 MySpace 中的 XSS 漏洞分发的。它仍然是有史以来传播最快的恶意软件，在短短20小时内影响了100万用户。
- eBay 允许在产品描述中包含恶意脚本。这导致 XSS 攻击 针对 eBay 用户。
XSS 攻击看似简单而且非常严重。它们可能导致会话、用户凭证或敏感数据被盗。声誉损害和收入减少是这些攻击的主要陷阱。即使只是破坏网站也可能给企业带来不良后果。
但是，XSS 可以像你一样被精明的安全战士击败。修复并不复杂，自从XSS成为常用漏洞以来，该行业已经走了很长一段路。
你可以击败 XSS。
击败 XSS 的关键是了解背景。具体而言，您的用户输入将在其中呈现回客户端以及在何处呈现回客户端的上下文。在 HTML 代码中或 JavaScript 片段中。
如果不必将用户输入发送回浏览器，那就更好了。但是，如果是，则通常应采用HTML编码。对输出进行 HTML 编码将告诉浏览器按原样呈现内容，而不是执行内容。
输入验证也很重要。但是，验证和白名单 不是 万无一失的解决方案。编码更进一步，可以阻止浏览器执行恶意脚本。无论验证和白名单策略中没有发现什么，编码都会起作用。
现在，许多框架都在自动对 HTML 输出进行编码。
角度的， ASP.NET MVC，以及 React.js 是使用默认 HTML 编码的框架。你必须明确告诉这些框架不要通过调用特殊方法进行编码。
大多数其他框架，（即 詹戈 和 春天) 有用于防止 XSS 的标准库，您可以轻松地将其整合到代码中。
最大的挑战是自学分析用户输入进入系统的所有方式，这样你就可以全神贯注。查询参数可以进行攻击，发布参数也可以进行攻击。关注整个应用程序中的数据流，不要信任来自外部的任何数据。
像边境巡逻一样思考。停止每条数据，对其进行检查，如果数据看起来很恶意，则不要允许其进入。然后在渲染时进行编码，确保遗漏的任何不良内容仍然不会造成问题。
执行这些策略，您的用户将免受通过 XSS 的攻击。看一看 OWASP 备忘单 获取更多控制数据的小贴士。
阻止 XSS 并提升您的安全技能。
XSS在OWASP 2017年十大网络安全风险清单中排名第七。它已经存在了一段时间，但如果你不小心，它仍然会出现并导致你的应用程序出现问题。
培训对于开发人员在编写代码时建立安全第一思维非常重要。而且，当使用开发人员正在使用的语言模拟真实应用程序时，这种训练始终是最有效的。考虑到这一点，为什么不看看我们的 学习资源 想了解有关 XSS 的更多信息？之后，你可以开始训练和练习，从而掌握自己的技能。
认为你现在准备好发现和修复 XSS 漏洞了吗？ 挑战自我 在 Secure Code Warrior 平台上。
自 2000 年代初以来，跨站脚本 (XSS) 一直是安全专业人员的麻烦，遗憾的是，几十年过去了，它仍然是最常见的代码级威胁之一。此类软件漏洞已经困扰我们太长时间了，最近发出的警报来自 CISA -作为其 “通过设计安全” 运动的一部分，他们正在寻求一劳永逸地予以阻挠。他们肩负着大规模消除漏洞类别的全球使命，而这种聚焦开发人员驱动的安全性确实可以起到推动作用并有所作为，但这需要智慧企业的承诺，让开发人员为安全方面的成功做好准备。
那么，XSS 到底是什么？
网络浏览器可能是我们访问所有在线精彩内容的门户，但遗憾的是，这并不全是好消息。网络浏览器的固有行为可能是安全漏洞的催化剂。浏览器一开始通常会信任它看到的标记，然后毫无疑问地执行它。除非该功能被用于不愉快的目的，否则一切都很好，花花公子... 当然，攻击者最终找到了利用这种趋势来实现其邪恶目的的方法。
跨站点脚本利用浏览器的信任和用户的无知来窃取数据、接管帐户和破坏网站；这是一个很快就会变得非常丑陋的漏洞。
让我们来看看 XSS 是如何工作的，可以造成什么伤害以及如何防止：
XSS 是如何工作的？
当不受信任的输入（通常是数据）在页面上呈现为输出但被误解为可执行代码时，就会出现 XSS。攻击者可以在输入参数中放置恶意可执行代码（HTML 标签、JavaScript 等），当返回到浏览器时，该输入参数会被执行而不是显示为数据。
如上所述，该漏洞是由于浏览器的核心功能行为而出现的，在这种行为中，很难区分数据和可执行代码。网络的运营模式如下：
- 用户访问网页
- 该页面告诉浏览器要加载哪些文件以及要执行什么
- 浏览器执行页面上的内容，不问任何问题
此功能带来了我们在网络上享受的一些最棒的互动体验。硬币的另一面是，它还导致了代价高昂的漏洞利用和漏洞。
当攻击者将其恶意脚本添加到易受攻击的站点时，毫无疑问会执行该脚本。没有更深入的调查，也没有侦查措施。
XSS 有三种类型：
- 存储的 XSS
- 反射式 XSS
- DOM XSS
存储的 XSS 当攻击者可以将恶意脚本持续存储在应用程序的数据字段（例如存储用户手机号码的字段中）时，就会发生这种情况。然后，每次在应用程序中显示该数据字段时，都会将这个粗略的脚本发送到用户的浏览器。
这种攻击通常出现在论坛网站或评论引擎上。攻击者在评论中输入恶意脚本，bam-每个查看该评论的用户都会在不知不觉中执行该脚本。
反射式 XSS 当用户输入按原样反射回用户浏览器时发生。例如，搜索框在获取搜索结果时向用户显示 “您搜索了...”。
现在，假设搜索是通过将搜索词作为查询参数放在 URL 中来实现的。恶意攻击者可以向受害者发送嵌入在这些完全相同的参数中的恶意脚本的链接，说实话，大多数网络用户几乎不会注意到它。
受害者点击链接并被重定向到钓鱼网站，在那里他/她不知不觉地输入了该网站的密码。他们几乎没有意识到，攻击者刚刚窃取了他们账户的密钥。
DOM XSS 是该漏洞的相对较新的变种。它利用了许多用户界面框架（例如Angular和React）中的复杂模板结构。
这些模板允许动态内容和丰富的 UI 应用程序。如果使用不当，它们可用于执行 XSS 攻击。
所以，你明白了。简而言之，你已经知道了 XSS 的范围。让我们更深入地研究如何破坏性地使用它。
为什么 XSS 这么危险？
XSS 可用于将用户重定向到恶意站点、窃取 Cookie 和搜寻会话数据。基本上，无论JavaScript能做什么，XSS攻击也是有能力的。
以下是三个 XSS 攻击示例：
- 雅虎电子邮件用户 他们的会话 cookie 被偷走了 2015 年使用 XSS。
- 这个 萨米蠕虫 是通过 MySpace 中的 XSS 漏洞分发的。它仍然是有史以来传播最快的恶意软件，在短短20小时内影响了100万用户。
- eBay 允许在产品描述中包含恶意脚本。这导致 XSS 攻击 针对 eBay 用户。
XSS 攻击看似简单而且非常严重。它们可能导致会话、用户凭证或敏感数据被盗。声誉损害和收入减少是这些攻击的主要陷阱。即使只是破坏网站也可能给企业带来不良后果。
但是，XSS 可以像你一样被精明的安全战士击败。修复并不复杂，自从XSS成为常用漏洞以来，该行业已经走了很长一段路。
你可以击败 XSS。
击败 XSS 的关键是了解背景。具体而言，您的用户输入将在其中呈现回客户端以及在何处呈现回客户端的上下文。在 HTML 代码中或 JavaScript 片段中。
如果不必将用户输入发送回浏览器，那就更好了。但是，如果是，则通常应采用HTML编码。对输出进行 HTML 编码将告诉浏览器按原样呈现内容，而不是执行内容。
输入验证也很重要。但是，验证和白名单 不是 万无一失的解决方案。编码更进一步，可以阻止浏览器执行恶意脚本。无论验证和白名单策略中没有发现什么，编码都会起作用。
现在，许多框架都在自动对 HTML 输出进行编码。
角度的， ASP.NET MVC，以及 React.js 是使用默认 HTML 编码的框架。你必须明确告诉这些框架不要通过调用特殊方法进行编码。
大多数其他框架，（即 詹戈 和 春天) 有用于防止 XSS 的标准库，您可以轻松地将其整合到代码中。
最大的挑战是自学分析用户输入进入系统的所有方式，这样你就可以全神贯注。查询参数可以进行攻击，发布参数也可以进行攻击。关注整个应用程序中的数据流，不要信任来自外部的任何数据。
像边境巡逻一样思考。停止每条数据，对其进行检查，如果数据看起来很恶意，则不要允许其进入。然后在渲染时进行编码，确保遗漏的任何不良内容仍然不会造成问题。
执行这些策略，您的用户将免受通过 XSS 的攻击。看一看 OWASP 备忘单 获取更多控制数据的小贴士。
阻止 XSS 并提升您的安全技能。
XSS在OWASP 2017年十大网络安全风险清单中排名第七。它已经存在了一段时间，但如果你不小心，它仍然会出现并导致你的应用程序出现问题。
培训对于开发人员在编写代码时建立安全第一思维非常重要。而且，当使用开发人员正在使用的语言模拟真实应用程序时，这种训练始终是最有效的。考虑到这一点，为什么不看看我们的 学习资源 想了解有关 XSS 的更多信息？之后，你可以开始训练和练习，从而掌握自己的技能。
认为你现在准备好发现和修复 XSS 漏洞了吗？ 挑战自我 在 Secure Code Warrior 平台上。
%20(1).avif)
.avif)
