Congratulations!

[Valid RSS] This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: http://crackingdrupal.com/rss.xml

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <rss version="2.0" xml:base="https://www.crackingdrupal.com"  xmlns:dc="http://purl.org/dc/elements/1.1/">
  3. <channel>
  4. <title>Cracking Drupal </title>
  5. <link>https://www.crackingdrupal.com</link>
  6. <description></description>
  7. <language>en</language>
  8. <item>
  9. <title>Improvements to Security in Drupal 7</title>
  10. <link>https://www.crackingdrupal.com/node/69</link>
  11. <description>&lt;p&gt;Drupal 7 has several security improvements. People often ask if the book &lt;a href=&quot;http://crackingdrupal.com/&quot;&gt;Cracking Drupal&lt;/a&gt; covers Drupal 6 or Drupal 7. The answer is that it mostly covers both because security issues did not change much between the versions. So the book is still just as relevant for Drupal 7 with the exception of the topics below. The only other major topic the book doesn&#039;t cover is CSRF, but you can read an article about &lt;a href=&quot;http://drupalscout.com/knowledge-base/protecting-your-drupal-module-against-cross-site-request-forgeries-csrf&quot;&gt;Protecting Drupal from CSRF&lt;/a&gt; .&lt;/p&gt;
  12. &lt;h3&gt;New Database API reduces opportunity for SQL Injection&lt;/h3&gt;
  13. &lt;p&gt;SQL Injection makes up roughly 10% of the vulnerabilities that have been found in Drupal core or contributed modules. A lot of the times this comes from people not using query placeholders, using the wrong placeholders, or trying to build dynamic queries without properly filtering user inputs. The new database API solves these three problems:&lt;/p&gt;
  14. &lt;ul&gt;
  15. &lt;li&gt;It is based on object oriented system so people are taught to use the placeholder system by default&lt;/li&gt;
  16. &lt;li&gt;It completely re-thinks how placeholders work making it so the right placeholder will be automatically inserted wither your argument is a number, string, or an array of data.&lt;/li&gt;
  17. &lt;li&gt;It makes it much easier to do dynamic queries - See &lt;a href=&quot;http://www.lullabot.com/articles/simplify-your-code-with-drupal-7s-database-api&quot;&gt;Jeff Eaton&#039;s post&lt;/a&gt; for details&lt;/li&gt;
  18. &lt;/ul&gt;
  19. &lt;p&gt;It&#039;s still possible to create SQL Injections in Drupal 7, of course. The first is to use the &lt;a href=&quot;http://drupal.org/node/310086&quot;&gt;-&amp;gt;where() method of conditional clauses&lt;/a&gt; which &quot;allows for the addition of arbitrary SQL as a conditional fragment.&quot; If your code can insert arbitrary SQL then it can insert a SQL Injection. The other way is to simply use &lt;a href=&quot;http://drupal.org/node/310072&quot;&gt;db_query for a static query&lt;/a&gt; but put concatenated user input into the query string. Luckily both of those things are easy to spot in a review and will soon become red-flags for every code reviewer.&lt;/p&gt;
  20. &lt;p&gt;As you can see, the redesigned database API is much less likely to be used incorrectly. I believe we&#039;ll see a decrease in SQL Injection vulnerabilities as Drupal 7 is adopted.&lt;/p&gt;
  21. &lt;h3&gt;Improved hashing algorithms&lt;/h3&gt;
  22. &lt;p&gt;We moved away from the increasingly crackable md5 hashing algorithm for all hashes. Passwords are now hashed with a user specific salt which makes them harder to crack. By default they are hashed 2^15 times, though you can control that number by setting&lt;/p&gt;
  23. &lt;p&gt;&lt;code&gt;&amp;lt;?php&lt;br /&gt; $conf[&#039;password_count_log2&#039;] = 16; &lt;br /&gt;?&amp;gt;&lt;/code&gt;&lt;/p&gt;
  24. &lt;p&gt; or whatever other number you choose. The benefit of setting that variable in your settings.php is that it is not in the database so a malicious user attempting to crack a password would have to try hashing it a different number of times. This provides several benefits. It makes it very difficult to reverse engineer the passwords associated with accounts/emails if a database backup is exposed to the world or a SQL injection is found. It also makes it harder for developers to make mistakes when building an external authentication mechanism since they are practically forced to use the password/user API.&lt;/p&gt;
  25. &lt;p&gt;The password hashing mechanism is based on phpass and is compatible with other systems that use that system. This is helpful if importing users from another site or exporting users from one version of Drupal to another.&lt;/p&gt;
  26. &lt;p&gt;There is now a site specific salt called&lt;/p&gt;
  27. &lt;p&gt;&lt;code&gt;&amp;lt;?php&lt;br /&gt; $drupal_hash_salt &lt;br /&gt;?&amp;gt;&lt;/code&gt;&lt;/p&gt;
  28. &lt;p&gt; that lives in the settings.php in addition to the site specific key called drupal_private_key which is stored in the database. These private key values can be used to increase the strength of hashed/encrypted data.&lt;/p&gt;
  29. &lt;p&gt;If you just install Drupal it wil create a drupal_hash_salt value for you, but if you want to use a different one that is managed outside of your settings.php you can simply edit the settings.php prior to installation and set the&lt;/p&gt;
  30. &lt;p&gt;&lt;code&gt;&amp;lt;?php&lt;br /&gt; $drupal_hash_salt = file_get_contents(&#039;/home/example/salt.txt&#039;); &lt;br /&gt;?&amp;gt;&lt;/code&gt;&lt;/p&gt;
  31. &lt;p&gt;. The salt.txt file should be somewhere that the webserver can read, but is not generally available to other users on your unix system. It should be read-only for the webserver. The permissions on settings.php should give a good guide for how to set the salt.txt permissions. The file should contain a string of randomly generated information. &lt;a href=&quot;http://www.random.org/&quot;&gt;Random.org&lt;/a&gt; can give tips on how to create random strings.&lt;/p&gt;
  32. &lt;p&gt;These improvements are more about hardening Drupal to stay &quot;current&quot; than it is about reducing any specific vulnerability.&lt;/p&gt;
  33. &lt;h3&gt;Drupal 7&#039;s built-in brute force detection&lt;/h3&gt;
  34. &lt;p&gt;Drupal 7 also includes brute force login attack prevention. This was possible in Drupal 6 via solutions like the &lt;a href=&quot;http://drupal.org/project/login_security&quot;&gt;Login Security module&lt;/a&gt; but now it&#039;s part of core. This feature was added in the issue to &lt;a href=&quot;http://drupal.org/node/485974&quot;&gt;Improve security: rate limit login attempts&lt;/a&gt; which does not provide a specific user interface to the feature. It does, however, have four important variables. The first two are for limiting the failed logins by IP: user_failed_login_ip_limit which defaults to 50 and user_failed_login_ip_window which defaults to 3600 seconds (i.e. one hour). The second set are for limiting failed logins per user: user_failed_login_user_limit which defaults to 5 attempts and user_failed_login_user_window which defaults to 21600 seconds (i.e. 6 hours).&lt;/p&gt;
  35. &lt;h3&gt;Easier module updates: plugin manager&lt;/h3&gt;
  36. &lt;p&gt;One of the persistent problems with security releases is getting sites upgraded. If the patch is out but nobody has installed it then it doesn&#039;t help. Drupal 7 includes the ability to install or update modules via the administrative interface making it much easier to keep a site up to date. This process uses ssh or ftp in a local loopback to access the files so that the webserver doesn&#039;t have to have the ability to write files. This, of course, can be seen to have drawbacks. The ideal way to manage this is as a separate user and keep close tabs on the &lt;a href=&quot;http://drupal.org/node/244924&quot;&gt;proper file permissions&lt;/a&gt; and the web-based installer promotes some bad practices (e.g. leaving FTP running). I think this feature is good for some sites and hope people will use it to keep their sites up to date. If you are scared of the practices it allows then I suggest you disable it by going into settings.php and uncommenting this line at the bottom to disable the feature.&lt;/p&gt;
  37. &lt;p&gt;&lt;code&gt;&amp;lt;?php&lt;br /&gt;$conf[&#039;allow_authorize_operations&#039;] = FALSE;&lt;br /&gt;?&amp;gt;&lt;/code&gt;&lt;/p&gt;
  38. &lt;h3&gt;Drupal.org improvements in security coincide with Drupal 7 release&lt;/h3&gt;
  39. &lt;p&gt;Drupal 7 was released in January of 2011 and the git migration wrapped up in March of 2011. The move to git helps module maintainers to create a new release of their module based on an old tag without having to do gymanistics in CVS. This will allow security releases to contain ONLY security fixes which will help site builders to deploy those changes quickly. Site builders will be able to QA the change much more rapidly and worry less about features and bugfix changes in the code that might break their site.&lt;/p&gt;
  40. &lt;p&gt;Knowing security is a process, we have also made improvements to our security advisory process. The security.drupal.org site is where the &lt;a href=&quot;http://drupal.org/security-team&quot;&gt;Security Team&lt;/a&gt; collaborates on issues. It now provides access to an issue for issue reporter and module maintainer to make collaboration with the team easier. This should increase the free time the Security Team has to work on other items, and for maintainers it will increase the ease of interacting with the Security Team making them more likely to get the fix released properly. We also are using a template for writing the Security Advisories. This process increases the quality of the advisories and lets module maintainers write them directly without needing nearly as much help from the security team. Again, that&#039;s a big help to both the Security Team and the module maintainers.&lt;/p&gt;
  41. </description>
  42. <comments>https://www.crackingdrupal.com/node/69#comments</comments>
  43. <category domain="https://www.crackingdrupal.com/taxonomy/term/60">Drupal 7</category>
  44. <category domain="https://www.crackingdrupal.com/category/tags/security">security</category>
  45. <pubDate>Wed, 01 Jul 2015 21:49:52 +0000</pubDate>
  46. <dc:creator>greggles</dc:creator>
  47. <guid isPermaLink="false">69 at https://www.crackingdrupal.com</guid>
  48. </item>
  49. <item>
  50. <title>Why counting vulnerabilities is not a sufficient method of comparing product security</title>
  51. <link>https://www.crackingdrupal.com/node/66</link>
  52. <description>&lt;p&gt;A lot of people find themselves in the position of trying to figure out which software package is the most secure, or at least &lt;em&gt;more&lt;/em&gt; secure between a field of choices. They often try to do this by comparing the number of vulnerabilities in the two packages, going to vulnerability databases like MITRE-CVE or NIST-NVD.&lt;/p&gt;
  53. &lt;p&gt;However, consider this example timeline of vulnerability disclosure from a &lt;a href=&quot;http://lists.grok.org.uk/pipermail/full-disclosure/2013-June/090761.html&quot;&gt;sample issue on full disclosure&lt;/a&gt;&lt;/p&gt;
  54. &lt;blockquote&gt;&lt;p&gt;
  55. 2013.05.11 Vulnerability reported to the vendor&lt;br /&gt;
  56. 2013.05.12 Vendor asked for details&lt;br /&gt;
  57. 2013.05.12 Details and exploit provided to the vendor&lt;br /&gt;
  58. 2013.05.30 Asked vendor about the status of investigation (no response)&lt;br /&gt;
  59. 2013.06.11 Sent another mail to the vendor (no response)&lt;br /&gt;
  60. 2013.06.15 Full disclosure
  61. &lt;/p&gt;&lt;/blockquote&gt;
  62. &lt;p&gt;That is actually a real problem that could expose passwords and private key of a site. It affects the core software. And even though the researcher followed responsible disclosure, apparently the security team didn&#039;t do anything about the issue after a month. Perhaps the worst part of all this...there&#039;s a good chance this vulnerability will never make it into a database like NVD or CVE.&lt;/p&gt;
  63. &lt;p&gt;Consider this example the next time someone talks about numbers of vulnerabilities. Remind them that it&#039;s more important that there is an active group of people who are:&lt;/p&gt;
  64. &lt;ol&gt;
  65. &lt;li&gt;Looking for vulnerabilities (these people don&#039;t have to be part of the product&#039;s insider community)&lt;/li&gt;
  66. &lt;li&gt;Fixing them&lt;/li&gt;
  67. &lt;/ol&gt;
  68. &lt;p&gt;In this case the active user base of the product has led a researcher to find the problem. But then the product developers didn&#039;t follow through on fixing the issue and therein comes the problem: users are vulnerable and unaware of the problem.&lt;/p&gt;
  69. </description>
  70. <comments>https://www.crackingdrupal.com/node/66#comments</comments>
  71. <pubDate>Tue, 18 Jun 2013 16:38:39 +0000</pubDate>
  72. <dc:creator>greggles</dc:creator>
  73. <guid isPermaLink="false">66 at https://www.crackingdrupal.com</guid>
  74. </item>
  75. <item>
  76. <title>Notes from Linux Security Tunables by Kees Cook</title>
  77. <link>https://www.crackingdrupal.com/node/65</link>
  78. <description>&lt;p&gt;I recently attended Drupalcon Portland where I attended Kees Cook&#039;s session on &lt;a href=&quot;http://portland2013.drupal.org/session/linux-system-security-tunables&quot;&gt;Linux System Security Tunables&lt;/a&gt;. He had some great general security advice before the session began. You can watch the video on the Drupalcon site and read the slides there. Here are my notes from the session.&lt;/p&gt;
  79. &lt;h3&gt;Authentication hygiene (e.g. ssh keys)&lt;/h3&gt;
  80. &lt;ul&gt;
  81. &lt;li&gt;know where your credentials live&lt;/li&gt;
  82. &lt;li&gt;keep away from devices with remote access&lt;/li&gt;
  83. &lt;li&gt;store encrypted, tied to a specific device - if you lose control of that device, revoke those keys&lt;/li&gt;
  84. &lt;li&gt;don&#039;t use password or even only-passphrase authentication&lt;/li&gt;
  85. &lt;li&gt;keep the ssh comments (user@host) so you can more easily revoke keys in case you need to&lt;/li&gt;
  86. &lt;li&gt;ssh gives you a host key when you first connect - verify that it&#039;s right! ssh-keygen -f /etc/ssh/ssh_host_rsa.pub -lv&lt;/li&gt;
  87. &lt;/ul&gt;
  88. &lt;h3&gt;Discretionary Access Control (user-defined)&lt;/h3&gt;
  89. &lt;ul&gt;
  90. &lt;li&gt;Personal accounts
  91. &lt;ul&gt;
  92. &lt;li&gt;no direct access&lt;/li&gt;
  93. &lt;/ul&gt;
  94. &lt;/li&gt;
  95. &lt;li&gt;Web services
  96. &lt;ul&gt;
  97. &lt;li&gt;no access to personal information nor reconfigure itself&lt;/li&gt;
  98. &lt;li&gt;cannot change execution&lt;/li&gt;
  99. &lt;/ul&gt;
  100. &lt;/li&gt;
  101. &lt;li&gt;Service maintainers
  102. &lt;ul&gt;
  103. &lt;li&gt;No access to personal acct, limited system access&lt;/li&gt;
  104. &lt;li&gt;Can modify a given service (e.g. the database service)&lt;/li&gt;
  105. &lt;/ul&gt;
  106. &lt;/li&gt;
  107. &lt;li&gt;System admin
  108. &lt;ul&gt;
  109. &lt;li&gt;extremely powerful&lt;/li&gt;
  110. &lt;/ul&gt;
  111. &lt;/li&gt;
  112. &lt;li&gt;This is great for logging because you can see transitions between levels&lt;/li&gt;
  113. &lt;li&gt;Clear lines between data and execution&lt;/li&gt;
  114. &lt;li&gt;Control access via sudo or other keys&lt;br /&gt;
  115. User_Alias SOME_SERVICE = kees, gchaix, pholcomb&lt;br /&gt;
  116. OR put individual keys into /home/some_service/.ssh/authorized_keys&lt;/li&gt;
  117. &lt;/ul&gt;
  118. &lt;h3&gt;Mandatory Access Control&lt;/h3&gt;
  119. &lt;ul&gt;
  120. &lt;li&gt;AppArmor&lt;/li&gt;
  121. &lt;li&gt;SELinux&lt;/li&gt;
  122. &lt;li&gt;SMACK&lt;/li&gt;
  123. &lt;li&gt;Tomoyo&lt;/li&gt;
  124. &lt;/ul&gt;
  125. &lt;h3&gt;Multifactor Authentication (TFA or more)&lt;/h3&gt;
  126. &lt;ul&gt;
  127. &lt;li&gt;Downside to recommending sudo: 1 password for 2 accounts&lt;/li&gt;
  128. &lt;li&gt;MFA can help&lt;/li&gt;
  129. &lt;/ul&gt;
  130. &lt;h3&gt;Kernel tunables&lt;/h3&gt;
  131. &lt;ul&gt;
  132. &lt;li&gt;Tree of items /proc/sys&lt;/li&gt;
  133. &lt;li&gt;Use sysctl to edit them, or they are files so you can just edit them&lt;/li&gt;
  134. &lt;li&gt;randomize_va_space=2&lt;/li&gt;
  135. &lt;li&gt;net.ipv4.tcp_syncookies=1&lt;/li&gt;
  136. &lt;li&gt;kernel.yama.ptrace_scope=1&lt;/li&gt;
  137. &lt;li&gt;vm.mmap_min_addr=65536&lt;/li&gt;
  138. &lt;li&gt;kptr_restrict=1&lt;/li&gt;
  139. &lt;li&gt;kernel.dmesg_restrict=1&lt;/li&gt;
  140. &lt;li&gt;fs.protected_symlinks=1&lt;/li&gt;
  141. &lt;li&gt;fs.protected_hardlines=1&lt;/li&gt;
  142. &lt;li&gt;kernel.modules_disabled=1&lt;/li&gt;
  143. &lt;/ul&gt;
  144. &lt;h3&gt;Start today&lt;/h3&gt;
  145. &lt;ul&gt;
  146. &lt;li&gt;Make a plan&lt;/li&gt;
  147. &lt;li&gt;Prioritize the changes&lt;/li&gt;
  148. &lt;li&gt;Make changes&lt;/li&gt;
  149. &lt;li&gt;Automate verification (cacti, nagios, cron, etc.)&lt;/li&gt;
  150. &lt;/ul&gt;
  151. </description>
  152. <comments>https://www.crackingdrupal.com/node/65#comments</comments>
  153. <pubDate>Fri, 31 May 2013 15:58:17 +0000</pubDate>
  154. <dc:creator>greggles</dc:creator>
  155. <guid isPermaLink="false">65 at https://www.crackingdrupal.com</guid>
  156. </item>
  157. <item>
  158. <title>Automated Security Reviews for Drupal - 2011 edition</title>
  159. <link>https://www.crackingdrupal.com/node/70</link>
  160. <description>&lt;p&gt;These are the &lt;a href=&quot;/web/20121118063717/https://docs.google.com/present/view?id=dc2n8pp9_93cnwschc7&quot;&gt;slides for a presentation&lt;/a&gt; on Automated Security Reviews I&#039;m doing at Drupalcamp Colorado. You may also be interested in &lt;a href=&quot;/steps-drupal-security-review&quot;&gt;Steps to a Drupal Security Review&lt;/a&gt;.&lt;br /&gt;
  161. &lt;br /&gt;&lt;/p&gt;
  162. &lt;p&gt;&lt;iframe src=&quot;https://docs.google.com/present/embed?id=dc2n8pp9_93cnwschc7&quot; frameborder=&quot;0&quot; width=&quot;410&quot; height=&quot;342&quot;&gt;&lt;/iframe&gt;&lt;/p&gt;
  163. </description>
  164. <comments>https://www.crackingdrupal.com/node/70#comments</comments>
  165. <category domain="https://www.crackingdrupal.com/category/tags/automated-scanning">automated scanning</category>
  166. <category domain="https://www.crackingdrupal.com/category/tags/security">security</category>
  167. <pubDate>Fri, 10 Jun 2011 07:00:00 +0000</pubDate>
  168. <dc:creator>greggles</dc:creator>
  169. <guid isPermaLink="false">70 at https://www.crackingdrupal.com</guid>
  170. </item>
  171. <item>
  172. <title>Cracking Drupal Kindle Edition now available for $14.84 (Still relevant for Drupal 7)</title>
  173. <link>https://www.crackingdrupal.com/blog/greggles/cracking-drupal-kindle-edition-now-available-1484-still-relevant-drupal-7</link>
  174. <description>&lt;p&gt;The day has finally come - &lt;a href=&quot;http://www.amazon.com/Cracking-Drupal-Drop-Bucket-ebook/dp/B004RD85CQ&quot;&gt;Cracking Drupal is available for the Kindle&lt;/a&gt;.&lt;/p&gt;
  175. &lt;h3&gt;Cracking Drupal on the Kindle&lt;/h3&gt;
  176. &lt;p&gt;I asked my publisher about this almost instantly after the book came out. I had recently received a Kindle as a gift and was excited about e-books. Unfortunately the technology was young and getting a book on such a specific topic into the Kindle format was a daunting task for them. It seems either the Kindle format got easier or they got better at reformatting things to Kindle format or both and now it&#039;s available.&lt;/p&gt;
  177. &lt;p&gt;&lt;a href=&quot;http://crackingdrupal.com/buy-amazon&quot;&gt;&lt;img src=&quot;http://crackingdrupal.com/sites/crackingdrupal.com/files/Selection_2078_0.png&quot; alt=&quot;Cracking Drupal available for Kindle&quot; /&gt;&lt;/a&gt;&lt;/p&gt;
  178. &lt;p&gt;The Kindle edition costs $14.84 compared to $25 for the Amazon version of the book compared to $40 for the Wiley hardback available in stores or the $40 Wiley PDF available from Wiley.com.&lt;/p&gt;
  179. &lt;h3&gt;Drupal 7: Covered by Cracking Drupal so far&lt;/h3&gt;
  180. &lt;p&gt;One other question I&#039;ve had a lot of recently is whether or not the book Cracking Drupal covers Drupal 7. The answer is basically yes. While I was writing the book the biggest change coming about was the database API. Indeed it is now out and indeed it makes it much harder to create sql injections. Everything else the book talks about - thinking like a hacker, the nature of cross site scripting, cross site request forgeries, and sql injection - are all still relevant in Drupal 7 as they were in Drupal 6 and the configuration, process and coding practices to keep your site safe are still basically the same.&lt;/p&gt;
  181. &lt;p&gt;There is a chance that I will create an updated version of the book that more specifically covers Drupal 7 but I think more likely is to skip Drupal 7 and instead wait for a version of the book on Drupal 8. By then things will have changed enough to make it worthwhile and I can expand the coverage of areas I didn&#039;t cover as much as I would have liked to (mainly CSRF).&lt;/p&gt;
  182. </description>
  183. <comments>https://www.crackingdrupal.com/blog/greggles/cracking-drupal-kindle-edition-now-available-1484-still-relevant-drupal-7#comments</comments>
  184. <category domain="https://www.crackingdrupal.com/category/tags/drupal">Drupal</category>
  185. <category domain="https://www.crackingdrupal.com/category/tags/e-books">e-books</category>
  186. <category domain="https://www.crackingdrupal.com/category/tags/kindle">kindle</category>
  187. <category domain="https://www.crackingdrupal.com/category/tags/security">security</category>
  188. <pubDate>Wed, 06 Apr 2011 15:56:39 +0000</pubDate>
  189. <dc:creator>greggles</dc:creator>
  190. <guid isPermaLink="false">64 at https://www.crackingdrupal.com</guid>
  191. </item>
  192. <item>
  193. <title>Steps to a Drupal Security Review</title>
  194. <link>https://www.crackingdrupal.com/node/71</link>
  195. <description>&lt;p&gt;As we developed our security review offering we came up with this outline. We don&#039;t follow all the steps on every site because sites sometimes have specific concerns that we want to address before the general set. But this is our exhaustive list of steps. Note that this is only about the Drupal portion of the stack. There is an array of things you could also analyze at the webserver, database server, operating system, network and even data center levels of the stack.&lt;/p&gt;
  196. &lt;p&gt;The first are relatively simple to perform. The last three (manual review, and putting it all in a report) are the hardest.&lt;/p&gt;
  197. &lt;h3&gt;Steps to review a Drupal site&#039;s security&lt;/h3&gt;
  198. &lt;p&gt;&lt;strong&gt;Automated or semi-automated steps:&lt;/strong&gt;&lt;/p&gt;
  199. &lt;ul&gt;
  200. &lt;li&gt;&lt;a href=&quot;http://crackingdrupal.com/blog/greggles/creating-sanitized-drupal-database-dump&quot;&gt;Santize the database&lt;/a&gt;, remove all e-mail addresses, remove passwords, etc.&lt;/li&gt;
  201. &lt;li&gt;Install one or more of &lt;a href=&quot;http://drupal.org/project/mail_logger&quot;&gt;mail_logger&lt;/a&gt;, &lt;a href=&quot;http://drupal.org/project/reroute_email&quot;&gt;reroute_email&lt;/a&gt;, &lt;a href=&quot;http://drupal.org/project/advanced_mail_reroute&quot;&gt;advanced_mail_reroute&lt;/a&gt;, &lt;a href=&quot;http://drupal.org/project/maillog&quot;&gt;maillog&lt;/a&gt; so that your testing won&#039;t accidentally send mails.&lt;/li&gt;
  202. &lt;li&gt;Is core modified anywhere? Are their contribs modified anywhere? check with &lt;a href=&quot;http://drupal.org/project/hacked&quot;&gt;Hacked!&lt;/a&gt;&lt;/li&gt;
  203. &lt;li&gt;Are those modifications documented somewhere or just modified? Ideally patch files should exist somewhere like /sites/example.com/patches/ or in the module directory itself with a Drupal.org issue number and comment number as part of the patch name).&lt;/li&gt;
  204. &lt;li&gt;Install &lt;a href=&quot;http://drupal.org/project/security_review&quot;&gt;Security Review&lt;/a&gt; module on the live site and local site and make sure it passes&lt;/li&gt;
  205. &lt;li&gt;Use a stronger than normal rainbow table to find anyone who has an advanced role and a weak password (See &lt;a href=&quot;http://drupal.org/node/897960&quot;&gt;this issue&lt;/a&gt; for some related work).&lt;/li&gt;
  206. &lt;li&gt;Run &lt;a href=&quot;http://drupal.org/project/coder&quot;&gt;Coder Security&lt;/a&gt; on all contributed modules and custom code&lt;/li&gt;
  207. &lt;li&gt;Run &lt;a href=&quot;http://drupal.org/project/secure_code_review&quot;&gt;Secure Code Review&lt;/a&gt; on contributed modules and all custom code&lt;/li&gt;
  208. &lt;/ul&gt;
  209. &lt;p&gt;&lt;strong&gt;Manual steps:&lt;/strong&gt;&lt;/p&gt;
  210. &lt;ul&gt;
  211. &lt;li&gt;Install &lt;a href=&quot;http://github.com/miccolis/vuln&quot;&gt;vuln&lt;/a&gt; and browse the site as a human&lt;/li&gt;
  212. &lt;li&gt;Interview the client: What does the site do? What can users do on the site? What content can they post, what fields can they edit? Based on those interviews &lt;/li&gt;
  213. &lt;li&gt;Probe the site, entering fuzz content and/or Javascript &lt;/li&gt;
  214. &lt;li&gt;Manually review the custom theme&lt;/li&gt;
  215. &lt;li&gt;Manually review custom code&lt;/li&gt;
  216. &lt;/ul&gt;
  217. &lt;p&gt;The manual review is based on knowledge of secure coding practices. That can be gained from &lt;a href=&quot;http://drupal.org/writing-secure-code&quot;&gt;reading the handbook&lt;/a&gt; and reading &lt;a href=&quot;http://crackingdrupal.com/&quot;&gt;Cracking Drupal&lt;/a&gt;.&lt;/p&gt;
  218. &lt;p&gt;&lt;strong&gt;Suggestions and report:&lt;/strong&gt;&lt;/p&gt;
  219. &lt;ul&gt;
  220. &lt;li&gt;Suggest SSL, especially for logins and admins, if they run a site where that is worth it&lt;/li&gt;
  221. &lt;li&gt;Suggest OpenID (part of core), &lt;a href=&quot;http://drupal.org/project/rpx&quot;&gt;Janrain Engage&lt;/a&gt;, etc. so that credentials like username/password can be remembered once and used on multiple sites.&lt;/li&gt;
  222. &lt;li&gt;Prepare report for issues including
  223. &lt;ul&gt;
  224. &lt;li&gt;a narrative describing the above process&lt;/li&gt;
  225. &lt;li&gt;prioritized vulnerability list with severity and estimated difficulty to fix&lt;/li&gt;
  226. &lt;li&gt;reference material describing vulnerabilities found (e.g. what is XSS?)&lt;/li&gt;
  227. &lt;li&gt;screenshots of vulnerabilities where applicable&lt;/li&gt;
  228. &lt;li&gt;a general assessment of the site&lt;/li&gt;
  229. &lt;/ul&gt;
  230. &lt;/li&gt;&lt;/ul&gt;
  231. &lt;p&gt;Originally posted on drupalscout.com&lt;/p&gt;
  232. </description>
  233. <comments>https://www.crackingdrupal.com/node/71#comments</comments>
  234. <pubDate>Mon, 21 Feb 2011 08:00:00 +0000</pubDate>
  235. <dc:creator>greggles</dc:creator>
  236. <guid isPermaLink="false">71 at https://www.crackingdrupal.com</guid>
  237. </item>
  238. <item>
  239. <title>Using XSS to steal access</title>
  240. <link>https://www.crackingdrupal.com/blog/ben-jeavons/using-xss-steal-access</link>
  241. <description>&lt;p&gt;We&#039;ve talked about Cross Site Scripting (XSS) before, and for good reason, it&#039;s a risk far too many sites are vulnerable to. XSS is scary because it runs in the context of the trusted relationship between your browser and a website; &lt;a href=&quot;http://drupalscout.com/knowledge-base/using-xss-steal-access&quot;&gt;XSS can do everything you can do&lt;/a&gt;.&lt;/p&gt;
  242. &lt;h3&gt;XSS cookie theft&lt;/h3&gt;
  243. &lt;p&gt;Let&#039;s look at another example of an XSS exploit: stealing administrative access to a site.&lt;/p&gt;
  244. &lt;ul&gt;
  245. &lt;li&gt;An attacker will enter Javascript that steals the visitor&#039;s browser cookie&lt;/li&gt;
  246. &lt;li&gt;An administrator will unknowingly execute this Javascript&lt;/li&gt;
  247. &lt;li&gt;The administrator&#039;s browser will send the cookie to the attacker&#039;s website&lt;/li&gt;
  248. &lt;li&gt;The attacker will use the stolen cookie to use the administrator&#039;s access on the site&lt;/li&gt;
  249. &lt;/ul&gt;
  250. &lt;p&gt;&lt;a href=&quot;http://drupalscout.com/knowledge-base/using-xss-steal-access&quot;&gt;&lt;img style=&quot;float: left; padding: 1em;&quot; src=&quot;http://crackingdrupal.com/sites/crackingdrupal.com/files/drupalscout-final-rgb-131x200.png&quot; /&gt;&lt;/a&gt;&lt;br /&gt;
  251. &lt;strong&gt;This article is now part of the &lt;a href=&quot;http://drupalscout.com/knowledge-base&quot;&gt;Knowledge Base&lt;/a&gt; of Drupal security articles on &lt;a href=&quot;http://drupalscout.com/&quot;&gt;Drupal Scout&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
  252. &lt;p&gt;Read the rest of &lt;a href=&quot;http://drupalscout.com/knowledge-base/using-xss-steal-access&quot;&gt;Using XSS to steal access&lt;/a&gt;&lt;/p&gt;
  253. &lt;p&gt;&lt;br style=&quot;clear:left;&quot; /&gt;&lt;/p&gt;
  254. &lt;p&gt;This page is kept so the comments posted here are available since they provide additional help and insights.&lt;/p&gt;
  255. </description>
  256. <comments>https://www.crackingdrupal.com/blog/ben-jeavons/using-xss-steal-access#comments</comments>
  257. <category domain="https://www.crackingdrupal.com/category/tags/cookies">cookies</category>
  258. <category domain="https://www.crackingdrupal.com/category/tags/demo">demo</category>
  259. <category domain="https://www.crackingdrupal.com/category/tags/planet-drupal">Planet Drupal</category>
  260. <category domain="https://www.crackingdrupal.com/category/tags/xss">XSS</category>
  261. <pubDate>Mon, 31 Jan 2011 19:00:09 +0000</pubDate>
  262. <dc:creator>Ben Jeavons</dc:creator>
  263. <guid isPermaLink="false">61 at https://www.crackingdrupal.com</guid>
  264. </item>
  265. <item>
  266. <title>Drupalcon Training: Securing your Drupal site with code and configuration</title>
  267. <link>https://www.crackingdrupal.com/blog/greggles/drupalcon-training-securing-your-drupal-site-code-and-configuration</link>
  268. <description>&lt;p&gt;&lt;em&gt;First things first, please take this &lt;a href=&quot;http://crackingdrupal.com/survey/drupal-security-2011&quot;&gt;survey about Security in Drupal&lt;/a&gt;&lt;/em&gt;.&lt;/p&gt;
  269. &lt;p&gt;Much like at last year&#039;s Drupalcon in San Francisco, Ben Jeavons and I will be giving a training about &lt;a href=&quot;http://chicago2011.drupal.org/training/security-process-code-hands-training&quot;&gt;Drupal and Security&lt;/a&gt;. When we gave this course at Drupalcon San Francisco, 88% of survey respondents said they would take the class again! We took all the feedback from last time and are working to make the experience even better.&lt;/p&gt;
  270. &lt;p&gt;The course is a mix of presentation, demonstration, guided hands-on work, and self exploration. We end the day with an hour where folks explore a vulnerable site looking for weaknesses and then wrap it all up by discussing the weaknesses found, and all the ones we knew about in the site.&lt;/p&gt;
  271. &lt;p&gt;Topics covered:&lt;/p&gt;
  272. &lt;ol&gt;
  273. &lt;li&gt;Insecure configurations&lt;/li&gt;
  274. &lt;li&gt;Cross Site Scripting&lt;/li&gt;
  275. &lt;li&gt;Cross Site Request Forgeries&lt;/li&gt;
  276. &lt;li&gt;Access bypass, the menu system, and permissions&lt;/li&gt;
  277. &lt;li&gt;SQL Injection and the database api&lt;/li&gt;
  278. &lt;/ol&gt;
  279. &lt;p&gt;Perhaps the best quote from the 2010 training:&lt;/p&gt;
  280. &lt;blockquote&gt;&lt;p&gt;Ben&#039;s jQuery administrator logout/change password/site offline demo induced buttock-clenching panic.&lt;/p&gt;&lt;/blockquote&gt;
  281. &lt;h3&gt;Trainings at Drupalcon&lt;/h3&gt;
  282. &lt;p&gt;This is one of the over &lt;a href=&quot;http://chicago2011.drupal.org/training&quot;&gt;30 trainings that will be given on March 7th&lt;/a&gt;, the day before normal Drupalcon Chicago sessions kick off. It&#039;s a really amazing list of training providers and topics and we&#039;re excited to be among them.&lt;/p&gt;
  283. &lt;p&gt;If you aren&#039;t interested in security you should definitely consider signing up for some of the other courses. Even if you&#039;ve already purchased your ticket to Drupalcon you can always add a training on the &lt;a href=&quot;http://www.regonline.com/register/checkin.aspx?eventID=911915&quot;&gt;registration form&lt;/a&gt;.&lt;/p&gt;
  284. &lt;h3&gt;Drupal security survey&lt;/h3&gt;
  285. &lt;p&gt;To prepare for the training, for the presentation, and just to get a better sense of what people think about security in Drupal, we are hosting a &lt;a href=&quot;http://crackingdrupal.com/survey/drupal-security-2011&quot;&gt;survey&lt;/a&gt; to collect some organized feedback from folks. Please take 5 minutes and fill it in.&lt;/p&gt;
  286. </description>
  287. <comments>https://www.crackingdrupal.com/blog/greggles/drupalcon-training-securing-your-drupal-site-code-and-configuration#comments</comments>
  288. <category domain="https://www.crackingdrupal.com/category/tags/drupalcon">Drupalcon</category>
  289. <category domain="https://www.crackingdrupal.com/category/tags/planet-drupal">Planet Drupal</category>
  290. <category domain="https://www.crackingdrupal.com/category/tags/security">security</category>
  291. <category domain="https://www.crackingdrupal.com/category/tags/training">Training</category>
  292. <pubDate>Tue, 18 Jan 2011 18:48:08 +0000</pubDate>
  293. <dc:creator>greggles</dc:creator>
  294. <guid isPermaLink="false">60 at https://www.crackingdrupal.com</guid>
  295. </item>
  296. <item>
  297. <title>Anything you can do XSS can do better</title>
  298. <link>https://www.crackingdrupal.com/blog/ben-jeavons/anything-you-can-do-xss-can-do-better</link>
  299. <description>&lt;p&gt;Cross Site Scripting (XSS) is the number one vulnerability in Drupal code¹ and one of the scariest forms of exploits, because anything you can do XSS can do better².&lt;/p&gt;
  300. &lt;h3&gt;More serious than &amp;lt;script&amp;gt;alert(&#039;xss&#039;)&amp;lt;/script&amp;gt;&lt;/h3&gt;
  301. &lt;p&gt;During XSS demos and vulnerability testing it&#039;s easy to use some code like &amp;lt;script&amp;gt;alert(&#039;xss&#039;)&amp;lt;/script&amp;gt; to see Javascript executed where it shouldn&#039;t be. But an alert box isn&#039;t scary.&lt;/p&gt;
  302. &lt;p&gt;It&#039;s scary when Javascript can put your Drupal site offline. And it&#039;s even scarier when it locks you out of logging back in because it changed your administrator account username, password, and email address. Watch the short video below to see a demo of this.&lt;/p&gt;
  303. &lt;p&gt;&lt;a href=&quot;http://drupalscout.com/knowledge-base/anything-you-can-do-xss-can-do-better&quot;&gt;&lt;img style=&quot;float: left; padding: 1em;&quot; src=&quot;http://crackingdrupal.com/sites/crackingdrupal.com/files/drupalscout-final-rgb-131x200.png&quot; /&gt;&lt;/a&gt;&lt;br /&gt;
  304. &lt;strong&gt;This article is now part of the &lt;a href=&quot;http://drupalscout.com/knowledge-base&quot;&gt;Knowledge Base&lt;/a&gt; of Drupal security articles on &lt;a href=&quot;http://drupalscout.com/&quot;&gt;Drupal Scout&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
  305. &lt;p&gt;Read the rest of &lt;a href=&quot;http://drupalscout.com/knowledge-base/anything-you-can-do-xss-can-do-better&quot;&gt;Anything you can do XSS can do better&lt;/a&gt;&lt;/p&gt;
  306. &lt;p&gt;&lt;br style=&quot;clear:left;&quot; /&gt;&lt;/p&gt;
  307. &lt;p&gt;This page is kept so the comments posted here are available since they provide additional help and insights.&lt;/p&gt;
  308. </description>
  309. <comments>https://www.crackingdrupal.com/blog/ben-jeavons/anything-you-can-do-xss-can-do-better#comments</comments>
  310. <category domain="https://www.crackingdrupal.com/category/tags/planet-drupal">Planet Drupal</category>
  311. <category domain="https://www.crackingdrupal.com/category/tags/xss">XSS</category>
  312. <pubDate>Fri, 01 Oct 2010 05:25:55 +0000</pubDate>
  313. <dc:creator>Ben Jeavons</dc:creator>
  314. <guid isPermaLink="false">57 at https://www.crackingdrupal.com</guid>
  315. </item>
  316. <item>
  317. <title>Zerodayscan and Drupal: finding bugs for fame</title>
  318. <link>https://www.crackingdrupal.com/blog/greggles/zerodayscan-and-drupal-finding-bugs-fame</link>
  319. <description>&lt;p&gt;If you use Drupal or are considering using Zerodayscan, please read &lt;a href=&quot;http://heine.familiedeelstra.com/ZeroDayScan-full-path-disclosure-bug-in-Drupal-6.16-0day&quot;&gt;Heine Deelstra&#039;s post about Zerodayscan&lt;/a&gt;.&lt;/p&gt;
  320. &lt;p&gt;As a Drupal user you should feel confident that Drupal&#039;s belief in &quot;secure by default&quot; doesn&#039;t override the goal of creating easy to use sites by default. It is often a balance between the two and in this case Drupal is choosing to be more usable rather than more secure.&lt;/p&gt;
  321. &lt;p&gt;If you are thinking of using Zerodayscan, consider the &quot;research&quot; they are doing and the way they promote the &quot;vulnerabilities&quot; that they find. There are better security products out there...&lt;/p&gt;
  322. </description>
  323. <comments>https://www.crackingdrupal.com/blog/greggles/zerodayscan-and-drupal-finding-bugs-fame#comments</comments>
  324. <pubDate>Thu, 29 Apr 2010 11:50:30 +0000</pubDate>
  325. <dc:creator>greggles</dc:creator>
  326. <guid isPermaLink="false">54 at https://www.crackingdrupal.com</guid>
  327. </item>
  328. </channel>
  329. </rss>
  330.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid RSS" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//crackingdrupal.com/rss.xml

Home · About · News · Docs · Terms

 
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda