ngx_pagepseed feature to auto https proxy images served via http ?

[Centmin Mod George]

With Google's focus on getting sites to use SSL and https, some folks are in a dilemma at the web application level with mixed content warnings for http/https where their web apps allow users to post and embed images on the site. For example forum software and user posted images. Xenforo is only forum software which has it's own native https proxy feature to proxy all detected http images on the forums over locally hosted/cached https proxy.

Google has similar thing for G+.

But everyone else is stuck dealing with this at web app level where not all web apps are equipped to deal with these mixed content warnings.

So maybe ngx_pagespeed could come up with a feature on auto detecting http:// served images on a site and auto proxy them over https with a saved cached copy to disk/memory with a TTL when it can be flushed ?

Would be a great feature to have in ngx_pagespeed :)

[Joshua Marantz]

Functionally that sounds good.  But security-wise it is raises a few flags.  If the origin image is served over HTTP, it could be MITM'd between ngx_pagespeed and the origin, and then served up as secure & private to the client.  The risk involved here seems high for ngx_pagespeed to have on automatic.

However, it is certainly supported today to use 'pagespeed MapProxyDomain ...' to serve HTTP origin content over HTTPS.  The site owner should understand the risks as described in the MapProxyDomain doc.

-Josh

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.
Visit this group at http://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

[Centmin Mod George]

Yeah security wise it ain't ideal, but isn't that what Google is doing for their web properties like Google+ when you post your own http served image in G+ post, it ends up being served by Google over https ?

[Jeff Kaufman]

The other risk here, aside from MITM between PageSpeed and origin, is
the risk of automatically moving images onto your domain. Imagine a
site allows users to insert image references, and an attacker puts in
a reference to a file that looks enough like an image to satisfy
PageSpeed but browsers will interpret as HTML. Normally this would
look like:

good.example.com/index.html:
<img src="http://evil.example.com/evil.gif">

But PageSpeed would turn that into something like:

good.example.com/index.html:
<img src="https://good.example.com/_pagespeed_external_images/evil.example.com/evil.gif">

And then the attacker could get someone to visit it by giving them the
link to that "image", which would be interpreted as HTML and run JS,
giving them an XSS exploit.

This doesn't apply to all browsers: on most modern browsers it's
enough to send "Content-Type: image/gif" and know it won't get
interpreted as HTML. But in some browsers, including IE7 and below,
an image content type enables Content-Type sniffing. This would make
sense if it only enabled sniffing between image types, because people
get that wrong a lot, but it also enables sniffing to html. IE7 is
old, but it's not old enough that we can ship something where it would
be vulnerable to XSS attacks like that.


Additionally, this would either turn PageSpeed into an open proxy for
images or sometimes break images. Background: right now it works for
people to run PageSpeed on multiple servers without a shared cache.
If your servers are near each other it's usually more efficient for
them to share a cache to resources don't have to be reoptimized, but
if you have PageSpeed running in multiple locations/datacenters that's
impractical and would add a lot of latency. So imagine a request
comes in for index.html:

https://good.example.com/index.html:
<img src="http://other.example.com/image.png">

If PageSpeed were set to auto proxy http images it would rewrite that
to something like:

https://good.example.com/index.html:
<img src="https://good.example.com/_pagespeed_external_images/other.example.com/image.png">

Now say the browser's request for that image hits a PageSpeed server
in a different location without a shared cache. How does it know this
request is legitimate? Because it can't check legitimacy it has to
just proxy any image it sees. This wouldn't be popular!

One way to fix this would be to require that people either have a
shared cache or turn on resource signing with a shared secret between
all their PageSpeed servers:
https://developers.google.com/speed/pagespeed/module/restricting_urls#url_signatures
But turning this on by default and adding a requirement like this
would break sites that have been doing fine with a shared cache, so
there would have to be a very compelling case.


As Josh says, however, this is something that sites can opt into
already with MapProxyDomain. Here you avoid the security issue by
only turning on MapProxyDomain for domains you trust not to XSS you,
and you avoid the open proxy issue by whitelisting domains.

On Sun, Mar 29, 2015 at 7:07 PM, Centmin Mod George

[Centmin Mod George]

Thanks Jeff both yours and Josh's insights have me thinking more about this :)

In Xenforo's forum image proxy they have secret key of sorts

"If you have enabled the image or link proxy, this secret key will ensure that images and links are only proxied if the requests originated at your forum. If you find that links are being accessed via third-party sites, you can change this secret key to expire these links. All links stored on the forum will be automatically updated to use the new secret key."

for

And then the attacker could get someone to visit it by giving them the 
link to that "image", which would be interpreted as HTML and run JS, 
giving them an XSS exploit. 

could that be limited by only allowing proxied url to resolve if served from my own domain or whitelisted set of domains ??

[Jeff Kaufman]

On Mon, Mar 30, 2015 at 10:06 PM, Centmin Mod George
<ng...@centminmod.com> wrote:
>
> In Xenforo's forum image proxy they have secret key of sorts
>
> "If you have enabled the image or link proxy, this secret key will ensure
> that images and links are only proxied if the requests originated at your
> forum. If you find that links are being accessed via third-party sites, you
> can change this secret key to expire these links. All links stored on the
> forum will be automatically updated to use the new secret key."
>

Yes, we could do this with a relatively small extension of url
signing. It would require people to put a secret key in their config
file, shared across all their servers.

>> And then the attacker could get someone to visit it by giving them the
>> link to that "image", which would be interpreted as HTML and run JS,
>> giving them an XSS exploit.
>
> could that be limited by only allowing proxied url to resolve if served from
> my own domain or whitelisted set of domains ??
>

When you say "if served from" do you mean that the html that
references the image is on your domain, or if the image itself is on
your domain? If the former, then you need either url signing or a
shared cache, if the latter then that's what MapProxyDomain is.

There's still the problem that moving images onto your domain can make
you vulnerable to XSS when you weren't before, so you have to be sure
that you only MapProxyDomain for domains you trust not to XSS you (the
same level of trust as when you include JS from another site).

[Centmin Mod George]

When you say "if served from" do you mean that the html that 
references the image is on your domain, or if the image itself is on 
your domain?  If the former, then you need either url signing or a 
shared cache, if the latter then that's what MapProxyDomain is. 

yeah actually was thinking of both situations :)