#196 Media proxy

Open
opened 8 months ago by Ghost · 11 comments
Ghost commented 8 months ago

If one were to embed an image into a document that automatically loads (e.g. a README), they could quite easily grab the IPs of targeted users.

GitHub combats this by implementing a media proxy, which is a safer mechanism for preventing these kind of attacks. For example, if an external image is embedded into a README, its request goes through camo.githubusercontent.com.

This prevents the attacker from gaining the IP of victim users. While the external images are still loaded, they are loaded from GitHub's servers, then fed back to the user and into the browser.

I'm not sure if this affects other Gitea instances, and Gitea itself.

If one were to embed an image into a document that automatically loads (e.g. a README), they could quite easily grab the IPs of targeted users. GitHub combats this by implementing a media proxy, which is a safer mechanism for preventing these kind of attacks. For example, if an external image is embedded into a README, its request goes through camo.githubusercontent.com. This prevents the attacker from gaining the IP of victim users. While the external images are still loaded, they are loaded from GitHub's servers, then fed back to the user and into the browser. I'm not sure if this affects other Gitea instances, and Gitea itself.
6543 commented 8 months ago
Poster
Collaborator
https://github.com/go-gitea/gitea/issues/916
Poster

Another way to solve this and to protect users and visitors of Codeberg other than waiting for the Gitea developers to integrate a proxy would be to modify Gitea to be able to configure a proxy URL and to then set up our own simple proxy server.

In fact, Gitea does something very similar already, as described in my answer to #220

That way, we could also fix the issues with SVG images, as described in #220.

I would also imagine that it can take some load off our servers in comparison to the integrated approach, because in a high-load scenario the proxy could run on another machine.

There are however a few open questions regarding setting up a media proxy (most of them are valid for both approaches):

  • How much additional traffic is to be expected?
  • How to deal with the potential of abuse of our proxy?
  • We would need to make sure to set proper Content-Security-Policy headers for any media returned from our proxy (and preferably test it in practice), to make sure that tracking cannot occur indirectly, for example due to external resources being loaded by an SVG.
  • A simple proxy that isn't build into Gitea would lack authentication and thus could only access content of public repositories and the public Internet. What to do with private repositories?
Another way to solve this and to protect users and visitors of Codeberg other than waiting for the Gitea developers to integrate a proxy would be to modify Gitea to be able to configure a proxy URL and to then set up our own simple proxy server. In fact, Gitea does something very similar already, as described [in my answer to #220](https://codeberg.org/Codeberg/Community/issues/220#issuecomment-69309) That way, we could also fix the issues with SVG images, as described in #220. I would also imagine that it can take some load off our servers in comparison to the integrated approach, because in a high-load scenario the proxy could run on another machine. There are however a few open questions regarding setting up a media proxy (most of them are valid for both approaches): - How much additional traffic is to be expected? - How to deal with the potential of abuse of our proxy? - We would need to make sure to set proper Content-Security-Policy headers for any media returned from our proxy (and preferably test it in practice), to make sure that tracking cannot occur indirectly, for example due to external resources being loaded by an SVG. - A simple proxy that isn't build into Gitea would lack authentication and thus could only access content of public repositories and the public Internet. What to do with private repositories?
Poster

How to deal with the potential of abuse of our proxy?

Perhaps it would be wise to add UUID's into the requests (camo and go-camo do this).

The latter should, in theory, be easy to implement. Just add a field to the configuration file that points at an instance of it.

> How to deal with the potential of abuse of our proxy? Perhaps it would be wise to add UUID's into the requests ([camo](https://github.com/atmos/camo) and [go-camo](https://github.com/cactus/go-camo#differences-from-camo) do this). The latter should, in theory, be easy to implement. Just add a field to the configuration file that points at an instance of it.
Poster

It would be wise to use an existing, tested implementation, instead of hacking together some nonsense.


I'm the author of this issue. I did email Codeberg about this, but they think it's a small security risk. Of course, I disagree. The user does not have to consent to their browser loading embedded images, which makes this effectively a click-and-grab attack: the user won't be aware of their IP being leaked.

I'm surprised this big security risk hasn't been paired up with an IP logger, yet. Just a matter of time...

It would be wise to use an existing, tested implementation, instead of hacking together some nonsense. --- I'm the author of this issue. I did email Codeberg about this, but they think it's a small security risk. Of course, I disagree. The user does not have to consent to their browser loading embedded images, which makes this effectively a click-and-grab attack: the user won't be aware of their IP being leaked. I'm surprised this big security risk hasn't been paired up with an IP logger, yet. Just a matter of time...
hw commented 6 months ago
Poster
Owner

please stay fair and considerate.

Analysis and proposals above and in #220 are well-founded and productive, many if not all of these options might evolve as viable solutions. As discussed in email communication, this issue is definitely not a security risk endangering operations, but surely a privacy improvement we all encourage. All help and PR welcome, please be invited to contribute!

camo/go-camo integration with gitea is surely a good point to start with. Relevant repos are http://codeberg.org/codeberg/gitea/ and http://codeberg.org/codeberg/build-deploy-gitea/ -- likely a lot of this work will be valuable to upstream gitea.

please stay fair and considerate. Analysis and proposals above and in #220 are well-founded and productive, many if not all of these options might evolve as viable solutions. As discussed in email communication, this issue is definitely not a security risk endangering operations, but surely a privacy improvement we all encourage. All help and PR welcome, please be invited to contribute! camo/go-camo integration with gitea is surely a good point to start with. Relevant repos are http://codeberg.org/codeberg/gitea/ and http://codeberg.org/codeberg/build-deploy-gitea/ -- likely a lot of this work will be valuable to upstream gitea.
Poster

please stay fair and considerate.

Oh, I thought I was. I'm sorry, but are upstream doing anything about this? I don't know where we stand.

Analysis and proposals above and in #220 are well-founded and productive, many if not all of these options might evolve as viable solutions.

Nice.

As discussed in email communication, this issue is definitely not a security risk endangering operations, but surely a privacy improvement we all encourage. All help and PR welcome, please be invited to contribute!

Well, to be rather frank, I now wonder if this issue should be here at all. It's more of a general issue with Gitea.

camo/go-camo integration with gitea is surely a good point to start with.

Of course it is. I mentioned the Go variant for a reason :-)

> please stay fair and considerate. Oh, I thought I was. I'm sorry, but are upstream doing anything about this? I don't know where we stand. > Analysis and proposals above and in #220 are well-founded and productive, many if not all of these options might evolve as viable solutions. Nice. > As discussed in email communication, this issue is definitely not a security risk endangering operations, but surely a privacy improvement we all encourage. All help and PR welcome, please be invited to contribute! Well, to be rather frank, I now wonder if this issue should be here at all. It's more of a general issue with Gitea. > camo/go-camo integration with gitea is surely a good point to start with. Of course it is. I mentioned the Go variant for a reason :-)
Poster

I can have a closer look at go-camo once I can spare some more time. Right now, my focus lies mainly on Codeberg Documentation though. Everyone willing to help with research and/or implementation for this issue is invited to do so :)

@resynth1943 Could you elaborate on how the UUID approach would address the risk of abuse?

I can have a closer look at go-camo once I can spare some more time. Right now, my focus lies mainly on Codeberg Documentation though. Everyone willing to help with research and/or implementation for this issue is invited to do so :) @resynth1943 Could you elaborate on how the UUID approach would address the risk of abuse?
Poster

The latter should, in theory, be easy to implement. Just add a field to the configuration file that points at an instance of it.

If you mean implementing a media proxy not by integrating it into Gitea but by giving a proxy URL, please refer to my answer in #220, as modifying Gitea to use an external proxy URL would need a bit more refactoring. Just changing the config file won't do, I'm afraid.

> The latter should, in theory, be easy to implement. Just add a field to the configuration file that points at an instance of it. If you mean implementing a media proxy not by integrating it into Gitea but by giving a proxy URL, please refer to [my answer in #220](https://codeberg.org/Codeberg/Community/issues/220#issuecomment-69309), as modifying Gitea to use an external proxy URL would need a bit more refactoring. Just changing the config file won't do, I'm afraid.
Poster

Could you elaborate on how the UUID approach would address the risk of abuse?

Can't speak too much about the technique, as I'm not too familiar with it. From what I can see though, the server signs the target URL with HMAC, which then is added to the URL. Morty does this, and it prevents Morty instances from being used as open proxies.

> Could you elaborate on how the UUID approach would address the risk of abuse? Can't speak too much about the technique, as I'm not too familiar with it. From what I can see though, the server signs the target URL with HMAC, which then is added to the URL. [Morty](https://github.com/asciimoo/morty) does this, and it prevents Morty instances from being used as open proxies.
Poster

If you mean implementing a media proxy not by integrating it into Gitea but by giving a proxy URL, please refer to my answer in #220, as modifying Gitea to use an external proxy URL would need a bit more refactoring.

Haha, well maybe that's a good thing 😛 Might open the door to other future additions.

> If you mean implementing a media proxy not by integrating it into Gitea but by giving a proxy URL, please refer to my answer in #220, as modifying Gitea to use an external proxy URL would need a bit more refactoring. Haha, well maybe that's a good thing 😛 Might open the door to other future additions.
lhinderberger added the
enhancement
label 6 months ago
lhinderberger added the
contribution welcome
label 6 months ago
Poster

OK I've made a very basic attempt to do this:

https://github.com/go-gitea/gitea/pull/12802

OK I've made a very basic attempt to do this: https://github.com/go-gitea/gitea/pull/12802
Sign in to join this conversation.
Loading…
There is no content yet.