Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Question about r3722: Strict routing for file downloads
One site I maintain has a podcast, and one episode got picked up by a MP3 search engine in China, causing a huge surge in downloads initiated by MP3 players. The site owner was alarmed and thought that it was fishy, but the raw server logs don’t seem to show any signs of anything untoward.
Except for one detail: All the download requests come with URLs like this:
/file_download/463/ba7acbb1-87c0-9b31-4779-*.mp3… and the part in the * is a seemingly random string that is different for different people and times. The actual name of the file is the URL-sanitized English title of the episode, nothing like the string of characters in the URL above. Since the topic of the episode is a contemporary political concern in China that might be subject to state censorship, I thought the URLs might be an attempt to circumvent the Great Firewall, but I really have no idea. Since Textpattern has always delivered the file based on the file_download ID, the the file has remained available regardless of what file name is appended to the ID.
Now that strict routing for file downloads by ID and name is part of the next TXP release, I’m wondering what we should do. I imagine that we could define a redirect in the site’s .htaccess file that would continue to make this file available to any request for that ID, but is it a security risk? Since the site owner has long been suspicious about this episode’s download count, I doubt he would mind cutting it off. But when I see MP3 players initiating the download, I feel hesitant about blocking the content for real people.
Last edited by johnstephens (2012-04-12 00:19:36)
Offline
Re: Question about r3722: Strict routing for file downloads
johnstephens wrote:
I imagine that we could define a redirect in the site’s .htaccess file that would continue to make this file available to any request for that ID, but is it a security risk?
No, not a “security” risk in a sense of actually compromising the server. Feel free to redirect matching URLs to the actual download location. Clients that pick redirections, and search engine may or will also then fix the URLs too as they get informed about the correct location.
But. The thing about the loose URL structure is, that textpattern should have never allowed these free URLs. Things like /id/title and /id/download both should and should have been strict from the start. All URLs must be validated and correct status returned when the request location is deemed invalid. Otherwise you are just allowing blackhats and sniffers to do what they do best.
Offline
Re: Question about r3722: Strict routing for file downloads
Thanks, Jukka!
Have you seen anything like this before? Does this scenario have any telltale signs of blackhats or sniffers? If so, what would they do?
Although there was a huge spike in downloads and that episode continues to generate more hits than any other almost two years later, we’re nowhere near our bandwidth limits. All told, it’s just over 49,000 downloads, which is certainly a shock for this obscure academic site, but nothing that affects performance in any way that we’ve noticed; the hosting provider said that they can’t detect any danger from the connections. Since the server logs record that the vast majority of requests came from “Nemesis Player” (NSPlayer) and Windows Media Player, I was inclined to think that the hits are authentic and the URLs may be an artifact of the “Golden Shield Project”, or an sign of efforts to bypass Chinese Internet censorship. But that hypothesis isn’t founded on anything other than speculation.
Offline
Re: Question about r3722: Strict routing for file downloads
It’s the interwidewebsnet… thing. You should be getting odd request every microsecond. From various automated exploit sniffs to what ever times ten.
But anyways, 50k downloads is a very small number. Pretty much anyone could steal more bandwidth in matter of seconds. What ever it might be, at least you are not getting DDoS’d your pants off for realzies.
As far as logs go, information in them is merely based on headers. While my logs say otherwise, i doubt that someone is using a toaster to browse a web. Or maybe they are, who knows.
Offline