Improper Input Validation on User's Location on PUT /WhoService/putLocation Could Affect Availability/Falsify Users

How it was found

Summary:

Note: I noticed that that the team has fixed issues like an XSS that's caused only from a header value (typically OOS since it's not directly exploitable) https://github.com/WorldHealthOrganization/app/pull/855, so in the spirit of this I'm also reporting another "good-to-fix" issue.

On the WHO app, users send approximate location data to the WhoService API:

/app/client/flutter/lib/pages/onboarding/location_sharing_page.dart:

  Future<void> _allowLocationSharing() async {
    try {
      await Location().requestPermission();
      if (await Location().hasPermission() == PermissionStatus.granted) {
        if (await Location().requestService()) {
          LocationData location = await Location().getLocation();
          Map jitteredLocationData = JitterLocation().jitter(
              location.latitude, location.longitude,
              5 /*kms refers to kilometers*/);

          await WhoService.putLocation(
              latitude: jitteredLocationData['lat'],
              longitude: jitteredLocationData['lng']);
        }
      }
    } catch(_) {
      // ignore for now.
    } finally {
      _complete();
    }
  }

Which in turn translates to a call to https://staging.whocoronavirus.org/WhoService/putDeviceToken:

curl --request POST \
  --url 'https://hackerone.whocoronavirus.org/WhoService/putLocation' \
  --header 'content-type: application/json' \
  --header 'who-client-id: ██████████' \
  --header 'who-platform: ios' \
  --data '{
	"latitude": 22222222,
	"longitude": "9999999"
}'

This returns a 200 OK response. On the server side, we see that it uses the following logic:

  @Override public Void putLocation(PutLocationRequest request) throws IOException {
    Client client = Client.current();
    client.latitude = request.latitude;
    client.longitude = request.longitude;
    S2LatLng coordinates = S2LatLng.fromDegrees(request.latitude, request.longitude);
    client.location = S2CellId.fromLatLng(coordinates).id();
    ofy().save().entities(client);
    return new Void();
  }

There is no validation on request.latitude, request.longitude before it is stored into the Google App Engine datastore. This is because the S2LatLng.fromDegrees (which transforms the values into a S2LatLng object) from the s2-geometry-library-java library specifically does not validate these values because, according to their comments at https://github.com/google/s2-geometry-library-java/blob/master/src/com/google/common/geometry/S2LatLng.java:

Like the rest of the "geometry" package, the
intent is to represent spherical geometry as a mathematical abstraction, so
functions that are specifically related to the Earth's geometry (e.g.
easting/northing conversions) should be put elsewhere.

Thus, even these values:

	"latitude": 22222222,
	"longitude": "9999999"

Are accepted and stored in the database even though they are technically non-existent coordinates on earth.

To reproduce, just run this request with different who-client-id UUID you generated yourself and impossible latitude and longitude.

curl --request POST \
  --url 'https://hackerone.whocoronavirus.org/WhoService/putLocation' \
  --header 'content-type: application/json' \
  --header 'who-client-id: ████████' \
  --header 'who-platform: ios' \
  --data '{
	"latitude": 22222222,
	"longitude": "9999999"
}'

Impact

An attacker can exploit this to affect the Availability or Integrity of the analytics data by injecting false location values and falsifying user data. A fix for this would be to implement a quick lat lng validator that is specifically meant to validate Earth geometry, instead of the S2LatLng class.