Grafana Reverse Auth Proxy has failed to load its application files

[adminf2ab]

Hi,

I am trying to show grafana dashboard or charts in my web application,

I read a lot of topics in Grafana community about this issue and nothing fixed my issue.

Below are my configurations and my full implementation.

I get 200 Ok response and I can see below info in the response.

Below is my nginx configuration

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}


server {
    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name  localhost;


    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-WEBAUTH-USER $remote_user;
        proxy_pass http://grafana.staged-by-discourse.com/;


     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #
        add_header 'Access-Control-Allow-Headers' '*' always;
        #
        # Tell client that this pre-flight info is valid for 20 days
        #
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
     }
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
    }
 location /api/live {
    rewrite  ^/(.*)  /$1 break;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $http_host;
    proxy_pass http://grafana.staged-by-discourse.com/;
  }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/localhost/fullchain.pem; # managed by 
                                                                                                      Certbot
    ssl_certificate_key /etc/letsencrypt/live/localhost/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

grfana.ini

[security]
cookie_secure = true
cookie_samesite = none
allow_embedding = true

[auth.basic]
enabled = true

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true
sync_ttl = 60

my frontend html code (angular)

 <div [innerHTML]="grafanaData" >
    
      </div>

service.ts file(angular)

 getGrfanaData(url:string) {
     return this.http.get(url, {
    headers: new HttpHeaders().set("X-WEBAUTH-USER", this.username)
     .set("Content-Type", "application/json"),responseType:'text'
      });    
  }

output

Please don’t send me the generic links. please paste your answer below.

[jangaraj]

It works on my computer™:

Seriously, you are giving away your Grafana admin access, data, … .

[jangaraj]

I think you don’t understand security consequences. I was cautious and I didn’t publish any private details, but black hat guys won’t give you any chance.

[yosiasz]

you want to discuss security issues with someone you are engaging with in a forum? Though a very qualified person (=> @jangaraj) You are asking to be ransomed for sure.

[jangaraj]

Why this particular config is dangerous.

1.) auth.proxy config in the Grafana means that proxy must handle authentication/authorization - Grafana trusts blindly to the value, which is in the X-WEBAUTH-USER header
2.) nginx is not performing any authentication in this case or any checks

Attacker will set own custom header X-WEBAUTH-USER on their side. For example there are plugins for the browsers, where you can define custom header per domain - plugin will add configured header to all domain requests.

But which username should we use? There is default admin user with Admin role (it is configurable, but I guess 99.999% of Grafana instalations use this default admin username for admin user). So attacker will configure header X-WEBAUTH-USER:admin and load targeted Grafana instance in the browser - attacker will be admin user there instantly.

I know that “Holy Grail” of all SPA devs is to have seamless Grafana integration. But you need to keep security in the mind.

For the record: my recommendation GitHub - jangaraj/grafana-iframe