LATEST FROM OUR BLOG

Take your daily dose of (only) relevant news, useful tips and tricks and valuable how to's on using the latest web technologies shaping the digital landscape. We're here to do all the necessary information sifting for you, so you don't have to, to provide you with content that will help you anticipate the emerging trends about to influence the web.

What Are Some Good Ways to Write Secure Drupal Code? Most Common Vulnerabilities and Secure Coding Practices
With the Drupalgeddon2 "trauma" still “haunting” us all — both Drupal developers and Drupal end-users — we've convinced ourselves that prevention is, indeed, (way) better than recovery. And, after we've put together, here on this blog, a basic security checklist for Drupal websites and revealed to you the 10 post-hack “emergency” steps to take, we've decided to dig a bit deeper. To answer a legitimate question: “What are some good ways to write secure Drupal code?” For, in vain you:   build a “shield” of the best Drupal security modules and plugins around your website enforce a rigid workplace security policy    … if you leave its code vulnerable to various types of cyber attacks, right? But how do I know how unsecured code looks like, to begin with? What are the site configuration gotchas that I should pay attention to? What are the most common vulnerabilities that I risk exposing my Drupal site to? And how can I test it for security issues that might be lurking in its code? But most of all: What top secure coding practices should I and my Drupal development team follow? Now, let's get you some answers:   1. SQL Injection Vulnerabilities: How You Can Fix & Prevent Them  SQL injections sure make one of the most “banal”, nonetheless dreadful types of attacks. Once such vulnerabilities are exploited, the attacker gets access to sensitive data on your Drupal site.   1.1. Prevent SQL Injection Attacks Using The Database Abstraction Layer In other words: the proper use of a database layer makes the best shield against any SQL injection exploit attempts. Now, let's talk... code. For instance, linking together data right into the SQL queries does not stand for a secure coding practice: db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']); In this case here, this is how you write secure Drupal code: db_query("SELECT foo FROM {table} t WHERE t.name = :name", [':name' => $_GET['user']]); Notice the usage of the proper argument substitution with db_query. The database abstraction layer uses a whole range of named placeholders and works on top of the PHP PDO. Now, as for a scenario requesting a variable number of arguments, you can use either db_select() or an array of arguments: $users = ['joe', 'poe', $_GET['user']]; db_query("SELECT t.s FROM {table} t WHERE t.field IN (:users)", [':users' => $users]); $users = ['joe', 'poe', $_GET['user']]; $result = db_select('table', 't') ->fields('t', ['s']) ->condition('t.field', $users, 'IN') ->execute(); 1.2. Have You Detected an SQL Injection Vulnerability? Here's How You Can Fix It There are some key Drupal security best practices to follow for addressing SQL injection issues:   always stick to the well-known Drupal database API always filter the parameters that you get (be twice as vigilant and cautious about those who can type anything on your Drupal site) always use placeholders: db_query with :placeholder always check the queries in the code: db_like()   Tip: remember to follow these coding practices for addressing and preventing SQL injections on your contrib modules, as well.   2. How to Protect Your Drupal Site Against Cross-Site Scripting (XSS) Attacks We could easily say that XSS attacks “rival” SQL injection attacks in “popularity”: Drupal's highly vulnerable to cross-site scripting. All it takes is some wrong settings — input, comment, full HTML — as you configure your website, to make it vulnerable to this type of attacks: They make a convenient gateway into your website for remote attackers to use to inject HTML or arbitrary web.   2.1. Check Functions to Rely on for Sanitizing the User Input (in Drupal 7) Securing your Drupal 7 site against cross-site scripting attacks always starts with: Identifying the very “source” of that submitted data/text. Now, if the “culprit” is a user-submitted piece of content, depending on its type you have several check functions at hand to use for sanitizing it:   check_url check_plain (for plain text) filter_xss (when dealing with pure HTML) filter_xss_admin (if it's an admin user that entered the “trouble-making” text) check_markup   Note: always remember never to enter the user input as-is into HTML! Tip: a good way to write secure Drupal code is to use t() with % or @ placeholders for putting together translatable, safe strings.   2.3. Cross-Site Scripting In Drupal 8: Twig & 3 Useful Sanitization Methods In Drupal 8, handling cross-site scripting attacks gets significantly easier. Here's why:   you have TWIG, with its autoescaping and “sanitize all” HTML mechanism!!! no SQL queries no access to Drupal APIs   Now, besides Twig, you have 3 more sanitizing methods at hand for fixing cross-site scripting issues in Drupal 8:   HTML: :escape(), for plain text Xss: :filterAdmin(), for admin-submitted content Xss: :filter(), where HTML can be used   2.4. Testing Your Code Against XSS In order to check whether certain user inputs are vulnerable, all you need to do is:   take the “suspicious” user input as a field, as an input HTML enter them both (or just one of them) in your test   Note: feel free to user Behat or another framework of choice to automate the whole process. 2 clear signs that you've detected an XSS vulnerability are:   you get this pop up alert: <script>altert ('xss') </script> or this error message close to the IMG tag: img src="a" onerror="alert ('title')"   3. Use Twig Templates: They Sanitize All Output...  Automatically  Did you know that a lot of the Drupal security issues on your website occur precisely because you've skipped sanitizing the user-submitted content before displaying it? And someone's neglect quickly turns into another one's opportunity... By skipping to clean up that text beforehand, you lend the attacker a “helping hand” with exploiting your own Drupal site. Now, getting back to why using Twig templates is one of the best ways to write secure Drupal code:   they sanitize the user input and output (all HTML, basically) by default; you can write your custom code without worrying about it risking to break up your website you won't run the risk of having safe markup escaped In short: securing your Drupal 8 website is also about having all HTML outputted from Twig templates.   4. How to Write Secure Drupal Code for Finding & Fixing Access Bypass Issues One of Drupal's strongest “selling points” is precisely its granular permission system. Its whole infrastructure of user roles with different levels of permissions assigned to them. Furthermore, there are all kinds of access controls that you can “juggle with”:   Node access system field access Views access control Entity access   In short: you're free to empower users to access different sections/carry out different operations on your Drupal site.   4.1. How You Can Check for Access Bypass Issues How do you know whether there are access bypass flaws on your website, that could be easily exploited? It's easy:   you simply visit some nid/node and other URL on your site  and just run your Behat automated tests   4.2. And How You Can Fix the Identified Access Bypass Issues Do keep in mind that there are quite a few access callbacks to consider:   entity_access user_access for  permissions Squery – addTag ('node_access') Menu definitions (make sure you set those correctly) node_access All you need to do is write automated tests to address any detected problems related to access bypass.   5. 3 Ways Deal With Cross-Site Request Forgery (CSRF) in Drupal  What does it take to write secure Drupal code?  Writing it... strategically, so that it should prevent any possible cross-site request forgery attack... Now, here are 3 ways to safeguard it from such exploits:   sending and properly validating the token using Form API using the built-in csrf_token in Drupal 8   In conclusion: a trio of good practices keeps the CSRF attacks away...   6. 7 Best Contrib Security Modules to Back Up Your Coding With Now, after we've gone through some of the best ways to write secure Drupal code, let's see which are the most reliable contrib security modules to strengthen your site's shield with:   Hacked!       Permission report   Encrypt       Composer Security Checker         Security Review           Paranoia       Text Formats Report   The END! This is how your solid Drupal security “battle plan” could look like. It includes:   some of the most frequent types of attacks and security issues to pay attention to most effective preventive measures vulnerability detecting methods post-attack emergency actions and sanitization mechanisms   What ways to write secure Drupal code would you have added or removed from this list? ... Read more
RADU SIMILEANU / Aug 24'2018
Drupal Project Management: Specific Challenges and Approaches
Let me guess: you're a Drupal developer (temporarily) turned into a... Drupal project manager! Or maybe a PM new to Drupal, facing the challenge of your first Drupal project management assignment? Have I guessed it? Now the questions roaming in your head right now must be:   What Drupal project-specific challenges should I expect? How should I address them? How should I approach the Drupal developers, site builders and themers involved? What questions should I ask them at each phase of the project? And which are the stages of a Drupal project management process more precisely? How do I collect accurate and explicit requirements for my Drupal project?   “Spoiler alert”: managing a Drupal project the right way isn't so much about using the right project management modules and “heavy-lifting” tools. It's about:   understanding the specific challenges that Drupal projects pose understanding the specific phases of the process empowering the people in your team to capitalize on their Drupal expertise within the given time frames and according to your client's objectives   Now, here's an insight into the process of managing a Drupal project. One shaped as a list of predictable challenges and their most suitable solutions:   1. Proper Planning: Get The Whole Team Involved In other words: defining objectives and setting up a final time frame with the client without getting your team, too, involved in the process is like: Throwing spaghetti at a wall and hoping that it would just... stick somehow. They're the Drupal experts, you know... Therefore, getting the Drupal developers, themers and site builders engaged at this stage of the project is no more than... common sense. They're the (only) ones able to:   give you an accurate time estimate for developing and implementing each functionality/feature tell if certain of the requested features can't be delivered identify interdependencies and conditions provide you vital information about the Drupal-specific architecture and the project-specific development process … information on what components to take, whether new contrib modules need to be developed to support certain functionalities etc.   Get your Drupal team involved in the planning and preparation process and strike a balance between their valuable input, the client's objectives, and time frames.   2. Tempted to... Micromanage? Empower Your Team Instead Yet, resisting temptation won't be easy. Especially if you're a former Drupal developer now turned into a Drupal project manager. You'd just die to get your hands dirty with code, wouldn't you? To supervise, closely, how every single line of code is being written. Refrain yourself from that... Instead, do keep your focus on the bigger picture! And, moreover, empower each member of your team to... shine. To excel at what he/she's doing.  That instead of obsessing over details, getting everyone on their nerves and making them doubt their own skills: By focusing on each one of the small steering wheels, you'd just lose sight of the larger mechanism that's a Drupal project.   3. To Tell or Not to Tell: Do Encourage Your Team Members to... Tell Hiding the dirt under the carpet, from the stakeholders' eyes/ears and having members of your team remain silent over certain bottlenecks in the project will only act as 2 “Trojan horses”. They'll lead your Drupal project to... failure. Instead:   dare be honest with the client and inform him/her if you run the risk of a delay  encourage your team to be open with you and with their teammates when they hit sudden challenges, unexpected issues   By:   hiding ignoring “genuinely” underrating   ... issues detected in the development process — instead of getting them “exposed” and dealt with —  you're only sabotaging the Drupal project. And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use? This could be the “place” where they'd share any issues that they will have detected in the project. Or challenges that they face and can't address by themselves.   4. Juggling with Resources, Timeline, and Unforeseen Events I'm not going to lie to you about this one: keeping the balance between staying flexible and being capable to assess risks is not going to be easy... Unplanned issues will strike, new requirements will come to “jeopardize” this balance, unexpected changes will need to be accommodated under the same time frame... Should you keep yourself rigid and inflexible to all changes, sticking to the initial plan? Or should you “assimilate” all the incoming requirements and additions to scope with the risk of a project delay? And that of overburdening your team with unscheduled tasks... Can't help you with a universal answer here, one that would apply to all Drupal project management scenarios. It's you, together with your Drupal team, who should be able to estimate:   the changes' level of complexity the project delay (if it's the case) the chances for these additional tweaks to turn into contractual changes   5. Drupal Project Management Is 90% Good Time Management And it all comes down to: Breaking your Drupal project down into small, manageable tasks.  Tasks that can be easily turned into goals and objectives:   daily objectives weekly objectives and so on...   Efficient Drupal project management, even if we're talking about truly complex ones, is all about making it... manageable. About ensuring that the lists of tasks are logically structured and (most of all) time framed! Needless to add that this strategy acts as a motivation-booster for your team:  Just think about it: with every ticked off task, each team member can visualize the project's progress in... real-time. A progress that he/she, too, will have contributed to. The END! These are the Drupal project-specific challenges that any project manager dealing with this CMS faces, accompanied by their life (reputation)-saving solutions.   ... Read more
Adriana Cacoveanu / Aug 21'2018
3 Essential Steps to Convert Your Website to a Progressive Web App
Thinking to convert your website to a progressive web app? And why shouldn't you? Since the benefits are obvious:   you “end up” with a website behaving like a native web app … one that works offline (and “offline” is the new black these days, right?), having its own home-screen icon  improved user experience: not only that your site goes mobile, but users don't even need to get your site-turned-into-an-app downloaded from an app store and then installed on their devices   Furthermore: Putting together a PWA out of a regular website (or blog) is unexpectedly easy! Basically, any site/blog can be turned into a progressive web app... No need to let yourself discouraged by terms such as:   service workers web app manifest (or “manifest.json)   … for the whole process is actually far less complex than it sounds. Here, see for yourself: go through the 3 essential steps it takes to convert your website to a progressive web app:   But First: All You Need to Know About PWAS— Benefits & Common Misconceptions A succinct and clear enough definition of progressive web apps would be: A PWA is a website that behaves like a native mobile app once visited on a mobile device. Whereas a more detailed and comprehensive one would go something like this: A PWA is a sum of modern web capabilities (and basic mobile capabilities) that enable users to save it on their own mobile devices (thus enjoying a native app-like experience) and access it offline, too. And now, without getting into the old “native mobile app vs PWAs” debate, let me point out to you some of progressive web apps' most “luring” benefits:   as compared to native apps, the setup process, on users' end, is significantly simplified: PWAs get instantly installed on their home screens, with no need to visit an app store for that they can get accessed offline, as well, via the home screen icon (a huge step forward from responsive web design) installation is conveniently lightweight: a few hundred KB essential files get cached locally (needless to say that this makes them faster than the standard web apps) they feature modern web capabilities: push notifications, cameras, GPS updates are run automatically, with no user interaction not only that they work offline, too, but once the network connection is restored, they synchronize the data    And now, before we virtually convert your website to a progressive web app, let's go, briefly, through some of the most common misconceptions about PWAs:   a. A progressive web app is literally an... “application”. Not necessarily: A progressive web app can be a blog, an online shop, a collection of... dog memes, you name it. Do not take the term “application” too literally when referring to PWAs. It's more of a concept, a code optimization technique which, once leveraged, "turbocharges” your app-like website or blog to deliver content faster.   b. Progressive Web Apps Are Developed Specifically for iOS or Android. On the contrary! Probably one of PWAs' “hardest to resist to” advantage is that: They're platform-independent. So, you don't need to:   develop separate codebases comply with platform-specific submission guidelines   c. Your Site Has to Be a JS-Based Single Page One So You Can Turn it Into a PWA. Nothing of that sort! If you're currently running... something on the web (be it a set of static HTML files), then you can easily make a PWA out of it!  And now, let's go straight to the 3-step set up process of a PWA out of your regular website:   Step 1: Go HTTPS to Convert Your Website to a Progressive Web App There's no way around it: the HTTPs protocol is the ONLY way to go when it comes to progressive web apps! All data exchanges need to be served on a secure domain: over an HTTPs connection! And how do you switch from HTTP to HTTPs? You get yourself an SSL certificate from a trusted authority. Now, there are 2 ways to get hold of it:   if your site runs on your own server (or at least you have root access to your server), consider setting up the LetsEncrypt certificate. if your website runs on a shared hosting, then both the process and the cost of your SSL certificate (for yes, there will be a monthly or an annual fee) depends greatly on your provider.   Step 2: Create a Web App Manifest  “But what is a web app manifest?”, you might ask yourself. A JSON text file that contains all the meta data of your PWA: description, scope, start_url, name, images, display, short_name... It's this information that will let browsers know how precisely they should display your app once saved as a home-screen icon. Now, before I go ahead and share a working example with you — one including the must-have entries of any web app manifest — I should also highlight that: A link to this JSON text file should be placed in the <head> of all your PWA's pages: <link rel="manifest" href="/manifest.json"> That, of course, after you've:   entered all the information about your PWA copied the manifest.json created a new “manifest.json” file in the root directory of your site and pasted it there  It should be served with:   Content-Type: application/json HTTP header or a Content-Type: application/manifest+json   And here's a “sample” piece of code: { "name": "My PWA Sample App", "short_name" : "PWA", "start_url": "index.html?utm_source=homescreen", "scope" : "./", "icons": [ { "src": "./android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" }, { "src": "./android-chrome-512x512.png", "sizes": "512x512", "type": "image/png" } ], "theme_color": "#ffee00", "background_color": "#ffee00", "display": "standalone" } Once the “Manifest” section of the Chrome's Development Tools Application tab has validated your JSON file, it will generate an “Add to home screen” link to be accessed on all desktop devices. Tip: as you convert your website to a progressive web app you don't necessarily need to configure the manifest.json file yourself — with all its different images sizes, meta tags etc. Instead, if you want to make it quick, you can just make a 500x500 sized image of your PWA and then rely on Real Favicon Generator to create all the needed icon sizes and a manifest file for you! And this is just one of the generators you could use!   Step 3: Set Up Your Service Worker This is where the “true power” of your PWA lies: A service worker is a JavaScript file, placed in your app's root, that plays the role of a “middleman” between the browser and the host. The one which, once installed in the supported browsers, intercepts and responds to the network request in different ways. Note: in most cases, it's for caching all the static files, so that our PWAs can function offline, too, that we use service workers. Now that we've seen what a service worker is, here's how you create one as you convert your website to a progressive web app:   a. You get it registered first things first. For this, just run this code in the JS file on your site: if ('serviceWorker' in navigator) { // register service worker navigator.serviceWorker.register('/service-worker.js'); } Practically, it will check whether the browser does support Service Workers and, if it does, it registers your Service Worker file. Note: NEVER call this file, inside your website, like this: <script src="./service-worker.js"></script> b. If you do not need your PWA to work offline, too, just set up an empty /service-worker.js file. Users will just be notified to install it on their devices!   c. Once you've registered your Service Worker, generate your Service Worker file, too. For this, just run this command in your terminal: $ npm install --global sw-precache Next, go ahead and run it on your website directory: $ sw-precache Et voila! You will have generated a service-worker.js including the service worker contents.   Test It Out! At this stage of the "convert your website to a progressive web app" process, you should:   check whether your service worker got properly registered and installed on Chrome run a performance audit on your PWA, using Chrome's Lighthouse Extension   For the first operation, go through these 3 basic steps here:   press F12 to open your Chrome Dev Tools click on the “Application” tab next, on the sidebar, select “Service Workers”    Then, check whether your service worker has been properly activated and is running normally: Just tick the “Offline” checkbox and try reloading. Does your PWA-site still display its content, even when there's no internet connection? Now let's run an audit using Chrome's dedicated testing tool, Lighthouse:   press F12 again to visualize the Chrome Dev Tools select the “Audits” tab then select “Perform an audit” check all the suggested checkboxes and finally, run the audit    And here's how the generated report would look like: The END! This is how you convert your website to a progressive web app in 3 steps:   enabling HTTPS configuring your web app manifest creating your service worker   See? Any website can be turned into a PWA and you don't need to be a senior developer to do it. ... Read more
Silviu Serdaru / Jul 24'2018
10 Essential Modules to Start Building Your Drupal Site from Scratch: Toolkit Must-Haves
So, you've installed your version of Drupal and you're now ready to actually start building your website. What essential tools should you keep close at hand, as a site builder? Which are those both flexible and powerful must-have modules to start building your Drupal site from scratch? The ones guaranteeing you a website that:   integrates easily with all the most popular third-party services and apps is interactive and visually-appealing, irrespective of the user's device is a safe place for users to hang on, interact with, shop on, network on... is conveniently easy for content managers and admins to handle   Luckily, there are plenty of modules, themes and plugins to overload your toolbox with: Long gone are the code-centric webmaster's “glory days”! Nowadays, as a Drupal site builder, you have a whole array of tools at your disposal to just start building and getting a Drupal site up and running in no time. Sometimes without the need to write a single line of code! But, let's not beat around the bush any longer and have a close look at these 10 essential modules that you'll need for your “Drupal 8 site building” project:   1. Password Policy Definitely a must-have module: Just consider that Drupal accepts ANY user password, be it a... one-letter password! So, in order to set up your own stricter and safer password policy, you need to install this module here. Then, you can easily define:   the minimal (and maximal) no. of characters that any user password on your Drupal site should include the no. of special characters that it has to include specific restrictions Like: "one can't use his/her email address as his/her password"   2. Comment Notify Why should this module, too, be in your essential toolkit of modules to start building your Drupal site with? Because it implements the functionality to get notified — you, the admin or content manager —  as soon as a user posts a comment on the website. Note: you can get “alerts” about both the logged in and the anonymous visitors' comments.   3. Breakpoints, One of the Must-Have Modules to Start Building Your Drupal Site  It goes without saying that one of the Drupal site building best practices is providing it with a responsive web design. And this is precisely what this module here facilitates: Setting the proper media queries, once you've defined your own breakpoints.   4. Simple Hierarchical Select             A module whose functionality bubbles up to the content manager's experience. Whenever he/she will have to make a selection involving both categories and subcategories, this hierarchical type of selection will prove to be more than useful: Practically, once you/they select the “main” option, a new drop-down menu/widget including the subcategories to select from, pops up, as well. Like in the image here below: 5. EU Cookie Compliance And complying with this EU notification is mandatory.  So, this is why EU Cookie Compliance is another one of the essential modules to start building your Drupal site with: It displays the given notification — providing visitors with the option to agree or/and to read more information about your cookie policy —  in the footer of your website.   6. Shield               Any Drupal site building guide would advise you to install a module that shields your website from anonymous users and search engines when running your test environments. And this is what Shield is built for: To screen your site from the rest of the world —  except for you and the logged in users — when you deploy it in a test environment. A more than convenient method, as compared to manually setting up a .htpasswd and then integrating it with .htaccess.   7. Beauty Tips     If you're not just another Drupal site builder, but a user experience-centric one, you must consider also those modules to build your Drupal site with that boost the level of user interactivity. Like Beauty Tips here. It displays balloon-help style tooltips whenever a user hovers over a certain text or page element on your website. Pretty much like Bootstrap tooltip does.   8. Secure Login           Another one of the Drupal site building best practices is to turn it into a safe place for your users to be.  In short: to protect their privacy. And if you're building a website that's available on both HTTP and HTTPS, the Secure Login module comes in handy as it makes sure that:   the user login form all the other fill-in forms that you'll configure for extra security   … get submitted via HTTPS. It locks them down, enforcing secure authenticated session cookies, so that user passwords and other critical user data don't get exposed all over the internet.   9. Menu Target   It's another one of those essential modules to start building your Drupal site with if you're determined to provide the best user experience there. What does it do? It enables particular visitors on your site — those granted permission to edit and to add new menu items — to choose whether they open menu items in new windows or in the current ones.   10. Persistent Login A module that makes up for the “Remember me” feature that's missing from the user login screen in Drupal: It comes to implement this missing option, one independent from the PHP session settings. So, we're not talking about the conventional, too long “PHP session time” here, but about a more secure and user-friendly “Remember me” feature added to the login form. Furthermore, the module enables you to define some extra security policies, too:   the no. of persistent sessions that a Drupal user can enjoy at the same time specific pages where users still have to log in again after how long the logged-in users will need to re-enter their credentials once again   And 2 “Extra” Modules to Consider When Building Your Drupal Site By “extra” I mean that they're not really essential modules to start building your Drupal site with. Yet, they're the first 2 ones to consider right after you've put together your “survival” toolkit as a site builder:   1. Site Settings & Labels     Take this common scenario: You need to display a social network URL on multiples pages on your Drupal site.  What do you do?   you hard coding this single setting in the source you start building a custom Drupal module for handling this variable you install the Site Settings & Labels module and thus display a checkbox to render page elements through a template conditional   The “c” variant's undoubtedly the winner here.  A win-win for you, in fact:   you save the time you'd otherwise have spent coding you improve the user experience on your Drupal site   2. Slick/Slick Views/Slick Media           It's actually a suite of modules to start building your Drupal site with. One “injecting” the needed functionality so that you can easily set up:   carousels slideshows   … on your freshly built website. Note! I won't lie to you: setting up the library dependencies is not exactly a child's play. Yet, once you've succeeded it, configuring the modules in this suite, right in your Drupal admin, is piece of cake. The END! These are the 10 must-have modules to start building your Drupal site from scratch with. Would you have added some more?  Or maybe you wouldn't have included some of the modules listed here, as you don't consider them “essential”? A penny for your thoughts! ... Read more
RADU SIMILEANU / Jul 20'2018
How to Add Autocomplete to Text Fields in Drupal 8: Defining a Custom Route
Let's say that it's a WhatsApp-like, a decoupled, Drupal 8-backed, real-time chat platform that you're building. One using Node.js. In this case, implementing field autocomplete functionality becomes a must, doesn't it? But how do you add autocomplete to text fields in Drupal 8? Needless to add that such otherwise "basic" functionality — implemented on fields like node reference and user/tags — would instantly:   improve the user experience  increase the level of user interactivity and engagement   Users would group around different "channels" and be able to easily add new members. The auto-complete text fields will make the whole “new member coopting” process conveniently easy: Users would only need to start typing and an array of name suggestions (of the already existing team members) would spring up. But let's see, specifically, what are the steps to take to implement autocomplete functionality in Drupal 8:   1. The Drupal Autocomplete Form Element: Adding Properties to the Text Field The first basic step to take is to define your form element. The one that will enable your app's users, on the front-end, to select from the suggested team members' names. For this:   navigate to “Form” (you'll find it under “Entity”) scroll the menu down to ”NewChannelForm.php”   Note: using “#autocomplete_route_name element”, when defining your form element, will let Drupal know that it should ignore it on the front-end. And now, let's go ahead and assign specific properties to your form's text field! For this:   define “#autocomplete_route_name”, so that the autocomplete JavaScript library uses the route name of callback URL define “#autocomplete_route_parameters”, so that an array of arguments gets passed to autocomplete handler   $form['name'] = array( '#type' => 'textfield', '#autocomplete_route_name' => 'my_module.autocomplete', '#autocomplete_route_parameters' => array('field_name' => 'name', 'count' => 5), ); And this is how you add #autocomplete callback to your fill-in form's text field in Drupal 8! Note: in certain cases — where you have additional data or different response in JSON —  the core-provided routes might just not be enough. Then, you'll need to write an autocomplete callback using the “my_module. autocomplete“ route and the proper arguments (“name” for the field name and “5” as count, let's say). And here's specifically how you write a custom route:   2. Add Autocomplete to Text Fields in Drupal 8: Define a Custom Route How? By simply adding the reference to the route — where data will get retrieved from — to your “my_module.routing.yml file”:   my_module.autocomplete: path: '/my-module-autocomplete/{field_name}/{count}' defaults: _controller: '\Drupal\my_module\Controller\AutocompleteController::handleAutocomplete' _format: json requirements: _access: 'TRUE' Note: remember to use the same names in the curly braces (those that you inserted when you defined your “autocomplete_route_parameters”) when you pass parameters to the controller!   3. Add Controller with Custom Query Parameters In the custom route that you will have defined, you'll have a custom controller AutocompleteController, with the handleAutocomplete method. Well, it's precisely this method that makes sure that the proper data gets collected and properly formatted once served. But let's delve deeper into details and see how precisely we can generate the specific JSON response for our text field element. For this, we'll need to:   set up a AutoCompleteController class file under “my_module>src>Controller > AutocompleteController.php"   then, extend the ControllerBase class and set up our handle method (the one “responsible” for displaying the proper results)   it's the Request object and those arguments already defined in your routing.yml.file (“name” for the field name and “5” for the count, remember?) that will pass for your handler's parameters   the Request object will be the one returning the typed string from URL, whereas the “field_name” and the “count” route parameters will be the ones providing the results array.   Note: once you get to this step here, as you add autocomplete to text fields in Drupal 8, remember that you should be having data in “value” and “label” key-value, as well: Next, you'll set up a new JsonResponse object and pass $results, thus generating a return JsonResponse.   Summing Up That's pretty much all the “hocus pocus” that you need to do to add autocomplete to text fields in Drupal 8. Now the proper data results should be generated. Just reload your app's form page and run a quick test: Try to create a brand new channel in your app and to add some of the already existing team members. Does the text field have autocomplete functionality added to? ... Read more
RADU SIMILEANU / Jul 18'2018
7 Common Mistakes in Interpreting Analytics Data: Statistical Pitfalls for Your UX Team to Avoid
All sorts of highly likely confusions, data taken out of its context, “obsessing over” numbers, approaching analytics with no clear goals in mind, metrics subjected to your own biases... We're all prone to making mistakes when analyzing data. Still, as a UX team striving to pull off an accurate picture of the user behavior, you need to take note of the most common mistakes in interpreting analytics data (UX analytics).  … of the biggest "gaffes" in reading data. Those responsible for all the wrong assumptions about your users that you'll end up making:   that low numbers are always a bad sign that if results show a correlation, there is definitely a causal relationship, as well   ... and so on. Now, allow me to “expose” to you the 7 most common mistakes that one can make when interpreting statistics:   1. Visits and Views: Confusing Them and Obsessing Over Them Using these two notions interchangeably is a pitfall that not only rookie data analysts fall into: With different UX analytics tools using different terminology for the very same concept and (even) confusing terminology used within the same tool, no wonder that you end up taking views for visits and vice versa. And still: make sure you fully understand the terminology, otherwise you risk to:   report on the wrong data put together some dangerously inaccurate reports   This is, no wonder, one of the most common data interpretation errors. Now, let's define views and visits and present them as two different concepts once and for all:   a view (or “pageview”) refers to a view of a page on your website tracked by the analytics tracking code a visit (or “session”) refers to a user's whole of interactions taken on your site, within a specific time frame   And now, speaking of views and visits, another one of the too common mistakes in interpreting analytics data is: Obsessing over views and visits! As a UX designer though, you may want to leave the challenge of increasing visits and page views to the marketing people in your team to handle. And, instead, to focus your efforts on that data that 's relevant to the user experience.   2. Settling for a Birdseye View Instead of Digging Deeper into Data Scratching the surface of the available data:   a quick assessment of the data at hand rapidly going over the “headline”  figures   … will only tell you something about your website's current performance in terms of traffic, but won't give you any clue on how to improve UX. How to increase the conversion rate. In other words: visits are no more than metrics signaling you how many visitors landed on your site during a given period of time, but this metrics won't reveal anything about how they actually engaged with those visited pages. See? Analyzing data as broadly as considering sessions to be the key indicator of performance and UX is another one of those common pitfalls in interpreting statistics: By far the best method of reading analytics data, as a UX-er, is to approach it with some well-defined goals in mind. This way, you'd focus your efforts on specific metrics, relevant for understanding user behavior, instead of getting yourself “drown” in a sea of data.   3. Common Mistakes in Interpreting Analytics Data: Not Looking Beyond Numbers … and not putting them in their contexts. For that's the proper way to interpret them. Otherwise, you're just... analyzing quantitative data stating the obvious: The “what” and not the “why”. This is undoubtedly one of the most common mistakes in interpreting analytics data: falling under the “spell” of numbers! Instead, you'll need to keep in mind that:   it's real users that those collected numbers represent once taken out of their contexts, numbers lack their true value they become truly valuable only when interpreted in connection with the user experience:   What do they tell you about the overall user experience on your website? This is why you should always apply qualitative methods when analyzing quantitative data. User research methods that enable you to go from “what has happened” to: “Why is it that visitors behaved that way on my website?”   4. Always Taking Low Numbers for a Bad Sign Another one of those more than common mistakes in data analysis is: Always thinking that low or a drop in numbers is a bad thing. Context is everything here! Just think of reading data analytics as a three-phase process:   what you want to see in those numbers what the available data seems like what it really means   Let me give you one good example: Less time spent on a web page could be good or bad. If we're talking about your redesigned homepage, it could very well mean that users do find its new design more intuitively efficient. That they can get to the pages on your site that they're interested in far more easily. In other words: do put those drops in numbers against their contexts before you alert everyone in your team that the site's going down the hill!   5. Overlooking to Segment Users For you surely agree that every given visitor uses your website differently:    on desktop  on mobile at different times of the day    And that multiple users interact differently with your site. Need I say more? Don't overlook these valuable considerations on your users' behavior when interpreting your quantitative data. Before you rush to make all the wrong assumptions reading your analytics data, make sure you break those figures down into multiple relevant segments:   mobile users desktop users users from different countries users falling into different age groups and so on   It's user base segmentation that turn quantitative data into... relevant data. And which, most importantly: Provide you with priceless clues regarding the areas on your site that you should be focusing your UX efforts on. Let's just say that your site has a conversion rate of 7%. Before you get overexcited about it, make sure you break that figure down. You might just discover that 9% comes from your desktop users and only 1% from your mobile users. And there you have it, there's your clue! Now you know just where to focus your UX efforts.   6. Not Setting Clear Goals Before Approaching Your Analytics And, as already stated, this could get you “tangled up” in a huge amount of data. But, if you take some time to define your goals first things first, you'll know just what you'll want to achieve from your data analysis session. And to:   direct your UX efforts towards those specific objectives focus exclusively on those metrics relevant for interpreting user behavior   If you don't know where you're heading, how can you know just how to get there; how to improve UX on your website?   7. Settling for a One-Size-Fits-All Reporting Setup Another one of those common mistakes in interpreting analytics data is sticking to a standard reporting setup. That instead of trying to custom-tune it so that it should deliver you precisely the data you need. The one relevant for your own website. Since each site works differently, you can't expect a one-size-fits-all approach to data analytics to perfectly suit them all, in the slightest details, now can you?   So, You've Analyzed Your Data: Now What? For reading your analytics data is just the first step. Now it's time you:   get some actionable takeaways from your analyzed data get to action   Are there usability tests that you need to run to figure out why the conversion rate is higher on your desktop site than on its mobile version? Or maybe you need to implement some user research methods to identify those contexts where users visit your site from their mobile devices? Time to put together your “data-fueled battle plan”! ... Read more
Adriana Cacoveanu / Jul 12'2018
These Are the 15 Best Drupal Security Modules Worth Installing on Your Website
I'm a woman of my word, as you can see: here I am now, as promised in my previous post on the most effective ways to secure a Drupal website, ready to run a “magnifying glass” over the best Drupal security modules. To pinpoint their main characteristics and most powerful features and thus to reveal why they've made it to this list. And why you should put them at the top of your own Drupal security checklist. So, shall we dig in?   1.  Login Security   It's only but predictable that since the login page/form is the entry to your Drupal site, it is also the most vulnerable page there, as well. Therefore, secure it! In this respect, what this module enables site admins to do is : define a certain number of login attempts; too many invalid authentication attempts will automatically block that account block/limit access for specific IPs   Moreover, you get notified by email or via Nagios notifications when someone is just username/password guessing or using other kinds of brute force techniques to log into your Drupal site. In short: the Login Security module, through its variety of options that it “spoils” you with, empowers you to set up a custom login policy on your site. To define your own restrictions and exceptions. 2. Drupal Core Update Module     As already mentioned here, on this blog, when we've tackled the topic of Drupal security: Keeping your Drupal core updated is that easily underrated, yet most powerful security measure that you could implement! Now what this module here does is assisting you in keeping your Drupal codebase up to date: safely patched and having all the crucial upgrades. And I don't need to remind you the security risk(s) that all those site owners ignoring the latest patches to Drupal core expose their websites to, right?    3. Captcha   Captcha is one of the best Drupal security modules since it's one of the most used ones. And no wonder: could you imagine submission forms on your website with no Captcha? The age-old system is one of the handiest ways to keep spammers and spambots away. So, having this module “plugged in”, providing you with the needed captcha support, becomes wisely convenient.   4. Password Policy   The module enables you, as your Drupal site's admin, to define specific rules for “wannabe users” to follow when they set up their account passwords. From constraints related to:   special symbols that those passwords should include, to ramp up both the given account's and your own site's security to uppercase letters to numbers...   … once you plug in this Drupal security module in, it's you who gets to set up the policy for creating account passwords.   5. Security Review, One of the Best Drupal Security Modules The Security Review module is that “Swiss knife” that you need for hardening your site's shield. Meaning that it's an all-in-one tool. One that comes with its own Drupal security checklist that it regularly goes through and sets against your website, detecting any missing or improperly implemented security measures. Moreover, it automates a whole series of tests for tracking down any signs of exploits and brute-force attacks:   arbitrary PHP execution XSS exploits SQL injection suspicious PHP or JavaScript activity in content nodes   Once it identifies the vulnerabilities, it “alerts” you and gives you the best recommendations for mitigating those security risks. All you need to do is follow the suggestions.   6. Security Kit Another module that “empowers” you to take full control over the security strategy on your Drupal site. To set up specific options for minimizing the chances of exploitable “cracks” showing up in its security shield: For instance, it could recommend you to set up HTTP headers on your Drupal site.   7. Session Limit     Here's another one of those best Drupal security modules that's also one of the widely used ones. Why is it a must-have on your own Drupal site? Because it enables you to set a limit to the number of simultaneous sessions per user, per role. This way, you trim down the chances of suspicious activity being carried out on your site and eventually leading to brute-force attacks.   8. Automated Logout       Another module that's a must on your Drupal site: It basically enables you, the site admin, to define a policy that would log out users after a specified time period of inactivity.    9. Two Factor Authentication     LinkedIn, Google, Twitter, Instagram, Facebook are just some of the big names that have adopted this user authentication method for security reasons. So, why shouldn't you, too? Especially when you have a dedicated module at hand, Two Factor Authentication, to:   provide you with various methods to select from: pre-generated codes, time-based one-time PINS or passwords, codes sent via SMS etc. give you full freedom in defining that two-factor authentication strategy that suits your site best   The principle is as simple for the user, as it is effective for your website, from a security standpoint: The user gets a security code that he/she'll then need to use for logging into your Drupal site.   10. Coder   A command-line tool, with IDE support, that gives your codebase a deep scan and detects any drift from the coding standards and best practices. Why has it made it to this exclusive list of 15 best Drupal security modules? Cause vulnerabilities might be lurking right in your Drupal code, not necessarily in your users' weak passwords or unpatched core modules. Having a tool at hand that would identify and notify you of all those weak links in your code, where the best practices aren't being followed, is just... convenience at its best.   11. SpamSpan     Another key module to add to your Drupal security checklist.  For you do agree that email addresses are some of hackers' easiest ways to infiltrate into your website, don't you?  Now what this module here does is obfuscate email addresses so that spambots can't collect them. Note: a key strength of SpamSpan is that it uses JavaScript for this process, which enhances accessibility.   12. ACL       “A set of APIs” This is how we could define this module here, which doesn't come with its own UI. Its key role? To enable other Drupal modules on your website to set up a list of users that would get selective access to specific nodes on your site.   13. Paranoia       Why is Paranoia one of the best Drupal security modules? Because it will end your “paranoia” — as its name suggests — that an ill-intentioned user might evaluate arbitrary code on your site. The module practically identifies all those vulnerable areas where a potential attacker could exploit your site's code and blocks them.   14. Content Access         Limiting or blocking access to key content types on your site is no more than a common-sense security measure to take, don't you agree? Therefore, this module here's designed to assist you throughout this process:   as you define detailed permissions on your site: to view/edit/ delete specific content types … by user role and by author    Word of caution: do keep in mind that, since Content Access uses Drupal's node API, you shouldn't enable other modules using the same endpoints on your website!   15. Google Apps Authentication         A module that ramps up not just your site's security, but also its accessibility. Just think about it: Nowadays anyone has at least one Google account. Therefore, “anyone” can easily log into your website using his/her own Google account credentials. Once, of course, you will have installed and turned this Drupal module on. END of list! These are the 15 best Drupal security modules worth installing on your site.  Scan them through, weigh their key features, set them against your site's specific security needs and make your selection! ... Read more
Adriana Cacoveanu / Jul 04'2018
What Are Some Quick and Easy Ways to Secure Drupal? 7-Step Security Checklist
You have patched your Drupal website, haven't you? If so, then that critical 3-month-old security flaw, Drupalgeddon2, can't get exploited on your site. Even so, with the menace of a cryptocurrency mining attack still lurking around the unpatched websites, you legitimately ask yourself: what are some quick and easy ways to secure Drupal? “Which are the most basic steps to take and the simplest best practices to adopt to harden my Drupal site's security myself?” Now, using keywords such as “security measures”, “quick”, “easy” and “handy”, I've come up with a list of 7 basic steps that any Drupal site owner can (and should) take for locking down his/her website. Here they are, in no particular order:   1. Keep Your Drupal Core and Modules Updated  Not only is this one of the simplest ways to secure Drupal, but one of the most effective ones, as well. Even so more now, with the Drupalgeddon2 Drupal security threat still fresh in our memory, ignoring the regularly released security updates for both Drupal core and its modules is just plain recklessness or... self-sabotage. Keep your Drupal version updated: apply security patches as soon as they get released, avoiding to leave your site exposed and exploitable. As simple as that! And where do you add that this is one of those Drupal security best practices that's the easiest to integrate into your routine. Since to run the latest updates you only need to:   sign in to your Admin panel go to “Manage”  scroll down to “Reports” → “Available Reports” click on “Check manually” if there are any critical security updates that you're advised to run, just click “Update”   This is all it takes for you to: seal any security loopholes in your Drupal core prevent any identified vulnerability from growing into a conveniently easy to access backdoor for hackers to get in   2. Install Drupal Security Modules  Strengthening the shield around your Drupal site with some powerful Drupal security modules is another both handy and effective measure that you, yourself, can easily implement. Luckily, you're definitely not out of options when it comes to good security modules in Drupal. And I'm only going to run a short module inventory here, since I'm already preparing a blog post focused precisely on this topic. Therefore, I promise to delve deep into details about each one of the here-listed modules in my next post:   Secure Login   The Security Review (Drupal 7 only)     Paranoia    Captcha     Two-factor Authentication    Content Access         Security Kit     Password Policy       Automated Logout     Password Strength     Downloading, installing security modules on your Drupal site is both:   quick and simple to do highly effective    And they serve a wide range of purposes, from:   enforcing strong password policies to monitoring DNS changes to locking down your site from security threats to blocking malicious networks to turning on a firewall on your site   As for their selection, it depends greatly on your list of priorities when it comes to improving your site's security. Take some time to weigh and to compare their features.   3. Remove Unused Modules: One of the Easiest Ways to Secure Drupal  Being the “easiest” security measure to implement doesn't make it also “the most popular” among Drupal site owners. Owners who more often than not:   underrate the importance of running a regular module usage audit on their sites ignore the Drupal security threat that an outdated piece of code (or an unused module) could turn itself into, once exploited by an attacker   So, don't be one of those site owners! Are there modules on your site that you no longer use?  That have grown outdated and that are just... lingering there, using your site's resources and risking to grow into an exploitable backdoor for hackers? Identify them and remove them! It won't take more than just a few priceless minutes of your time.   4. Enforce a Strong Password Policy Since it's not just the admin (you do have a smart username and password for logging into your admin dashboard, don't you?) that will log into your Drupal site, but users, too, implementing some strong user-side security measures is a must. In this respect, creating a strong password policy — one that would enforce the creation of complex, “hard-nut-to-crack” type of login credentials — is one the best and the easiest ways to secure Drupal on the user's side. Come up with a policy that defines specific requirements for setting up passwords of high enough entropy (letters, uppercase/lowercase, symbols, different characters combos). And don't hesitate to rely on dedicated Drupal modules for enforcing those requirements defined in your policy:   Password Strength   Secure Login    5. Block Access to All Your Sensitive Files I bet you don't want important folders, core files — upgrade.php., install.php, authorize.php, cron.php —  to be easily accessible to just... anyone, right? So, how about limiting or blocking access to them? And you can easily do that by configuring your .htaccess file —  it's the one containing details of crucial importance regarding your website access and credentials to specific parts and core files on your site: Just specify the IP addresses allowed to access those core folders, files and subdomains. Here's one “enlightening” example: <FilesMatch "(authorize|cron|install|upgrade)\.php"> Order deny, allow deny from all Allow from 127.0.0.1 </FilesMatch> Note! Now speaking of limiting access, don't limit your restrictions to your core folders and files. Remember to restrict/block access to your web server, to your server login details, as well. How? By adding a basic layer of authentication limiting server access and file access usage. Also, do remember to cautiously manage access to certain port numbers that your site/app might be using.   6. Back Up, Back Up, then... Back Up Some More  You can't anticipate brute-force attacks, but you sure can “land back on your feet” if the worst scenario ever happens. And you can only do that if you have a clean and recent backup at hand to just rollback and restore your website. In other words: back up regularly!  And remember to always back up your files and MySQL database before any update that you run on your Drupal code and modules. It is one of those common sense Drupal security best practices that should be included in any basic security checklist! Where do you add that you even have a dedicated Drupal module —  Backup and Migrate — to assist you with this process. Some of the back up “burdens” that this module will take off your shoulders are:   backing up/restoring code and multiple MySQL databases integrating Drush  backing up files directory setting up several backup schedules AES encryption for backups 7. Review All User Roles and Grant the Minimum Permissions Necessary How many user roles are there assigned on your Drupal site? If you don't quite know the answer, then it's obvious: You must give your entire user role system an audit! And to stick to this habit, one of the simplest ways to secure Drupal, after all. Review all the user roles and, most of all, review each one's set of permissions and make sure you trim them down to the minimum necessary for each role.  This way, you'll also limit access to critical files for those users that shouldn't have the permission to download or visualize them. And speaking of permission, do keep in mind to review all your file permissions, as well! See which user roles are granted permission to access key directories or to read, write or modify certain files on your website and block/restrict access where necessary. The END! Of course, this isn't even close to a complete list of ways to secure Drupal. If it had been an exhaustive one, it would have continued with more Drupal security best practices, such as:   getting the SSL Certificate securing HTTP headers using secure connections only   Etc. etc. I've only focused on some of the easiest and quickest measures that anyone, with little, close to no technical know-how at all, can implement. And I feel like stressing out the term “practice” here: Securing your Drupal site is a constant process; a series of persistent efforts and not a one time thing. Remain vigillant and cautious and don't rely on just a one-time, multifaceted security hardening “marathon”.   ... Read more
Adriana Cacoveanu / Jun 28'2018
My Drupal Site Has Been Hacked: What Do I Do? How Do I Restore It? 10 Steps to Clean It Up
Oops! The worst has happened: your Drupal site has been hacked! Maybe it was precisely one of those critical vulnerabilities, that the Drupal security team has been drawing attention to these last months, that the attacker(s) exploited?  Now what? What to do? Should you be:   rushing to restore your website to a healthy, good-working state (that, of course, if you do have a clean and recent backup available)? starting to rebuild it? investigating how your Drupal site got contaminated in the first place: where's the “open door” that the attackers used to get in? focusing on closing any backdoors that could make new attacks possible?   Now “tormenting” yourself with too many questions simultaneously will only distract you from what should be your main objective: cleaning up your website (and preventing further hacks I should add). So, let's go about it methodically, step by step:   Step 1: Write Down Issues, Steps to Take, Preventive Measures to Apply Keep your cool and go for a methodical approach to crisis management: Just open up a document and start... documenting:   the issues and any suspicious activity that you identify on your site all the steps that your strategy for removing malware and restoring your site should include the preventive security measures you commit to taking for preventing such a scenario from happening again the future   Step 2: Make a Forensic Copy of Your Drupal Site  Before you start running your “investigations” on the attack, on how your Drupal site has been hacked, and way before you get to rebuild anything: Make a forensic copy of all your files, you database and your operating system environment! Note: go with an external storage medium for these copies and store them offsite. As you're scanning through your files, detecting viruses and malware and having them cleaned up, feel free to make new and new “working backups”. And to store them in a different directory (from your regular backup files, I mean). “But why bother? When will these backups turn out particularly useful?”   when you call out to a third party to assist you with the troubleshooting process; these “working” backups will then provide a clear picture of the site before you started “malware detecting” on your own when you try to fix the issues you detect, but instead you make them worse; then, you can easily roll back those changes    Step 3: Scan Your Servers and PC for Malware, Malicious Code Injections, Viruses Before you rush to change all the passwords on your site, pause for a moment to think through your next “move”: What if the attack has been “programmed” so that the attacker should get notified once you change your password(s)? And what if it's precisely your PC or one of your servers that's got infected? Then storing a clean backup of your site precisely there would only make it even more vulnerable. So, how do you prevent that? You give both your PC and your servers a deep scan before making any change. And, thank God, you sure aren't nickel and dimed in anti-malware tools and anti-virus software: AVG, BitDefender, Malwarebytes, ESET, AV-Comparatives etc.   Step 4: Detect & Remove the Backdoors One of the crucial steps to take, once you realize that your Drupal site has been hacked, is to “close” all the backdoors. These could easily turn into hackers' access ticket into your site even after you've removed malware and restored it to its healthy state. But, for closing them you first need to... find them right? So, where to look? Here are a few key places on your site that you should focus your “searches” on:   access logs: while scanning them, be vigilant and look for PHP scrips and POST requests added to directories that have writable access   eCommerce set up: check all the payment methods, shipping addresses, credit card addresses, linked accounts, looking for any suspicious, newly added data   passwords: FTP passwords, admin passwords, control panel passwords   email rules and filters: check that the answers to the security questions are “legitimate”, that messages are being forwarded to correct email addresses etc.   Step 5: Consider Taking Your Site Offline And your decision depends greatly on the nature of your site: If it's a hacked eCommerce Drupal site that we're talking about here, then don't wait even one more minute: take your site down (along with the internal network and servers) and install a placeholder! This way, you'll prevent:   malware from being further distributed spam from being sent to your online store's customers   Note: do keep in mind that taking your site offline will instantly let the attackers know that you've detected the malware that they've “infiltrated” and that you are about to “take action”. If you decide not to take your Drupal site offline at the web server level, ensure that you've got your clean forensic copy at hand before deleting all the sessions. Note: have you detected suspicious changes of the passwords? If so, use this query here for updating them (Drupal 7):   update users set pass = concat('ZZZ', sha(concat(pass, md5(rand())))) As for the users, they can easily use the reset password tool for updating their passwords. Word of caution: mind you don't take "Drupal on maintenance mode” for “offline Drupal". They're 2 completely different things! Once your Drupal site has been hacked, the malware could be of such nature that it allows the attacker to infiltrate as long as the site's online.   Step 6: Notify Your Hosting Provider That Your Drupal Site Has Been Hacked  They should be informed about the breach and about your site being taken offline (if it's the case) immediately. The sooner the better, this way they can:   start scanning their own systems for incursions get ready to assist you with your site recovery and securing process   Step 7: Handle Client Data with Extra Precaution  And these are the specific scenarios where you'll need to take extra precautions when handling client information:   your Drupal site stores client information on the web host … it leverages the data POST method for sending form data via e-mail … it doesn't integrate with a 3rd party payment gateway, but manages the payment processes itself   If one of these 3 scenarios suits your case, then here are some of these extra precautions that you need to make to ensure the private user data doesn't get exposed:   update your SSL certificate re-check all logfiles (have any of the hosted client information been copied, updated or downloaded?) implement AVS (address verification system)  add CVV (card verification value) encrypt connections to back-end services used for sending confidential user data    Step 8: Investigate the Attack: Identify the Source(s) of Infection No matter how much pressure you might find yourself under to get your site back online ASAP, don't let take control over your site's restoring process! Not until you've detected the main source of contamination on your site. The key vulnerability that attackers exploited, the key reason why your Drupal site has been hacked in the first place. That being said, make sure that:   you first audit, on a staging server, that “clean” backup of your site that you're planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code  you compare pre- and post-hack files, looking for any suspicious changes   Now if you have a clean (and recent) backup at hand for running this comparison, the problem's almost solved. Just use the right tools to compare your files and track down discrepancies. But if you don't have a backup at hand, then there's no other way but to: Manually inspect your files and databases to identify any suspicious changes that have been made. look for any suspicious iframe or JavaScript at the end of the files (if detected, save the code in an external file) look for any sources of “Drupal site hacked redirect”; for links to external URLs   Now, as for the places that you should be running your investigations on, let me give you just a few clues:   .php files, .html files  sessions table  newly modified/created files new/updated user accounts  in writable directories and database    Step 9: Do a Full Restore of Your Site  So, you've noticed that your Drupal site has been hacked, you've assessed all the damage caused, removed malware and even detected the vulnerability that hackers exploited to get in, not it's only but logical to: Try to repair your website, right? Word of caution: never ever run your changes on your production site; instead, fix all detected issues on a staging site. Also, once you've cleaned it all up, remember to run the latest Drupal security updates, as well! Now, getting back to repairing your site, you have 2 options at hand:   you either restore a clean backup, if you know the date and time that your Drupal site has been hacked and you're also 100% sure that none of the system components, other than Drupal, got contaminated or you rebuild your Drupal site    The latter method is, undoubtedly more cumbersome, yet a lot more cautious. Go for it if:   you do not know the precise date and time when your site's got contaminated you do not have a clean (and recent) backup available to restore you've evaluated the damages as being already too widespread     Step 10: Give Your Restored Site a Full Check Before Going Live  Do remember to give your newly recovered site a final audit before getting it back up:   remove all malicious code detected suspicious files unauthorized settings   And, most of all: Close all the backdoors!   Final Word  A pretty long, complex and discouragingly tedious recovery process, don't you think?  So, why wouldn't you avoid all these steps that you need to go through once your Drupal site has been hacked? Why not avoid the risk of finding yourself forced to take your website offsite for... God knows how long, risking to impact your site's reputation and to drive away users/online customers? Don't you find it wiser to:   be prepared instead? opt for ongoing Drupal maintenance and support services? make a habit of regularly backing up your website? keep your system and software up to date (and to install all the recommended patches)? stop underrating the security advisories that the Drupal team makes?   ... Read more
RADU SIMILEANU / Jun 25'2018