几个严重的漏洞——CSRF, SSRF, RCE。大多数情况下，XSS漏洞是导致漏洞被利用并升级到严重问题的原因。
我知道你知道的。 但是你知道你不知道什么吗？ XSS是跨站点脚本攻击，对于安全测试人员来说是非常基本的攻击。 但仍然，重新读取（或跳过）没有危害。 请记住——学习，未习得并重新学习。 所以，来吧。
跨站点脚本（XSS）攻击是一种注入形式，其中恶意脚本被注入否则会成为良性和可信赖的网站。 当攻击者使用Web应用程序将恶意代码（通常以浏览器端脚本的形式）发送给不同的最终用户时，就会发生XSS攻击。使这些攻击成功的缺陷非常普遍，并且会在任何地方发生。 网络应用程序使用用户的输入，在生成的输出中无需验证或编码，即OWASP。
XSS在OWASP Top 10 **（2017）A7：2017-跨站点脚本（XSS）中排名第七。 这并不是说XSS现在并不常见，而是其他漏洞更严重而被优先考虑了。
此外，自动化工具可以自动发现一些XSS问题，尤其是在诸如PHP，J2EE / JSP和ASP.NET之类的成熟技术中。——进入白盒/灰盒测试。
How a browser & website function?
Before diving in deep, it's important to get the basics right.
We know the world runs on some basic rules & principles, to save us from havoc. In a similar manner, the Internet does, & so, the browser and websites do.
Browser & Websites co-exist together on the basis of certain rules. Some rules, mentioned-below, that you should know of, to have a clear understanding of the security impact of a flaw:
1. Same-Origin Policy- SOP
The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors — Mozilla.
In Simple Words: The server defines the rules for a browser, in which Website1 can interact with a Website2.
2. Cross-Origin Resource Sharing- CORS
CORS is an HTTP-header based mechanism that allows a server to indicate any other origins (domain, scheme, or port) than its own from which a browser should permit loading of resources — Mozilla.
In Simple Words: CORSis the HTTP header, that server sends, to state a browser, which sites are in its friends list/allow list.
3. Cross-Site Request Forgery tokens- CSRF tokens
To prevent cross-origin writes, an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token is added. You must prevent cross-origin reads of pages that require CSRF token — Mozilla.
In Simple Words: CSRF Tokens are- a one-time use, non-predictable(random) and long (at least- 16 bytes /128 bits) token(value/key), generated by the server (not in control of the user) — given to a browser to perform a single task.
4. HTTP Cookie
An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with later requests to the same server. Typically, it’s used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol — Mozilla.
In Simple Words: Cookie is, generally, a replacement of your credentials (Username & Password) that a server sends back and forth to the browser to remind him of a particular session(HTTP-a Stateless protocol, that forgets who you are & what you want from him, after every request) and keep a track of the activities performed.
5. HTTPOnly -Set-Cookie
HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client-side script accessing the protected cookie. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can be sent to a hacker’s computer or Web site with the script. A cookie is set on the client with an HTTP response header.
In Simple Words: HTTPOnly attribute specifies that a cookie is not accessible through script, but only by an HTTP header.
Note: The use of the above individual technique is not enough, but, when used together, can mitigate the risk of cross-site scripting. Used alone, they cannot completely eliminate the danger of cross-site scripting.
There are several other rules that are used by a browser for safe-secure communication. But, here we are limiting the scope of the rules for an XSS.
Now, that we know what an XSS is and How a browser & website function, on the basis of certain rules. Let’s move further to types of XSS and important XSSs’ in Bug Hunting.
Types of XSS (generally):
- Reflective XSS- your payload impacting you/logged-in user, *
- Stored XSS- your payload-impacting other users’ *
- DOM XSS- vulnerable document-object model*
- Blind XSS- tricky to get the result of your injected payload*
- Self XSS -out of scope in bug hunting(or low impact/informational)
- 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:
- Reflective XSS
- Stored XSS
- DOM XSS
- 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:
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.
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:
- Server XSS
- Client 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.
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.
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.
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。