|
Home > Archive > IIS Server > July 2005 > escape characters in file name cause problems in media player
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
escape characters in file name cause problems in media player
|
|
| Joe Braun 2005-07-18, 8:47 pm |
| Using file names with embedded escape characters can cause problems in
all versions of media player. Some escape characters when encoded will allow
the file to be processed and played. Only occurs on files served up from a
virtual directory. Files loaded from local file system are unaffected. Also
wav files with small selection of escape characters encoded will process
correctly. Problem mainly with mp3 files containing embedded escape
characters in file name. Source application does not allow file names to be
changed. So we need ability for IIS to allow these wacky file names to be
served up and played in media player. Anyone know of a work around?
| |
| David Wang [Msft] 2005-07-19, 2:48 am |
| Please give an example problematic URL.
I realize that you are just looking for a solution to make reality work --
but in this case, I cannot help. Your problem is not what you claim: "So we
need ability for IIS to allow these wacky file names to be served up and
played in media player. Anyone know of a work around?" -- because these
wacky characters happen to mean something in HTTP but not the FileSystem,
hence you get different behavior. That is totally by-design. How does the
server distinguish between a broken HTTP client and a malicious HTTP client?
The same security that stops malicious clients also stop broken clients, and
since you cannot distinguish between the two, you have a choice -- working
but very insecure server, or secure server breaking just the bad clients.
For example, if the original filename looks like:
Filename % & .ext
Then the URL should look like:
Filename%20%25%20%26%20.ext
If the client does not use the above encoded URL when making a HTTP request
for the original filename, then the client is broken and the fix needs to be
made there. The server's job is to keep failing those requests so that
either:
1. User stops using those names
2. Client gets fixed
Trying to work around it on the server is the wrong thing to do, both in
terms of business decision as well as HTTP spec. Encouraging lax client
behavior only serves to undermine the validity of common specifications like
HTTP.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Joe Braun" <Joe Braun@discussions.microsoft.com> wrote in message
news:4C267FC2-F092-48EA-B328-A80FCC16F8B2@microsoft.com...
Using file names with embedded escape characters can cause problems in
all versions of media player. Some escape characters when encoded will
allow
the file to be processed and played. Only occurs on files served up from a
virtual directory. Files loaded from local file system are unaffected.
Also
wav files with small selection of escape characters encoded will process
correctly. Problem mainly with mp3 files containing embedded escape
characters in file name. Source application does not allow file names to be
changed. So we need ability for IIS to allow these wacky file names to be
served up and played in media player. Anyone know of a work around?
| |
|
| We have found a solution! The reason we HAVE to use these file names is
because a third party tool is creating them. We have millions of these
files. The software creating these files is used by thousands of cutomers
world wide. They said in the next release they will have a solution similar
to the one we came up with. We created a custom ISAPI filter to process
these URLS and Base64Decode the filename in order to retrieve the physical
file using Server.MapPath on the filename portion to extract the filename
strFileName =
toStringFromByteArray(Convert. FromBase64String(lastNode(strip(strFileN
ame,".customfileextension"),"/"))).Trim();
An additional step is required to remove the null character:
strPathAndFileName = context.Server.MapPath(strFileName.Replace("\0",""));
Then we write the file back to the HTTP requestor:
objResponse.ContentType = "audio/x-mpegurl";
objResponse.WriteFile(strPathAndFileName);
Example Bad URL that we can now serve up:
/RAD/20050712/)0LI##FB06962799.MP3
Maps to a NAS drive...
"David Wang [Msft]" wrote:
> Please give an example problematic URL.
>
> I realize that you are just looking for a solution to make reality work --
> but in this case, I cannot help. Your problem is not what you claim: "So we
> need ability for IIS to allow these wacky file names to be served up and
> played in media player. Anyone know of a work around?" -- because these
> wacky characters happen to mean something in HTTP but not the FileSystem,
> hence you get different behavior. That is totally by-design. How does the
> server distinguish between a broken HTTP client and a malicious HTTP client?
> The same security that stops malicious clients also stop broken clients, and
> since you cannot distinguish between the two, you have a choice -- working
> but very insecure server, or secure server breaking just the bad clients.
>
>
> For example, if the original filename looks like:
> Filename % & .ext
>
> Then the URL should look like:
> Filename%20%25%20%26%20.ext
>
> If the client does not use the above encoded URL when making a HTTP request
> for the original filename, then the client is broken and the fix needs to be
> made there. The server's job is to keep failing those requests so that
> either:
> 1. User stops using those names
> 2. Client gets fixed
>
> Trying to work around it on the server is the wrong thing to do, both in
> terms of business decision as well as HTTP spec. Encouraging lax client
> behavior only serves to undermine the validity of common specifications like
> HTTP.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "Joe Braun" <Joe Braun@discussions.microsoft.com> wrote in message
> news:4C267FC2-F092-48EA-B328-A80FCC16F8B2@microsoft.com...
> Using file names with embedded escape characters can cause problems in
> all versions of media player. Some escape characters when encoded will
> allow
> the file to be processed and played. Only occurs on files served up from a
> virtual directory. Files loaded from local file system are unaffected.
> Also
> wav files with small selection of escape characters encoded will process
> correctly. Problem mainly with mp3 files containing embedded escape
> characters in file name. Source application does not allow file names to be
> changed. So we need ability for IIS to allow these wacky file names to be
> served up and played in media player. Anyone know of a work around?
>
>
>
>
| |
| David Wang [Msft] 2005-07-26, 5:54 pm |
| Actually, I think your solution is not correct.
The problem is that the "#" symbol has special meaning when handled by a URL
handler (HTML defines it as an anchor name).
So, given the following URL:
/RAD/20050712/)0LI##FB06962799.MP3
The server thinks it is accessing the following URL
/RAD/20050712/)0LI
and the following index within it: #FB06962799.MP3
The way to solve this encoding problem is to do the following -- you want
whatever is sent to be resolved as the "Filename" of the URL -- so just
write an ISAPI Filter to %-encode the incoming URL. Then let everything else
work as-is, no modifications. Your filter "fixes" the mistake of the client
by making their URL interpreted as a real file resource instead of breaking
other HTTP/HTML specs, and clients won't know a thing.
There is no need to write an ASP.Net HttpModule to do this -- I think it is
more problematic that you have code which automatically Base64Decodes
arbitrary strings without knowing if it is valid-- this will eventually lead
to a security vulnerability. I am also concerned that you have to strip off
null characters because valid operations should never end up with that --
you're definitely writing insecure code here that can be eventually
attacked.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Joe" <Joe@discussions.microsoft.com> wrote in message
news:B1470C4D-22AA-4D16-8E82-8FD8E0FFB841@microsoft.com...
We have found a solution! The reason we HAVE to use these file names is
because a third party tool is creating them. We have millions of these
files. The software creating these files is used by thousands of cutomers
world wide. They said in the next release they will have a solution similar
to the one we came up with. We created a custom ISAPI filter to process
these URLS and Base64Decode the filename in order to retrieve the physical
file using Server.MapPath on the filename portion to extract the filename
strFileName =
toStringFromByteArray(Convert. FromBase64String(lastNode(strip(strFileN
ame,".
customfileextension"),"/"))).Trim();
An additional step is required to remove the null character:
strPathAndFileName = context.Server.MapPath(strFileName.Replace("\0",""));
Then we write the file back to the HTTP requestor:
objResponse.ContentType = "audio/x-mpegurl";
objResponse.WriteFile(strPathAndFileName);
Example Bad URL that we can now serve up:
/RAD/20050712/)0LI##FB06962799.MP3
Maps to a NAS drive...
"David Wang [Msft]" wrote:
> Please give an example problematic URL.
>
> I realize that you are just looking for a solution to make reality work --
> but in this case, I cannot help. Your problem is not what you claim: "So
we
> need ability for IIS to allow these wacky file names to be served up and
> played in media player. Anyone know of a work around?" -- because these
> wacky characters happen to mean something in HTTP but not the FileSystem,
> hence you get different behavior. That is totally by-design. How does the
> server distinguish between a broken HTTP client and a malicious HTTP
client?
> The same security that stops malicious clients also stop broken clients,
and
> since you cannot distinguish between the two, you have a choice -- working
> but very insecure server, or secure server breaking just the bad clients.
>
>
> For example, if the original filename looks like:
> Filename % & .ext
>
> Then the URL should look like:
> Filename%20%25%20%26%20.ext
>
> If the client does not use the above encoded URL when making a HTTP
request
> for the original filename, then the client is broken and the fix needs to
be
> made there. The server's job is to keep failing those requests so that
> either:
> 1. User stops using those names
> 2. Client gets fixed
>
> Trying to work around it on the server is the wrong thing to do, both in
> terms of business decision as well as HTTP spec. Encouraging lax client
> behavior only serves to undermine the validity of common specifications
like
> HTTP.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Joe Braun" <Joe Braun@discussions.microsoft.com> wrote in message
> news:4C267FC2-F092-48EA-B328-A80FCC16F8B2@microsoft.com...
> Using file names with embedded escape characters can cause problems in
> all versions of media player. Some escape characters when encoded will
> allow
> the file to be processed and played. Only occurs on files served up from
a
> virtual directory. Files loaded from local file system are unaffected.
> Also
> wav files with small selection of escape characters encoded will process
> correctly. Problem mainly with mp3 files containing embedded escape
> characters in file name. Source application does not allow file names to
be
> changed. So we need ability for IIS to allow these wacky file names to be
> served up and played in media player. Anyone know of a work around?
>
>
>
>
|
|
|
|
|