1

I'm trying to setup Sonarqube behind a Azure Web App using .NET Core's proxy library. This might sound weird but as Web Apps provide a SSL certificates automatically and I am not able to get a custom domain I thought this solution to be the easiest for me ;)

Now after some playing around everything works great, the site works without any errors in browsers, the Log-in is possible using Sonar login or Azure Active Directory.

But in my build processes it is just not possible to post the analysis result to the server. The response is always 401.

I have checked the Sonarqube logs and found the following corresponding entries:

in Web.log

DEBUG web[...][auth.event] login failure [cause|Wrong CSFR in request][method|JWT][provider|LOCAL|local][IP|some ip|actual client ip:37390][login|admin]

in access.log:

some ip - - [...] "POST /api/ce/submit HTTP/1.1" 401 - "-" "Mozilla/5.0 ..." "..."

Therefore I can see that the actual sonar request comes from a different IP, probably because of the network setup or any other Azure magic.

I cannot figure out how to solve this issue :D

My reverse proxy solution is very simple. Basicly I use a simple empty ASP.NET Core application and integrate the reverse proxy functionality in the Startup.cs like this:

app.RunProxy(new ProxyOptions
{
    BackChannelMessageHandler = new HttpClientHandler
    {
        CheckCertificateRevocationList = false,
        ServerCertificateCustomValidationCallback = (message, certificate2, arg3, arg4) => true,
        AllowAutoRedirect = true,
        AutomaticDecompression = DecompressionMethods.GZip,
        CookieContainer = new CookieContainer
        {
            Capacity = int.MaxValue,
            MaxCookieSize = int.MaxValue,
            PerDomainCapacity = int.MaxValue
        }
    },
    Scheme = serverConfiguration.Scheme,
    Host = serverConfiguration.Host,
    Port = serverConfiguration.Port,

});

I also added some middleware to add the X_FORWARDED_PROTO header and I check if the X-Forwarded-For header is configured correctly. I also configured the Azure IIS to not truncate query parameters or content in large requests via the web.config way.

I also tried to fake it and set the X-Forwarded-For IP to the IP sending the actual request to Sonarqube with no effect.

Has anyone an idea how to get this solved? :) As this is just a POC setup I would love to just turn CSRF checking off but i could not find any config for that. Any help would be appreciated.

Edit + Current Solution

Thinking a bit more about my initial solution the problem becomes quite clear. I am trying to connect to the server by using Azure App Service's VNet Integration Feature. This provides a secure VPN Connection between the Proxy site and the actual server. But it also causes the IP to be different than expected:

Client [Client IP] -> Web App Proxy [Proxy Public IP] -> VNet VPN [VPN IP of the Web App == some ip in the logs] -> Sonarqube => 401 CSRF error

I guess that the X-Fowarded-For chain is not correct in that case, and I don't know how to fix that.

Now, as a workaround, I have added a Public IP to the Sonarqube server and configured the Network Security Groups to allow traffic only from the Web App (using the provided outgoing IP addressess of the Web App). With that solution everything works :)

I still would like to facilitate the VNet integration feature, so if someone has an idea, please let me know :)

maki.stud
  • 11
  • 4
  • According to your description, I guess the reason why you get the Wrong CSFR in request is your jwt token(which stored in the cooke)'s CSRF_JWT_PARAM isn't equal with your request's CSRF_HEADER value.So I suggest you could check your request's header when you redirect your request to your local server. – Brando Zhang May 22 '17 at 07:39
  • Hmm, I guess I could modify the JWT in the proxy implementation but somehow I have a bad feeling about this :D Is this the default way proxies are doing it? I thought the only thing required would be the `X-Forwarded-For` chain? – maki.stud Jun 05 '17 at 15:34
  • As far as I know, the CSFR token is used to prevent Cross-Site request attack. Now, what you doing is adding a middle site to redirect the request to your local server. This is the cross site. So you will face this issue, because the sonarqube will check the CSFR token. As I says, the reason is the CSFR token, the two site's request isn't same. More details, I suggest you could refer to this artilce:https://stackoverflow.com/a/33829607/7609093. This isn't a good way, I suggest you use normal way to buy a custom domain and bind it with your server or use VNET. – Brando Zhang Jun 08 '17 at 09:47

1 Answers1

1

we have the same problem with Sonar behind Apache as reverse proxy with SSO. Apache sends the SSO Headers in the proxy request to sonar.

I have reported this problem to google group as bug:

"Sonar native login form displayed randomly even if SSO is used"

https://groups.google.com/forum/#!msg/sonarqube/o2p2ZmjqRN8/UAZZF3tMBgAJ

What I have found is, that apache reuses one connection for different users. User-A comes through Apache-Sonar connection-1, then Apache reuses this connection for other request of other user-B and then next request in the same Apache-Sonar connection is used for new request from user-A. This request is then classified as unauthorized and Sonar generates Login Form, although the Apache request contains the headers with SSO Login data.

Today, I have activated DEBUG logs and found the message "Wrong CSFR in request". It looks really like CSFR protection, but with some bug, as if the code does ignore username or something like this.

Regards,

Robert.

Robert
  • 11
  • 1