Earlier I wrote about the Security Report Chain (via security.txt), how one documents their policy on vulnerability reporting. You can see the the Agilicus’ security.txt here, as well as the policy. Well, people find them, and, they send you information in the hopes of gigantic bug bounties. Let’s talk about the reports.
The Security Report Chain breaks down into 2 categories so far. The first are exceptionally basic, no research, things like “your web site runs on non-tls”. Well, yes… but all it does is “301 redirect https://”, here we have an HSTS record. And, we are all-in on TLS, being on the preload list. So, uh, thanks for nothing.
Its the second type of Security Report Chain that intrigue me more. They have taken some time. I think they have some automated tools. And they often say things like:
I find you have https://auth.agilicus.com/.well-known/openid-configuration which links to https://auth.agilicus.com/keys which has a set of authentication keys. These should only be available to authenticated users, this is a critical vulnerability.
–some hopeful security researcher
So yes, this is true. And, it does take a bit of reading to understand what it is, and why its not only safe, but desirable. The standard is OpenID Connect, and, it has a discovery document (that first link). In turn, it has a means of discovering the current public keys, which are rotated hourly. Why do we do that? Well, the standard requires it. But what is the intent?
The first, the discovery document, this allows zero-configuration software to just work. A client can read this document, use the configuration, and proceed onwards with OpenID Connect. Nothing in the document is security sensitive (the alternative would have been to hard code it in the client). It simply says which URI to talk to to authenticate, how to obtain tokens, and, how to validate them. Does this belong in my Security Report Chain
The second, the keys (JWKS) are the public key. This allows a client which has received a token from the authentication process to independently verify it. It does not allow you to sign a token, it is not the private key.
OK, so in this Security Report Chain the reporter has done some scan, has found something of interest. Without knowing the standard, they have assumed that encryption keys should not be available unauthenticated. So they have followed my policy, reported the “problem”. But, here’s where I’m not sure what to do. They are doing this solely because they want a bug bounty. I decline to pay such for things which are “as designed, not a bug”, on principle. Would I be better to pay $5 for their diligence? I sent them a response (there were more than a few on similar topics) pointing out individual reading they could do to learn about the standards involved.
Suggestions anyone?