Fix broken admin ui access

[grantrburgess]

Adds the fix for spoofing the Admin UI, includes some minor changes around how 404 error responses are accessed and includes tests.

[jcrew99]

Looks good

[bcoles]

The issue is related to access controls. These comments don't match the issue:

        # NOTE: Allowing the reverse proxy will enable a vulnerability where the ui/panel can be spoofed
        #   by altering the X-FORWARDED-FOR ip address in the request header.

Also, the Configuration wiki page should be updated to reflect the changes introduced with beef.http.allow_reverse_proxy.

[jcrew99]

@bcoles I believe that comment relates to "fix for spoofing the Admin UI", which should be this issue.#1354
It is to stop IP Spoofing via HTTP Headers to make the server believe you are coming from another IP, thus bypassing the IP whitelisting rules.

[bcoles]

@bcoles I believe that comment relates to "fix for spoofing the Admin UI", which should be this issue.#1354
It is to stop IP Spoofing via HTTP Headers to make the server believe you are coming from another IP, thus bypassing the IP whitelisting rules.

Right, but that's not what the comment says. where the ui/panel can be spoofed by altering the X-FORWARDED-FOR ip address in the request header sounds like the admin panel can be spoofed... somehow. Sounds more like some form of injection issue, and doesn't describe the issue, which is that of access control bypass.

[grantrburgess]

@bcoles access to the admin UI is restricted to a particular subnet through beef.restrictions.permitted_ui_subnet config option. The bug was you could bypass this by changing the X-FORWARDED-FOR value in the header, allowing anyone access to the Admin UI login page. Using this IP address for non-reverse proxy applications isn't necessary which is why we've added the beef.http.allow_reverse_proxy config option with a warning. I believe this is a temporary fix until we can separate the Admin UI from the server. I believe that should resolve #1354 but if i'm mistaken please let me know.

[grantrburgess]

The issue is related to access controls. These comments don't match the issue:

        # NOTE: Allowing the reverse proxy will enable a vulnerability where the ui/panel can be spoofed
        #   by altering the X-FORWARDED-FOR ip address in the request header.

Also, the Configuration wiki page should be updated to reflect the changes introduced with beef.http.allow_reverse_proxy.

Updated.

[bcoles]

@bcoles access to the admin UI is restricted to a particular subnet through beef.restrictions.permitted_ui_subnet config option. The bug was you could bypass this by changing the X-FORWARDED-FOR value in the header, allowing anyone access to the Admin UI login page. Using this IP address for non-reverse proxy applications isn't necessary which is why we've added the beef.http.allow_reverse_proxy config option with a warning. I believe this is a temporary fix until we can separate the Admin UI from the server. I believe that should resolve #1354 but if i'm mistaken please let me know.

This is correct, however the comment in the configuration file does not describe this behavior. My issue is that the risks associated with a security control should be clear.

where the ui/panel can be spoofed by altering the X-FORWARDED-FOR ip address in the request header doesn't make any sense. Someone editing/reading the configuration file has no idea what that means. The issue is not that the admin UI can be spoofed, the issue is that the access controls can be bypassed by using x-forwarded-for headers (and possibly others).

Additionally, the code surrounding use_x_forward_for should also be addressed. #1354 (comment)