The header `Access-Control-Allow-Origin: *` can be injected in the responses

[data-sync-user]

HackerOne Report: https://hackerone.com/reports/2397360 Report Date: February 29, 2024, 10:43pm UTC Reporter: p3db Weakness: Improper Neutralization of HTTP Headers

Initial Report:

Summary:

An attacker can inject the header Access-Control-Allow-Origin: * to the responses by adding Origin: null in the HTTP request.

Steps to Reproduce

Request (normal request)

GET /api/v1/suggest?q=firefox&providers=localhost&client_variants=001 HTTP/2
Host: stage.merino.nonprod.cloudops.mozgcp.net
Sec-Ch-Ua: "Chromium";v="121", "Not A(Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
X-Request-Id: 0x
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=0, i

Response (normal)

HTTP/2 200 OK
Server: nginx
Date: Thu, 29 Feb 2024 22:38:37 GMT
Content-Type: application/json
Content-Length: 113
X-Request-Id: fa69d763cb534edb9bb945c2ebb33758
Access-Control-Expose-Headers: X-Request-ID
Strict-Transport-Security: max-age=31536000
Via: 1.1 google
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{"suggestions":[],"request_id":"fa69d763cb534edb9bb945c2ebb33758","client_variants":["001"],"server_variants":[]}

Proof of Concept

AddingOrigin: null in HTTP request

GET /api/v1/suggest?q=firefox&providers=localhost&client_variants=001 HTTP/2
Host: stage.merino.nonprod.cloudops.mozgcp.net
Sec-Ch-Ua: "Chromium";v="121", "Not A(Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
X-Request-Id: 0x
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=0, i
Origin: null

Response with Access-Control-Allow-Origin: * injected.

HTTP/2 200 OK
Server: nginx
Date: Thu, 29 Feb 2024 22:20:11 GMT
Content-Type: application/json
Content-Length: 113
Access-Control-Allow-Origin: *
X-Request-Id: 8ff370cb49624bf1bd850d001854a769
Access-Control-Expose-Headers: X-Request-ID
Strict-Transport-Security: max-age=31536000
Via: 1.1 google
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{"suggestions":[],"request_id":"8ff370cb49624bf1bd850d001854a769","client_variants":["001"],"server_variants":[]}

Impact

The exploitation of this vulnerability is crucial to chain with other vulnerabilities/attacks, highlighting the bypass of the CORS configurations.

┆Issue is synchronized with this Jira Bug ┆Attachments: Access-Control-Allow-Origin_authenticated.png | Access-Control-Allow-Origin_no_auth.png

[data-sync-user]

➤ Scott Fraser commented:

Conversation in HackerOne ticket ( https://hackerone.com/reports/2397360 ) to date:

{quote}Scott Fraser commented in H1:{quote}

Hi p3db (hackerone reporter), can you provide a link which would trigger this CORS issue? If a victim needs to intercept their own request to add a header, we consider that a session fixation issue.

{quote}p3db replied:{quote}

Variant analysis:

Check this vulnerability on other variants of *.nonprod.cloudops.mozgcp.net

scott-f, I consider it a more severe issue because if the header Access-Control-Allow-Origin: * can be inserted in the responses, then, if an attacker has an XSS, he is able to chain it, thus bypassing CORS.

When such header is in the responses, the attacker can use XHR to set a new request header, in this case, Origin: null and open the website in a new window, with the XSS payload and the malicious header.

In short, if there is an XSS to combine with this vulnerability, then it would be like:

• Attacker sets up a malicious page that opens a new window redirecting to the asset domain using the malicious header and the hypothetically XSS payload.
• Victim visits attacker's website; the malicious window is triggered; victim gets infected.

{quote}Scott Fraser replied:{quote}

Hi @p3db, I checked our documentation here ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin ) and it says Attempting to use the wildcard with credentials results in an error.. This bug only returns when the user does not provide a cookie. When a user provides a cookie, Access-Control-Allow-Origin returns null, not .

!Access-Control-Allow-Origin_authenticated.png|width=1020,height=329!

!Access-Control-Allow-Origin_no_auth.png|width=1042,height=323!

The documentation also says Note: null should not be used [...].

I agree that with an XSS bug (no known XSS to trigger this Access-Control-Allow-Origin issue is known at time of writing), this issue might be used for malicious activities. I'm going to request additional information from the team that manages this service and see what they say. Thank you for being patient with us while we sort this one out. As updates are made available, they will be posted here (here in context is HackerOne).

[data-sync-user]

➤ Scott Fraser commented:

The problem is a misconfiguration of the Access-Control-Allow-Origin response header when the client request contains the header Origin: null. MDN docs ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin ) says that Access-Control-Allow-Origin is only supposed to reply with * for unauthenticated users, and Null should not be used at all as it’s function may change in the future. An as yet unknown XSS vulnerability may be able to leverage this Access-Control-Allow-Origin: null into a issue at a future time.

[data-sync-user]

➤ HackerOne JiraIntegration commented:

p3db posted a comment on HackerOne: Sure @scott-f, will be looking forward to it. Just a note, in short we can say that it affects unauthenticated users but remember that a user that has a valid login may end up on an infected page that he will use to actually submit the login.

[data-sync-user]

➤ Scott Fraser commented:

Hi Nan Jiang, can you take a look at this HackerOne report and help determine the impact or if it needs to be fixed? It seems like Access-Control-Allow-Origin header may be improperly set if a user provides the header Origin: null.

[data-sync-user]

➤ Nan Jiang commented:

Hi Scott Fraser, thanks for the flag! We will take a look into this.

[data-sync-user]

➤ Nan Jiang commented:

After reviewing the CORS settings ( https://github.com/mozilla-services/merino-py/blob/main/merino/main.py#L62-L67 ) in Merino, we believe that the settings are configured as expected. Here is more context:

• Merino is the API backend for Firefox Suggest in Firefox (Desktop for now with the future expansion to Mobile), therefore, we set Access-Control-Allow-Origin: * in the response by default
• Merino doesn’t require any authentication, nor does it uses other user credentials, so we set Access-Control-Allow-Credentials:false
• All the API responses of Merino are returned in JSON rather than HTML, and the consumers in the browser would validate the JSON responses and then use the validated results to render the content. This should mitigate the XSS attacks that make use of malicious scripting in HTTP
• In the event of attackers injecting malicious scripts into the query parameter of the API request, Merino would also validate/normalize the query string. More importantly, Merino would never echo the problematic query string back in the API response (it will return an empty payload instead) if it couldn’t find any suggestions from the suggestions providers, nor would it persist those queries anywhere

To my understanding, the above handling should defend most of the XSS attacks. Though I am also open to hearing other thoughts if i missed anything.

cc: Scott Fraser Frida Kiriakos

[data-sync-user]

➤ Scott Fraser commented:

Thank you for reviewing this issue. That all looks good to me and I will close out the HackerOne report as informative.

[data-sync-user]

➤ HackerOne JiraIntegration commented:

scott-f closed the report on HackerOne as informative: Hi @p3db, I chatted with the developers and reviewed source code that generates this header for Merino here. After review, and considering the context of this application's use case, header Access-Control-Allow-Origin is set correctly. Thank you for researching this potential issue and bringing it to our attention for review.