0

Are user generated search queries classed as sensitive data?

For example, if an application put PII from a search query such as names, date of birth, addresses etc. in the query string of a URL (HTTPS GET request), it was my assumption this would be sensitive data that must be protected, i.e. do not use GET, use POST, as per CWE.

However, some colleagues do not agree with securing these URLs because they say "user generated content is not sensitive, as it can be data that doesn't exist, or the search data can be sent via other methods e.g. email". I disagree with this but was looking for an expert opinion on whether or not user generated search queries can technically contain PII, and are they sensitive?

qwrez
  • 3
  • 2

2 Answers2

0

The main difference between GET and POST requests is that in GET requests a third person can see the information passed to the application just by viewing the url, something that doesn't happen with POST requests. This is why it's considered better and safer to use POST instead of GET http-method for sensitive data.

Have in mind though, that from a security perspective if someone by any mean manage to execute successfully e.g. a MITM attack to the network, he will be able to retrieve not only GET but also POST parameters/data, so make sure that when you pass sensitive data to your application - you pass them encrypted - so https combined with HSTS in this case plays a very important role to protect your application and clients from remote attackers.

Now about what's considered sensitive data? I'm not a lawer, but I believe that sensitive are the data that should be protected by any unauthorised access. Also that depends on the application. For example facebook allows authenticated users to view some of your information (if you set your settings to do so) - so in this case it's up to the user to select what to share and what to keep private (of course some things must be kept private, like passwords, social security numbers, credit card numbers etc...).

Also if some of the user's information are used by the application's functionality and must be passed to the application frequently (e.g. user's email for authentication) but they don't need to be visible then it's better to hide them and when needed pass them to your application using POST instead of GET. In this way you can prevent (or at least discourage) some kind of attacks like brute-force attacks. Imagine that the complexity of such an attack reduces from O(n^2) to O(n) when the attacker knows either the username or the password and doesn't have to guess the correct combination.

game0ver
  • 585
  • 4
  • 12
  • Thanks for the answer, in regards to this application, there is nothing stopping users sharing these URLs with unauthenticated users, thus the PII would end up in emails, logs, history etc regardless if they had access - which is my concern. Also, sorry I should have clarified this is over SSL, I've edited the post. – qwrez Mar 20 '18 at 16:44
  • Check the last paragraph - when something can be manipulated/used by an attacker should be avoided to be transmitted using GET. The same of course goes for info exposure that the user prefers to keep private. – game0ver Mar 20 '18 at 16:48
0

Privacy decisions are based on worst case scenarios (i.e. whether a query can reasonably contain private data) and not on best case scenarios (i.e. whether a query can contain public data).

Search queries become PII when they can be associated with a specific person, which can be done both via identifiers in logs (IP addresses, usernames, cookies etc.) and via the queries themselves (inference and aggregation attacks).

The answer to your question is in my opinion yes: generic search queries (i.e. not strictly related with domains that exclude use of PII) are reasonably expected to contain personal and sensitive information, and as such they must be adequately protected: among other things they must travel in encrypted form and cannot be recorded in logs (including proxy logs) unless the latter are also adequately protected.

Enos D'Andrea
  • 1,047
  • 5
  • 12