91

That drupal page like so many is very long and confusing. But it contains this post by Jason, who hit the nail on the head: Posted by Jason Sale on November 1, 2010 at 12:40pm Thanks for writing this and everything, but all that I and 99% of people reading this page really want is a list of numbers next to a list of folders. /default on 755 ...


65

In this case, it looks like you need to do drush rf # pm-refresh before you do drush up drupal This will refresh the list of available updates so Drush knows there is a new release for Drupal.


34

Worth mentioning is $ drush up --security-only Only update modules that have security updates available. That includes Drupal core.


29

If you're reading this article and hoping to check a Drupal 7 site more than a month after the exploit landed, your site quite likely already got hacked. Your best bet is to restore a backup from before the attacks commenced and work from there. There is a FAQ on SA-CORE-2014-005. How do I tell if my sites have been compromised? One way to quickly check ...


24

Some checks for common attacks are (this is not an exhaustive list, but are some of the attacks seen in the wild so far): Check your user 1 account to make sure its user name, email address or password are what you expect them to be. Also check any other user accounts that have high levels of permissions if possible. Check for new user accounts that look ...


19

Whats going on with 7.32 By checking the testing module. You can see the following test was added to 7.32; + + /** + * Test SQL injection via database query array arguments. + */ + public function testArrayArgumentsSQLInjection() { + // Attempt SQL injection and verify that it does not work. + $condition = array( + "1 ;INSERT INTO {test} ...


18

You shouldn't really delete any files. If you really wanted to, you could delete the install file and various txt files, but that's about it. A better solution if you are afraid of security is to not let the files be accessed through the web server. Drupal only use the index.php file for serving content.


18

The company that found the bug has some examples on Advisory 01/2014: Drupal - pre Auth SQL Injection Vulnerability : Extract: The function assumes that it is called with an array which has no keys. Example: db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2'))); Which results in this SQL Statement ...


16

The researchers who found the bug have a proof of concept. Others have developed proofs of concept as well. However, they are purposefully not posting them to try to reduce the likelihood that it will get widely exploited. We should respect that research and restraint and not post examples here. After some time has passed and sites get upgraded then it will ...


14

I have two ideas to help with this problem. There are tools and services you can use to look for brute force attacks. The security review module and droptor tools both look in your watchdog (at Administer > Reports > Recent log messages) to see if you have a lot of failed logins for one user. You can also do that manually. In Drupal 7 the "access rules" ...


14

These kinds of probes are very common across the internet. There are a few things you can potentially do to block this problem and reduce the success of an attacker. First, I recommend everyone use Two Factor Authentication so that even if the attacker guesses your username and password they still can't login. There was a bounty for $500 to break TFA and ...


14

Drupal 8 (like Drupal 7) uses PDO to communicate with databases. With PDO, the DB API makes use of prepared statements, specifically to avoid SQL injection attacks. Practically, this means that you should use the database API methods. If you use the select, update, delete methods directly, you have a better chance of avoiding SQL injection as everything ...


13

The Drupal database layer wraps around PDO and uses prepared statements, so yes, the insert statements are sanitised and protected from SQL injection attacks. This quote from the Prepared Statements docs says it best: The parameters to prepared statements don't need to be quoted; the driver automatically handles this. If an application exclusively uses ...


13

I have migrated other CMS's to Drupal and had experience moving user accounts. Drupal's password algorithm is extremely good. The salt you are referring to in the settings.php is not used for passwords. The drupal_hash_salt salt is used for generation of things like cookies. Hence why it says you must keep it the same across all web servers if you are in ...


12

As you can see in the code, the function user_login_final_validate register a flood event. That means if a same IP try to connect a user/login password many times we will be "banned" for a while. This is one of the protections that Drupal offers. Another one, and I think if its happens to your web site you will notice it very fast, it's the CSRF token that ...


12

It will not, in any way shape or form protect you from injection. Quite the contrary, using the PHP filter is generally a horrible security problem, because it enables arbitrary code to be executed. Do not use the PHP module, at all. Greggles mentions the Paranoia module in his answer, which is awesome, consider using it. However, if you have enough ...


12

First, read up about these in the Drupal API: filter_xss check_plain So check_plain() encodes special characters that has special meaning in HTML (such as < and &) into plain text entities (i.e. &lt; and &amp; respectively) that will make these be rendered literally (not interpreted as HTML) when that string that is then displayed as part of ...


12

The specific vulnerability seems to be the ability of a requester to send one request path to the webserver, but use an HTTP header to make Drupal see a different path. The rewrite happens early, so the access layer in Drupal/Symfony runs as intended. But it bypasses path-based restrictions that happen earlier ("on higher level caches and web servers", ...


11

Here is the security vulnerability reason to avoid giving this permission to your users if you don't want your non-admin users to modify the db directly. <?php echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php"); ?> Hacking the Drupal db credentials


11

No, it very much will not! SQL injection prevention is something that needs to happen in the PHP code itself; the PHP filter won't alter your PHP, so it can't add protection to your code. I'd be very surprised if there's anything out there that can auto-magically take an arbitrary PHP script and save it from SQL injection. In fact, if you ever see ...


11

Here's some slides on automated security reviews using Drupal tools Here are some manual steps for a review You can try to improve password strength And to make all passwords stronger, Two Factor Authentication is helpful Security Review is a good call As is Paranoia And Cracking Drupal is a good resource (disclosure, I wrote it)


11

First, you need to know which input text filter you have enabled where the images are not showing. For the sake of this answer, let's say it's the "Basic HTML" input filter. Go to the configuration for this input filter, such as /admin/config/content/formats/manage/basic_html Scroll down to "Enabled Filters" and look for: "Restrict images to this site" ...


11

They see a blank 403 page with this message specifying that their IP address has been banned: The block is done at the application level. Drupal inserts a record into the blocked_ips table which is referenced upon bootstrapping; if a match is found the above page is shown. I've not heard a module that does this at the OS level. Considering the variety of ...


10

See: Securing file permissions and ownership You also might want to try adding the Security Review module to help make sure your site is following the correct file permission settings.


10

In Drupal 7, while all passwords are hashed (SHA-2 with 64-bit words) and salted, if your user's passwords have low entropy, brute-force password attacks are feasible. Image source: xkcd, explanation. Also note that the cartoon above assumes that an attacker tries to brute-force passwords over the web. As pointed out by @Damon in a comment: Readily ...


10

I think I would go with the advice drupal.org "You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.". As Bevan said in this comment "Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching ...


10

Sanitizing on output to avoid Cross Site Scripting (XSS) attacks Use Twig templates The Twig theme engine now auto escapes everything by default. That means that every string printed from a Twig template (e.g. anything between {{ }}) gets automatically sanitized if no filters are used. See Filters - Modifying Variables In Twig Templates for the ...


10

Only full releases get the security shield. Your screenshot only shows a dev version. I don't think the shield was removed from your module, as it wouldn't have had one in the first place since you don't have a full release. To get the security shield, you'll need to release a full version (one not suffixed with -dev, -alpha or -beta). ** EDIT ** I have ...


10

How can I tell if someone used this exploit to hack my site? Your Drupal 7 or 8 site can experience loss or theft of data, data can be removed, deleted or changed, wreaking havoc on the site in many different ways. See this Stack Exchange post for general information on checking to see if your website has been hacked. What can they do with this exploit ...


9

Drupal file uploads (in core or modules) should use file_save_upload which itself also calls file_munge_filename. Together those two functions should ensure that even if a file contains php it is not named in a way that a typically configured webserver would execute them. They also have protection against pl|py|cgi|asp|js files which can often contain code. ...


Only top voted, non community-wiki answers of a minimum length are eligible