Wouldn't ya know it, RSnake has in his XSS filter evasion is something just like this for persistent XSS. Including one with a PHP Injection. The question about non-persistent XSS leading to SSI Injection is still up in the air though.
"I noticed through numerous tests that they were running on Apache andI've seen this behavior happen from time to time in the same areas where you might find persistent XSS. But only rarely. Ryan goes on to speculate about possible SSI Injection where non-persistent XSS typically occurs.
that they had some default configs set. One of these settings is
"Options Includes" which allows for Server-Side Include parsing of
pages. Anyways, instead of submitting the normal "<>alert('XSS
Alert')< /script>" XSS injection code, I used this -
< !--#exec cmd="cat /etc/passwd" -->
and it showed the contents of the passwd file in the returned page."
"While this does work, it doesn't work in all circumstances. AfterI can't say that I've seen this behavior personally. We'll start doing our wider testing on this since it sounds plausible. Anyone else would care to chime in if they've seen this behavior?
some testing, I found that this will not work in reflected XSS. It
needs to be stored XSS as it needs to be stored in a page first and
then the page is parsed for SSI. This attack also doesn't work with
normal CGI pages but might work with other scripting languages.
The bottomline is this - where ever you find XSS input validation
issues, you should try different SSI strings to see if you can get OS
commands to execute in the returned page. "