Is there any chrome:// url that allows script injection?
And be one of the many on their glory list? I assume people are getting paid for this.
I found you can run straight system commands through chrome:// urls
What system commands can one run specifically through an internal chrome page? date, cal, rm? This statement does contradict with the ...
XSS generally impacts integrity and confidentiality (an attacker can read and modify data they shouldn't).
If you only have static pages with no authentication and/or user-specific content, then confidentiality may not be as important (an attacker may eg still be able to log which specific pages a victim user views, which depending on the nature of the ...
It sounds like you are asking how to tamper with form submissions that are sent in the body via POST, not as part of the URL as with GET.
The way to do this is with a man-in-the-middle proxy such as Burp or ZAP. They will allow you to intercept, read, and modify requests being sent from the browser to the server. As an example, if there are client-side ...
We will be deprecating that passive scan rule shortly.
Here's the issue: https://github.com/zaproxy/zaproxy/issues/5849
Here are the related PRs:
You should really have CSP in place, as for whether or not it matters for those files it depends if they exist, ...
In theory, sitemap.xml could be an issue. There are lots of nasty tricks you can do with xml. In reality, it would be a very, very difficult attack to pull off (especially given the likely scenario that this is a static file).
The very first usage of XSS I thought of was in this very situation. Suppose the attacker wants to read all the private information stored in the user's account. The attacker crafts a phishing email that looks legitimate and even links to the real site, but the URL includes a concealed script that when it loads, screen-scrapes the webpage and sends all the ...
What if a user leaves their account logged in? Normally the attacker would only have a short window of time to exploit this but if there is an XSS vulnerability, they can leave a malicious script which might just give them permanent control of the account, even after password changes.
The script does not even have to be ready at the time. An attacker can ...
I was wondering if antivirus software can detect when a PC get's hooked to BeEF
A few years ago there was an open source browser plugin "Vegan" released that showed some examples of how BeEF could ...
I was wondering if antivirus software can detect when a PC get's
hooked to BeEF.
Can an antivirus detect that?
tl/dr: Yes! Defense in depth is critical, so any XSS vulnerability is
a vulnerability that needs to be fixed, regardless of whether or not a
method of exploit is immediately obvious.
The Underlying Question
Whether intentional or not, there is a question behind your question that is much more important to answer. In essence what you are really asking ...
What you describe prevents only Stored XSS. But reflected XSS is still possible if cross-site requests are allowed by the server and the authentication status is transported between requests using a session cookie - both things are usually the case. And DOM XSS is even possible without cross-site requests and cookie based
authentication since the request is ...
how does the 'Same origin policy' prevent XSS attacks
The SOP works when there is no XSS vulnerability.
It ensures that evil.com cannot read data with your authentication from eg facebook.com. This holds true as long as facebook.com doesn't introduce it's own vulnerability which allows bypassing of the SOP.
And that is where XSS comes into ...
It's not enough. One possible bypass:
This works because of the extra space after textarea.
You could adapt your filter to catch this as well. But I wouldn't recommend it because the approach is already flawed.
If you do not need to allow a user-supplied subset of HTML to be rendered (which isn't ...
An XSS attack here means that the attacker somehow must be able to compromise the HTML in the Ajax result. Assuming that the connection itself can be trusted (i.e. HTTPS) there are basically two options: sanitize the HTML in the client and/or make sure that there is no XSS in it in the first place in the server.
The latter option is preferred if you have ...
First of all, I assume that you are the owner of the website disclosing the phpinfo, and you ask this for academic purposes.
To achieve what you said, I would do the following :
Create an invisible iframe (0px x 0px)
Store cookies in var x by parsing the iframe content through contentDocument getter/setter
Create an invisible <img/> (0px x 0px) with ...