Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFlag potential sensitive information leak in Get URLs #271
Labels
Comments
|
It's definitely a good idea. Wondering how can we collect a decent set of URL arguments which could potentially be leaked over HTTP? |
|
I think this slight overlaps with #2. |
ccojocar
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Get URLs that have parameters, whether http or https, leak sensitive information when they capture parameters such as API-Keys, usernames, and passwords. Browser extensions, bookmarks, history, and server log files capture these, even when operating in anonymous mode. Browser providers could share the information and log files need to mask the sensitive information. Refer: https://www.fullcontact.com/blog/never-put-secrets-urls-query-parameters/
In non-browser based applications that are controlled by the developer there is more control on client side information leak.
Noticed sites such as Here and Google, for ease of use, suggest putting API keys in the url.
See: https://developer.here.com/documentation/geocoder/topics/quick-start-geocode.html and
https://developers.google.com/maps/documentation/roads/get-api-key
Steps to reproduce the behavior
gosec version
NA
Go version (output of 'go version')
NA
Operating system / Environment
NA
Expected behavior
It would be good to flag such 'sensitive' URL construction, alerting the developer to its potential security implications. And its complement -- alert when urls are logged in the code when they have not explicitly marked as "ignore" or have not tackled some kind of masking.
Actual behavior
NA