0

We're implementing SonarQube in our environment running behind an IIS proxy for HTTPS connection.
After running a security scan on the application (HP Fortify), it came back with some cookie security issues, Specifically as follows:

Cookie Security: Cookie Not Sent Over SSL (4720)
CWE: 614

GET /sonarqube/ HTTP/1.1
Host: sonar
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
X-WIPP: AscVersion=16.20.608.0
X-Scan-Memo: Category="Crawl.EventMacro.Startup";
SID="F0A2B8712E7F609FAA4899C"; SessionType="StartMacro"; CrawlType="None";
X-RequestManager-Memo: sid="13442"; smi="0"; Category="EventMacro.Login";
MacroName="sonarqube-priv-loginmacro";
X-Request-Memo: ID="0e42a-fcf-4b6-a8f-0fbceb4c"; ThreadId="169";
Pragma: no-cache
Cookie: CustomCookie=WebInspect0
Response:
Report Date: 09/3/2017 38
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-Type: text/html;charset=utf-8
Location: https://sonar/sonarqube/sessions/new
Server: Microsoft-IIS/10.0
Set-Cookie: JSESSIONID=XXX; Path=/sonarqube/; HttpOnly
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1...TRUNCATED...

Do you think this is due to an IIS configuration or that's just a standard configuration within the SonarQube application here?
I'm not sure how to interpret the results here or how to dig through it.
Any suggestion would be appreciated.

G. Ann - SonarSource Team
  • 22,346
  • 4
  • 40
  • 76
lapfrank
  • 11
  • 4

2 Answers2

0

With a reverse proxy such as IIS, you have to configure the reverse proxy to send the following header to SonarQube : X-Forwarded-Proto: https.

You can have a look here : IIS Equivalent of "proxy_set_header X-Forwarded-Proto https;"

With this header set, the session will have the secure flag that is missing.

Eric Hartmann
  • 1,691
  • 8
  • 8
  • Thanks Eric. I already have the `X-Forwarded-Proto: https` set in `IIS`. The rest of the traffic is `https`. As per the link you referenced, I tried adding `HTTP_X_FORWARDED_SCHEMA` too, but it didn't work. I had followed the steps linked to in the official SonarQube install [here](http://blog.jessehouwing.nl/2016/02/configure-ssl-for-sonarqube-on-windows.html). It seems like I'm missing something for the cookies to be set to secure. – lapfrank Oct 10 '17 at 16:28
  • I was able to reproduce the same thing using NGINX. The `JSESSIONID` doesn't have the `secure` flag. `location / { proxy_pass http://localhost:9000/; proxy_read_timeout 90; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto "https"; }` – lapfrank Oct 10 '17 at 18:22
  • @lapfrank can you tell me which SonarQube version are you using ? – Eric Hartmann Oct 11 '17 at 08:49
  • I'm using version 5.6.6 LTS. – lapfrank Oct 11 '17 at 20:19
  • Oh I see 5.6.6 is still using Ruby on Rails and secure flag is missing on those cookies. The best way is to configure IIS to add this missing flag. I'm not a IIS expert but something like https://stackoverflow.com/questions/25676490/using-iis-rewrite-to-add-httponly-flag-to-cookies-not-working#32904611 will fix this. – Eric Hartmann Oct 12 '17 at 05:44
  • Thanks Eric. Looks like this would work, I'll give it a try. I think my solution of editing the `web.xml` in the embedded tomcat is closer to the root of the problem and a better place for the fix until we upgrade to newer versions? – lapfrank Oct 12 '17 at 21:58
  • I'm unsure because I think the main issue is in Ruby code. The easiest way for me is to do it in the reverse proxy. – Eric Hartmann Oct 13 '17 at 06:40
0

Thanks to this answer, I was able to set the flag to secure on the JSESSIONID cookie.

In the embedded tomcat instance in WEB-INF\web.xml, I added the secure true line:

  <session-config>
    <!-- in minutes -->
    <session-timeout>20</session-timeout>
    <cookie-config>
      <http-only>true</http-only>
      <secure>true</secure>
    </cookie-config>
  </session-config>

This is probably not the safest way to do this, since it seems to force the secure flag in any event, but since I am behind the reverse proxy and deny any incoming connections except for https/443 traffic, it should work.

lapfrank
  • 11
  • 4