Security op website en CMS niveau

Deze week is er een update uitgegaan naar websites van opdrachtgevers, waarbij een security-wijziging heeft plaats gevonden. Dit vond plaats bovenop andere security maatregelen.

Voor afnemers van het LightBolt CMS betekent dit een stukje aanvullende security van de website als ook beheer-omgeving. Het belang van website security in het algemeen, behoeft in praktijk nog wel eens toelichting. Erg kort door de bocht, enkele redenen om aandacht uit te laten gaan naar website security:

  • je website kan een bron worden om een virus of aanval verder te verspreiden (via de achterliggende mailserver of via een bezoek aan de website);
  • je website kan misbruikt worden voor fraude doeleinden (bijvoorbeeld, contact- of bankgegevens wijzigen);
  • je website kan misbruikt worden om data te laten lekken, waardoor de AVG wetgeving om de hoek kan komen kijken;
  • je website kan worden platgelegd.

Waar gewerkt wordt, vallen echter spaanders, bewijzen de lekken die Wordpress als ook Wordpress plugins voortbrengen. Wat bovendien online staat, valt te hacken.

Wordpress en security

Het waarborgen van de security is een taak op zichzelf en hangt volledig van zowel de toepassing (website, webshop, intranet) als ook gebruikt framework af. Gebruik je bijvoorbeeld Wordpress, dan kan er meer werk aan de winkel zijn op basis van de OWASP guidelines:

Knowing the type of framework can automatically give a great advantage ... which helps a
penetration tester to expand his attack vectors. When performing fingerprinting, always carefully inspect every HTTP-header for such leaks.

Wordpress versus OWASP guidelines

Bovenstaand verklaart direct het volgende: zelfs op niet-Wordpress sites, zoals de website die je nu leest, ontvangen we bezoeken van automatische bots die op zoek zijn naar Wordpress-informatie. Bijvoorbeeld, de gebruikte Wordpress versie of aanwezige plugins (zogenaamde 'vulnerability sniffing'). Per minuten vinden er ruim 90.000 security attacks plaats, ongeacht de omvang of doel van een website.

Bij positieve resultaten, kan er dan over worden gegaan op vervolgacties, zoals automatisch of handmatig hacken van (al dan niet bekende) kwetsbare plugins.

Al meer dan eens hebben Wordpress tot backdoors geleid, waarmee een aanvaller zichzelf toegang kon verschaffen. Een recent als ook ironisch voorbeeld is de AVG / GDPR plugin om de privacy te verbeteren. Tegelijkertijd kwam de security op de tocht te staan.

Security maatregelen

Tijd voor maatregelen dus. In het geval van Wordpress of ander type systemen dat een zwaar beroep doet op plugins of externe toepassingen, des te meer.

Technische security maatregelen

Technische security maatregelen voor een applicatie of webshop zullen verder moeten gaan dan voor een website. De volgende zaken zijn echter eenvoudig van buitenaf te controleren:

  • open source updates en upgrades;
  • bron integriteit;
  • tabnabbing;
  • kwetsbare bronnen;
  • beveiligde login;
  • clickjacking.

Op AVG Cloud Register valt een verdere toelichting per security-punt te lezen.

Organisatische security maatregelen

In het geval van organisatorische maatregelen kunt u denken aan een clean-desk-policy, wijze waarop inloggegevens worden verstrekt, et cetera.

Security binnen het LightBolt CMS

Met regelmaat word me gevraagd hoe de security binnen LightBolt gewaardborgd is. Door niet primair te bouwen op third-parties, worden er vele risico's weggenomen. Dit komt zowel de security als ook privacy ten goede.

profiel settings

Overige algemene maatregelen binnen het LightBolt CMS zijn als volgt:

  • Brute-forcing maatregelen;
  • Onthouding van specifieke feedback bij mislukte inlogpogingen;
  • Historie van begonnen sessies of mislukte inlogpogingen bijgehouden, waardoor u controle houdt op activiteit van uw account (zie foto);
  • Audit-trail van beheerders;
  • Optionele Two Factor Authenticatie;
  • Op organisatie-niveau, Two Factor Authenticatie verplicht stellen voor (inzage in) specifieke modules, of voor alle accountshouders;
  • Algehele ip-adres restrictie, om middels VPN in te kunnen loggen;
  • Optioneel ip-adres en/of browser restrictie op individueel account-niveau;
  • Optioneel notificaties per mail uitsturen bij onjuiste inlog-pogingen;
  • Instelbare maximum sessieduur;
  • Rechten van beheerders op Roled-based Access Control (RBAC) basis plaats;
  • Ondersteuning van Single Sign On vanuit intranets, via de aanwezige CMS API;
  • Clickjacking preventie via framebusting;
  • Voorkoming van Cross Site Request Forgery middels CSRF tokens.

Op zoek naar een CMS of applicatie met hoge applicatie security standaarden of vragen over bovenstaande of verdere security maatregelen? Ik hoor het graag!

Laat ons weten wat je hiervan vindt!

  • Houd reacties relevant aan het onderwerp en wees redelijk en billijk naar anderen. Houd je bij het plaatsen van een reactie aan de Nederlandse wet.
  • Uw emailadres zal enkel gebruikt worden om u, indien aangegeven, op de hoogte te houden van nieuwe reacties op dit bericht.
  • Indien u er voor kiest uw emailadres weer te geven, zal deze voor bots onleesbaarder worden gemaakt.