By forcing the user to make a lot of requests towards a web server, an attacker is able to extract information from the page even though https is used, assuming both the browser and web server are vulnerable against SSL BREACH.
This vulnerability has been resolved in all popular web browsers and as such, it only affects people with old outdated web browsers. It is therefore understandable if you do not consider this a threat. If that is the case, please mark the finding as Accepted Risk and it will automatically be filtered out in future reports.
What can happen?
An attacker will be able to extract information from the page even though https is used. This information may be any information displayed on the page or in client side code. Common examples would be user information, CSRF tokens or credit card data.
Detailed information how the attack work
Assume we have a page that looks like this:
<?php
$token = "abcdef";
echo "Hi $_GET['user']! <br>";
echo "Your secret token is $token.";
?>If we make the user (e.g. by buying an ad on a popular website we know the target visits regularly) send several requests, the first one being as follows: https://example.com/?user=admin
The page will look like this:
Hi Admin! Your secret token is asdef.
Now imagine the response was 100 bytes (made up number).
If we now trick the user into making the following request, https://example.com/?user=adsf, the response will only be 90 bytes as there is a overlap between token and user. When there is a overlap the compression can make the response smaller.
This makes it possible to bruteforce the token, so to say. ?user=axxxx generates 99 bytes, ?user=aaxxx 99 bytes, ?user=abxxx 98 bytes etc. Trying each character until we get a partial and eventually full overlap allows us to figure out the token even though all the traffic is actually encrypted with HTTPS.
Remediation
The issue can be remediated either in the server or in the web browser. For this to be exploitable both parties must allow the dangerous request. Due to this and the fact that every popular browser has already mitigated SSL breach, some do not consider this to be a security issue anymore. This is the accepted view on it, and if you agree, you can mark the finding as Accepted Risk and it will be automatically filtered out in the future.
The best approach to mitigate this issue server side (and what our scan looks for) is to disable HTTP compression. How that is done depends on your server setup.