I have a website that has a search function that uses the GET method. It returns in the url that "www.xxx.com/query?=something"

Would like to seek opinions on why such a function is not worth exploiting or exploring even though there is a parameter there in the URL that can be changed

  • Why do you think it's not worth exploring?
    – nobody
    Aug 2, 2021 at 8:23

2 Answers 2


It's definitely worth testing. At a minimum, it might be a reflected XSS vector, though since it's kind of the most obvious such vector possible anybody with any awareness of XSS will handle that. It might be a SQLi vector, although again, obvious.

One way it might be interesting is for a cross-site search attack. If different users on the site have access to different resources, and especially if the search can filter very tightly, an attacker with a man-in-the-middle position can learn a lot about what another user can access by having their browser submit search queries the attacker chooses. The attacker can't see the responses directly (assuming HTTPS), but can see the approximate length of the responses (and get get a baseline from their own search). The attacker can then vary the query string and make the victim's browser submit the request to see what things the victim can search for. This could be used to reveal information about the victim's data (e.g. if a search for a person's name gets a response length consistent with items being found, congrats, you know the victim has some searchable info about that person).

You can even brute-force strings you care about one character at a time. For example, suppose the site stores documents containing the user's social security number. You can search SSN: and see if there's a match. Then you can start adding a digit at a time to the search, trying each value in sequence until you find the match again (e.g. if SSN: 0 through SSN: 6 return no matches, but SSN: 7 returns one, congrats, you know the first digit; repeat for the second digit and so on). That doesn't necessarily work, of course (it depends on how the search is implemented, and a lot of search tools don't handle portions of "words") but it'll work with some sites. Alternatively, if you have the last four digits from somewhere else, you could try searching for the entire string by attempting to brute-force the first five; that'll only take at max 100,000 requests.

To protect against cross-site search, the site can use CSRF protection on the search endpoint, or can pad the length of the response so it's always the same, or otherwise mask the actual search response length.

  • If SSN: 9 matches there is either a bug or fraud because no valid SSN has been or ever will be assigned beginning with 9. (Originally the area in the first 3 digits was assigned upwards from 001 and they only reached 772; after randomization in 2011 they started using 'areas' up to 899. Almost half the 9xx range is used by IRS for ITINs, which must be disjoint from SSNs to avoid throwing the tax system into chaos -- okay, further into chaos -- and reclaiming the other half probably isn't worth it.) Aug 3, 2021 at 1:42
  • @dave_thompson_085 Huh, TIL. Edited the example.
    – CBHacking
    Aug 3, 2021 at 4:35

You can't say it's not worth testing/exploiting right away, it all depends on how your search works. There is actually a very little chance of it not being worth testing.. If it works in any way with the database then it's a 100% reason to test it (SQLi). If it leaves any form of residue in the system, test it (XSS). If it's not properly written, possibly DoS or who knows. And this only accounts for some of the issues that are directly connected with the search, there are other issues that might be connected with handling the request itself.

Frankly if there is a user input of any sort, tinfoil hat or not, there is a possible attack vector worth checking out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.