20

Reflected XSS is not only by GET. It can be by POST too. And they are not prevented always by the browsers. And of course, is still relevant. A couple of definitions: https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting https://www.acunetix.com/websitesecurity/xss/ And from Checkmarx knowledge base, it says: "The most commonly found XSS". ...


16

Yes, all forms of XSS are still relevant today. The particular attack that you tried was obvious for the browser to heuristically find, but the code generated by more subtle injections might not be. What if I change the submission URL of a form because the developer used <form action="{$_SERVER['PHP_SELF']}"? What if I change your error message to a ...


13

You can force the user interaction with CSS, by making the a element an fixed positioned block element with a large size and z-index. <a style="display: block; position: fixed; top: 0; left: 0; z-index: 99999; width: 9999px; height: 9999px;" onmouseover="alert('xss')">


11

Yes, this code is vulnerable, but not to XSS. The subdomain variable's value can indeed be controlled by an attacker, but that variable is only used to set the href parameter of a CSS stylesheet; which won't accept JavaScript code. However, controlling this value does still allow CSS injection. The stylesheet's href is prefixed by /, but an attacker can ...


11

These automated checks work by putting a script tag containing a random token into every field. For example, /someRequest?foo=x&bar=y might become: GET /someRequest?foo=<script>alert("147230578")</script>&bar=<script>alert("561972456")</script> It maintains a map of fields and the random values it chose (in this case foo=...


10

If you're really just trying to help out for the greater good, you can send a message anonymously using something like Guerrilla Mail over Tor. Believe there's also a Tor hidden service for/like this, but I'm at work right now and can't check to see if it still works.


8

In this specific case, if I replace \ with \\ and " with \" is it possible to trick my filter? That's not sufficient, your filter is insecure. E.g., one valid XSS attack vector would be </script><svg onload=alert(1)>, ending up with: <script> var test = {src: "test", layer: {"input": "</script><svg onload=alert(1)>", "event": ...


7

The security measures you are thinking of already exist. Take a look at this example from jQuery's CDN page: <script src="http://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script> The notable part is the integrity="sha256-...", which a browser should check ...


7

I think the Mozilla link you provide has enough in it to answer your question (quotes taken out of order from the thread so I can tell a better story): Firefox could do better using a (probably more expensive) algorithm such as the one described here (http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf). Interposing on script execution instead of HTTP ...


6

You can not craft a link that contains a POST body. So you will have to go a somewhat different route. You will need to create your own page that contains the payload: <form action="http://target.com" method="post" onload="this.submit()"> <input type="hidden" value="payload" name="fieldname"> </form> Or you can achieve the same effect ...


6

Yes, that's possible. The onfocus and autofocus trick does not work in tag (correct me if I'm wrong). Correct, the autofocus attribute doesn't exist for <a> tags. But instead, you can take advantage of anchor names to still achieve the autofocus effect. E.g., create a document with this link: <a href="#" onfocus="alert('Gimme bounty!')" name="...


5

Reflected XSS is still relevant because not every browser implements the same filters in the same way, some times a bypass is discovered for some implementations, therefore the auditor may not block it. Some sites don't have the X-XSS-Protection header enabled, so those sites are vulnerable too And, as said in other answer, the payload may be delivered ...


5

Any ideas if this code is vulnerable and how can it be exploited? As mentioned in the comments, this code could be vulnerable to CSS injection. For example, if the URL looks like: http://some.company.com/p1=test&css=/evil.com/more_evil Then this javascript will create a new link in the header like: link rel="stylesheet" href="//evil.com/more_evil....


5

This is very common for automated scanning tools. They can only be so smart, and so false positives can always happen (as can false-negatives for that matter). As a result any flagged vulnerability should be manually verified. This is why, for instance, bug bounty programs always have notices like "Results from automated scanners will not be considered" - ...


4

If you can't verify the result of an automated tool, it is not a good idea to report it's findings. Automated tools are great, but they have a problem with false positives.


4

If you view how your code is actually delivered by the server (for example by using the "view frame source" context menu in Chrome for the white frame in jsfiddle) you can see that it is embedded in some other code like this: <body> <svg/onload=alert(1) <script> This essentially means that the full HTML element seen by the browser is ...


4

Yes, this does look like a false positive. Obviously you should double check with manual testing, as you are doing. Can you confirm that this is the only place on the page where the payload is reflected? I've raised this ZAP bug: https://github.com/zaproxy/zaproxy/issues/5958


3

The general advice (to inject an event handler in the image tag) from @MarkBuffalo in the comment is correct, but onload isn't a great choice of event handler for images. The better option is usually onerror, which is very easy to reliably trigger; just set the source to be something you know won't exist (or at least won't be an image), like src="qq" onerror=...


3

Assuming the situation is: A webpage directly insert part of the URI inside its HTML content and the restriction is: Webpage returns a static error if that URI part contains <[a-zA-Z0-9] Then you could have XSS exploit in these case: Code is inserted inside a <script> tag in the page, inside a <style> tag, inside some HTML attributes ...


3

Came across similar scenario today. Upon debugging I found that vulnerable web page was reflecting exact URL path onto the web page which was making it vulnerable to reflected XSS. Modern web browsers do encode URL path every time and the GET variable does get decoded on the server. But in this case, the server side script isn't reflecting any specific GET ...


3

The answer is no... at least not how you're thinking of it working. XSS attacks actually happen on the client's browser. You could use an XSS to attack the site administrator. I mean, theoretically, the answer is yes, but not as you likely envision it happening. There are a lot of IFs involved, but only if you could store a XSS attack on that web ...


3

My question is if the Content-Type header in the response has an impact on the exploitability of XSS and possibly other vulnerabilities? Yes, the content type makes a difference. XSS only applies to documents that are capable of running active (script) content in the first place. A page with the MIME type application/json can't contain active content. To ...


3

After your injection, the resulting code should look like this: <input type="hidden" accesskey="X" onclick="alert(1)"> For the payload to be executed, the user needs to press the access key combination for the hidden input field (for Firefox, Alt+Shift+X, see this for other browsers). If you want to make sure you are fireing the access key, you can ...


3

It seems unlikely that all of these companies are properly sanitizing characters and after doing some research I think this could happening because of XSS auditors in Chrome/Firefox? Chrome's XSS auditor does not actually render the payload harmless, it throws a warning preventing the user from accessing the page. If you check the source code when you get ...


3

Unescaped backslashes can be dangerous, depending on the context. Let's assume that X and Y are user-controlled (with ' and < escaped, but not \). Then, this is exploitable: <script> var name = "X"; var id = "Y"; </script> An attacker can set X to \ to escape the first string's closing quote ("), and set Y to ;alert()// to inject the ...


3

There are a couple of things I want to establish first before I give you general advice for spotting common characteristics of cross-site scripting (XSS) probing attempts in your logs. I am assuming you will be manually inspecting your logs; Without loss of generality, let's also assume you are able to keep up with the number of entries in your logs. So ...


3

If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete ...


3

The HTTP method does not matter for Cross Site Scripting attacks (XSS). It is even possible to get XSS trough the HTTP TRACE method. Is it possible to have reflective XSS through POST requests? Most definitely!


2

You can not gain reverse shell only by performing XSS attack. But that same attack can be done on the owner/admin of that website or server. Here is an example OWASP XENOTIX XSS EXPLOIT FRAMEWORK V3: XSS Reverse Shell.


Only top voted, non community-wiki answers of a minimum length are eligible