Yes, one would think so but unfortunatly it does not.
Here is an more accurate copy that section for my companies
guidelines.
| Code | Vulnerability | Information About Vulnerabilty |
| ... |
| V42 | Acceptance meta code embedded within input data | Enables "stealth commanding" i.e., the insertion of specieal control or escape characters in data input -- e.g., "!" (which precedes command strings in UNIX shell scripts, and "%", which invokes system level commands in Perl) -- or complete control strings, such as those that may trigger hidden debug code and developer backdoors left in the deployed code. If the application's user interface code has this vulnerability, special characters may be used to insert entire progams in the application's data input fields, a technique called "cross site scripting" |
I am not sure my company's guidelines are accurate. What do you think? | [reply] |
"!" (which precedes command strings in UNIX shell scripts
This is a very strange way to put it. What they're describing -- I think -- is the fact that many Unix programs (such as the vi editor and a few others) accept ! as a command that would drop you to a shell. However, "command strings in Unix shell scripts" don't have any special characters.
Like the previous poster, I suspect the author of this guideline once encountered a program, possibly written in Perl, that would drop you to a shell when given the command %.
I think what they're trying to say is "Don't build shell escapes in your programs". They're just saying it in a confusing way, with very poor examples. A much better example would be Eric Allman's infamous hack in the early versions of sendmail: he extended the SMTP protocol adapter in sendmail to accept a command SHELL that would give you an interactive shell on the machine the sendmail daemon was running on. Most places ran/run sendmail as root, so you can guess the impact. (You were supposed to give it a password to enable that command, but due to a bug, it didn't demand a password....
BTW, that bug was fixed around 1987 as I recall.)
| [reply]
[d/l]
[select] |
With the cross site scripting reference, I wonder if they are referring to HTML escaped strings passed in via urls? like http://site.name.here/%2E%2E/%2E%2E/%2E%2E/etc/passwd or the like attempting to get past a filter looking at the URL for extra dots in the url. This could be checked and passed along and then get evaluated to a path with ../../../ in the middle of it.
This is the only thing I can think of offhand which would have % in the context of security and cross site scripting. The shell escape character also might be seen to have a similar purpose.
| [reply] |