New answers tagged xss
No, otherwise anyone could make a website with an XSS vulnerability, get the victim to visit it and then they would be able to steal all the user's session cookies. Also, XSS isn't anything about tabs.
In google chrome each tab is a separate process, isolating access from other tabs, so traditional cookies are not accessible to a JS script. As for apps and speaking only about google chrome, I believe this is possible but have not tested it myself, but in this case when you install the app, you are giving permissions to read cookies.
Depends on how well the browser has implemented tab separation and cross-site origin policy. In modern browsers, no, you won't be able to do that. It would be possible to write a non-standard conforming browser that would allow you to access third party cookies, but at that point, the attacker can do much more interesting things, so being able to steal ...
How about </script><script>alert('xss');</script><script>/* ? JS parser will find the close script, and assume the original code is malformed. HTML parser will see the open script and start a new script block. The rest is just to make the rest of the block ignored. Note that it doesn't contain any of the characters you're ...
I usually do a Google image search for an amusing image, save this to my own HTTPS server and then create an <img /> tag using the XSS vulnerability. With a bit of imagination, this can demonstrate the vulnerability in a humorous way. Also check out the http://www.xss-payloads.com/ site for other interesting payloads.
For demonstration purposes, you could do a document.location redirect to a different website. A fun one would be to inject the Harlem Shake js that makes everything on the page dance.
<img src="test.com/index.php?something=document.location/> If put somewhere non-persistant.
For testing purposes, I think the most useful one is a HTTP request. This allows your server to log URLs which successfully reflected the XSS. (new Image()).src = "https://localhost/log_xss?from=" + window.location; You can also wrap it in a userscript: // ==UserScript== // @match <all_urls> // @run-at document-start // ==/UserScript== ...
You can try console.log('XSS').
With DOM-Manipulation one could change the page itself. In case one knows the target page, it can be manipulated in some nice ways. An easy example would be: document.body.innerHTML = 'XSS';
The blog post from Paul Moore holds back quite a lot of information, probably on purpose, seeing that asda hadn't fixed the issue when he published the post. Here is an article that is a bit more explicit about the vulnerabilities of Asda. CSRF Vulnerability First of, they did not seem to have any CSRF protection: There is no XSRF protection ...
Assuming stored XSS were possible, the stored XSS could use the echo endpoint to present a phishing version of the site (since further XSS resource loading through the echo would be permitted and trusted due to the same origin it was coming from).
It's definitely not a good idea to put raw user input directly into styles. Is CSS injection as bad as XSS? No, but there are still problems with it. Some of these examples below don't apply to you as quotes are required, but I'll include them anyways for readers interested in CSS injection in general, and to show that CSS is more powerful than generally ...
It may be enough, and it may not be, but it is definitely not a good idea. Can a hacker still get away with a XSS? Possibly, depending on the situation. @BenoitEsnard already described one situation where filtering out < and > is not enough: When the user input is echoed inside attributes of existing HTML tags, because then an attacker could ...
Replacing < and > characters isn't enough in all cases. Sure, it will prevent any user to open a HTML tag, but that won't prevent him/her to inject HTML attributes in a HTML tag. For example, let's take a parser which transforms [img=XXX] into <img src="XXX" />, only replacing < and >. A malicious user could enter [img=X" ...
XSS is still possible even in newer versions. But it depends how the JSON is used. The article you reference cares only about executing JSON by itself, i.e. accessing a JSON document via a link. It does not discuss the case when you return JSON from an XHR request and then include the received data directly with document.write or even interpret it with ...
If the content is being specifically served with Content-type: application/json then I believe there is not currently a known way to execute script within the response. As you mentioned, it may be possible to manipulate the behavior of older content inspecting browsers based on the payload, unless the the content is being specifically served with ...
No, if you can't change the part before the colon, you are guaranteed to always produce a HTTP URL, no matter what you append. This follows the Uniform Resource Identifier (URI): Generic Syntax RFC 3986. Each URI begins with a scheme name [...]. The syntax of the scheme part is specified as follows: URI = scheme ":" hier-part [ "?" query ] [ "#" ...
Top 50 recent answers are included