A parameter is a parameter: a data element (necessarily a character string, in the context of a URL) indexed by a formal name. What is done with that parameter on the server is entirely up to the server.
We here enter the realm of suppositions. The parameter name "
xmlPath" is suggestive of the parameter value being a path name for a file which uses XML. We may imagine that, upon receiving the request:
then the server will try to read one of its local files named "
something", decode its contents as XML, and then interpret the contents in some application-specific way. Conceivably, since the base URL includes the name "
Findme.swf", the result of the server-side processing might be a SWF file to be interpreted in the client browser (specifically, in its Flash plugin). We could even infer that the exact SWF file contents will depend on the result of the processing of the above-mentioned XML file.
What can possibly go wrong ? This is the important security question, because attacks can be viewed as forcing systems to derail when faced with unexpected, abnormal or invalid input. We could try something like this:
in order to try to get the server to read the
/etc/shadow file (which, on a Unix-like system, contains the hashed versions of the local users' passwords), process it, and somehow leak the file contents in what the server returns. This specific example is unlikely to work for two reasons:
On a normal Unix-like system,
/etc/shadow cannot be read by non-administrative local users, and, in particular, the user who runs the Web server process. This depends on the server configuration, of course, but it usually takes some inordinately creative incompetence to make
/etc/shadow readable from Web applications.
/etc/shadow is not in XML format so the decoding will fail.
Note that, for point #2, any decoding error could result in some complex debug information which may contain a dump of the input data which triggered the decoding, e.g. the complete
/etc/shadow file itself... Also, we do not really know if the server really decodes the XML file. It is possible that the server simply reads and embeds the XML file "as is" in the returned SWF, to be decoded on the client. As I said, we are just layering suppositions on top of each others. Anything is possible.
A common reflex of Web programmers is to think of such vulnerabilities in terms of "sanitized input". This is wrong. It is true that any input from external entities, in particular connected Web clients, is suspect and must not be trusted; however, it does not follow at all that there would be some magic sanitation operation which would make the data "clean" and absolutely innocuous. This is the wrong mindset. There is no such thing as generically clean data. This guy:
is NOT an IT security specialist.
When input data must be processed, it must be inspected with all due care for its intended purpose. Here, the
xmlPath parameter is processed as a path to a file so it must be inspected for actually designating an allowed file path, where "allowed" depends on the application. It can be surmised that the server hosts some XML files which are to be read upon normal processing, probably stored in a specific directory or directory tree. The code on the server should then make sure that the
xmlPath parameter it is about to use really designates one of these files, and none other on its hard disk. This is not easy because the server code must keep track of all the possible ways of interpreting a file path by the OS; OS vendors have proven very creative in that respect. There are many encoding issues to deal with.
A more secure way of processing such input parameters is to work symbolically. The server should not expect a path but some sort of identifier that the server code will map to a local file. For instance, an
xmlId parameter could be, when received by the server, hashed with some cryptographic hash function, and the hexadecimal result used as file name in a specific directory. Hexadecimal contains no dot, slash or any other special character, so there is no risk of escaping the directory and reading unwanted files.
There is no reason to suspect that the site we are talking about is subject to XSS (at least, no more reason than "this is a Web site").