We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 21255
    • 215 Posts
    If you’re using MODx in a shared hosting environment, there are some common security problems, mostly regarding file permissions. Of course, these apply to all scripts, not only MODx, and depend on your provider’s system configuration.

    To allow less experienced users to do a quick test of the webserver-setup, I’ve written a simple php-script that performs some very basic checks and - in addition - tries to correct some permissions of your MODx cache-files and config.

    USAGE

    • Uncompress the attached tar.gz-file into your MODx base directory (where manager-folder resides).
    • Open http://yoursite/modx-audit.php in your browser.
    • See the results.

    Please note this script has been only tested on Linux machines. It may work and output senseful results on FreeBSD, it’s assumed not to work on Windows or MacOS.

    WHAT IT DOES

    • Drops world-readable permission off cache-index files and config.inc.php
    • Checks if session-files are world-readable
    • Detects if your php-scripts are run under your userid (su-execed)
    • Outputs the software version of your webserver and php-interpreter

    It’s planned to enhance the features of this script if it seems to be useful. I’m thinking over a function to check existing snippets/plugin/modules if they’re following some basic security concepts. Your feedback is well appreciated.
    • Um...I’m no expert, but if my scripts are running as the Apache user, won’t that prevent MODx from being able to access the files? At least in my filesystem, those two cache files have my ftp user as owner, not the Apache user. Of course, the config.inc.php should be set to 644 as soon as it has been created.

      Ah, I think I see...if the script is running as the Apache user it won’t be able to change the file permissions if they are owned by my ftp user. Correct?
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 21255
        • 215 Posts
        You’re right. wink

        BTW: In a shared hosting environment, it is generally not a good idea to have your scripts run as apache. It would be much better if php is launched under your userid (well, you won’t change that, that’s your providers job to). If you’re alone on that server, it doesn’t really matter.
        • Plesk servers, which are very common on shared server enviroments, run sites as the FTP user, not as the apache user. In order for the cache file to work, the files have to be 777. :/
            Ryan Thrash, MODX Co-Founder
            Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
            • 22221
            • 283 Posts
            I’ve tried the script and I’ve got the following result :
            OK: PHP is running as user 'u39467675', which is most likely your own username.
            WARNING: register_globals is set to 'on' in your php.ini - This is dangerous in most cases. Turn them off, NOW!
            INFO: Your server software is Apache/1.3.33 (Unix) - You may want to visit your server software vendor's website to check if your httpd is up to date.
            INFO: This machine uses PHP in version 4.4.2 - Please visit http://www.php.net/ to check out if this is a recent version without any known vulnerabilities.


            What can I do for the Warning ? Where is the php.ini ? huh

            Thanks
              • 6726
              • 7,075 Posts
              Thanks NetNoise I’ll test that !

              OncleBen31 : custom php.ini on shared hosting is (to my knowledge) rather uncommon (TextDrive offers this, but it’s the only one that gave me the possiblity to have custom php.ini...). Check with your host...
                .: COO - Commerce Guys - Community Driven Innovation :.


                MODx est l'outil id
                • 21255
                • 215 Posts
                You could try switching the register_globals to off using a .htaccess-file and "php_flag" syntax (see the .htaccess file that comes with MODx). But on most shared hosts, that wouldn’t change anything, I guess.

                (More about ’register_globals’ at http://www.php.net/register_globals)
                  • 33175
                  • 711 Posts
                  But on most shared hosts, that wouldn’t change anything, I guess.
                  In general, you can turn off register_global but not turn on, for security reason.
                    Sorry for my english. I'm french... My dictionary is near me, but it's only a dictionary !
                  • Quote from: rthrash at Mar 13, 2006, 02:31 PM

                    Plesk servers, which are very common on shared server enviroments, run sites as the FTP user, not as the apache user. In order for the cache file to work, the files have to be 777. :/

                    Same with CPanel. The files are all owned by the user, but scripts are run as the Apache user. This makes it awkward when dealing with a file uploading script, since it must be able to write to the folder which is owned by the user. The files the script uploads (images, whatever) are thus owned by the Apache user, and can be troublesome for the user to deal with. And any files that a script needs to write to must also be world-writable so the Apache user can write to them. This makes it possible for anybody with access to the server (and these servers can be hosting as many as 500 different websites) to hack into your webspace and fiddle with your world-writable files and folders.

                    Bottom line? If your site is of any serious importance, first of all don’t use a shared hosting environment. Get at least a semi-dedicated server. Secondly, make sure your hosting is done with a php-suexec filter that lets the scripts run as your user, not as the Apache user. In fact, I’m not doing anything important, but this summer when my current hosting contract is finished, I’m moving to a hosting company that proveds PHP 5 as well as suexec, even if I end up paying a bit more (unfortunately I can’t afford a dedicated or even semi-dedicated server). The company where I am, although otherwise I have had no complaints with their service, will not even discuss either issue. So they lose my business, my partner’s business, and that of anybody I deal with who finds this to be of concern.
                      Studying MODX in the desert - http://sottwell.com
                      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                      Join the Slack Community - http://modx.org
                      • 22221
                      • 283 Posts
                      I’ve tried to use the Modx .htacces file with teh following modification. (I don’t use flriendly URL, and I comment the line php_flag register_global)

                      # MODx supports friendly URLs via this .htaccess file. In order to use it, you must change the 
                      # file name from ht.access to .htaccess. If you don't want to use friendly URLs, you can comment 
                      # the three Rewrite directives out with pound signs (like the beginning of this line).
                      #
                      # Make sure RewriteBase points to the directory where you installed MODx.
                      # E.g., "/" if your installation is in your root web documents directory (it comes this way by 
                      # default) or "/MODx" if your installation is in a MODx subdirectory, per the comments below. You
                      # must serve web pages via Apache with mod_rewrite to be able to use this functionality.
                      #
                      # The last two blocks of rules at the bottom of this .htaccess file address anamolies with IE 
                      # for Windows PCs and the way in which it caches images, which causes a distracting flicker in 
                      # background images when links are hovered on the page.
                      #
                      # The output compression directives immediately below serve to speed up delivery of web pages, 
                      # and may also be optionally commented out.
                      
                      php_flag zlib.output_compression On
                      php_value zlib.output_compression_level 5
                      # php_flag register_globals 0
                      
                      # Rewrite directives here for SEF (Search Engine Friendly) URLs
                      
                      #RewriteEngine On
                      #RewriteCond %{REQUEST_FILENAME} !-f
                      #RewriteCond %{REQUEST_FILENAME} !-d
                      
                      # If your MODx installation is in a subdirectory, change the following line to match the physical
                      # path to the "root" of the site as follows:
                      # RewriteRule ^(.*)$ /path/to/subdirectory/index.php?q=$1 [L,QSA]
                      
                      #RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
                      
                      # This following two sections stops screen flicker in IE on rollovers (Bad IE Win, Bad!).
                      # Comment these sections out if you do not need them. They can result in having to force reload
                      # pages when developing sites and changing images frequently to see your changes. 
                      
                      #ExpiresActive On
                      #ExpiresByType image/gif A2592000
                      #ExpiresByType image/jpeg A2592000
                      #ExpiresByType image/png A2592000
                      
                      #BrowserMatch "MSIE" brokenvary=1
                      #BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
                      #BrowserMatch "Opera" !brokenvary
                      #SetEnvIf brokenvary 1 force-no-vary


                      And when I try to acces my site, I’ve got the following message :

                      [tt]Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request[/tt]

                      Any Idea to solve the problem ?

                      Thanks