Fix bad geoip reporting

[LDiazN]

This PR will fix the bad geoip reporting that was caused by how we parse the X-Forwarded-For header:

According to MDN:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#directives

A proxy IP address. If a request goes through multiple proxies, the IP addresses of each successive proxy are listed. This means that the rightmost IP address is the IP address of the most recent proxy and the leftmost IP address is the address of the originating client

And AWS:
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html#x-forwarded-for

The X-Forwarded-For request header may contain multiple IP addresses that are comma separated. The left-most address is the client IP where the request was first made. This is followed by any subsequent proxy identifiers, in a chain.

But we're taking the right most header instead, the most recent proxy server (backend-fsn)

backend/ooniapi/services/ooniprobe/src/ooniprobe/utils.py

Line 127 in 30f3860

real_ip_headers = ["X-Forwarded-For", "X-Real-IP"]

And looking at the logs I found the following value for X-Forwarded-For:

'xxx.xxx.xxx.xxx, 162.55.247.208'

Where 162.55.247.208 is backend-fsn

So the solution should be just taking the first value instead of the last one

closes #1003

[aagbsn]

Is there an issue here where the client can inject an X-Forwarded-For header with a bogus IP?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#security_and_privacy_concerns

Any security-related use of X-Forwarded-For (such as for rate limiting or IP-based access control) must only use IP addresses added by a trusted proxy.

If there is a (single) proxy as part of the ooni infrastructure, maybe it makes sense to drop the last proxy IP from the list.

[LDiazN]

Is there an issue here where the client can inject an X-Forwarded-For header with a bogus IP?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#security_and_privacy_concerns

Any security-related use of X-Forwarded-For (such as for rate limiting or IP-based access control) must only use IP addresses added by a trusted proxy.

If there is a (single) proxy as part of the ooni infrastructure, maybe it makes sense to drop the last proxy IP from the list.

Hi @aagbsn, this code is fixing a metric that we use to check the relationship between the reported CC and ASN from the ones we can observe from the server using the reported client IP, the idea is precisely to see how trustworthy the reported data is:

1. We take the reported probe_cc and probe_asn from the measurement
2. We take the reported ip from the request headers
3. Using an IP database, we look up the reported ip an get a db_cc and db_asn
4. If any of these parameters does not match, then we count it with Prometheus metrics

However this data is not used for anything critical or even exposed to the public, we use it internally to study if there's an unusually high volume of inconsistencies and why.

In case of a bogus IP, it would pollute the mismatch metric, but nothing more

Do you see any case where this could still be an issue?