Media proxy #196

Ghost commented 2020年06月17日 23:20:48 +02:00

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.

---

upstream issue: https://github.com/go-gitea/gitea/issues/916
upstream pull: https://github.com/go-gitea/gitea/pull/12802
example proxy: https://github.com/cactus/go-camo

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. ---- upstream issue: https://github.com/go-gitea/gitea/issues/916 upstream pull: https://github.com/go-gitea/gitea/pull/12802 example proxy: https://github.com/cactus/go-camo

6543 commented 2020年06月19日 12:47:12 +02:00

https://github.com/go-gitea/gitea/issues/916

https://github.com/go-gitea/gitea/issues/916

lhinderberger commented 2020年07月21日 23:51:13 +02:00

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?

resynth1943 commented 2020年08月16日 23:53:25 +02:00

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.

resynth1943 commented 2020年08月16日 23:56:10 +02:00

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 2020年08月17日 09:07:24 +02:00

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.

resynth1943 commented 2020年08月17日 11:56:25 +02:00

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 :-)

lhinderberger commented 2020年08月17日 13:59:10 +02:00

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?

lhinderberger commented 2020年08月17日 14:01:25 +02:00

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.

resynth1943 commented 2020年08月18日 02:13:21 +02:00

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.

resynth1943 commented 2020年08月18日 02:14:50 +02:00

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.

zeripath commented 2020年09月10日 22:26:53 +02:00

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

6543 commented 2022年03月29日 11:36:15 +02:00

backported ... Codeberg/gitea@4964756816

backported ... https://codeberg.org/Codeberg/gitea/commit/49647568169140fd128d3a816ba043aee1cb7b91

HexagonCDN commented 2022年12月18日 12:14:29 +01:00

finally... no more repos connecting to shields.io directly!

finally... no more repos connecting to shields.io directly!

fnetX commented 2022年12月19日 16:12:00 +01:00

How can this be closed, we didn't do any config change IIRC? And it's not enabled by default? And all places I know still directly link external sources?!

How can this be closed, we didn't do any config change IIRC? And it's not enabled by default? And all places I know still directly link external sources?!

6543 commented 2024年01月19日 00:29:42 +01:00

this is now a configuration issue only ...

this is now a configuration issue only ...

kita commented 2024年02月03日 05:17:21 +01:00

This issue is still here to this day. Hopefully this issue gets fixed as this is a privacy concern not only for me but also for everyone else.

This issue is still here to this day. Hopefully this issue gets fixed as this is a privacy concern not only for me but also for everyone else.

fnetX commented 2024年02月03日 17:17:28 +01:00

Freel free to step up and setup and maintain the media proxy.

Freel free to step up and setup and maintain the media proxy.

Codeberg/Community