Drupal Security
close

on 23rd May 2016 / by Moses Raymond
Security Audits play a crucial role in an organization’s ongoing effort to address security concerns. After identifying any potential security issues, remedial steps need to adopted; in fact, a Security audit is one of the first steps that need to be taken. No organization in its right mind would want to leave their websites vulnerable to hacking, and conducting a security audit is the best way to tackle security issues. A Security audit should be conducted at regular intervals if: Your website is slowing down and you want to diagnose the reason and repair it quickly You want to assess the security level of your Drupal website You are keen to reduce maintenance expenses by enhancing Drupal code quality You want to give your visitors a better overall experience on your website A Security Audit is also a fool-proof method of evaluating the work carried out by a third party and check for any underlying defects. Also, a security audit conducted before initializing any development work is useful in identifying any unresolved issues. The following steps are a few of the key checks done during a Security Audit: Code and Security: Here, the website is checked for any vulnerabilities, and proper analysis is done to make sure that the appropriate security updates are installed. The proper working of the software and updates is thoroughly checked. Content Structure: Any critical issues related to your site’s content structure, within your site’s nomenclature, is deeply examined and the corrective action is taken. Complete Functionality check: The website is checked for any broken links, obsolete and non-operational modules, along with any missing functions. This ensures that the website is functional in all aspects. Speed and Performance check: The security audit firm will also check for the site’s receptiveness and speed issues, if any, and document the probable causes of the same. Check for Best Practices: A comprehensive review of the website’s nomenclature, code, configuration and modules is also carried out to confirm that standard and best practices are being employed. On-page SEO: This is also an important assessment that is done by most security audit companies. An in-depth review confirms if your website needs any changes or enhancement to the on-page SEO and a detailed report is submitted. Zyxware's Drupal Security Audit Zyxware's Drupal Security Audit consists of the below mentioned steps: Consultation: In this phase, our audit team meets with the client to understand their requirements and gather any other information that may be critical to the audit process. Comprehensive Audit: Our technical experts examine every area of the website including the architecture, page timings etc. Documentation: After the review, every team documents its findings that will become part of an exhaustive report which is submitted to the client. Review and Recommendations: The Audit team then schedules a review meeting with the client and also creates a plan with suggestions and recommendations. Over the past decade, Zyxware has provided end-to-end Drupal services; from Drupal design and development to consultancy and support, which also involves Drupal Security Audit and Reporting services. We have a long list of satisfied clients who will vouch for our proven and successful methods. We carefully analyze your site, identify security concerns, provide recommendations and work closely with you to implement them. So, give us a call today to find out how you too can benefit by partnering with us. Drupal Development services Drupal Audit Drupal Security Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 11th August 2015 / by prince.kr
Security updates are essential in Drupal websites. Such updates are vital to address certain security vulnerabilities and keep your website protected from potential threats. You can get the details of the security updates that need to be applied on the Drupal site from the link given below:http://www.buildamenu.com/admin/reports/updates. The steps to install security updates in Drupal sites: Check available updates. drush ups Check for hack details using meld module. You can install the meld module using sudo apt-get install meld and just type meld in the command to check the differences in the files and directories. If hacks are found, please proceed below, or else create patches for the hacks and proceed. Delete the current version of the module. git rm -r sites/all/modules/module_name Download the new version of the module. drush dl module_name Add the new version of the module. git add sites/all/modules/module_name Commit the module updates to the version control system if added. git commit -m "security update for module_name module" If patches are present: Update the patches for the hacked modules and add the patch. git add sites/all/PATCHES.txt Commit the patch to the version control system, if added git commit -m "comment wrapper template patch applied to module_name module" Run the database update script. drush updb Also, you can skip all the above steps and use directly the command given below to update after checking the hacked details using meld module. drush up module_name It's always good to follow the above steps if security updates are being done in the server directly instead of shortcuts. You may also look into other articles related to Drupal security here. Please feel free to share your thoughts and queries regarding this here. Drupal Drupal Security Drupal Planet Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 15th July 2015 / by deepa.n
One of our clients had a security issue with their Ad Server. The OpenX Ad Server has been reported with a Remote Code Execution Vulnerability for the version OpenX-2.8.10. Since the OpenX Ad Server downloads contain backdoor. public_html/etc/plugins/openXVideoAds.zip: Backdoor.OpenX.CVE_2013_4211 FOUND public_html/plugins/deliveryLog/vastServeVideoPlayer/flowplayer/3.1.1/flowplayer-3.1.1.min.js: Backdoor.OpenX.CVE_2013_4211 FOUND Even the next higher version OpenX-2.8.11 didn't rescue us. Also there was a Zero Day Vulnerability reported for OpenX-2.8.11. Hence we decided to upgrade the Ad server to Revive Adserver 3.2.0. Both share the same origin and Revive Adserver offers a full upgrade path from OpenX. Here are the steps: Step 1: Download Revive Adserver 3.2.0 release package from http://www.revive-adserver.com/ to your local machine. Step 2: Prepare to install Backup your current OpenX code in LIVE server. Make a copy of your current Database and name it say, 'db_adserver_320'. Create a new folder say, 'adserver_new' in public_html/ (or in root folder). Upload the Ad Server 3.2.0 to server and uncompress it to the folder - public_html/adserver_new/. Copy all images from public_html/www/images/ to public_html/adserver_new/www/images/. Now, copy the configuration file - YourDomainName.conf.php from public_html/var/ to public_html/adserver_new/var/. Then edit the file - public_html/adserver_new/var/YourDomainName.conf.php and set the database name as 'db_adserver_320'. Create a file named “NOBACKUPS” in the folder - public_html/adserver_new/var/to prevent creating additional backup tables. Step 2: Install Revive Ad Server Now, run http://domain.com/adserver_new/ in your browser. Follow the simple upgrading steps presented on screen. Please note: In the second upgrading step, you will have to login by entering your Adserver administrator user name and password. After the final step, your browser may be redirected to the original URL of your Adserver installation instead of 'public_html/adserver_new/'. You can then just insert the '/adserver_new/' part to the URL to see the proper page. Step 1: Step 2: Step 3: Step 4: Step 5: Once you're done with your checks whether everything is running fine, swap your ad server code. Move your existing ad server code to a sub folder say, ‘adserver_old’ and copy the new version from 'public_html/adserver_new/' to 'public_html/'. Finally, change the permissions of the file - 'public_html/var/YourDomainName.conf.php' from ‘777’ to ‘644’. This will ensure security of the configuration. Hope this helps. OpenX Drupal Security Leave a reply Your email address will not be published. Required fields are marker *
close

on 15th May 2015 / by prince.kr
I had updated a Drupal site recently and do had faced some issues after successful update of the site. Upgrading a Drupal site is an effective way to make sure that your Drupal site is currently updated with all the latest security updates. Before performing any major changes on your Drupal site, remember to take a complete files and database backup of the site. Follow the below steps to get an updated Drupal site: Firstly we have to look out the sites available updates and status reports Next look for the hacked module list in the site. Hacked module means the modules which has been made changes and checking for the changes that can be updated to the new versions To get the modules that are been hacked we have to first enable the hacked module and to get the difference of the changes in the version diff module should also be enabled.For enabling the modules we can use the following commands. Enabling hacked module drush dl hacked drush en hacked Enabling diff module drush dl diff drush en diffAfter enabling the hacked module,see for the hacked list in reports-hacked list. The modules which are been hacked will be listed with the unchanged modules.Hacked modules will have recommended version ,release note and the number of changed files. Also using the command we can find the hacked module details drush hacked-details module_nameNow check on the changes of the hacked modules and just click the changes with the new version Before getting through ,please download the same version of the module which has hacks.check for the changes in the module files We can check manually or use the meld software for the easy update Look for the changes in the file.lists out the files hacked If no files hacked is result, then update the same using the command drush up module_name/file_nameIf hacked details result changes -check for the changes with version. -Keep the changes patch if its required for the new version. -Update the current module using the above command. -Make the changes that you find standard for new drupal version behaviour. -commit the updates After the process carried for all the all hacked modules like the above ,run the database update script drush updbYou can also run using the url/update.php Checks for the database updates Lists all the pending updates Checks for any module file or library missings Run the site after the above procedure done and check for the site performances. Major Issues and fixing of the same during the Drupal update implementation Database update finished.showed some files miss in the update Mail chimp library file missing XML site map not secure htaccess permission error The above issue can be fixed by the following Added mail chimp library file in --sites/all/libraries/mailchimp Run cron to make changes to XML site map In .htaccess file made the changes with old version .htaccess Admin menu theme style change after update Issue can be fixed by changing the updates error and removing the cache and rebuild to the menu builder Issue of web page alignment change after changing the .htaccess Fixed the issue by changing the .htaccess to the origin path in the staging site Issue found with the the admin menu showing vertically on any admin menu selection Approached to disable the administrative views and clear all caches Issue found with the the admin menu content --requested page "URL/#overlay=admin/content/node" could not be found Issue fixed by enabling the overlay module , disable the administrative views and clearing caches Drupal Security Drupal 7 Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 11th December 2014 / by arjun.s
Drupal is a stable,reliable, and robust Content Management System. Views is a Drupal module, which provides a flexible method for site designers to control how lists and tables of content, or any other type of content has to be presented. The views module was a contributed one and was later adapted to the core from Drupal 8. Drupal views are being used by almost 75% of the Drupal based sites to present the elements in a page. Most of the websites still use the Views module versions such as 6.x. Drupal Views versions, 6.x-2.9, 6.x-2.10 and 6.x-2.11, in Drupal 6 are vulnerable. The vulnerability To test for the Proof of concept of this vulnerability, go to any Drupal website and browse the url ?q=admin/views/ajax/autocomplete/user/. This will list out the first n number of usernames starting with the character given. For eg: if you have given the url as ?q=admin/views/ajax/autocomplete/user/a the n usernames starting with a will be listed. This vulnerability could lead to exposing important user names, thus keeping the site open to brute-force or dictionary attacks. This vulnerability actually exposes the original usernames so that certain modules for user name aliasing will be prone to this attack. A simple solution will be to set a permission for the ajax menu, or check if a user with the right permission is logged in or not. More precisely, the views module failed to provide access controls in the function views_ajax_autocomplete_user(). Vendor response Several newer versions of the views module are available and updating to any one of them is the only solution put forward by the vendor. Otherwise, we have to use third party patches to resolve the issue, or we can write our own patch. Ultimately, Drupal security concluded that this is not a vulnerability and could be handled in public. Drupal Drupal Security Drupal Views Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 14th December 2012 / by sujith.s
If your Drupal website is delivering content to other third party sites through web syndication mechanisms like the RSS feed you need to purify the HTML markup before delivering it to them to prevent an XSS attack on those sites through your feeds. Read on to know how to programmatically purify the contents of your Drupal website's feed . The most simple solution that you can use to filter your feed content is to programmatically filter the content in the View’s feed template file. Check out the steps below We are going to use HTML Purifier which is a PHP filter library to do the job. It will remove malicious HTML code in the content present in your Drupal site. First install and configure the Drupal HTML purifier module in your Drupal site Next copy and paste your View’s row template file to your theme directory You can find the row theming file from the Theming information link in Views basic settings. A typical View template for the feed display will have following variables<?php /** * @file * Default view template to display a item in an RSS feed. * * @ingroup views_templates */ ?> <item> <title><?php print $title; ?></title> <link><?php print $link; ?></link> <description><?php print $description; ?></description> <?php print $item_elements; ?> </item> Now you have to filter $description using the following code.$description = _htmlpurifier_process($description, -1);The variable description will now have purified HTML ready to be shipped. Hope the article was helpful in solving the problem in your Drupal site Web Development Drupal HTML RSS Drupal Security Web Security Leave a reply Your email address will not be published. Required fields are marker * Erik Verkuil (not verified) access_time 21 Feb 2019 - 14:01 Nice article, could you please show how the template looks like after changing the code? Like this? <description><?php print _htmlpurifier_process($description, -1); ?></description> Erik webmaster access_time 21 Feb 2019 - 14:01 In reply to example of the code by Erik Verkuil (not verified) @Erik - The line you have copied over only corresponds to the description field. This will replace the line <description><?php print $description; ?></description> in the template. Hope that helps Add new comment
more_horiz
close

on 17th September 2012 / by webmaster
Drupal is inherently secure but as with most secure systems there will always be a few security loopholes that could be utilized by a user with malicious intent to bring down the whole site. As usual most of these security flaws lie mostly with the admin users of the website. We have listed down the top 7 security mistakes commonly found in a Drupal website which can be easily rectified by using a simple Drupal Security Checklist. The easiest way to ensure that your Drupal site is build safe is to have it built by experts. Contact Us to build your drupal site for you. Failure to set a strong admin password The is is the Achilles Heel of all web security systems and is not specific to Drupal itself. What separates the admin user from the rest of the web is a piece of alphanumeric text - the password. If the admin password is weak, formed from some commonly used password then any negligibly competent attacker can gain complete control over the system. Weak passwords are a gargantuan security flaw as it can bypass all other security systems put in place by Drupal as if it were non existent. Make sure that all admin passwords are cryptic, build using a combination of numeric characters, symbols, upper case and lower case text. The should never contain meaningful words, important dates names and telephone numbers and should be kept as long as possible. Failure to review user permissions This is another security mistake commonly found in Drupal websites . The Drupal user permission system makes it extremely easy to manage user permissions and define user roles. However this also means that unauthorized users might be given unnecessary permissions by oversight enabling malicious users to gain access to the whole system. Make sure that anonymous users are given only the minimum set of required permissions. Classifying authorized users based on their roles and assigning them only the required permissions will increase site security if an attacker manages to create an account in the website. Failure to review user creation settings The is yet another potential security flaw commonly found in Drupal websites. Users should not be given the permission to create accounts as it is a potential security vulnerability. Malicious users can create an account and if authorized users are given unnecessary permissions in a Drupal website they can cause a malicious event to happen. Verify that all account creation settings are as intended. Failure to update core and contrib modules to the latest version. Failure to update all the modules in a Drupal site to their latest version is yet another security vulnerability. The Drupal community ensures that all of the security vulnerabilities are fixed whenever as soon as they are discovered. Make sure that the Core and Contrib modules in a Drupal site are always updated to the latest version whenever they are available. Failure to monitor status reports Monitoring status reports in Drupal website is vital to security as they can reveal potential security flaws and happenings on a website. They can indicate the presence of DDOS attacks, spammers or if someone is trying to access a Drupal site with malicious intent. Status reports should be periodically verified to see that they are free from warnings and errors. Failure to disable on-screen error reporting While developing a Drupal website getting to know relevant messages via on screen error reporting is extremely helpful in speeding up development. This should be disabled in productions sites as it could reveal info associated with the database of a Drupal website to an reasonably experienced hacked leading to a security flaw and besides it looks bad on a production system. Leaving SQL dumps and file dumps in the webroot It is a good practice to take a backup of a working site before you make changes to the site. However it is an extremely bad practice to keep the backups in the webroot or in subfolders which are directly accessible from the web. Because the backup files would normally have extensions that are not caught by .htaccess these files can potentially be available from the web. The security risk increases several fold if you keep dumps of the database right in the web folder itself. Developers should ensure that they do not leave any backup files or database dumps in the webroot or sub folders. Besides backups are to be kept locally and not on the web servers. Source: Drupal Security Checklist Drupal Drupal Security Leave a reply Your email address will not be published. Required fields are marker *
close

on 29th June 2012 / by Anoop John
Apache allows you to protect contents of specific directories in your website or the whole website from unauthorized access using a mechanism called httpd password protection. During development of new sites the partially built sites are protected from unauthorized access using httpd authentication. This could sometimes interfere with testing of integration with third party services that might expect some of your URLs to be accessible without authentication. Here is how you can exclude a given file or directory from httpd authentication The standard set of lines in htaccess to enabled httpd authentication is as follows AuthType Basic AuthName "Auth Required" AuthUserFile /path/to/.htpasswd Require valid-user Now adding the following below this will allow you to exclude directories and files # Allow access to excluded diretories SetEnvIf Request_URI "path/to/excluded/directory/" allow SetEnvIf Request_URI "path/to/excluded/file" allow Order allow,deny Allow from env=allow Satisfy any If you wrap the above in a <Limit GET> section you can limit the authentication to GET requests only. You can also allow access from specific IP addresses by adding the following for each IP you wish to allow Allow from 208.67.222.222 Apache Server Administration Drupal Security Web Security Access Control Leave a reply Your email address will not be published. Required fields are marker * Muddy Mind (not verified) access_time 21 Feb 2019 - 04:34 Nice work this helps me a lot to some basic changes in my blog :) Add new comment
close

on 15th June 2012 / by deepa.n
Password-protecting drupal development site with .htaccess file There might be few scenarios when we need to protect our site from the general public and make it accessible to a selected group of users. One of the most common scenarios in the development workflow of a Drupal site is when you want to avoid your half-complete drupal site showing up in Google search results.For such needs, it is advisable to go for password-protecting the site using HTTP authentication. If you have cPanel installed on your hosting server, you can use the ‘Password Protect Directories’ option from the ‘Security’ section on the cPanel home page. Click here to read on How to enable HTTP Authentication using cPanel (link to an article for the same on our site) For those without cPanel, here’s how to get Apache work your way: Password protection on directories using .htaccess and .htpasswd: On a hosting server running using apache as the webserver, you need to do the following things to add HTTP Authentication (password protection) to your site: Create .htpasswd file Add/modify .htaccess file 1. Create .htpasswd file .htpasswd (do not forget to add the ‘.’ before htpasswd) is the file that stores the HTTP username and password. You need to tell Apache to verify against the credentials given in .htpasswd. First, to create .htpasswd with the desired username and password, SSH into your server (or open up a terminal window on your local machine, cd (change directory) to the folder where you want to create your password file, and type in the following command: htpasswd -c .htpasswd You'll be prompted to enter and retype your password, then the .htpasswd file will be created for you. Here’s what it looks like: user@user-desktop:~$ htpasswd -c .htpasswd userjohn New password: Re-type new password: Adding password for user userjohn If you open up the file, you can see the username and encrypted password generated. It looks something like this: userjohn:lOy81yOkKmeXc Step2: Add/modify .htaccess file .htaccess (that too, with the ‘.’), is the file that tells apache what custom settings to use for the site. What we have to do here is that we have to add the setting in .htaccess that tells apache to use the password in .htpasswd. Drupal has a default .htaccess file in its root. You just have to put in the following lines of code to your .htaccess file: AuthUserFile //.htpasswd AuthType Basic AuthName "Restricted Access" Require user userjohn is the path to the file from the Web server's root folder - for example, /home/username/.htpasswd or C:\wwwroot\username\.htpasswd. The above .htaccess file will password protect all files in the folder that it is placed in, and all sub-folders under that folder. For protecting your entire site, just place it in your web root. Apache Server Administration Drupal Security Web Security Access Control Leave a reply Your email address will not be published. Required fields are marker * website (not verified) access_time 21 Feb 2019 - 04:34 Hey this is kinda of off topic but I was wondering if blogs use WYSIWYG editors or if you have to manually code with HTML. I'm starting a blog soon but have no coding experience so I wanted to get guidance from someone with experience. Any help would be enormously appreciated! Add new comment
close

on 14th June 2012 / by Anoop John
Once in a while you will come across a Drupal site where you have to login to the site without having access to the credentials of user 1. You can easily reset the password of user 1 directly in the database or you can create a small work around to login to the site. Here is how you can login to the Drupal 7 site programmatically as user 1 without knowing user 1 credentials. In Drupal 7 you can do this by copying over index.php as test.php (or whatever name you wish to call it) and replace the last line menu_execute_active_handler(); with global $user; $user = user_load(1); drupal_session_regenerate(); drupal_goto('user'); Remember to delete this file immediately after logging in as it would be a gargantuan security vulnerability to leave this file in the website as anybody who accesses this file will be able to gain access to your site as user 1. Drupal Drupal Development Drupal Security Drupal 7 Leave a reply Your email address will not be published. Required fields are marker *