New answers tagged

0

javascript: is the URI scheme (like http: or https: or ftp: or file:) for immediate-execution javascript. Javascript URIs can be set as the "URL" of a window, both the top-level window or an iframe/popup/etc. They execute in the context of the currently-loaded origin and page, so it's equivalent to injecting a script tag into the page. Outside of ...


0

If the sink is in a renderable or executable context (HTTP headers, HTML, CSS, JS, SVG, etc.), then yes, an unsanitized and unrestricted flow is always dangerous. Not all of them will directly lead to script execution - it's not possible to have scripts in (modern) CSS, and they're ignored in SVGs that are rendered inside img tags - but they still allow a ...


1

At the time of this writing: Not only did browser filtering fail to stop XSS, but XSS killed browser filtering! The XSS Auditor (controlled by the X-XSS-PROTECTION header) in all its forms is officially dead. In general, it died because it's goals were simply not realistic. Protecting against even just reflected XSS from the browser-level is just not as ...


1

Intrusion Prevention System is a broad term. It basically says only that it is a system to prevent intrusions and does not imply a specific technical implementations. Therefore a variety of systems which somehow had the goal to prevent intrusion, were marketed as IPS when the term was hot. Therefore a generic statement about the capabilities of IPS to solve ...


1

That looks like a real XSS vulnerability, and I do think you should report it. To get around the problems with the quotes, simply pass a number instead of a string to the alert function, e.g. alert(1). That way, you don't need the quotes but you can still demonstrate that JS is executed. That should be enough to prove that the vulnerability is real. If you ...


0

A XSS has only read-access to the cookies on the specific page and only to cookies which are not set httponly. Thus only these cookies can be stolen. But a XSS can do more than just steal cookies: it can use the page as a base to send requests to other sites. In this case the browser might automatically send the cookies from the target site to the target ...


2

Is it safe to allow passing the [script URL] as a URL query param? No, this is very dangerous. See question #3. If this code is an issue, what are the specific attacks that could happen here? Since an attacker could pass any script into the URL, and have it run in your sites origin, you are basically opening yourself up to XSS attacks. That is very bad. ...


1

This is my own code, and I trust it as far as not having malicious code in it. This is just an assumption. As long as this assumption is not enforced it can not be relied on. The current proposal allows to load script from arbitrary URL into your page, i.e. completely out of your control. This allows for an XSS attack. To secure this you need to make sure ...


Top 50 recent answers are included