Tag: applicatie

E-mailen vanuit webapplicaties

E-mail verzenden vanuit webapplicaties kan op twee manieren.

SMTP (Postfix)

Bij voorkeur gebruikt de webapplicatie SMTP (Postfix) via localhost poort 25. Hiervandaan wordt e-mail getransporteerd naar de mail relay server voor verzending naar de buitenwereld. Indien de verbinding tussen de webserver en de mail relay server niet tot stand kan komen, dan wordt e-mail tot drie dagen bewaard op de webserver. Zodra de verbinding is hersteld, wordt deze e-mail alsnog verzonden.

Sendmail

Als alternatief kan de webapplicatie sendmail gebruiken. Hierbij moet u er op letten dat u vanuit uw applicatie een correct ‘envelope FROM address’ instelt.

Voor PHP-applicaties vindt u de documentatie hierover op: https://www.php.net/manual/en/function.mail.php

Het gaat om de -f optie bij additional_parameters.

Het ‘envelope FROM address’ is een e-mailadres waar bounce-berichten naartoe worden verzonden.

Eventueel kan een engineer van Secure Webhosting de juiste instellingen voor sendmail ook in php.ini configureren.

Transport en opslag op de mail relay server

E-mail die vanuit de webserver is getransporteerd naar de mail relay server. Hier wordt gecontroleerd of het uitgaande bericht geen spam bevat en vervolgens per verzonden naar de geadresseerde(n). Daarbij wordt berichtversleuteling toegepast als de ontvangende server dat ondersteunt. Indien de verzending mislukt, dan wordt de e-mail maximaal drie dagen bewaard terwijl er periodiek nieuwe verzendpogingen worden ondernomen.

Verzonden e-mails worden standaard 14 tot 28 dagen bewaard en daarna vernietigd.

Randvoorwaarden

Om e-mail betrouwbaar te verzenden, moet aan de volgende randvoorwaarden worden voldaan:

  1. U verstrekt een bestaand e-mailadres waarop bounced mail kan worden afgeleverd. De domeinnaam van dit e-mailadres moet in ieder geval een geldig MX-record hebben.
  2. Het FROM-adres in de e-mail heeft een domeinnaam waarvoor DKIM en SPF records bestaan die Secure Webhosting erkennen als legitieme verzender (zie artikel).
  3. U gebruikt de e-maildienst uitsluitend voor transactionele e-mails, bijvoorbeeld een orderbevestiging, een ingevuld webformulier of een resetlink voor een wachtwoord. U gebruikt de dienst niet voor (bulk) e-mailmarketing of andere grootschalige mailings.
  4. De webapplicatie beschermt openbaar toegankelijke webformulieren met een goede CAPTCHA om misbruik (spamverzending) te voorkomen.
  5. De webapplicatie produceert correct geformatteerde berichten die niet als spam worden gemarkeerd:
    1. Ieder bericht heeft een Subject
    2. Ieder e-mailadres in het To, Cc of Bcc veld heeft een display name en is als volgt geformatteerd: Jane Doe <jane.doe@gmail.com>
    3. Het content-type in de header komt overeen met de content van het bericht

Applicatie geschikt maken voor Secure Webhosting

Secure Webhosting heeft zogenoemde profielen ontwikkeld om de hostingomgeving af te stemmen op een bepaald type applicatie. Profielen zijn in essentie sjablonen voor onder meer omgevings- en veiligheidsinstellingen, het aantal webservers, de hoeveelheid werkgeheugen en het aantal CPU’s.

Als onderdeel van de veiligheidsinstellingen zijn er per profiel bepaalde URL’s benoemd als restricted. Toegang tot deze URL’s is enkel mogelijk voor bevoegde gebruikers. U kunt hierbij denken aan een URL voor het inloggen op de beheeromgeving van een applicatie.

De huidige profielen:

  • WordPress Single site
  • WordPress Multisite (MU)
  • Magento 2
  • Laravel
  • PHP Generic*

* Algemeen toepasbaar profiel voor PHP maatwerk applicaties

Voor applicaties die tot deze profielen behoren, gelden onderstaande eisen voor het onderbrengen op het platform van Secure Webhosting:

Mediabestanden in bepaalde folder(s)

Onder mediabestanden verstaan wij bestanden die tijdens het gebruik van de applicatie door gebruikers worden ge-upload of door de applicatie zelf worden gedownload vanaf andere systemen (crawlen, synchroniseren, API-calls etc.).

SecWeb bewaart deze bestanden op het mediafile platform en maakt ze als folder(s) beschikbaar voor webservers. Op die manier worden twee belangrijke eigenschappen van mediafiles gerealiseerd:

  • De mediabestanden zijn direct beschikbaar zijn voor alle webservers, dus niet alleen voor de webserver waar de upload / download plaatsvond.
  • Bij een redeployment van een webserver wordt de oude versie van de webserver vernietigd, maar de mediabestanden blijven bestaan.

De mediafile folders op webservers zijn verschillend per profiel:

WordPress: /wp-content/uploads en /wp-content/cache
Magento: /pub/media
Laravel: ‘Storage’ folder
PHP Generic: onderling af te spreken

Belangrijk: De mediafolders moeten door de webdeveloper worden opgenomen in de .gitignore van de git repository van de applicatie, om te voorkomen dat de inhoud in acceptatie en productie wordt overschreven door de inhoud van een developeromgeving bij een redeployment.

Database op platform met dynamische configuratie

De database van de applicatie wordt op een databaseplatform gehost, gescheiden van de webserver. Dat leidt tot een betere spreiding van de serverbelasting (betere performance) en een verbeterde informatieveiligheid. De parameters voor de databaseverbinding worden door SecWeb automatisch ingevuld in het juiste applicatie-configuratiebestand tijdens het (re)deployen van de webserver. De applicatie moet dit ondersteunen.

Voor standaardapplicaties zoals WordPress en Magento hebben wij dit al geregeld. Voor maatwerkapplicaties maken we hierover afspraken.

E-mail via SMTP (Postfix) of Sendmail

Vanuit de applicatie kan er bij voorkeur gebruik worden gemaakt van SMTP (Postfix) met als toegestaan alternatief Sendmail om e-mailberichten te verzenden. Lees het artikel hierover.

Houd er rekening mee dat er enkele DNS records binnen de DNS omgeving van uw domein verplicht aanwezig moeten zijn om de authenticiteit van e-mailberichten te bewijzen. De benodigde records kunt u vinden in het artikel ‘DNS Omgeving‘.

Sessies niet op webserver opslaan

Omdat er op Secure Webhosting gebruik wordt gemaakt van meerdere webservers, kan sessiedata niet op één specifieke webserver worden opgeslagen. Dan kunnen andere webservers namelijk niet bij die sessiedata.

De sessiedata moet namelijk voor alle webservers beschikbaar zijn. Dit kan (bijvoorbeeld) gerealiseerd worden door de informatie van alle sessies in een database op te slaan.

Hierdoor kan de applicatie altijd de juiste sessiedata ophalen, ongeacht de webserver waar de gebruiker belandt.

Web Application Firewall (WAF)

Web Application Firewall (WAF)

Alle applicaties maken gebruik van de Web Application Firewall. Dit systeem zorgt ervoor dat op HTTP-niveau alleen verkeer wordt doorgelaten (ingaand en uitgaand) dat voldoet aan de ingestelde Web Application Firewall Rules.

Op die manier worden bekende aanvalspatronen in de vorm van HTTP-requests automatisch geblokkeerd. Relevante gebeurtenissen worden geregistreerd via het SIEM.

De WAF rules zijn voorgeconfigureerd voor een bepaald type applicatie, bijvoorbeeld een WordPress website of een Magento webshop.

Iedere applicatie heeft echter unieke kenmerken en die vereisen vaak aanpassingen in de WAF rules. Met die aanpassingen voorkomen we dat legitiem HTTP-verkeer ten onrechte wordt geblokkeerd (false positives).

Het bij de intake van een nieuwe applicatie daarom van belang om in de acceptatieomgeving alle functionaliteiten grondig aan te roepen. Als er een blokkade door de WAF plaatsvindt, dan is dat zichtbaar als een HTTP 403 response. Onterechte blokkades worden door het SecWeb-team weggenomen door WAF rules te wijzigen of aan te vullen.

Als de nieuwe applicatie vervolgens naar de productieomgeving gaat, zijn de WAF rules goed ingeregeld en treden er geen onterechte blokkades meer op.