0

I'm penetration testing a website right now (they have a policy and a system for it), and I noticed that the search feature filters brackets.

After some messing around, I also noticed if you search this: <%20> it returns to the home url (example.com/home).

However, if you use this specific combination of characters: <&#anynumberorletterhere it will return the text after the ampersand in that home url. For example, if you search <&#hi it will go to the homepage with the url example.com/home#hi. It also returns special characters, such as !@#$%^&*() completely unfiltered.

I'm sorry if this isn't enough detail, but I don't want to expose any information leading to what website it is in particular. If you need more info, please just ask below.

Essentially I'm wondering if there's any reason to report this. Also, if you have a payload you would like me to test, I'd be happy to do so and tell you the results.

  • Whether or not it is possible to exploit is up to the backend. You have not shown anything that would indicate that there is a vulnerability. – schroeder Dec 31 '17 at 16:47
  • An oddness like this may point to weak code, even if it doesn't let you get past filtering – jrtapsell Jan 1 '18 at 19:48
  • You have discovered hash fragments. Anything following a # in a URL won't be passed to the server in most cases, but will be available to the browser. This was originally used to jump to specific parts of a page, but is often used by single page apps now. See: security.stackexchange.com/questions/176401/… (look at the address bar after clicking) – Matthew Jan 2 '18 at 17:28
  • @Matthew thanks, i forgot the name but a I knew this information about them. Is there any way to use hash fragments to create a PoC where an attacker could cause damage or socially manipulate someone with them? – Jack Jan 2 '18 at 20:17
1

Based on the information in your original post there is a low likelihood this would lead to something useful in an attack. The hash fragment is not sent to the server.

However, the hash fragment can be used to direct to a named anchor or may be read by client side code. This is very common in single page application by using [location.hash][3] call. So it might be possible to exploit this with DOM-based / client side XSS. For example: maybe there is some logic based upon the hash or a script makes an AJAX calls based upon the hash.

In your example, when given example.com/home#hi does hi show up anywhere on the page or in the source (is the input reflected back in the page returned)? If so then there may be the possibility of structuring an XSS which will not be filtered.


However, the fact that it is returning the hash an appending it at all could indicate a bug in the backend and you may want to try other odd character fuzzing as you continue your testing. Since you mentioned other special characters are also not being filtered in the expected way this may be enough to get credit through this company's bug bounty depending on their rules.

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.