Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Incorrect statement regarding HTML5 cross-origin resource sharing

DAU | Last updated: Sep 14, 2016 12:32PM UTC

Hello, In burp, the issue regarding "Access-Control-Allow-Origin: *" is described as follows: Issue detail The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request which allows access from any domain. Allowing access from all domains means that any domain can perform two-way interaction with the application via this request. Unless the response consists only of unprotected public content, this policy is likely to present a security risk. Note: The application does not issue an Access-Control-Allow-Credentials header allowing two-way in-session interaction. Without this header in the response, although client code can initiate cross-domain with-cookies requests to the target, the code will not be able to read responses from with-cookies requests. This constraint mitigates the impact of this behavior in relation to cross-domain retrieval of sensitive in-session data. This is not true, since "*" origin allows only unauthenticated request to be sent. Quote: (source https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Allow-Origin) For requests without credentials, the server may specify "*" as a wildcard, thereby allowing any origin to access the resource. Anyway, I tested Firefox, Chrome, and IE, they won't send with-cookies requests when detecting "Access-Control-Allow-Origin: *". Please verify and correct the issue accordingly. Regards

PortSwigger Agent | Last updated: Sep 14, 2016 01:04PM UTC

Thanks for this feedback. We're aware of some problems with the current CORS scan check logic and reported issues. We're already working on some enhancements in this area, and we should have these ready to release within the next few weeks.

Burp User | Last updated: Jan 20, 2017 08:06PM UTC

Dear support team, Our scan(using v 1.6.39) also reported same CORS issue (medium Severity) for all our requests. "The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request which allows access from any domain. Allowing access from all domains means that any domain can perform two-way interaction with the application via this request. Unless the response consists only of unprotected public content, this policy is likely to present a security risk. Note: The application does not issue an Access-Control-Allow-Credentials header allowing two-way in-session interaction. Without this header in the response, although client code can initiate cross-domain with-cookies requests to the target, the code will not be able to read responses from with-cookies requests. This constraint mitigates the impact of this behavior in relation to cross-domain retrieval of sensitive in-session data." Should we treat it as real security risk or is this some burp suite reporting issue(non-issue)? Please advise.

Liam, PortSwigger Agent | Last updated: Jan 23, 2017 12:17PM UTC

Hi Kuldeep Thanks for your message. You haven't provided enough information for us to assess whether you have a genuine CORS issue. More importantly, you are using a very outdated version of Burp Suite. If you update to the latest version of Burp Suite (1.7.16), the scan check for CORS will be accurate. https://support.portswigger.net/customer/en/portal/articles/2327557-downloading-burp-software-and-your-license-key Please let us know if you need any further assistance.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.