Symfony version(s) affected: all I think

Description

Request::get looks at the following data:

• $this->attributes
• $this->query
• $this->request

in that order. So it checks $_GET before it checks $_POST. I haven't checked, but I think it might have been implemented this way because of a misunderstanding about how the ini setting request_order works: The default there is GP, but

Registration is done from left to right, newer values override older values.

so P (POST) takes precedence over G (GET)

and if you think about it, that is the only logical order, because the way Symfony does it, allows for trivial attacks by sending malicious links to users which completely override whatever they enter in a (POST) form.

How to reproduce

If the backend code uses (directly or indirectly) $request->get() and you have a POST form in the frontend, anyone can make a malicious link like /order?selectedproduct=ultra-deluxe-edition which completely overrides anything the user enters in a form, without them knowing. So for POST forms, $request->get() is outright dangerous.

If your frontend code uses a GET form, then your backend might as well just use $request->query->get(), because where is the POST data going to come from? The only way to get POST data in this scenario would be if the backend code adds it itself programmatically. But if the backend code does that, it might as well just add its stuff to $request->attributes or modify $request->query directly.

Possible Solution

There seems to be no scenario where Request::get can be used safely and does something useful. One way to fix this would be to invert the order, i.e. look at POST before looking at GET, but that would be a very hard to detect BC break. So it might be best to just get rid of the function completely

Additional context

See discussion in #40974