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" - it's easy to run a scanner and report a vulnerability, but security teams probably already do that anyway, so 99% of times it is a waste of time. However that leads to the next question:
Is this particular script handling this input properly?
That's a much trickier question to answer. You've already checked for the most obvious work around (injecting a double quote), but there are more options. The two that come to the top of my head is the mangling of character encoding and testing out backslashes. The former is a bit of a long-shot so I'll just focus on the latter:
- Try injecting a backslash at the end of your input
?search=whatever\
- If the application doesn't escape your backslash the javascript will be:
var search = "whatever\";
- This will break the javascript. If you're lucky it will also let you inject XSS via a second parameter.
The last step could use an example. Imagine the full javascript was something like this:
var a="[search input]";var b="[name input]";
To be clear the code has been minimized to save bandwidth. This will be important. Also, neither escapes backslashes. Therefore you could put together a payload like this:
?search=\&name=;alert(1)//
You'll end up with this javascript:
var a="\";var b=";alert(1)//";
Which is a valid XSS payload. Your backslash escapes the closing double quote for the var a = "
statement and so the starting double quote for the second variable ends up being a closing double quote. As a result your input for the second input ends up executing as plain javascript - you just need to end with a semi colon and then a comment character to get rid of the final closing double quote.
Now you probably won't have any luck getting this to work. If they also handle backslashes properly then you won't have any luck. If these lines are split into separate lines then you also won't have any luck (in most versions of javascript a line continuation character is required, but there are some non-standard browser behaviors here sometimes). However if they forgot to escape backslashes and you can find two inputs on the same line, then you have an easy XSS vulnerability.
Summary
Really though this highlights the main take away, which is why these things are so tricky: the kind of exploit required varies strongly on the context that the data gets injected into, and it is effectively impossible for automated scanners to test everything. Therefore as a penetration tester you have to be familiar with all your options, which is quite tricky! Fortunately though this is also why XSS is so common - programmers are equally bad at understanding all the ways in which they must be careful to protect against XSS vulnerabilities.