翻译进度
4
分块数量
3
参与人数

XSS 入门:跨站点脚本攻击

呀呀呀-看我40m大刀! 2021-02-20
英文原文 Web安全 发布于 2021-02-20 19:05:38 阅读 1941 评论 0

这是一篇协同翻译的文章,你可以点击『我来翻译』按钮来参与翻译。


几个严重的漏洞——CSRF, SSRF, RCE。大多数情况下,XSS漏洞是导致漏洞被利用并升级到严重问题的原因。
首先介绍一下本文的结构:我们将从学习XSS的基础知识开始,然后:您应该了解的东西——浏览器和网站的功能,接下来:XSS的类型-了解XSS的危害,最后:XSS的漏洞挖掘。

专栏

XSS是什么?

我知道你知道的。 但是你知道你不知道什么吗? XSS是跨站点脚本攻击,对于安全测试人员来说是非常基本的攻击。 但仍然,重新读取(或跳过)没有危害。 请记住——学习,未习得并重新学习。 所以,来吧。
跨站点脚本(XSS)攻击是一种注入形式,其中恶意脚本被注入否则会成为良性和可信赖的网站。 当攻击者使用Web应用程序将恶意代码(通常以浏览器端脚本的形式)发送给不同的最终用户时,就会发生XSS攻击。使这些攻击成功的缺陷非常普遍,并且会在任何地方发生。 网络应用程序使用用户的输入,在生成的输出中无需验证或编码,即OWASP。
XSS在OWASP Top 10 **(2017)A7:2017-跨站点脚本(XSS)中排名第七。 这并不是说XSS现在并不常见,而是其他漏洞更严重而被优先考虑了。
此外,自动化工具可以自动发现一些XSS问题,尤其是在诸如PHP,J2EE / JSP和ASP.NET之类的成熟技术中。——进入白盒/灰盒测试。

简而言之:如果您可以控制典型网站运行的JavaScript。 然后,就有可能使用XSS。

专栏

呀呀呀-看我40m大刀! 翻译于 1年前

浏览器和网站是如何运行的?

在深入研究之前,重要的是要把基础知识搞清楚。

我们知道,世界是在一些基本规则和原则的基础上运行的,以使我们免受灾难。以类似的方式,互联网也是如此,浏览器和网站也是如此。

浏览器和网站在某些规则的基础上共存。下面提到的一些规则,是你应该知道的,以便清楚地了解一个缺陷的安全影响。

1. 同源政策--SOP

同源策略是一个重要的安全机制,它限制了从一个来源加载的文件或脚本如何与另一个来源的资源互动。它有助于隔离潜在的恶意文件,减少可能的攻击载体 - Mozilla。

用简单的话说就是:服务器为浏览器定义了规则,网站1可以与网站2互动。

2.跨域资源共享-CORS

CORS是一种基于HTTP头的机制,它允许服务器指示浏览器应允许从其自身加载资源的任何其他来源(域、scheme或端口) - Mozilla。

用简单的话说就是:CORS是服务器发送的HTTP头,用来说明浏览器有哪些站点在其友好列表/允许列表中(白名单)。

3. 跨站请求伪造令牌-CSRF令牌

为防止跨域写入,在请求中添加了一个不可猜测的令牌--被称为跨站请求伪造(CSRF)令牌。你你必须防止对需要CSRF令牌的页面进行跨源读取 - Mozilla.

用简单的话说就是: CSRF令牌是--一次性使用的、不可预测的(随机的)和长的(至少16字节/128位)令牌(值/密钥),由服务器生成(不受用户控制)--交给浏览器执行单一任务。

4. HTTP Cookie

HTTP cookie(网络cookie,浏览器cookie)是服务器发送给用户的网络浏览器的一小段数据。浏览器可以存储它,并在以后向同一服务器提出请求时将其发送回来。通常情况下,它被用来判断两个请求是否来自同一个浏览器--例如,保持用户的登录状态。它为无状态的HTTP协议记住了有状态的信息 - Mozilla。

用简单的话说就是: 一般来说,Cookie是你的证书(用户名和密码)的替代品,由服务器来回发送给浏览器,以提醒他一个特定的会话(HTTP--无状态协议,在每次请求后都会忘记你是谁和你想从他那里得到什么),并保持所进行的活动的跟踪。

5. HTTPOnly -Set-Cookie

HttpOnly是一个包含在Set-Cookie HTTP响应头中的附加flag。在生成cookie时使用HttpOnly flag有助于减轻客户端脚本访问受保护cookie的风险。 此属性指定一个cookie不能通过脚本访问。通过使用HTTP-only cookie,客户端上设置了一个带有HTTP响应头的Cookie,网站消除了cookie中包含的敏感信息可以通过脚本发送到黑客的计算机或网站上的可能性。

用简单的话说:HTTPOnly属性指定一个cookie不能通过脚本访问,而只能通过HTTP头访问。

注意: 使用上述单个技术是不够的,但是,如果一起使用,可以减轻跨网站脚本的风险。单独使用,它们不能完全消除跨站脚本的危险。

还有一些其他的规则被浏览器用来进行安全的通信。但是,我们在这里限制了XSS的规则范围。

现在,我们知道了什么是XSS,以及浏览器和网站如何在某些规则的基础上运作。让我们进一步了解XSS的类型和重要的XSS'在Bug Hunting。

专栏

梦幻的彼岸 翻译于 1年前

Types of XSS (generally):

  1. Reflective XSS- your payload impacting you/logged-in user, *
  2. Stored XSS- your payload-impacting other users’ *
  3. DOM XSS- vulnerable document-object model*
  4. Blind XSS- tricky to get the result of your injected payload*
  5. Self XSS -out of scope in bug hunting(or low impact/informational)
  6. Flash-based XSS -obsolete(flash is simply dead)

*(important in bug hunting — as can have severe impacts- CSRF, SSRF, RCE.)

XSS in Bug Hunting:

We will be discussing the below XSS types, that are relevant from a Bug Hunting perspective:

  1. Reflective XSS
  2. Stored XSS
  3. DOM XSS
  4. Blind XSS

1. Reflected XSS Attacks

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable website, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

Reflected XSS Attacks often require social engineering tricks to deliver the impact.

2. Stored XSS

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Classic Example for a Stored XSS:

Samy (computer worm), that was designed to propagate across the social networking site MySpace by Samy Kamkar. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload making Samy the fastest-spreading virus of all time.

专栏

The message on a victim’s profile

The worm itself was relatively harmless; it carried a payload that would display the string “but most of all, samy is my hero” on a victim’s MySpace profile page as well as send Samy a friend request. When a user viewed that profile page, the payload would then be replicated and planted on their own profile page continuing the distribution of the worm. MySpace has since secured its site against the vulnerability. Read More.

3. DOM XSS

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script. So that the client-side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client-side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed on the response page (due to a server-side flaw).

When looking for a DOM-Based XSS, keep an on DOM Objects like:

  1. Source
  2. Sink

Check if your input/payload can control the output.

Source — where your input goes to.

document.url document.documentURI document.URLUnencoded document.baseURI document.referrer location location.href loaction.search location.hash location.pathname window.cookie window.referrer window.name

Sink — where your input is reflected back.

element.innerHTML() element.outerHTML() eval() setTimeout() setInterval() documemt.write() document.writeln()

4. Blind XSS

Blind XSS vulnerabilities belong to persistent XSS vulnerabilities. These vulnerabilities arise when the attacker's injected payload is preserved by the web server and executed as a malicious script in another component of the application or in a totally different application.

For Example:

An attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application Here, it could be an internal application where the administrator reviews the access logs or the application exceptions.

专栏

Also, the above XSS kinds could be further categorized into two:

  1. Server XSS
  2. Client XSS

Server XSS

Server XSS occurs when untrusted user-supplied data is included in an HTTP response generated by the server. The source of this data could be from the request, or from a stored location. As such, you can have both Reflected Server XSS and Stored Server XSS.

In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the response and executing any valid script embedded in it.

Client XSS

Client XSS occurs when untrusted user-supplied data is used to update the DOM with an unsafe JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. This source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load). The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.

DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the Server.

专栏

CheatSheets:

Now that, we have covered the Basics of XSS. We are ready to escalate the attack. Refer to the below cheat-sheets that could help to bypass common WAFs & Filters.

本文章首发在 网安wangan.com 网站上。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://link.wangan.com/check?link=https...

译文地址:https://www.wangan.com/t/3231

参与译者:3
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!
请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!