Additional parameter for servers with weird security configurations

[GoogleCodeExporter]

While working with TimThumb on a HostGator server I've had issues referencing 
external images. From what I can tell, HostGator is blocking the request (and 
returning a 403/404) when a GET parameter is passed in that is a URL to another 
website.

For example:

These work...
http://example1.com/timthumb.php?src=pic.png
http://example1.com/timthumb.php?src=/pic.png
http://example1.com/timthumb.php?src=http://example1.com/pic.png

But this returns either a 403 or a 404...
http://example1.com/timthumb.php?src=http://example2.com/pic.png

From what I can tell, this appears to be an issue with HostGator and not 
TimThumb. I tested a similar GET request against a script that just print_r's 
the GET superglobal and I got the same server error.

What I propose is a workaround for sites running in this kind of environment. 
The idea is pretty simple. Basically the src can be split into two parts: The 
protocol and the src. So...

http://example1.com/timthumb.php?src=http://example2.com/pic.png

would become...

http://example1.com/timthumb.php?p=http&src=example2.com/pic.png

The attached patch does what I've described, while maintaining backward 
compatibility for existing uses of TimThumb. If no protocol parameter is 
specified, the src is taken as-is. If a protocol is included, it is prepended 
to the src variable.

Original issue reported on code.google.com by javayaht...@gmail.com on 8 Feb 2011 at 6:14

Attachments:

• separate-protocol.diff

[GoogleCodeExporter]

so is this issue happening because http:// appears in the url twice?

The fix you propose is simple enough but I wonder if there's some better method 
for it that would always work in all situations. If I could make it really 
generic so that people don't need to pass a new set of parameters for a single 
webhost (and I guess there's probably others as well) then that would be great 
:)

Original comment by BinaryMoon on 8 Feb 2011 at 2:27

• Changed state: Accepted

[GoogleCodeExporter]

The issue is more than just having http:// appear twice, because having a link 
to the same address (e.g. 
http://example.com/timthumb.php?src=http://example.com/pic.png) works fine. 
That's what makes me think HostGator (and I'm guessing at least a few other 
hosting companies) blocks requests that contain URLs on other domains.

The addition of the protocol parameter doesn't change anything for existing 
URLs, and any new scripts can utilize the new parameter and work on any host 
(not just HostGator).

Original comment by javayaht...@gmail.com on 8 Feb 2011 at 5:37

[GoogleCodeExporter]

ah ok - that makes more sense. So they see the request from an external domain 
and block it because it could be considered an XSS risk.

I must admit I am thinking about this from a WordPress point of view, 
essentially, how would I go about integrating this into my themes in an 
automated fashion? Simplicity is key, and this creates an extra layer of 
potential for confusion, however I don't know if there's anything that can be 
done to work around it.

Original comment by BinaryMoon on 9 Feb 2011 at 12:06

[GoogleCodeExporter]

Again, there's no requirement that WordPress themes etc. take advantage of 
this, but here's an example of what I did in the plugin that led me to think 
about this enhancement.

if ( preg_match( '/([^:]+):\/\/(.*)/', $src, $matches ) ) {
    $protocol = $matches[1];
    $src = $matches[2];
    // ... print TimThumb image with protocol parameter
} else {
    // ... print TimThumb image without protocol parameter
}

This may not be the absolute best way of doing things, but at least it's not 
too complicated. The most confusing part will probably be figuring out how to 
document the new parameter. I'd say specifying that it's an optional parameter 
and providing this code snippet (or something similar) as an example of how to 
use it would probably be a good start.

Original comment by javayaht...@gmail.com on 10 Feb 2011 at 6:34

[GoogleCodeExporter]

We can't change the query params because TT has to be backwards compatible. 
We can add new ones, but I'm not sure this is still an issue. So please test 
the newest version of timthumb on your host and let me know what the exact 
repro of the problem is  - preferably file a new bug. 

Original comment by mmaun...@gmail.com on 7 Aug 2011 at 2:07

• Changed state: WontFix