January 28, 2019 at 13:21

50 shades of Drupal security

  1. For password hashing, a modified version of phpass is used , from which they have disowned on the official website. But they are in no hurry to change the mechanism [# 1845004] .
  2. They do not even want to provide the option of choosing a hashing mechanism [# 2939888] .
  3. The number of iterations for hash persistence has not been updated for more than 7 years [# 1850638] , although iterations were expected to increase at least 2 years [# 1203852] .
  4. When using PostgreSQL, password hashes are compared case insensitive [# 2475539] .
  5. PostgreSQL also has SSL support issues [# 850600] .
  6. The minimum allowable version of PostgreSQL 9.2, which has long been without security support [# 2846994] .
  7. The official assembly of Drupal contains outdated versions of vendor libraries (due to compatibility with PHP 5.5). Some of them, for example Zend, even have known vulnerabilities [# 2989631] .
  8. Also in the assembly are all 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. Checking for updates is implemented using GET requests using an insecure HTTP protocol [# 1538118] . During a MITM attack, you can palm off any links to module archives (domain and hash amounts 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 will match on ip with accounts on d.org). The HTTP protocol allows you to place a script for collecting information outside of drupal.org.
  11. A user with id = 1 is the most tasty object to attack, because he always has all the permissions that exist on the site and also has all attempts to strip him of these rights [# 540008] .
  12. This behavior is not entirely obvious, because 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. Any administrator or other user with the necessary rights can take control of this divine user with id = 1 [# 39636] .
  14. Certain rights implicitly give control over the entire site, but they also do not stand out in any way [# 2846365] , [# 594412] .
  15. Some rights may be misleading even by their name. For example, the right to view the logs actually allows you to delete them [# 1635646] .
  16. Restoring order in permissions has long been an urgent task, but it is simply ignored [# 2628870] , [# 2667018] .
  17. The administrator cannot delete the file object downloaded by another user, no matter how malicious he is [# 2949017] .
  18. The hook hook_file_download does not use the appropriate controller during validation [# 2148353] .
  19. Validation for files on the client side does not work out [# 2938441] .
  20. Weak checks on loading arbitrary files [# 2543590] , not to mention all sorts of RarJpeg glues.
  21. Some file checks rely only on the .htaccess rule [# 2829048] .
  22. .Htaccess has enough other security rules that are implicitly lost when switching to another environment (especially Nginx), but the implementation of the similar web.config rules has stalled [# 154339] , [# 2669870] .
  23. By default, on any site with Drupal 8, you can upload images with a simple POST request, consisting of the name of the registration form and the user avatar field. It is noteworthy that in Drupal 7 the output of such a field was rejected by default [# 31056] , but those days are over.
  24. When loading a file with the same name multiple times, a problem arises related to the implementation of the algorithm for generating unique file names [# 2684403] .
  25. Image address filtering is also lame. Therefore, you can log out 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 fields that are processed using the “Scale and crop” effect [# 2931533] , [# 872206] .
  27. You can simply fill up the database with the garbage cache simply by sorting the urls [# 1245482] , although the caching system perfectly takes away all resources for storing results that would be faster even from scratch [# 2888838] .
  28. You can load the site and fill the logs with error messages using special requests for contextual links [# 2864933] .
  29. Access to attached files and images is always there, regardless of access to content [# 2904842] .
  30. Comments on content will also remain available when access to content is denied [# 1781766] .
  31. You can find out whether you can use Zaregan on the site by the message for password recovery [# 1521996] .
  32. Password reset form is not protected from flooding [# 1681832] .
  33. When creating and checking passwords, without any warning, all white space characters ("\ t \ n \ r \ 0 \ x0B") around [# 1921576] are deleted . This may be a surprise to the user, and a little relief for the search algorithm.
  34. If you do not have the opportunity to get a password hash for brute force, but there is a user session, then you can brute the password without restrictions through the account itself, for example, changing the mailbox [# 2339399] .
  35. By the way, if that, the user does not even know that his box has been changed, since the attempt to implement this feature has been stopping for several years [# 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 Twig templates allows you to get unlimited control over the site [# 2860607] .
  40. The XSS attack through the 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 X-XSS-Protection security header [# 2868150] is not used .
  43. XSS can also be pushed through the PlainTextOutput class rerouting method, although the class name says the opposite [# 2896735] .
  44. It may also be a surprise that some methods check and cache the access rights of the current user, and not the one that was transferred to them [# 2628870] , [# 2266809] .
  45. Due to incorrect cache settings, you can make it impossible for the user to view their own profile [# 2614230] . A similar trick can be done with certain settings with both content [# 2982770] and media [# 2889855] .
  46. The statistics of material views can be easily manipulated through the usual for loop in the browser console, winding thousands of views per minute even if you do not have access to the material itself. You can wind up even not yet existing materials [# 2616330] .
  47. Lame validation of external urls [# 2691099] , [# 2652236] .
  48. There is no full protection from breachattack.com [# 2234243] .
  49. If you configure the Content Security Policy, then the content editor falls off [# 2789139] .
  50. This is an amateur selection, not claiming anything. Maybe someone knows worse holes? From 01/30/2019 to 10/15/2020, a bounty from the EU budget of 89,000.00 € is valid . You can try to fix something. But if it doesn’t work out, don’t despair, the manners of this project are trained to skillfully maneuver between tasks in order to keep Drupal in one place for years.
Tags:

Also popular now: