SSI Injection instead of JavaScript Malware

Update:
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.

While everyone is busy hacking the browser when it comes to JavaScript Malware, Ryan Barnett is researching the possibility of Server-Side Include (SSI) Injection using the same attack vector. He ran his ideas by me earlier today...

"I noticed through numerous tests that they were running on Apache and
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."

I'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.

"While this does work, it doesn't work in all circumstances. After
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. "

I 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?