What are the major differences between, Persistent XSS and Non-Persistent XSS?
Asked
Active
Viewed 6,760 times
2 Answers
7
As the naming suggests, the difference between Persistent and Non-Persistent XSS are as follows.
Persistent XSS
Stored XSS, inside of cookies or the server's database.
Example of Persistent XSS in a chat application
If a chat application stores all user messages into a database and a user can send a string of HTML, such as <script>alert('XSS');</script> then that code will be executed every time the user visits the chat application.
Non-Persistent XSS
XSS executed on the client, for example JavaScript executed in the URL or the user is tricked into pasting JavaScript into their console.
Example of Non-Persistent XSS
You can execute javascript:alert('XSS') in the browser, although most modern browsers will not let you copy/paste this into the URL.
You can read more about this here.
Enijar
- 6,387
- 9
- 44
- 73
-
can you give some examples of possible attacks for each – recurf May 25 '16 at 11:32
-
Non-Persistent XSS => in the url parameters (The console is not really an XSS IMHO) – Tom May 25 '16 at 11:33
-
If the XSS was stored in cookies, I would say this was reflected XSS (i.e. non-persistent) because it only affects the current user. Also, your example of non-persistent XSS is confusing. [See here](https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)#Example_1) for a better one. – SilverlightFox May 26 '16 at 08:57
-
@Enijar your examples of "Non-Persistent XSS" are usually called "Self-XSS" (in the console and javascript: in the url). Other "Non-Persistent XSS" are url parameters ( http://victim.host/notfound?
) and cookies – Tom May 26 '16 at 09:00
-
@SilverlightFox A better way of calling them would be Session-Persistent XSS. You can store a payload in local storage and session storage as well. Reflective XSS also means direct execution of payload on payload-placing request, and that's not always the case with a payload in cookie or local storage. – nv1t May 26 '16 at 10:12
-
1@nv1t: Very true. OWASP tried to reclassify them as [Server and Client XSS](http://stackoverflow.com/a/28409421/413180), but I don't think it took off. At the end of the day XSS is XSS and the remediation is the same - as with any security vulnerability the devil is in the detail so it probably doesn't make too much sense on focusing on different types of XSS as long as the problem is understood. – SilverlightFox May 26 '16 at 10:17
4
(Source)
Stored XSS/Persistent 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.
Example:
- Writing an XSS Payload inside a guestbook. The payload gets stored inside the database and executed every time a user visits the guestbook
- Accessing the Site:
http://victim.host/notfound?<img src=0 onerror=Alert(1)>. This get's stored inside a log file on the server and if the logfile get's interpreted as HTML through a Browser, the payload get's executed.
Reflected XSS/ Non-Persistent XSS
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 web site. 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 web site, 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.
Example:
- Directing a user to
http://victim.host/?a=<payload>and this payload gets outputed and executed directly on the website. You can find this behaviour in searches and error pages mostly.
Note: In current browsers, if a JavaScript String is seen in the URL, which gets reflected on the website, it will be blocked. It depends if the whole page gets blocked or just the one script.
-
You may want to add a section about "Self-XSS" (tricking the user to past JS in the console, or "javascript:something" in the url). – Tom May 26 '16 at 09:02