When Input Reflections Attack
Defining the issue
Out of band attacks?
The most common way I have observed OOB attacks exploited for XSS are through modifying something about a user/customer account much like in this excellent write-up about an issue with GoDaddy's customer service portal. Other methods might involve poisoning logs, or naming a file or transaction or some other record in the attacker's control which is then pulled into some back-end service.
How do we test for it?
When testing for OOB XSS you will need to try additional payloads besides your typical POC like an alert box. In example we would want to inject payloads such as:
In this case we can monitor our web server's logs for attempts to retrieve www.mccormackcyber.com/xss. The problem here comes in the fact it is entirely possible that you will not have someone on the back-end trigger your payload while you are performing your test. This is why these issues can be easily missed during a pentest that is scoped for a week or two because there are so many other back-end systems which may or may not be accessed. How often is someone opening a customer service portal on a testing account to help a customer complaint after all? This is why I recommend resolving the issue at its root if a reflected input IS identified unless you can ensure it will not impact you elsewhere.
The standard remediation recommendations for injections apply here as well. Make sure you are validating inputs against a whitelist where appropriate, and stripping special characters that aren't necessary before storing or reflecting your inputs. Additionally, performing output encoding on any stored data that is later reflected like in the example of GoDaddy's customer service portal.
Are you looking for a security assessment for your network or applications? Send us an email at firstname.lastname@example.org