📜 ⬆️ ⬇️

50 shades of security Drupal

  1. For password hashing, a modified version of phpass is used , which was disowned on the official website. But they don’t rush to change the mechanism [# 1845004] .
  2. They do not even want to give the opportunity to select the hashing mechanism [# 2939888] .
  3. The number of iterations for the persistence of hashing has not been updated for more than 7 years [# 1850638] , although an increase in iterations of at least 2 years has been suggested [# 1203852] .
  4. When using PostgreSQL, password hashes are compared case insensitive [# 2475539] .
  5. Also with PostgreSQL there are problems with SSL support [# 850600] .
  6. The minimum allowed version of PostgreSQL 9.2, which has long been without security support [# 2846994] .
  7. The official build of Drupal contains outdated versions of vendor libraries (due to compatibility with PHP 5.5). Some of them, like Zend, even have known vulnerabilities [# 2989631] .
  8. Also in the assembly are all the tests, test modules, test topics and vendor libraries for testing, which increases not only the size of the archive, but also the area of ​​possible gaps [# 2338671] .
  9. The idea of ​​moving executable files outside the site [# 1672986] was also stalled .
  10. Check for updates implemented using GET requests over an insecure HTTP protocol [# 1538118] . With the MITM attack, you can slip any links to the archives of the modules (the domain and hash sums are not checked). You can also collect information about the composition of the site, the list of developers and their activity (requests from local versions of sites match ip with accounts on d.org). HTTP protocol allows you to place a script to collect information outside of drupal.org.
  11. A user with id = 1 is the most valuable object to attack, because he always has all permissions on the site, and also has all attempts to deprive him of these rights [# 540008] .
  12. This behavior is not entirely obvious, since visually in the admin panel this user is no different from others. But even an attempt to highlight this feature ended in nothing [# 572240] .
  13. You can take control of this divine user with id = 1 by any administrator, or another user with the necessary permissions [# 39636] .
  14. Certain rights implicitly give control over the entire site, but outwardly, they also do not stand out in any way [# 2846365] , [# 594412] .
  15. Some rights may even be misleading. For example, the right to view logs actually allows you to delete them [# 1635646] .
  16. Bringing order to the permissions has long been an urgent task, but it is simply ignored [# 2628870] , [# 2667018] .
  17. An administrator cannot delete a file object uploaded by another user, no matter how malicious [# 2949017] .
  18. The hook_file_download does not use the corresponding controller [# 2148353] for validation.
  19. Does not work validation for files on the client side [# 2938441] .
  20. Weak checks download arbitrary files [# 2543590] , not to mention all sorts of RarJpeg gluing.
  21. Some file checks rely only on the .htaccess rules [# 2829048] .
  22. In .htaccess, there are enough other security rules that are implicitly lost when switching to another environment (especially Nginx), but the implementation of similar rules of web.config has stalled [# 154339] , [# 2669870] .
  23. By default, you can upload images to any site with Drupal 8 with a simple POST request consisting of the name of the registration form and a field with the user's avatar. It is noteworthy that in Drupal 7, the withdrawal of such a field by default was refused [# 31056] , but those times are over.
  24. When you repeatedly download a file with the same name, there is a problem with the implementation of the algorithm for generating unique file names [# 2684403] .
  25. Filtering image addresses is also lame. Therefore, you can log off users with a picture with src = '/ user / logout' [# 144538] , or implement a DOS attack by placing a couple of hundred pictures with src = 'very / hard / page'.
  26. Another way to eat resources is to load 1000x1 images into the fields, which are processed using the “Scale and crop” effect [# 2931533] , [# 872206] .
  27. You can clog the database with the garbage cache simply by going through the urls [# 1245482] , although the cache system and without any outside help perfectly take all the resources for storing the results that even from scratch would get faster [# 2888838] .
  28. You can load the site and clog the logs with error messages using special requests to contextual links [# 2864933] .
  29. Access to attached files and images is always there, regardless of access to the content [# 2904842] .
  30. Content comments will also remain available when content access is denied [# 1781766] .
  31. Registered to use on the site can be found by post on password recovery [# 1521996] .
  32. The password reset form is not flood protected [# 1681832] .
  33. When creating and checking passwords, without any warning, all whitespace characters ("\ t \ n \ r \ 0 \ x0B") are deleted around [# 1921576] . This can be a surprise for the user, and a slight indulgence for the brute force algorithm.
  34. If you are not able to get a password hash for brute force, but there is a user session, then you can unlock the password without restrictions through the account itself, for example, changing the mailbox [# 2339399] .
  35. By the way, if anything, the user does not even know that his box has been changed, because the attempt to implement this feature has been stopped for more than a year [# 85494] .
  36. The session generation algorithm is also so-so [# 2238561] .
  37. Cookies flow between sites that are located in subfolders [# 2515054] .
  38. In some cases, you can block users by manipulating requests for incorrect password entry [# 2449335] .
  39. Access to editing templates Twig allows you to gain unlimited control over the site [# 2860607] .
  40. XSS attack through Twig attributes [# 2567743] , [# 2552837] , [# 2544110] is stubbornly ignored .
  41. You can also embed XSS in info files. For example, through the description or package fields, which can be interesting to exploit through features [# 846430] .
  42. The security header X-XSS-Protection [# 2868150] is not used.
  43. XSS can also be pushed through the class PlaingTextOutput method of rewriting, although the class name suggests the opposite [# 2896735] .
  44. It can also be a surprise that some methods check and cache the access rights of the current user, and not the one that was passed to them [# 2628870] , [# 2266809] .
  45. Due to incorrect cache settings, you can make it impossible for a user to view their own profile [# 2614230] . A similar trick can be done with certain settings and with content [# 2982770] , and with media [# 2889855] .
  46. Statistics of material views can be easily manipulated through the usual for loop in the browser console, spinning thousands of views per minute, even if you do not have access to the material itself. Even non-existent materials [# 2616330] can be wound.
  47. Lame external validation [# 2691099] , [# 2652236] .
  48. There is no full protection from breachattack.com [# 2234243] .
  49. If you configure Content Security Policy, then the content editor [# 2789139] falls off.
  50. This is an amateur collection that does not pretend to anything. Maybe someone knows holes pohlesche? From 30/01/2019 to 10/15/2020, there is a bounty from the EU with a budget of € 89,000.00. You can try to fix something. But if it does not work out - do not despair, the mantels of this project are trained to maneuver supremely between tasks to keep Drupal in one place for years.


Source: https://habr.com/ru/post/437820/

More articles: