Met CAA records is het mogelijk te bepalen welke diensten certificaten mogen uitgeven voor een domein. Hierdoor wordt de kans beperkt dat iemand anders een certificaat aanvraagt voor jouw domein en een zogenaamde man-in-the-middle attack kan uitvoeren. Omdat een CAA record in het DNS is vastegelegd ligt de verantwoordelijkheid hiervoor bij jou, de eigenaar van het domein. Ook wanneer het DNS-beheer van jouw domein in onze handen ligt kunnen wij niet geautomatiseerd een CAA-record aanmaken omdat zo'n record ook geldt voor alle subdomeinen die mogelijk niet in ons beheer zijn. Ook in dat geval ben je zelf verantwoordelijk voor de juiste instelling, maar kunnen wij hier uiteraard wel bij faciliteren.

Ons platform past automatisch HSTS headers toe voor domeinen waarvoor ingesteld staat dat een beveiligde verbinding geforceerd moet worden. Omdat dit een geautomatiseerd proces is en de includeSubDomains directive voor alle, ook interne of extern gehoste, subdomeinen geldt hebben wij er voor gekozen om vooralsnog deze directive niet toe te passen.

Zie de includeSubDomains directive. Deze directive is vereist om op de preload list te kunnen worden opgenomen.

Zogenaamde httpOnly cookies kunnen niet worden gelezen door de browser en zijn daardoor veel minder gevoelig voor misbruik. Cookies die ons platform gebruikt voor sessies en inloggen zijn daarom ook altijd httpOnly. Toch zijn er enkele cookies die in ons platform voorkomen die dat niet zijn:

• accept_cookies of hide_cookie_bar: De cookiekeuze van de bezoeker
• mod_community_order_#: De sortering van community items

Standaard genereert ons platform een CSP die zo beperkend mogelijk is zonder bestaande functionaliteit te verstoren. Omdat we te maken hebben met zowel functionaliteit die al een aantal jaren meegaat als maatwerk gebruikersinterfaces die buiten ons eigen beheer gemaakt zijn kunnen we deze CSP nog niet zo streng maken als we zouden willen en als je zou verwachten in deze tijd. Wat we wel doen is meten waar deze onveilige instellingen (unsafe-inline in script-src en style-src en unsafe-eval in script-src) nog noodzakelijk zijn. Vervolgens kunnen we de CSP op andere plekken strikter maken en kijken of we de noodzaak voor deze onveilige directives kunnen aanpakken. Dit kost echter tijd.

Wij bieden binnen ons platform functionaliteit aan die gebruik maakt van (s)ftp. Denk hierbij aan geautomatiseerde imports en exports. De ftp geeft nooit toegang tot de bronbestanden van het platform zelf of tot andere databestanden dan die via ftp aan het platform zijn aangeboden of door het platform via ftp beschikbaar zijn gemaakt.

We ondersteunen op dit moment de zwakke coderingssuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (zie: https://ciphersuite.info/cs/TLS_DHE_RSA_WITH_AES_128_GCM_SHA256/) binnen TLSv1.2. Hoewel het risico op misbruik erg laag is zijn we aan het onderzoeken of we de ondersteuning voor deze coderingssuite kunnen stoppen. Omdat het risico zo laag is zullen wij dit alleen doen wanneer het aantal gebruikers dat van deze codering afhankelijk is laag genoeg is.