Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^4: Using relative paths with taint mode

by Bod (Parson)
on Jun 20, 2021 at 15:47 UTC ( [id://11134074]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Using relative paths with taint mode
in thread Using relative paths with taint mode

If a website has more than one environment, then you need a plan anyway (again, nothing to do with taint mode) how you deploy and maintain the files in your different environments. There are many solutions for that, but I'd go for something like this:
/home/myusername/somewebsite/prod/cgi-bin /home/myusername/somewebsite/prod/lib /home/myusername/somewebsite/prod/templates

That is pretty much what I have at present - except the contents of lib are hung directly off cgi-bin. So doing it that way doesn't mean changing things drastically which is a good thing.

But I don't see how having the modules like this

/home/myusername/somewebsite/prod/lib/Site/HTML.pm
is anymore secure than having them like this
/home/myusername/somewebsite/prod/cgi-bin/Site/HTML.pm
as they are still accessible through HTTP as prod/ is the web root. Of course they can be made inaccessible either through putting an index.html file in there or through an .htaccess file.

Replies are listed 'Best First'.
Re^5: Using relative paths with taint mode
by haj (Vicar) on Jun 20, 2021 at 17:56 UTC
    as they are still accessible through HTTP as prod/ is the web root.

    Why is that so? Do you understand the purpose of "web root"? Please clean that up: neither cgi-bin nor lib are supposed to lie under the web root (nor are templates). Also, an index.html doesn't make anything inaccessible, it just gets served when a browser is pointed to the directory (in a typical configuration).

    I mean, of course you can fiddle with as many of .htaccess files as you like, but why not simply avoid the problem in the first place?

      Why is that so?

      Because that's where it gets put on my shared hosting...

      When I add a domain in cPanel it adds this by default:

      /home/myusername/domain/cgi-bin/
      Where domain/ is the webroot.

      I modify it slightly cPanel so I get:

      /home/myusername/domain/prod/cgi-bin/ /home/myusername/domain/test/cgi-bin/ /home/myusername/domain/dev/cgi-bin/
      Where:
      www.domain.com -> prod/
      test.domain.com -> test/
      dev.domain.com -> dev/

      Because that's the way cPanel does it, I hadn't considered that there was a better way!

        Why is that so?
        Because that's where it gets put on my shared hosting...

        Well, yeah, that explains a lot. In that case you might be stuck with .htaccess and all its shortcomings. Or maybe not, since your environment setup somewhat resembles virtual hosts, each of which can have its own config. But again, that's a question of "secure virtual host configuration" and not of "taint mode".

        (See also Re^5: Using relative paths with taint mode and Re^7: Using relative paths with taint mode)

        When I add a domain in cPanel it adds this by default:

        /home/myusername/domain/cgi-bin/

        Where domain/ is the webroot.

        I modify it slightly cPanel so I get:

        /home/myusername/domain/prod/cgi-bin/ /home/myusername/domain/test/cgi-bin/ /home/myusername/domain/dev/cgi-bin/

        That should be sufficient to get any number of protected directories that are not reachable via HTTP(S), without messing with .htaccess files:

        Given that only very few characters are allowed in host and domain names (only ASCII letters, ASCII digits, and the hypen are allowed for any subdomain, and the dot separates subdomains), it is trivial to create a directory below /home/myusername/ that is NOT a valid domain name, e.g. _lib or !private. (Note that all Internationalized domain names use Punycode to encode Unicode to that restricted set of characters.)

        Even without shell and FTP access, you seem to be able to modify cPanel, and cPanel can create directories. So you can modify cPanel to create the directories.

        Now you can create directories unreachable for HTTP(S) clients where you can store modules, configuration and database files.

        Of course, depending on the actual webserver configuration, it may be possible to manually issue an HTTP request with an invalid hostname after using a valid hostname to resolve the IP address of the server. So to be paranoid, put a .htaccess file in those protected directories that prohibits all access. It won't affect the normal webserver use at all, it is just a last resort.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11134074]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (8)
As of 2024-03-29 13:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found