What Grafana version and what operating system are you using?
Ubuntu 22, Grafana Version 9.5.3 (commit: 916d9793aa, branch: HEAD)
What are you trying to achieve?
Use the X-Grafana-User header sent in an API to filter results in that API. I wrote a Restful API accessed via JSON datasource (or Infinity) in Grafana. I plan to use this header value to limit returned results to a subset of all available results.
Specifically, I want to know if this header is:
Set in the backend (i.e. by dataproxy) and hence, I think, can be trusted to reflect the actual Grafana authenticated user, OR
Set in the front-end and so can be fudged by calling dataproxy directly with a false X-Grafana-User header
How are you trying to achieve it?
I set the configuration as so
# In grafana-ini, I set:
[dataproxy]
send_user_header = true
… and then check to see if the header is set by the client or backend.
What happened?
I saw the header as expected in the Restful API I called. I saw it:
print (request._request.headers['X-Grafana-User']) # "admin" or "user1", from Grafana
I looked in logs and the browser requests, and didn’t see X-Grafana-User. So I think it’s set in dataproxy and (therefore?) can be relied upon.
Note: This is not user authentication per-se, but related. I authenticate with the API via a seperate username/password, which is the same for all Grafana users. Many other questions relate to JSON/Auth but I think this is a unique, unanswered question.
Some other one, written by me.
It is not publicly accessible, but it takes something like https://api.com/foo/1 and returns { name: "foo", bars: 2 }. I can modify this api to read and use the header, if I can rely upon it. Authentication to the API is separate.
Looking at the source and searching for this header, I see it is set in ProxyUtil and middleware.
If my understanding is correct, the information flow goes:
Browser → make SQL → send to DataProxy (running on server) → middleware (header added) → my REST API (checks header) → JSON returned …
Since grafana-server adds the header, it can’t be injected from the browser, and can be relied on.
It depends how paranoid you are and what kind of data you want to protect.
Attacker can use man in middle attack. You will say no problem: I will use HTTPS (TLS) communication.
Attacker then can use use attack on vulnerable TLS/cipher. You will say no problem: I will configure HTTPS properly.
Attacker then will be your secops guy and he will start TLS inspections. You will say: I gave up.
Cryptograhy is used usually in this case, e.g. JWT token, so server can verify received information, that it was not tampered during transit.
What is stopping the users to use the same authentication in the Postman, but sending different authorisation details (X-Grafana-User header)?
Did you think about attack outside of Grafana?
You are asking for security approval of your idea from random people on the internet. That indicates a security problem. Also you want to use feature, which IMHO was never intended to be used for proper authorisation.
IMHO:
yes, X-Grafana-User is trustworthy for POC/academic projects with unimportant data
no, X-Grafana-User is not trustworthy for serious (enterprise) use cases, because there is no way how value can be verified. I believe you also didn’t verified different attack vectors (just example to give you an ideas, not tested, e.g. what will happen if my username will be literally X-Grafana-User: admin and there is much more attacks: different encodings/injections which will change a meaning, …).
What is stopping the users to use the same authentication in the Postman, but sending different authorisation details (