symfony: [Security] access_control host option can't be trusted?

There’s a few options to match the access_control rule and host is one of them: http://symfony.com/doc/current/security/access_control.html#matching-options

This all looks fine but it gives the impression you can grant or deny access by matching the host. Sadly this value can be spoofed and doesn’t do a reverse dns lookup (which would probably slow everything down by a lot).

While matching on host can be nice, especially for routing, I don’t think this has any place in the access_control as it can lead to security issues.

Case: I had a page which should’ve only been visible from the internal network. Someone added ROLE_NO_ACCESS unless a certain host was matched. Example from the docs (with host instead of IP):

# app/config/security.yml
security:
    # ...
    access_control:
        #
        - { path: ^/internal, roles: IS_AUTHENTICATED_ANONYMOUSLY, host: some-internal-domain\.com }
        - { path: ^/internal, roles: ROLE_NO_ACCESS }

This looks secure and would mean you don’t have to work with IPs (as they can change in theory). The problem comes when you have this on a public website (think of liip monitor bundle for example). While it looks safe, with a simple hostname spoof, you’re in. I don’t think this option should be in the access_control as is (and possibly not even the firewall).

Or am I mistaken and did I miss something?

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 26 (26 by maintainers)

Most upvoted comments

The goal of the host option is if you do host base routing.

If you have an admin interface available on admin.example.com you need to be able to define access_control rules only for this domain.

Spoofing is not a problem in this case because if you spoof the domain you will be routed to the non-admin version of the website instead.

jvasseur on Sep 19, 2016

@iltar well yes and no, when you have access_roles for one firewall, you don’t want to match those for other firewalls.

security:
    # ...
    access_control:
        - { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/, roles: ROLE_ADMIN, host: admin.example.com }
        - { path: ^/, roles: ROLE_USER, host: example.com }

But there should a warning about using a hostname to GRANT access to a specific uri. Because that’s the current problem.

sstok on Sep 19, 2016