Veiligheid

  • Abusebeleid

    Vevida voert een (pro-)actief onderzoeksbeleid naar misbruik, er wordt veel eigen onderzoek naar gedaan. De medewerkers participeren in verschillende nieuwsgroepen en mailinglijsten om op de hoogte te blijven van de laatste beveiligingszaken en (anti-)spamtechnieken.

     

    Lees meer »

  • Bewerking persoonsgegevens

    Opslag van persoonsgegevens in bij Vevida ondergebrachte websites en databases is niet toegestaan, tenzij hiertoe met Vevida een expliciete bewerkersovereenkomst is gesloten. Deze bewerkersovereenkomst maakt geen deel uit van de normale overeenkomst tussen Vevida en haar klanten.

    De wet stelt bijzondere eisen aan de opslag van persoonsgegevens. In het bijzonder moet de opslag geborgd zijn in een zogenaamde bewerkersovereenkomst. Deze overeenkomst heeft als doel de afspraken omtrent de opslag, beveiliging en transport van persoonsgegevens vast te leggen. Zonder een dergelijke bewerkersovereenkomst mag u persoonsgegevens als bedoeld in de wet, niet bij een derde in bewaring geven.

    Voor meer informatie hierover kunt u het contact opnemen met onze klantenservice.

  • Maandelijks onderhoud

    Elke maand plegen wij gepland onderhoud aan onze servers. Dit onderhoud is telkens op de eerste woensdag na de maandelijkse uitgave van beveiligingsupdates door Microsoft (de tweede dinsdag van elke maand). Het onderhoud begint steeds om 22.00 uur. Elke webserver wordt dan een of meer keren herstart, waardoor je website enkele minuten onbereikbaar is.

    Wil je op de hoogte blijven van ons maandelijks onderhoud? Meld je dan aan voor onze technische nieuwsbrief: Hosting updates. Daarin lees je ook welke updates wij gaan installeren. Of volg ons via Twitter.

    Gebruik je Microsoft Windows of Office? Dan is ons maandelijkse onderhoud voor jou ook een goed moment om updates voor je eigen computer te installeren. Daardoor blijf je beter beschermd tegen virussen en inbraak.

    Meer informatie over de beveiligingsupdates van Microsoft vind je in de Microsoft Security Bulletin Advance Notification of de Microsoft Beveiligingsbulletins.

  • Striktere websitebeveiliging met HTTP-reactieheaders

    Een HTTP-reactieheader is wat de webserver terugstuurt naar de browser, vóórdat de content wordt getoond. Een header zie je dus niet altijd, het bevindt zich op de achtergrond. Dat wat de browser -of client- stuurt naar de webserver, heet een verzoekheader (vandaar: Request header en Response header).

    In reactieheaders staat veel informatie, soms te veel informatie. Ook kun je er veel zaken in regelen, zoals hoe een browser zich gedragen moet, of wat de server moet terugsturen. Hiermee kun je de beveiliging van jouw website strikter maken.

    In een ander artikel hebben we je utigelegd dat je met een HTTP Strict-Transport-Security reactieheader volledige SSL-versleuteling tussen client en server kunt forceren.

    Zo is er nog een aantal headers dat aandacht behoeft:

    • X-Content-Type-Options
    • X-Frame-Options
    • X-XSS-Protection
    • Server
    • Content-Security-Policy

    Ja, dit is een ingewikkelder en geavanceerder artikel, maar wij vinden het wél belangrijk dit te benoemen. In het kort uiteraard.

    Je vindt op de website van het Open Web Application Security Project (OWASP , en speciaal voor WordPress: OWASP WordPress Security Implementation Guideline) belangrijke en handige informatie over deze HTTP-headers. Op internet.nl en securityheaders.io vind je meer handige informatie.

    Ook van belang is het goed instellen en terugsturen van beveiligde cookies.

    Na de tekstuele uitleg hieronder plaatsen we alle genoemde headers in een voorbeeld web.config-bestand.

    X-Content-Type-Options reactieheader

    Als je de HTTP-header X-Content-Type-Options de waarde “nosniff” meegeeft dan houdt dat in dat een browser zoals Internet Explorer, en in sommige gevallen Google Chrome, niet zelf probeert te achterhalen welk type bestand wordt gestuurd.

    De browser moet uitgaan van het Content-Type dat de website/server terugstuurt.

    X-Frame-Options reactieheader

    Met X-Frame-Options kun je instellen vanaf welk domein een frame of iframe geladen mag worden. De waarde kan “deny” zijn om het laden van externe frames tegen te gaan, “sameorigin” om alleen frames vanaf hetzelfde domein – of dus jouw website – te tonen, en “allow-from: DOMAIN“, om van een specifiek domein frames te laden. Hierbij moet je DOMAIN dus vervangen door de desbetreffende domeinnaam.

    Let op: WordPress zet zelf een X-Frame-Options header. Doe je dit ook met behulp van het web.config-bestand dan conflicteert dat en kun je ongewenst gedrag van jouw WordPress website verwachten. Hierom is de header uitgecommentarieerd in het voorbeeld hieronder, maar wel geplaatst ter illustratie. Je kunt deze header wél zelf plaatsen als je geen WordPress gebruikt en jouw website dit niet zelf doet.

    X-XSS-Protection reactieheader

    De X-XSS-Protection header schakelt het Cross Site Scripting filter van browser in. Hiermee wordt het moeilijker gemaakt om via de browser Cross Site Scripting (of XSS) aanvallen uit te voeren op websites.

    Deze XSS-beveiliging staat vaak standaard ingeschakeld in browsers, maar mocht een kwaadaardige gebruiker dit hebben gedeactiveerd, dan kun je het hiermee forceren. Geef het de waarde “1; mode=block” mee.

    Server reactieheader

    Server reactieheader: Een webserver mag graag vertellen welke software hij draait, bijvoorbeeld Windows Server IIS 8.5 of Apache 2.4. Voor aanvallers kan dit heel waardevolle informatie zijn en daarom heeft het de aanbeveling om deze Server: HTTP-reactieheader te legen. Verwijderen kun je de header helaas niet, wel kun je het besturingssysteem of webserver-versie eruit verwijderen, of er zelf iets voor in de plek zetten.

    Content-Security-Policy reactieheader

    Content-Security-Policy, of CSP, is een heel ingewikkelde header. Hierin moet je precies aangeven welke content wel geladen mag worden op jouw website, en al het andere mag simpelweg niet. Ga je hiermee aan de gang, maak dan veelvuldig gebruik van de Chrome of Firefox hulpprogramma’s console. Deze console is bereikbaar via de sneltoets F12.

    Omdat elke website weer anders is kunnen wij helaas geen goed voorbeeld hiervan geven, behalve een klein stukje ter illustratie (LET OP: niet overnemen in jouw website!). Zie http://w3c.github.io/webappsec-csp/ voor alle relevante technische informatie, een beter begrijpbare introductie staat op http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

    Voorbeelden

    Hieronder volgen de web.config-voorbeelden die je over kunt nemen in het web.config-bestand van jouw website. Let er te allen tijde op dat je geldige XML-syntaxis gebruikt, het kan zijn dat je zelf de juiste locaties moet vinden of maken in het web.config-bestand om delen van het onderstaande toe te voegen.

    Reactieheaders regelen in jouw web.config-bestand

    X-Content-Type-Options, X-Frame-Options, X-XSS-Protection: het eerste deel van het voorbeeld is eenvoudig. In de XML node httpProtocol > customHeaders (let op de casing van hoofdletters en kleine letters) kunnen we headers verwijderen en toevoegen. Je doet dit met behulp van de headernaam en de opdracht remove of add.

    Het voorbeeld zie je hieronder:

    <httpProtocol>
      <customHeaders>
        <add name="X-Content-Type-Options" value="nosniff" />
        <!-- X-Frame-Options is sometimes set by WordPress, this one might conflict -->
        <add name="X-Frame-Options" value="deny" /> <!-- of 'SAMEORIGIN' -->
        <add name="X-XSS-Protection" value="1; mode=block" />
        <add name="Content-Security-Policy" value="default-src 'self'; script-src https://cdn.example.com/scripts/; object-src 'none'; plugin-types application/pdf application/x-shockwave-flash;" />
      </customHeaders>
    </httpProtocol>

    .htaccess:

    Header set X-Content-Type-Options nosniff
    Header set X-Frame-Options SAMEORIGIN  # of 'deny'
    Header set X-XSS-Protection "1; mode=block"
    Header set Content-Security-Policy "default-src 'self'; script-src https://cdn.example.com/scripts/; object-src 'none'; plugin-types application/pdf application/x-shockwave-flash;"
    

    Server: header verwijderen

    Helaas valt de Server: reactieheader niet in de categorie customHeaders van httpProtocol in het web.config-bestand. Zoals al geschreven kun je deze header niet verwijderen, maar wel legen. En dat moet met een URL Rewrite outboundRule (een IIS URL Rewrite regel om in de output stream of uitvoerstroom van de webserver wijzigingen aan te brengen).

    De output stream is de reactie die de server terugstuurt naar de browser, ofwel de reactieheaders + pagina HTML-broncode.

    Neem in het web.config-bestand het volgende op:

      <outboundRules rewriteBeforeCache="true">
        <rule name="Remove Server header">
          <match serverVariable="RESPONSE_Server" pattern=".+" />
          <action type="Rewrite" value="" />
        </rule>
      </outboundRules>
    

    en wel ná de afsluiting van de WordPress Permalink rewrites:

    
        </rule>
      </rules>

    maar vóór de afsluitende </rewrite>.

    Deze outboundRule zoekt in de uitvoerstroom naar de HTTP-reactieheader “Server:” en herschrijft of vervangt de waarde -bijvoorbeeld- “Microsoft-IIS/8.5” met niets (value=""). Als je wilt, kun je hierin jouw eigen informatie juist toevoegen, gewoon voor de fun, bijvoorbeeld:

    <action type="Rewrite" value="Vevida speedy web server 1.0" />

    In een .htaccess is dit helaas niet mogelijk.

  • Veiliger programmeren

    Goede code zou in elk geval aan de volgende eisen moeten volden (maar niet uitsluitend):

    • Nette programmeerstijl, goed gedocumenteerde code (remarks) – dit verkleint de kans op fouten en vergemakkelijkt het toetsen;
    • Veiligheid – de code moet geen mogelijkheden bieden tot het schrijven op schijf op willekeurige lokaties, en dergelijke;
    • Stabiliteit – de code moet geen lussen bevatten die makkelijk in een oneindige loop terecht kunnen komen, foute geheugenallocaties doen, of anderszins onderdelen bevatten die de stabiliteit in gevaar kunnen brengen;
    • Portabiliteit – de code moet niet zo sterk afhankelijk zijn van een specifieke versie van Windows, IIS, .NET of een andere technologie, zodanig dat de website niet meer functioneert op een andere (nieuwere) server of na het toepassen van Service Packs.

    Lees meer »

  • Waarom wordt een gehackte website stopgezet?

    Helaas gebeurt het soms dat een website wordt gehackt. Die gehackte website wordt dan door ons stopgezet (ontoegankelijk gemaakt). Maar waarom wordt een site dan uit de lucht gehaald? In dit artikel geven wij hierover wat extra uitleg.

    Lees meer »

  • WordPress beveiligen

    WordPress beveiligen tegen hacks, dat is een steeds terugkerend onderwerp onder gebruikers en ontwikkelaars van dit CMS. Wij geven jou graag tekst en uitleg over de mogelijkheden rond WordPress beveiliging op Windows Server hosting. Daarnaast geven wij je ook 11 extra WordPress beveiligingstips, waarmee je voor een nóg betere beveiliging van jouw website zorgt.

    Lees meer »

Klantenservice

Niet gevonden wat je zocht? Neem contact op met onze klantenservice:

We zijn je graag van dienst.