1

I've found that my website is using id_token and it contains user's information. One of that is my phone number which I think it could be a sensitive information. Because, if the attackers are able to capture the request, they get my id_token and decode it. They have my email (obviously) and my phone number which I think should not be there. I'm confused that if my phone number gets disclosed, is that considered a vulnerability?

email: "[email protected]",
 email_verified: false,
 phone_number: "+372591114xxx",
 firebase: {
  identities: {
   phone: [
    "+372591114xxx"
   ],
   email: [
    "[email protected]"
   ]
  },
  sign_in_provider: "custom"
 }
}.
[signature]
Improve this question
6
  • The OIDC standard allows, and even encourages this kind of behavior, in some places. For instance the id_token_hint. While it's allowed to POST the data, it's not required. But I agree with your sentiment...
    – Geir Emblemsvag
    Commented Dec 14, 2018 at 5:59
  • "Because, if the attackers are able to capture the request,..." - first: was this transmitted with HTTP or HTTPS? Also, how were these sensitive information submitted in the first place, i.e. via web too and thus affected by the same risk as the id_token?
    – Steffen Ullrich
    Commented Dec 14, 2018 at 6:44
  • HTTPS or HTTP, I don't see the point here because HTTPS just encrypts the contents of it. With the id_token resides on the URL. It could be captured, saved in logs, URLs may also be displayed on-screen, bookmarked or emailed around by users. Yes it's submitted via web though. @SteffenUllrich
    – Ender
    Commented Dec 14, 2018 at 7:51
  • @Ender: Saved in logs: this is likely only done at a server who already has your data anyway. Captured: not with proper HTTPS and if improper HTTPS or plain HTTP is used POST body could be captured as well. Displayed on screen: should only be done to somebody who already knows these data anyway. Shared with others: likely a problem since the average use does not know what he shares.
    – Steffen Ullrich
    Commented Dec 14, 2018 at 8:25
  • @Ender: "...I've found that my website ..." - do you mean with "my" that this is a website you've setup to be public and which publishes your private information to everybody via id_token? Or do you just mean a website you've visited, i.e. these private data are only sent to you?
    – Steffen Ullrich
    Commented Dec 14, 2018 at 8:28

1 Answer 1

Reset to default
2

Passing sensitive or personal information as query parameters is generally considered a problem, as it is revealed in many ways that POST data isn't. See for instance the similar question "Should sensitive data ever be passed in the query string?" OWASP has a short description of the problem: Information exposure through query strings in url.

The main problems are generally considered to be

  • Bookmarks and browser history if someone has access to the browser
  • Access logs at the intended recipient of the query (or any proxies between you and the recipient)
  • That the query parameters are included in the "referer" header sent to other servers.

What makes this case particularly interesting is that the information in question is actually a signed ID token. It can conceivably be used to authenticate the users at other service providers (though this requires a broken implementation at a service provider, a type of confused deputy problem).

Including ID tokens in this manner is actually encouraged by the OpenID Connect standard, as the id_token_hint. It can be POSTed, but most implementations (few as they are) that I have seen, use query parameters. So having the developers of your service change this could be challenging.

Improve this answer
1
  • Thanks so much. At least, it gives me a glimpse ideas how to consider it in the most of the case.
    – Ender
    Commented Dec 17, 2018 at 2:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .