I'm not sure I understand the issue here.

The feature is already present and can be disabled, so why should it be dropped?

Same as @jmsche.

When you go to entity show view for exemple, you can"t modify Id in URL and go to different ID, you have to go list and click on other show link to have this signature.

I think remove the referrer url from the query url is more needed than this or make more pretty the url.

This feature can be desativated by default if you want.

@ioniks about "pretty URLs", our opinion is that it doesn't matter because this is a backend. About "referrer", we definitely need it to provide a nice navigation flow through the backend (we can't rely on HTTP Referrer Header because some browsers block it).

@jmsche the question is not about enabling/disabling but about ... "is this really protecting anything? Does this really prevent you doing something that you cannot do in other ways?"

If we think this is truly useless, let's remove it. Less code to maintain and many less problems for users (including the current impossibility of generating dynamic URLs using JavaScript).

@javiereguiluz i think a config for have referrer in url or not is better, but it's not the question here ;)

I don't think this is useless, but if you have to drop it for a good reason I'm okay with this.

I am for removing it. Nobody has found any real use case or attack where this feature protects the application in the discussion so far. Even for a signed URL we still must check for permissions (for routes, actions, entities,..). And, the Symfony security features already provide almost everything I ever needed..

Removing it means less code, less complexity, less maintainance, less issues hopefully..

I also agree to: “provides a false sense of extra security“ - unless somebody can give a real example where this really can provide security.

@michaelKaefer
I think it's a not a good idea to remove URL signature. Lot's of CMS use this feature for security reasons.

First of all, it is simply possible to deactivate it if you do not wish to use it.

Then, I use it in several projects and it allows to protect the urls, we cannot access another entity if we use a UUID identifier and change it directly in URL.

@john-dufrene-dev but, if you search in the backend for that other UUID (or part of it) you'll get that other entity and you can see its details.

In other words, can anyone prove that signing URLs protects some resource in some way that you cannot access it via a different way (e.g. via pagination, search or filtering)?

@javiereguiluz Okay, I understand what do you mean, sorry my english not the best.

Url signature in my opinion makes it possible to protect a change of parameters directly in the url and therefore the injection of malicious code.

Indeed to block access to resources with filters, search or other it is necessary to use a security system like Voter.

But I don't understand why just disabled this feature if you don't need it ?
By default could be disabled too

Why remove this (if we reach the conclusion that it doesn't protect anything at all)? Because having this feature not only means maintaining it ... but it also complicates other features; even making them impossible (e.g. because we can't generate routes dynamically using JavaScript).

I am not a security expert by any means, but I don't really see what benefit it offers. I would be fine seeing it go away.

I am not a security expert by any means, but I don't really see what benefit it offers. I would be fine seeing it go away.

If another user send you a link with delete thing and change the ID for exemple the id of your account or the admin account.
You can broke your app.

@ioniks This sounds like a CSRF attack, I think you should be protected against it by using Symfony forms out of the box. I did not test it now but I think it is like that. For deleteions I'm not sure now if forms are used or if there is any CSRF protection in EA (I would strongly guess there is), I could check that the next weeks. Also I'm not sure if deletions are possible in EA with a GET request (= clicking on a link), I did not test it now.

I would love to see this "feature" removed. I seems it gives a false sense of security, security that should already be covered by Symfony via security, access control, XSS, CSRF, ...

It is switched off in all my projects so okay for me as well

i agree in removing it, there are other specific ways to protect resources

For me, it does not really protect your backend. There are several ways to protected again URL hacks and using EA permissions and Symfony security (voters by example) is sufficient, even if you can hack the URL, you will not be able to perform the action if you don't have rights to do it.

Just a thing, passing the referrer in the URL seems ugly, why not passing the referrer using sessions ?
Same for the crudController crudControllerFqcn=App\Controller\Admin\UserCrudController maybe just do crudControllerFqcn=UserCrudController and find a way to retrieve the namespace App\Controller\Admin if possible.

The fact that the admin area is secured by some roles doesn't prevent CSRF attack, so I would not count firewalls as an argument in favor of removing the signature.

a few parameters that can be used to attack a backend by [...]

This is what roles protect against: having a non allowed user do those things. But signing the query doesn't help at all in this regards - the firewall is enough.

To me, the signature is absolutely required to prevent against CSRF attack because easyadmin allows changing the state of things via GET requests. This is a critical design issue in EA to me, and the signature mitigates the issues this opens.

My personal conclusion is: yes, let's remove these signatures, but only after we ensure that all requests with side effects go through a POST.

@javiereguiluz This is already solved, or? The actions new, edit and delete use POST requests already (still they use query parameters like in a GET request but the method is POST) - or am I missing something? Plus: all 3 use CSRF tokens by default (I just checked it).

I will try to write some functional tests the next days to check it.

@michaelKaefer yes, everything should be OK: delete action has been using forms for long, edit/new used POST requests since the begining I think. The only issue was the toggles, which made a GET request to change the value of a property, but you fixed that in #4981. We also use CSRF tokens everywhere, so I think all issues were solved 👍

I don't feel qualified to give an opinion, but if they are kept, I'd definitely support making disabling the signatures easier via configuration.

@richard4339 as explained in https://symfony.com/bundles/EasyAdminBundle/current/dashboards.html#dashboard-configuration you can disable signatures just by calling one method on your dashboard:

    public function configureDashboard(): Dashboard
    {
        return Dashboard::new()
            // ...
            ->disableUrlSignatures();
    }

@richard4339 as explained in https://symfony.com/bundles/EasyAdminBundle/current/dashboards.html#dashboard-configuration you can disable signatures just by calling one method on your dashboard:

    public function configureDashboard(): Dashboard
    {
        return Dashboard::new()
            // ...
            ->disableUrlSignatures();
    }

Thanks @javiereguiluz I'd completely missed that.

@javiereguiluz Thank you for your infos! In my fix #4981 I missed to fix the CSRF problem so I think this must be done before removing the URL signatures like others pointed out above. I created an issue: #5028. For the actions I did a PR which adds tests.

The PR was merged: #5028. That means that URL signatures could be removed now I guess. @javiereguiluz Did you decide yet and do you want a PR?

A non-obvious side effect of removing signatures is that with multiple dashboards you can bypass security set with setEntityPermission on a given Dashboard's configureCrud method.

The documentation never really says that different Dashboards are completely separate (because they aren't), but it definitely feels that way due to how the configuration is set up.

You could have two dashboards (even in different namesapces!) that don't share any controllers, entities or anything, and rely on the Dashboard security through setEntityPermission. This works correctly when you only use internally generated links (except for an edge case where AssociationField automatically links to the target CRUD controller that's supposed to be displayed under a different dashboard than the one that links to it), but you can manually craft a URL with the different dashboard, and since now the configureCrud method is not run (or more specifically, it's run under the other dashboard) this can lead to change in privilege requirements and access to resources the user shouldn't have access to.

Importantly, the documentation also suggests that "securing the whole backend" through security.yaml's access_control is a good idea, which it ... isn't. It should be more explicit that it's a good first line of defense, but one should use Voters for access control and check each action properly, ignoring what dashboard it runs from.

I think the documentation should be more clear about this behavior, and ideally setEntityPermission should not work under dashboard's configureCrud because it's meaningless.

Well that, or even better, force users to explicitly "link" controllers with dashboards, so a given Controller can only be under the dasboard it's allowed to live under. This could also improve linking between Controllers of different Dashboards. Which, as a side note, is problematic - f.e. with the AssociationField.

IMHO the app dev is responsible for configuring EA - which includes calling setEntityPermission() on every DashboardController where it's necessary.

(For access_control vs. voters: there are apps that don't need any custom voters nor special entity permissions)

calling setEntityPermission() on every DashboardController where it's necessary

I'm not sure you understand; when you have different dashboards that are meant to be completely separate with their separate Crud Controllers and also separate permissions, you can still use either Dashboard to render any Crud Controller that exists in your app with no limit, potentially using lower permissions to access a resource that's supposed to be better protected.

That's extremely non-obvious and IMO should be fixed or at the very least explicitly documented.

Yes I understood it like this. I don't see a problem with this, AFAICS a CRUD controller doesn't belong to one dashboard. Maybe you can add it to the docs if you miss something. Or maybe there are more opinions.