Description:
------------
Note:
- Tested with PHP-8.1.5, but I believe all PHP versions are affected
- I had to use `[:]` in all links to avoid being flagged as spam by the bug submission platform

To ensure backward compatibility with `register_globals`, PHP replaces spaces (` `), dots (`.`) and open square brackets (`[`) with underscores (`_`) in the keys of `$_POST` and `$_GET` superglobal arrays. The same string transformation applies to the keys of the $_COOKIE superglobal array.

As a result, a cookie sent by the browser as `Cookie: ..Host-test=foo` is treated by PHP as `Cookie: __Host-test=foo`. Notice that cookies with `__Host-` and `__Secure-` prefixes have a special semantic (see [MDN: Set-Cookie, Cookie Prefixes](https[:]//developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes)) which ensures, for instance, that `__Host-`-cookies sent by the browser cannot be overwritten by a network attacker or by a [malicious sibling domain](https[:]//canitakeyoursubdomain.name/).

This vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim's browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications. The reported issue is related to [CVE-2020-7070](https[:]//bugs.php.net/bug.php?id=79699).

Notice that this issue raises further integrity concerns when legitimate cookies contain the underscore symbol. For instance, non-secure origins can use this bug to "overwrite" secure cookies, violating point 16 of the [Cookies Storage Model (Sec. 5.5)](https[:]//datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-10#section-5.5).


### Vulnerable Example
Consider a website at https[:]//bank.com which adopts the double-submit CSRF protection together with `__Host-`-cookies to ensure high integrity of POST requests, as described in the [Cross-Site Request Forgery Prevention Cheat Sheet](https[:]//cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#cookie-with-__host-prefix). This solution works by matching the value of a special cookie (`__Host-xsrf=<token1>`) against a POST variable (`_xsrf=<token2>`). If the values are equivalent, i.e., `token1 === token2`, then the request is accepted, otherwise it is rejected. Given that the token value is secret and attackers have no way to forge a request with an arbitrary `__Host-xsrf` cookie, the solution is effective against CSRF even in presence of a powerful attacker.

Due to the reported vulnerability, a same-site attacker can lure a victim into visiting a page at http[:]//test.bank.com which:
1. Sets the cookie `..Host-xsrf=eviltoken; domain=bank.com; Path=/app`
2. Executes the HTTP POST request to https[:]//bank.com/app/transfer with parameters:
   - `to=<attacker>`
   - `amount=1000`
   - `_xsrf=eviltoken`
3. The PHP backend at https[:]//bank.com receives the HTTP header `Cookie: ..Host-xsrf=eviltoken; __Host-xsrf=goodtoken` which is stored in the `$_COOKIE` superglobal array as `Array( [__Host-xsrf] => eviltoken )`
4. Given that the values of the `__Host-xsrf` cookie and `_xsrf` parameter match, the request is accepted, bypassing the CSRF protection.

### Proposed Solution
Cookies should be parsed according to the standard [rfc6265bis](https[:]//datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-10) without being affected by additional string transformations.