Root + Impact

Description

In the GetWeather.js script, the Geocoding API is first called to convert a pincode and country code into latitude and longitude. The script checks geoCodingResponse.error, and if true, throws an error "Request failed, try checking the params provided". However, it does not check if geoCodingResponse.data actually exists or contains the expected lat and lon fields before using them in the subsequent Weather API request.
If the Geocoding API request itself does not have a network error (geoCodingResponse.error is false), but returns an unexpected data format (e.g., due to an invalid pincode or country code combination, the API might return an empty data object or an error message body without lat/lon), then accessing geoCodingResponse.data.lat and geoCodingResponse.data.lon could result in undefined.
When these undefined values are used as parameters for the Weather API request, the Weather API request will almost certainly fail, either returning an error or weather for a nonsensical default location (like near the equator and prime meridian). The script subsequently checks weatherResponse.error, but this may not catch logical errors stemming from invalid latitude/longitude.

Risk

Likelihood: Medium

• Users might provide invalid pincode or country code combinations (e.g., typos, non-existent pincodes).

• In such cases, the Geocoding API response body might not contain lat and lon.

Impact: Low

• Chainlink Function Failure or Inaccurate Data Return: If the Weather API request fails due to invalid lat/lon, the Chainlink Function might fail (if weatherResponse.error becomes true), or if the Weather API silently handles invalid lat/lon by returning some default data, the NFT might be updated with weather for an irrelevant location.

• Wasted Oracle Calls and Gas: A failed Function execution still consumes LINK from the oracle subscription and gas for the transaction.

• Poor User Experience: User-provided input leads to unexplained errors or inaccurate weather updates.

Proof of Concept

1. A user initiates a request in WeatherNft.sol (either requestMintWeatherNFT or performUpkeep) where args[0] (pincode) is "00000" and args[1] (ISO country code) is "XX" (an invalid country code).

2. GetWeather.js executes the Geocoding API request.

3. The OpenWeather Geocoding API, for an invalid zip and country code, might return an HTTP 200 OK response, but with an error message in the body, e.g., {"cod":"404", "message":"city not found"}. In this scenario, geoCodingResponse.error is false.

4. The script attempts to access geoCodingResponse.data.lat and geoCodingResponse.data.lon. Since geoCodingResponse.data is {"cod":"404", "message":"city not found"}, these accesses will yield undefined.

5. The script proceeds to construct the Weather API request with lat and lon URL parameters both being undefined.

6. The Weather API (api.openweathermap.org/data/2.5/weather) receives a request with invalid lat/lon parameters.

   • Scenario A: The Weather API returns an error (e.g., HTTP 400 Bad Request). weatherResponse.error would then be true, and the script would throw "Request failed, try checking the params provided".

   • Scenario B: The Weather API might attempt to "guess" or use default values (e.g., lat=0, lon=0) and return weather for that location. The script would not detect this problem, and the NFT would be updated with weather for the wrong location.

7. The end result is either a failed Function call or an NFT updated with incorrect data.

Recommended Mitigation

Add stricter checks after the Geocoding API call to ensure geoCodingResponse.data exists and contains the required lat and lon fields before accessing them. If the check fails, a more specific error should be thrown.

By adding these extra checks, the script can catch issues arising from invalid input or unexpected API responses earlier and provide more informative errors, rather than potentially proceeding with invalid data or returning inaccurate results. A check on the weatherResponse.data structure has also been added to ensure the subsequent extraction of weather_id is safe.