I have a URL to a flash file. Sample :-
http://abc.mydomain.com/Findme.swf
Now, there is a parameter called xmlpath as :-
http://abc.mydomain.com/Findme.swf?xmlPath=something.
Is it not that xmlpath is used to point to an xml file? If proper sanitization of the parameter xmlPath is not done, how can it lead to an XSS. Explanation with an example would be well appreciated.
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:
http://abc.mydomain.com/Findme.swf?xmlPath=something
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:
http://abc.mydomain.com/Findme.swf?xmlPath=..%2F..%2F..%2F..%2F..%2Fetc%2Fshadow
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.
None of the above has any relation with XSS, aka cross-site scripting. XSS is a generic name applied to attacks when some user-provided input data is reflected into some answer which is sent to another user, and the browser of that second user interprets it as a script excerpt. When XSS applies, a user can then choose some executable code (Javascript, but executable nonetheless) to run in the security context of another, target user, which opens the road to a lot of nastiness.
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").
try ?xmlPath=www.yahoo.com
When you put that xmlPath variable in a query string, and then look at the network tab on your console, you might see that the browser will actually go to that 3rd party site (yahoo in this case), and check there for a crossdomain.xml file. If that site has a crossdomain policy, it will be loaded. Scary.
My thinking would be to cut off that as a possibility of external requests at the network layer, or maybe do an htaccess type rewrite rule. As of now, i'm still looking into it, and will update if there is any success with these approaches.
