Skip to content

How do you secure it? #36

Closed
Closed

Description

@hopeseekr

How would I securely deploy this to a production server running on nginx?

Activity

  1. ITwrx commented on Nov 5, 2018

    @ITwrx

    control access to it with your nginx config.

    if you're using https, basic auth could do the trick.
    https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

    you could also only allow your ip to access that location.
    http://nginx.org/en/docs/http/ngx_http_access_module.html

    if you were bored or paranoid you could even require a client certificate to be furnished by your browser. it's up to you.

  2. amnuts commented on Nov 19, 2018

    @amnuts
    Owner

    Great answer @ITwrx, thanks!

    This is one of the reasons I didn't put any auth in there... Some people will be using nginx, some apache, some will want something simple like HTTP Auth, others more complicated. Can't get one-size-fits-all, so it's very much a Bring Your Own Auth party. ;-)

  3. pingram3030 commented on Jun 12, 2019

    @pingram3030

    Because there is no setting of the Cache-Control header, be very careful with using this behind a caching proxy like Varnish. If you simply have access restriction, when you access it legitimately for the first time, the proxy will cache the page and the next request, which may be illegitimate, will immediately return the full cached page.

    (yes the following config is httpd, but you can do similar things in nginx)

    So, if you do put in some kind of access restriction to this, ensure you also set Cache-Control; e.g. for .htaccess

    Header set Cache-Control "no-cache"
    

    If you control and sanitise X-Forwarded-For in your caching proxy you can have on your backend server something like:

    RewriteEngine on
    RewriteCond %{HTTP:X-FORWARDED-FOR} !^aaa\.bbb\.ccc\.ddd
    RewriteRule .* - [R=503]
    

    Noting that by default X-Forwarded-For is appended to by AWS ELBs and that the client can manipulate it before it hits your servers; hence the need to sanitise it yourself.

    I would like to see the Cache-Control header in this script set to 'no-cache' by default to reduce security issues inherited by unsuspecting users.

  4. yourpropertyexpert commented on Sep 11, 2020

    @yourpropertyexpert
    Contributor

    I secure it by adding some extra authentication stuff before the main code. Like this:

    
    <?php
    
    namespace Our\Namespace;
    
    include("../includes/includes.php"); // autoloader for both Composer and our custom classes
    $session = new Session(); // our own object that has a method called checkAdminSession() to do what you might imagine
    
    if ($session->checkAdminSession()) {
        header("Location: /admin/index.php"); // They shouldn't be here send them home!
        exit;
    }
    
    // And from this point onwards, either just copy/paste the code, or include it in the way suggested by the README
    /**
     * OPcache GUI
     *
     * A simple but effective single-file GUI for the OPcache PHP extension.
     *
    
    
  5. frayber commented on Mar 16, 2022

    @frayber

    In apache conf restrict access to internal ip:

    <Location /opcache.php>
    Require ip 192.168. 172.19.

  6. Repository owner locked and limited conversation to collaborators on Jul 16, 2022
  7. converted this issue into a discussion #88 on Jul 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions