{"id":10990,"date":"2016-04-29T10:10:21","date_gmt":"2016-04-29T10:10:21","guid":{"rendered":"https:\/\/www.fullcontact.com\/?p=10990"},"modified":"2020-03-23T17:19:37","modified_gmt":"2020-03-23T17:19:37","slug":"never-put-secrets-urls-query-parameters","status":"publish","type":"post","link":"https:\/\/www.fullcontact.com\/blog\/engineering\/never-put-secrets-urls-query-parameters\/","title":{"rendered":"Never Put Secrets in URLs and Query Parameters"},"content":{"rendered":"

\t\t\t\tURLS and query parameters aren’t secure. They should never contain sensitive or important information (passwords, static shared secrets, private information, etc). It is asking for trouble, something we here at FullContact have discovered first-hand.<\/p>\n

Recently, a security researcher came to us with 75 of our customer\u2019s API keys<\/a>, and noted that they could get many more with a vulnerability they had found.<\/p>\n

Security is a very high priority for us. We\u2019re a contact management company and we’re responsible for people\u2019s private contact information. So naturally, this incident put several of our engineers on high alert. If this researcher can get access to 75 API keys, \u00a0could they have deep access to one of our systems?<\/p>\n

The Good News<\/b>: The researcher never had access to our systems; in fact, there was no direct vulnerability in our servers or code.<\/p>\n

The Bad News<\/b>: The vulnerability did<\/em> exist, and was through a vector very few people think about.<\/p>\n

The central cause is that the FullContact Person API<\/a> was designed to be simple to get started with: no coding required, just paste a URL into your browser and start looking\u00a0at our\u00a0data. This is made possible by allowing our API key to be passed in as a query parameter as part of the URL. For example:<\/p>\n

https:\/\/api.fullcontact.com\/v2\/person.json?email=bart@fullcontact.com&apiKey=your_api_key_here<\/code><\/p>\n

Unfortunately, putting authentication and secrets in URLs and HTTP query parameters comes with a surprising and subtle security cost.<\/p>\n

The Vulnerability<\/h2>\n

Some web analytics companies aggregate and record traffic across the web, and then sell analytics based on that traffic. One of their major sources of this data is browser extensions<\/em> that have access to their users’ internet activity. Ostensibly, these extensions have access to browsing history and your tabs so that they can do something useful with it. But there are some that sell this data to web analytics companies.<\/p>\n

Although these analytics companies claim to only display anonymized data, many have premium offerings that allow customers to see individual popular requests made to a domain. To be fair, this usually doesn\u2019t include clearly identifying information, like IP address, but it will include the full URL of the request, including any sensitive query parameters like API key<\/strong>.<\/p>\n

This security researcher acquired individual requests for our API site<\/a> using a premium data service offered by a web analytics company. Of course, some of those requests included a customer\u2019s API key as a query parameter.<\/p>\n

It\u2019s not really a surprise that this web analytics company got a hold of that data. Some of our customers (or their developers) were most likely testing their API key in their browser before integrating our API into their stack. What they didn\u2019t know was that one of their browser extensions (or some similar source) was spying on this and sending off every GET request they made to web analytics companies.<\/p>\n

This doesn\u2019t just apply to secrets like API keys in query parameters. We also found URLs for internal company systems and admin pages (of course, inaccessible to the open internet). If an employee at a company has a snooping plugin installed, they are sending off the URLs of internal company pages to these analytics companies. A hacker with premium data offerings effectively has network mapping on steroids: they are able to see a bunch of internal URLs that may be accessible via the open internet or once gaining access to a server on the edge of a network.<\/p>\n

The Fix<\/h2>\n

This is not strictly the fault of our code, but it is the fault of our design. This vulnerability would be costly to exploit (requires premium access to web analytics services), and the scope is limited to a subset of users with snooping browser extensions, but we want to be as careful as possible.<\/p>\n

We are currently switching out the keys of affected customers and recommending that all authentication to our API happen through HTTP headers<\/a> (which are not included in HTTP urls and thus aren\u2019t as vulnerable). Future generations of our APIs will not allow authentication using query parameters. This particular web analytics company has also stopped serving out data for our API domain.<\/p>\n

What you SHOULDN\u2019T do<\/h2>\n

The reality is that URLS and query parameters aren’t secure. They should never contain sensitive or important information (passwords, static shared secrets, private information, etc). It is asking for trouble, especially when browser spyware gets involved.<\/p>\n

Here\u2019s why query parameters are unsafe:<\/p>\n