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
var search = "whatever\";
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:
var a="\";var b=";alert(1)//";
Which is a valid XSS payload. Your backslash escapes the closing double quote for the
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.