HSTS check fail with Connect Security Requirements Tester (CSRT)

Jira Development Jira Cloud
, , , ,
1

Hi,
We are following the Security requirements for cloud applications and we are struggling to make the Connect Security Requirements Tester (CSRT) verify the Requirement 1.2 - HSTS Validation. Our application is using Atlassian Connect Spring Boot library and we have implemented a custom request interceptor to add the security header (HSTS) in each request’s response headers. In result, the security header is applied, but the checker tool is still failing.

image
image1163×339 15.9 KB

Have you encountered this problem? Have you managed to solve it? Any opinion is highly appreciated.
Thank you in advance.

Kind Regards,
Philip

3 Likes
2

Make sure to check if the header is available on every endpoint that is scanned. The scanner will check all endpoints listed in the descriptor, incl. webhooks

3

That is the problem. We have checked all the endpoints and they all have the security header. When running the command with the debug flag ( python main.py https://xxxx.xx/xx-xx/atlassian-connect.json --debug=True/False --json_logging=True/False ) no ERROR logs are found. We wanted to ask you whether you have implemented the HSTS header only on the backend side of your application or you have some configuration on your host (AWS for example) ? Thanks.

Regards,
Philip

1 Like
4

The ticket was automatically closed after a while, and then a new one was opened - does it work as intended?

5

I did not get you. What ticket?

6

I’m sorry for not being clear. We received the same notification for one of our apps, but this ticket was automatically closed after few hours, even though we did not change anything in our infrastructure.

7

That is right. We received a ticket, too and started a conversation with an Atlassian member, but they still tell us that the problem persists. Nevermind, would you mind sharing with us whether you have implemented the HSTS header only on the backend side of your application or you have some configuration on your host (AWS for example)? Thank you in advance.

Regards,
Philip

8

The HSTS header is implemented only on the backend side of our app, and when manually tested it works fine.

9

Hi @Grzegorz.Tanczyk could you please point me to the ticket number that you are referring to? I can take a look.

10

Hi @fkasapov, could you please tell me the ticket number that is assigned to you? I can take a look at it to see what’s going on

13

Hi @AnshumanBhartiya ,
Thanks for reaching out. The ticket key is AMS-12098 . Actually we are leading a conversation with you in it. Unfortunately, we have not come up with a solution yet. Any suggestions would be highly appreciated.

Kind Regards,
Philip

14

This is my ticket: Log in with Atlassian account

15

@fkasapov If you are using Atlassian Connect Spring Boot library, according to my notes, the HSTS header should automatically be implemented by the library. This was fixed in version 2.0.7. What version are you on?

16

@Grzegorz.Tanczyk I see what you’re saying. First of all, thank you so much for bringing this to our attention. If you see such weirdness again in the future, please feel free to create a ESSD request here Jira Service Management. This should not be happening definitely.

I can tell you that there is one more case where we’ve observed this behavior and although not 100% confirmed (we are still investigating), I believe this is happening because our scanner doesn’t handle HTTP/2 very well.

I just verified that when I manually send requests to your app’s endpoints, I do see the HSTS header however, when the scanner runs, it doesn’t detect it hence it creates a ticket. Why the ticket gets auto patched by the scanner - I am surprised because it should continue detecting the issue and should keep the ticket open.

So, a couple of action items on my end:

  • I will continue investigating how to handle HTTP/2
  • I will investigate why the scanner is auto patching and then re-opening. We have not seen this with other apps. At least, nobody has reached out yet.

When I have an update, I will post it here.

Thanks!

2 Likes
17

@AnshumanBhartiya The version of Atlassian Connect Spring Boot library is 2.1.5 . However, if you check manually the endpoints you will be able to see the HSTS header. Can you confirm?

18

Hi @fkasapov , I am still not seeing the HSTS header on all the endpoints. My last comment on your ticket still stands.

19

Hi @fkasapov - we fixed a bunch of things in our scanner and now it detects any redirects as well. As a result, your ticket was auto-patched today. Please feel free to create a request here Jira Service Management if you have any further questions/concerns about the Ecoscanner.

1 Like
20

Hi @Grzegorz.Tanczyk, as promised I am back to give you an update here. As you might have already noticed, your tickets got auto patched and there was no new ticket created as it was happening before. This happened because we fixed a bunch of things in our scanner. We made our HSTS check as its own check and we no longer rely on a library (sslyze) that we used to before.

In the future, if you see tickets getting patched and new tickets get created with the same content, please create a request here Jira Service Management and let us know about it. It should not be happening anymore.

21

Hello @fkasapov,
We encountered the exact same problem months ago, you can add this configuration in your WeSecurityConfiguration (extends WebSecurityConfigurerAdapter)

@Override
    protected void configure(HttpSecurity http) throws Exception {
        http.headers()
                .httpStrictTransportSecurity()
                    .includeSubDomains(true)
                    .preload(true)
                    .maxAgeInSeconds(31536000)
                    .requestMatcher(r -> true);
        http.headers().contentTypeOptions();
        http.headers().frameOptions().disable();
        http.headers().referrerPolicy(ReferrerPolicyHeaderWriter.ReferrerPolicy.NO_REFERRER);
    }

Have a nice day :+1:

5 Likes
22

Thank you, @AnshumanBhartiya for your cooperation and leading us through this.