Drupal HackCamp 2018- Things I found interesting
A couple of weeks back, Softescu's team went to Drupal Hack Camp in Bucharest.
Drupal HackCamp was an event based on security, with speakers from all over the world, we focused on Drupal and Security, but there were also talks about security in general.
We all know that the internet has become somewhat of a dangerous place and malicious users have become very inventive when it comes to breaking into a website or an application. But we only know half of the story.
This event taught me that, even though I know and program for some security threats, there are many more where those came from. I've learned that we might think it is a backend developers job to focus on threats, but in actuality it is also the frontend developers job.
It is a collective work that of securing a website or application and we all have the responsibility of protecting our products as much as possible. Of course there will still be malicious users that will find holes in our programs, but at least it will be harder for them to do so. Some things I found interesting were:
$result = db_query("SELECT n.title FROM {node} n WHERE n.type = '$type'");
This example is vulnerable to SQL injection attacks. Some users can use a UNION and the query can changed to:
'SELECT n.title FROM {node} n WHERE n.type = 'story' UNION SELECT s.sid, s.sid FROM {sessions} s WHERE s.uid = 1 -- '
In this way the query results contain the session for the administrator(user 1) and can have full permissions on the site.
To prevent SQL injection I prefer to use dynamic queries, but it is possible to use static ones with the help of a PARAMETERIZED query. Example:
db_query("SELECT n.nid FROM {node} n WHERE n.nid > %d", $nid);
SANITIZING OUTPUT
- It is recommended to use Drupal.checkPlain() in Js to avoid sending malicious data to the DOM.
- For translations I always use the t() function with replacement tokens. Reading documentation on the drupal.org I realized that there are multiple ways to use it, for example:
When you use placeholders in string translations you have different options:
- '@variable' - when the placeholder is a replacement string or a MarkupInterface object.
- '%variable' - when the placeholder replacement value needs to be wrapped in em tags.
- ':variable' - when the placeholder replacement value is a URL to be used in the "href" attribute.
I often use '@variable' but it is good to know there are 2 additional options there to help.
- In the best practices listed on the official documentation is mentioned the following usages for sanitizing the strings:
- Html::escape() - escapes text by converting special characters to HTML entities.
- SafeMarkup::format() - Formats a string for HTML display by replacing variable placeholders. - this is deprecated but you can use the \Drupal\Component\Render\FormattableMarkup class c) Xss::filter() - Filters HTML to prevent cross-site-scripting (XSS) vulnerabilities.
SECURE CONFIGURATION
- Keeping the site up to date including Drupal core, contrib modules. To make sure that you will update everything on time you should subscribe to the security announcements through the email/RSS/Twitter.
- If the site has automated testing it is recommended to disable the Testing (simpletest) module from core. That is because a user could maliciously run them over and over.
- Make sure you don't have installed Composer-based dev tools.
