A Comparative Study On The Security Of Open Source Web Content Management Systems

Steve Bottelbergs
De veiligheid van WordPress, Joomla en Drupal onder de loep De alomtegenwoordigheid van het internet is tegenwoordig niet meer weg te denken. Bijna iedereen heeft een account op websites als Facebook, Twitter en Instagram. Dit betekent dat men allerlei persoonlijke gegevens zoals naam, e-mailadres en wachtwoord verspreidt op het internet, veronderstelt dat deze veilig worden opgeslagen, en dat het gebruik van de websites zelf ook veilig is.

A Comparative Study On The Security Of Open Source Web Content Management Systems

De veiligheid van WordPress, Joomla en Drupal onder de loep

De alomtegenwoordigheid van het internet is tegenwoordig niet meer weg te denken. Bijna iedereen heeft een account op websites als Facebook, Twitter en Instagram. Dit betekent dat men allerlei persoonlijke gegevens zoals naam, e-mailadres en wachtwoord verspreidt op het internet, veronderstelt dat deze veilig worden opgeslagen, en dat het gebruik van de websites zelf ook veilig is.

Veel mensen hebben ook een eigen website of blog waar ze hun creativiteit de vrije loop kunnen laten, of zijn geregistreerd op andere websites om op de hoogte te blijven van de laatste nieuwtjes. Velen zullen niet zelf een eigen website programmeren, maar grijpen naar zogenaamde content management systemen of CMS’en. Deze systemen voorzien alle functionaliteit om een eigen website op maat te maken zonder dat de beheerder zich zorgen hoeft te maken over de veiligheid of de interne werking van het systeem. Er kan ook altijd extra functionaliteit geïnstalleerd worden als plug- ins, om de website verder te personaliseren.

CMS’en kunnen gebruikt worden om blogs te bouwen, maar bijvoorbeeld ook om websites te bouwen die een band of jeugdvereniging promoten of om een eigen webwinkel op te zetten. Meer dan 30% van alle websites op het internet gebruiken een of ander CMS. De drie meest gebruikte zijn WordPress (gebruikt door o.a. Ebay), Joomla (gebruikt door o.a. MTV) en Drupal (gebruikt door o.a. Het Witte Huis). Dit is precies de reden waarom we onderzocht hebben hoe veilig deze drie veelgebruikte CMS’en zijn.

Ons onderzoek bestaat uit een vergelijkende studie tussen deze drie CMS’en op basis van de technieken die ze gebruiken om zich te beveiligen tegen de meest voorkomende veiligheidsrisico’s op het internet. Deze veiligheidsrisico’s zijn vooropgesteld door The Open Web Application Security Project of OWASP, een organisatie die zich bezighoudt met het verbeteren van de beveiliging van software. De OWASP Top 10 geeft een overzicht van de 10 gevaarlijkste en meest voorkomende veiligheidsrisico’s op het internet. De top 10 bestaat uit de volgende veiligheidsrisico’s:

1. Injection

Dit type van veiligheidsrisico maakt het mogelijk om gegevens te bemachtigen die normaal afgeschermd zijn, bijvoorbeeld in een database. Meestal gebeurt dit door programmacode te injecteren, bijvoorbeeld in een zoekveld op een webpagina. Als de applicatie niet veilig omspringt met de gegevens die ze ontvangt van haar bezoekers kan een kwaadwillige bezoeker hier misbruik van maken om gegevens te stelen of aan te passen.

2. Broken Authentication and Session Management

Veel websites voorzien een mechanisme waarmee men zich kan inloggen, hetgeen vaak werkt met behulp van cookies, kleine gegevenspakketjes die worden opgeslagen op de computer. Sessie cookies kunnen gebruikt worden om een bepaald ID in op te slaan, wat de website vervolgens gebruikt om

een bezoeker te identificeren. Als men het ID van een bepaalde bezoeker kan achterhalen kan men zich voordoen als die bezoeker en toegang krijgen tot diens gegevens.

3. Cross-Site Scripting (XSS)

Websites kunnen scripts bevatten die in de browser worden uitgevoerd, bijvoorbeeld JavaScript. Deze zorgen er bijvoorbeeld voor dat dynamische handelingen mogelijk zijn zoals het tonen van nieuwe meldingen op Facebook. Indien men de website niet goed beveiligt, is het mogelijk dat een kwaadwillige gebruiker zelf scripts kan toevoegen, bijvoorbeeld om de sessie cookie van iemand anders te stelen.

4. Insecure Direct Object References

Vaak bevatten websites onderdelen die niet publiek toegankelijk zijn voor iedereen. Er moeten dus veilige mechanismen aanwezig zijn die ervoor zorgen dat deze afgeschermd blijven van iedereen zonder de juiste toestemming.

5. Security Misconfiguration

Een CMS voorziet verschillende instellingen die een administrator kan aanpassen. Het is belangrijk dat de standaard instellingen veilig zijn, zodat het CMS meteen veilig gebruikt kan worden.

6. Sensitive Data Exposure

Gegevens enkel afgeschermd bewaren is niet voldoende. Het is bijvoorbeeld mogelijk dat er een fout in het systeem zit waardoor men toegang krijgt tot de database en alle wachtwoorden kan lezen. Deze moeten dus geëncrypteerd worden opgeslagen, wat wil zeggen dat ze zo vervormd moeten worden dat ze niet achterhaald kunnen worden, zelfs als ze gestolen worden.

7. Missing Function Level Access Control

Dit type veiligheidsrisico is sterk gerelateerd aan Insecure Direct Object References. Het is bijvoorbeeld niet voldoende om gewoonweg geen link te tonen naar onderdelen die niet gezien mogen worden door onbevoegden. Function Level Access Control houdt in dat er achterliggend in de web applicatie ook mechanismen aanwezig moeten zijn die nagaan of een bepaald verzoek al dan niet wordt toegestaan.

8. Cross-Site Request Forgery (CSRF)

Een website moet kunnen achterhalen of een bepaald verzoek van een gebruiker afkomstig is, en dat hij deze handeling ook effectief wilde uitvoeren. Het zou bijvoorbeeld niet mogelijk mogen zijn dat iemand op een andere website op een link klikt en ineens uitgelogd is op zijn eigen website.

9. Using Components with Known Vulnerabilities

Eerder werd al vermeld dat een CMS uitgebreid kan worden door plug-ins te installeren. Deze kunnen echter ook fouten bevatten, waardoor de website onveilig kan worden. Het is belangrijk dat men weet welke plug-ins al dan niet onveilig zijn, en dat deze ook gemakkelijk geüpdatet moeten kunnen worden.

10. Unvalidated Redirects and Forwards

Een web applicatie kan bezoekers doorsturen naar andere pagina’s, bijvoorbeeld om na het inloggen naar de homepage van de website gestuurd te worden. Als dit doorsturen afhankelijk is van parameters die door iedereen aangepast kunnen worden, kan deze functionaliteit misbruikt worden om bezoekers bijvoorbeeld naar een andere website te sturen waar gegevens gestolen kunnen worden.

Uit ons onderzoek blijkt dat deze CMS’en wel degelijk mechanismen bevatten om deze risico’s te beperken of te voorkomen. Soms zijn deze technieken vergelijkbaar, maar soms ook zeer verschillend. Uit statistieken blijkt dat er meer fouten gevonden worden in plug-ins, maar ondanks alle pogingen om de standaard systemen te beveiligen, worden er toch regelmatig veiligheidsfouten gevonden in de basisfunctionaliteit. Daarom is het belangrijk om steeds alle onderdelen up to date te houden, zodat er zo weinig mogelijk kwetsbaarheden geëxploiteerd kunnen worden. CMS’en waarbij er geautomatiseerde updatesystemen aanwezig zijn, zijn daarom meer aangewezen voor onervaren gebruikers. 

 

Bibliografie
  1. [1]  OWASP Top 10 - 2013, author = Williams, Jeff, organization = OWASP, year = 2013, note = Available from: http: // owasptop10. googlecode. com/ files/ OWASP% 20Top% 2010% 20-%202013. pdf ,.

  2. [2]  Mihir Bellare, Ran Canetti, and Hugo Krawczyk. Keying Hash Functions for Message Authentication. http://cseweb.ucsd.edu/~mihir/papers/ kmd5.pdf, June 1996.

  3. [3]  Bram Bonn ́e. Improving session security in web applications, 2011.

  4. [4]  Jon Cave. Drupal 7: Secure password storage by default at last. http://joncave.co.uk/2011/01/password-storage-in-drupal- and-wordpress/, 2011.

  5. [5]  Daniel Chrysostomos. How to Configure Secure WordPress Database Per- missions. http://www.websitedefender.com/faq/configure-secure- wordpress-database-permissions/, 2012.

  6. [6]  Drupal. Drupal Upgrading Handbook. https://drupal.org/upgrade, 2002.

  7. [7]  Drupal. Detailed response to publicly posted CSRF concerns in Drupal 7.12. https://groups.drupal.org/node/216314, 2012.

  8. [8]  Drupal. Drupal Database API. https://drupal.org/developing/api/ database, 2012.

  9. [9]  Drupal. Hiding information from visitors. https://drupal.org/node/ 244642, 2012.

  10. [10]  Drupal. Drupal API Database Abstraction Layer. https: //api.drupal.org/api/drupal/includes!database!database.inc/ group/database/7, 2013.

  11. [11]  Drupal. Drupal Core Release Windows. https://drupal.org/ documentation/version-info, 2013.

  12. [12]  Drupal. Drupal Form API Reference. https://api.drupal.org/api/ drupal/developer%21topics%21forms_api_reference.html/7, 2013.

  13. [13]  Drupal. Drupal Function Reference: Drupal goto. https://api.drupal. org/api/drupal/includes%21common.inc/function/drupal_goto/7, 2013.

    [14]  Drupal. Drupal Installation Guide, Step 2: Create the database. http: //drupal.org/documentation/install/create-database, 2013.

  1. [15]  Drupal. Drupal Modules. https://drupal.org/project/modules, 2013.

  2. [16]  Drupal. Drupal Security Team. https://drupal.org/security-team,

    2013.

  3. [17]  Drupal. Usage statistics for Drupal core. https://drupal.org/project/

    usage/drupal, 2013.

  4. [18]  Faronics. Blacklist-based Software versus Whitelist-based Software. Tech- nical report, Faronics, 2011. Available from: http://www.faronics.com/ assets/blacklistvswhitelist2.pdf.

  5. [19]  The PHP Group. Prepared statements and stored procedures. http:// php.net/manual/en/pdo.prepared-statements.php, 2013.

  6. [20]  The PHP Group. Stored Procedures. http://php.net/manual/en/ mysqli.quickstart.stored-procedures.php, 2013.

  7. [21]  Infosec Institute. What is an SQL Injection? SQL Injection: An Intro- duction. http://resources.infosecinstitute.com/sql-injections- introduction/, 2013.

  8. [22]  Benjamin James Jeavons and Gregory James Knaddison. Drupal Se- curity White Paper. Technical report, Drupal, 2010. Available from: http://drupalsecurityreport.org/sites/drupalsecurityreport. org/files/drupal-security-white-paper-1-1.pdf.

  9. [23]  Joomla. Delete Installation folder. http://docs.joomla.org/Delete_ Installation_folder, 2012.

  10. [24]  Joomla. Leadership Highlights from March 2012. http://magazine. joomla.org/issues/Issue-Apr-2012/item/736-Leadership- Highlights-from-March-2012, 2012.

  11. [25]  Joomla. Access Control List Tutorial. http://docs.joomla.org/J2.5: Access_Control_List_Tutorial, 2013.

  12. [26]  Joomla. Accessing the database using JDatabase. http://docs.joomla. org/J3.1:Accessing_the_database_using_JDatabase, 2013.

  13. [27]  Joomla. Extension types (general definitions). http://docs.joomla.org/ Extension_types_(general_definitions), 2013.

  14. [28]  Joomla. How to add CSRF anti-spoofing to forms. http://docs.joomla. org/How_to_add_CSRF_anti-spoofing_to_forms, 2013.

  15. [29]  Joomla. Joomla! Vulnerable Extensions List. http://vel.joomla.org/, 2013.

  16. [30]  Joomla. Publishing to JED. http://docs.joomla.org/Publishing_to_ JED, 2013.

  1. [31]  Joomla. Retrieving request data using JInput. http://docs.joomla.org/ Retrieving_request_data_using_JInput, 2013.

  2. [32]  Joomla. Secure coding guidelines. http://docs.joomla.org/Secure_ coding_guidelines, 2013.

  3. [33]  Joomla. User Group Access Levels explained in simple terms.

    http://docs.joomla.org/User_Group_Access_levels_explained_ in_simple_terms, 2013.

  4. [34]  Joomla. What version of joomla! should you use? http://docs.joomla. org/What_version_of_Joomla!_should_you_use%3F, 2013.

  5. [35]  Amit Klein. Cross Site Scripting Explained. http://crypto.stanford. edu/cs155/papers/CSS.pdf, 2002.

  6. [36]  MITRE. Common Vulnerabilities and Exposures. http://cve.mitre. org/, 2013.

  7. [37]  OWASP. About The Open Web application Security Project. https: //www.owasp.org/index.php/About_OWASP, 2009.

  8. [38]  OWASP. OWASP Application Security Verification Standard Project.

    https://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_ Std_Release.pdf, 2009.

  9. [39]  OWASP. Cross-site Scripting (XSS). https://www.owasp.org/index. php/Cross-site_Scripting_(XSS), 2011.

  10. [40]  OWASP. Input Validation Cheat Sheet. https://www.owasp.org/index. php/Input_Validation_Cheat_Sheet, 2012.

  11. [41]  OWASP. Cross Site Request Forgery (CSRF). https://www.owasp.org/ index.php/Cross-Site_Request_Forgery_(CSRF), 2013.

  12. [42]  OWASP. Cross Site Request Forgery (CSRF) Prevention Cheat Sheet.

    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF)_Prevention_Cheat_Sheet, 2013.

  13. [43]  OWASP. Cryptographic Storage Cheat Sheet. https://www.owasp.org/ index.php/Cryptographic_Storage_Cheat_Sheet, 2013.

  14. [44]  OWASP. Injection Theory. https://www.owasp.org/index.php/ Injection_Theory, 2013.

  15. [45]  OWASP. Password Storage Cheat Sheet. https://www.owasp.org/index. php/Password_Storage_Cheat_Sheet, 2013.

  16. [46]  OWASP. SQL Injection. https://www.owasp.org/index.php/SQL_ Injection, 2013.

  17. [47]  OWASP. SQL Injection Prevention Cheat Sheet. https://www.owasp. org/index.php/SQL_Injection_Prevention_Cheat_Sheet, 2013.

  1. [48]  OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet.

    https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting) _Prevention_Cheat_Sheet, 2013.

  2. [49]  Alexander Peslyak. Portable PHP password hashing framework. http: //www.openwall.com/phpass/, 2010.

  3. [50]  PhilD. MySQL user privileges. http://forum.joomla.org/viewtopic. php?f=432&p=2692532#p2692532, 2011.

  4. [51]  PHP. mysql real escape string. http://php.net/manual/en/function. mysql-real-escape-string.php, 2013.

  5. [52]  PHP. PHP Runtime Configuration. http://www.php.net/manual/en/ info.configuration.php#ini.magic-quotes-gpc, 2013.

  6. [53]  Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger. MD5 considered harmful today. http://www.win.tue.nl/hashclash/rogue-ca/, 2011.

  7. [54]  Todd Timlinson and John K. VanDyk. Pro Drupal 7 Development. Paul Manning, 2010.

  8. [55]  udemy. Drupal vs Joomla vs WordPress: CMS Showdown. https://www. udemy.com/blog/drupal-vs-joomla-vs-wordpress/, 2013.

  9. [56]  W3Techs. PHP Manual: Overview. http://www.php.net/manual/en/ mysqli.overview.php, 2013.

  10. [57]  W3Techs. Usage of content management systems for websites. http:// w3techs.com/technologies/overview/content_management/all, 2013.

  11. [58]  WebAppSec.org. Cross site scripting. http://projects.webappsec.org/ w/page/13246920/Cross%20Site%20Scripting, 2011.

  12. [59]  WordPress. WordPress.

  13. [60]  WordPress. WordPress API: Uusing Alternative Databases. http://

    codex.wordpress.org/Using_Alternative_Databases, 2006.

  14. [61]  WordPress. WordPress API: Data Validation. http://codex.wordpress.

    org/Data_Validation, 2013.

  15. [62]  WordPress. WordPress API: Updating WordPress. http://codex.

    wordpress.org/Updating_WordPress, 2013.

  16. [63]  WordPress. WordPress API: WordPress Cookies. http://codex.

    wordpress.org/WordPress_Cookies, 2013.

  17. [64]  WordPress. WordPress API: WP DEBUG. http://codex.wordpress.

    org/WP_DEBUG, 2013.

  18. [65]  WordPress. WordPress Coding Standards Handbook. http://make.

    wordpress.org/core/handbook/coding-standards/php/, 2013.

  1. [66]  WordPress. WordPress Function Reference: Hash Password. http:// codex.wordpress.org/Function_Reference/wp_hash_password, 2013.

  2. [67]  WordPress. WordPress Glossary. http://codex.wordpress.org/ Glossary, 2013.

  3. [68]  WordPress. WordPress Plugin Directory. http://wordpress.org/ plugins/, 2013.

  4. [69]  WordPress. WordPress Plugin Directory: About. http://wordpress. org/plugins/about/, 2013.

  5. [70]  WordPress. WordPress Release Cycle. http://make.wordpress.org/ core/handbook/how-the-release-cycle-works/, 2013.

  6. [71]  WordPress. WordPress Release History. http://wordpress.org/news/ category/releases/, 2013.

  7. [72]  WordPress. WordPress Requirements. http://wordpress.org/about/ requirements/, 2013.

  8. [73]  WordPress. WordPress Security FAQ. http://codex.wordpress.org/ FAQ_Security, 2013. 

 

Universiteit of Hogeschool
Informatica - Multimedia
Publicatiejaar
2013
Kernwoorden
@sbottelbergs
Share this on: