Sicherheitsbedenken bei Web-App-Entwicklung

[CyborgBeta]

Krankmeldungen dürften zu den Gesundheitsdaten zählen und damit zu sensiblen Daten.
Siehe dazu auch DSGVO Artikel 9
Daher ist auch besondere Sorgfalt an den Tag zu legen,

Und das widerspricht sich inwiefern mit meinem Vorschlag? Langsam wirds albern.

Ergänzung (31. Mai 2025)

Verstehe. Das ist dein Standpunkt.
Digital first, Bedenken second.

Nö, entweder richtig, oder gar nicht.

Ergänzung (31. Mai 2025)

Irgendeine Software von irgendeiner Seite zu benutzen die man in irgendeinem Webforum aufgeschnappt hat, dürfte da unter Fahrlässigkeit fallen.

Was hat das damit zu tun, ob eine solide Herangehensweise in einem Webforum vorgeschlagen wurde oder nicht?

1 + 3 = 4

Hey ... das muss aber jetzt falsch sein ... denn es steht ja schließlich im Internet. 🤦‍♂️

Ergänzung (31. Mai 2025)

Noch mal, mir ist es komplett egal, was sie hinterher machen - oder ob sie das überhaupt umsetzen wollen. Ich habe nur eine technische Einschätzung gegeben, mehr nicht.

 

[BeBur]

Das ist doch ganz leicht: EmailJS muss DSGVO-konform sein, sonst kann der Dienst nicht benutzt werden.
Der Ansatz klingt für mich spontan ganz gut (bin aber kein WebDev), ich rate aber auch davon ab, ein kleines, potentiell nicht mehr gepflegtes github Projekt zu nutzen.

nochmal zur Frage der Sicherheit zurückkehren.

Meine persönliche Erfahrung (retrospektiv) als ich vor Jahren ein WebApp Projekt gebaut habe und das vorher noch nie gemacht hatte: In die Sicherheitsthemen kann man sich alle einlesen. Das ist kein Hexenwerk, hochwertige Artikel gibt es Online. Das ist kein Geheimwissen wie man z.B. sshd absichert. Man muss sich nur in 30 Themen einlesen, weil es so viele relevante Themen gibt. Man muss bestehende Frameworks/Technologien nutzen, da wird vieles sowieso schon richtig gemacht per default. Es fühlt sich sehr falsch und unsicher an, weil man keine peers (z.B. ein senior) hat die einem sagen können "so ist gut".

Was ich noch auf den Weg geben will: Wenn es um Features geht, sagt per Default erstmal "nein" statt "ja". Ich habe damals per default "ja" gesagt, weil, wenn man selber was umsetzt, dann kann man ja grundsätzlich alles mit einbauen. Damit explodieren die Anforderungen aber und wenn man die vorher nicht verschriftlicht hat wird das Projekt ggf. nie fertig (ich habe irgendwann die Kurve hinbekommen ^^).

Sprecht viel mit den Stakeholdern, überlegt viel, sprecht über die use cases, dokumentiert etc.. Ich würde z.B. vermuten, dass einige Lehrer auf die Daten auch vom Homeoffice oder von unterwegs aus draus zugreifen wollen. Damit müsste das System das ihr baut auch vom Internet aus erreichbar sein. Ihr kommt dann vermutlich auf die Lösung, VPN einzurichten. Das zieht aber wieder weitere "Dinge" nach sich.

 

[foofoobar]

Personenbezogene Daten, insbesondere aus dem medizinischen Bereich sind schon ein heißes Eisen.

Mann sollte sollte vorher die Angriffsvektoren durchgehen und sich überlegen was es bedeutet wenn Komponente X kompromittiert wurde und sich dann überlegen ob man dafür ein anderes Design/Architektur nehmen kann und diese dann erneut prüfen. Mit etwas Glück fallen bei so einem Prozess auch bestimmte Sicherungen raus weil die sowieso nicht helfen :-) Und man kann daraus Handlungsanweisungen für Havarien ableiten.

Und Frameworks haben Vorteile allerdings vergrößern diese meistens die Angriffsfläche, jedoch haben diese einen wunderbaren "Cover my ass" Effekt.
Nach KISS zu implementieren ist meistens sicherer, aber da gibt es eben weniger "Cover my ass".

Ich könnte noch jede Menge dazu schreiben .......

@andy_m4 Ich arbeite halt für eine kommunale Verwaltung und auch wenn ich das Thema Datenschutz richtig und wichtig finde, ist es aus meiner Sicht zu restriktiv. Gerade wenn es darum geht, alte analoge Prozesse der öffentlichen Verwaltung zu modernisieren und zu verbessern.

Bedenke das es sich die Betroffenen sich nicht aussuchen können von euch verwaltet zu werden, daraus ergibt sich eine ganz besondere Sorgfaltspflicht von Behörden.
Ich bin schon etwas verwundert das dir das nicht klar ist wenn du in so einem Laden arbeitest.

Noch im letzten Jahrtausend habe ich mal für eine Behörde gearbeitet welche den Kommunen vorgelagert ist, da hat es mich genervt das wir den Kommunen keine bestimmte technischen Vorgaben machen konnten weil den Kommunen per Landesverfassung bestimmte Autonomien zustehen, welche diese auch unterschiedlichst genutzt haben.

Auch wenn es sich einige Kreise in diesem Land sich nicht vorstellen können ist in Deutschland so einiges nach dem Subsidiaritätsprinzip geregelt, allerdings hat das eben Konsequenzen.
Aber auch das solltest du wissen wenn du für so einen Laden arbeitest.

Nein, das ist nicht aufwändig, weil es keine Angriffsvektoren gibt. Dieser muss nur aktuell gehalten werden, also sprich, immer die neuste LTS einsetzen. Zurzeit ist das bei httpd die 2.4: https://hub.docker.com/_/httpd/tags

Auf irgendwelchen Kram den man sich irgendwo runter laden kann sollte man eher nicht setzen.

 

[andy_m4]

Und das widerspricht sich inwiefern mit meinem Vorschlag? Langsam wirds albern.

Das wird vor allem albern, weil Du überhaupt nicht auf meine Punkte eingehst.
Du stellst nur irgendwelche Behauptungen auf ohne die wenigstens ein bisschen mal zu unterlegen.

Was hat das damit zu tun, ob eine solide Herangehensweise in einem Webforum vorgeschlagen wurde oder nicht?

Wenn man keine wirkliche Ahnung vom Thema hat, weiß man ja gar nicht, ob die Vorgehensweise wirklich solide ist oder nicht. Man kann allenfalls Anregungen erhalten.

Aber darum ging es ja auch nicht bei meinem Einwand. Du hast ein konkretes Produkt empfohlen (was man ja auch machen kann) und ich habe lediglich auf ein paar Punkte hingewiesen die Du dann auch nicht wirklich entkräften konntest, außer halt irgendwelche Behauptungen und - ich paraphrasieren jetzt mal: "ihr mit euren Datenschutzbedenken!", zu antworten.

 

[CyborgBeta]

Auf irgendwelchen Kram den man sich irgendwo runter laden kann sollte man eher nicht setzen.

Ja, am besten ist es, einen eigenen Webserver zu schreiben.

potentiell nicht mehr gepflegtes github

Warum sollte es denn nicht mehr gepflegt werden, stimmt doch nicht.

Das wird vor allem albern, weil Du überhaupt nicht auf meine Punkte eingehst.

Es ging hier primär um die Konzeption, Umsetzbarkeit und Sicherheit. Die rechtlichen Aspekte kann hier wohl niemand sicher beantworten, der kein Jurist ist (mit entsprechender Spezialisierung auf so ein Themengebiet). Also versuche ich das auch nicht.

 

[foofoobar]

Ja, am besten ist es, einen eigenen Webserver zu schreiben.

Wenn man seine Lieferketten nicht im Griff hat braucht man über Sicherheit nicht zu reden.

Ärgerlich ist das wenn man seine Lieferanten nach formalen Kriterien von Sicherheit und BCM ausrichtet das fast nur noch diese blöden Monopolisten als Lieferanten übrig bleiben.

Aber darum ging es ja auch nicht bei meinem Einwand. Du hast ein konkretes Produkt empfohlen (was man ja auch machen kann) und ich habe lediglich auf ein paar Punkte hingewiesen die Du dann auch nicht wirklich entkräften konntest, außer halt irgendwelche Behauptungen und - ich paraphrasieren jetzt mal: "ihr mit euren Datenschutzbedenken!", zu antworten.

Vor allen in der ersten Phase sind konkrete Produkte völlig egal.
"Lösung sucht Problem" ist da mit einer der falschesten Ansätze die man sich überhaupt vorstellen kann.
Was allerdings leider wenig an seiner Verbreitung ändert. Wenn man nur einen Hammer kennt sieht eben alles wie ein Nagel aus.

 

[andy_m4]

Ja, am besten ist es, einen eigenen Webserver zu schreiben.

Das war gar nicht der Punkt. Du lenkst ab.

Warum sollte es denn nicht mehr gepflegt werden, stimmt doch nicht.

Selbst wenn es jetzt gepflegt wird, heißt das ja nicht, das es morgen oder im nächsten Jahr noch gepflegt ist. Insbesondere dann nicht, wenn da überhaupt keine Reputation hinter steht.

Es ging hier primär um die Konzeption, Umsetzbarkeit und Sicherheit.

Eben. Sicherheit!

Die rechtlichen Aspekte kann hier wohl niemand sicher beantworten, der kein Jurist ist

Na vielleicht nicht auf der Ebene eines Juristen. Aber so grobe Kenntnis sollte man vielleicht haben, wenn man Empfehlungen abgibt.

Ich verstehe auch ehrlich gesagt Deine Reaktion nicht. Wenn Du hier was Neues dazu lernst, dann freue Dich doch darüber und bedanke Dich brav, statt rumzulamentieren, das man das alles nicht bräuchte und Wissen müsse. :-)

Ergänzung (1. Juni 2025)

Vor allen in der ersten Phase sind konkrete Produkte völlig egal.

Ja. Da hast Du recht.
Und wenn dann schon was als Produktvorschlag kommt, sollte es nicht gleich an offensichtlichen Kriterien scheitern.

Was allerdings leider wenig an seiner Verbreitung ändert.

Ja.

Ergänzend dazu:
Vielleicht ist das ja aber auch nicht völlig verkehrt in bestimmten Szenarien.
Wenn zum Beispiel also Produkt B optimal geeignet ist und Produkt A zwar nicht optimal, aber geht schon. Und Produkt A kennt man gut und weiß auch um seine Schwächen während Produkt B unbekannt ist, dann kann es u.U. sinnvoll sein Produkt A - trotz seiner geringen Eignung - zu nehmen.

Aber selbst den Fall haben wir hier ja nicht.

 

[CyborgBeta]

Vor allen in der ersten Phase sind konkrete Produkte völlig egal.
"Lösung sucht Problem" ist da mit einer der falschesten Ansätze die man sich überhaupt vorstellen kann.

Sagen wir so, mir sind pragmatische Lösungen lieber, als ... alles schlechtzureden.

Und wenn dann schon was als Produktvorschlag kommt, sollte es nicht gleich an offensichtlichen Kriterien scheitern.

Das ist eine Vermutung von dir, aber keine Begründung bzw. kein Beweis. Du unterstellst EmailJS einfach, sie hätten böse Absichten.

Ich bin jetzt erst mal raus aus diesem Thema, denn das wird mir zu Offtopic.

 

[foofoobar]

Sagen wir so, mir sind pragmatische Lösungen lieber, als ... alles schlechtzureden.

Und das taugt grundsätzlich für diesen Schutzbedarf?

 

[andy_m4]

alles schlechtzureden.

Es geht ja gar nicht ums schlecht reden. Nur man muss ja mal über die Dinge sprechen die wichtig sind. Eine optimale Lösung kriegt man ja ohnehin in den seltensten Fällen hin.
Daher ist es ja wichtig, über Für und Wider unterschiedlicher Vorgehensweisen zu reden.

Das ist eine Vermutung von dir,

Naja. Mehr als Vermutungen hast Du ja auch nicht vorzuweisen.
Hab ja nun schon mehrmals nach Reputation z.B. von post to mail gefragt. Da kam NICHTS von Dir.
Und ist ja auch nicht schlimm, dann Du dazu nichts sagen kannst. Aber dann kann man den Punkt trotzdem ja auch mal zur Kenntnis nehmen und anerkennen, das dies ein Grund ist, warum Leute skeptisch sind.

Du unterstellst EmailJS einfach, sie hätten böse Absichten.

Man kann es halt nicht wissen. Und selbst wenn man jetzt mal unterstellt, die sind die Guten, können die ja dennoch ungewollt ein löchriges System bauen, wo dann unbeabsichtigt Daten abfließen.
Security und Privacy ist ein vielschichtiges Thema, das man nicht einfach mit "gut" und "böse" erschlagen kann.

denn das wird mir zu Offtopic.

Es wird vor allem unangenehm, weil Du merkst, das die Punkte der anderen Seite vielleicht doch nicht ganz von der Hand zu weisen sind und Du das aber nicht eingestehen willst, so scheint mir. :-)

 

[CyborgBeta]

Angelehnt an https://doc.traefik.io/traefik/user-guides/docker-compose/acme-tls/ hätte ich mir das so vorgestellt.

services:

  traefik:
    image: "traefik:latest"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entryPoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      #- "--certificatesresolvers.myresolver.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"
      - "--certificatesresolvers.myresolver.acme.email=postmaster@example.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
    ports:
      - "443:443"
      - "127.0.0.1:8080:8080"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest
    # ...
    labels:
      - "traefik.enable=false"

  mariadb:
    image: mariadb:lts
    user: 1000:1000
    hostname: mariadb
    volumes:
      - ./mariadb/:/var/lib/mysql/
    environment:
      TZ: Europe/Berlin
      MARIADB_USER: user
      MARIADB_PASSWORD: password
      MARIADB_DATABASE: db
      MARIADB_ROOT_PASSWORD: password
    labels:
      - "traefik.enable=false"

  post-to-email:
    image: matthiasmullie/post-to-email
    environment:
      - ALLOW_ORIGIN=*
      - DSN=smtp://user:password@smtp.my-domain.com:port
      - RECIPIENT=Firstname Lastname <my-email@example.com>
    #ports:
    #  - '8080:80'
    healthcheck:
      test: 'curl --fail http://localhost:80/?SENDER=test@example.com'
      interval: 1m
      timeout: 10s
      retries: 3
      start_period: 20s
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.post-to-email.loadbalancer.server.port=80"
      - "traefik.http.routers.post-to-email.rule=Host(`post-to-email.example.com`)"
      - "traefik.http.routers.post-to-email.entrypoints=websecure"
      - "traefik.http.routers.post-to-email.tls.certresolver=myresolver"

  website-1:
    image: httpd:2.4
    volumes:
      - ./website-1/:/usr/local/apache2/htdocs/
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.website-1.loadbalancer.server.port=80"
      - "traefik.http.routers.website-1.rule=Host(`example.com`)"
      - "traefik.http.routers.website-1.entrypoints=websecure"
      - "traefik.http.routers.website-1.tls.certresolver=myresolver"

  backend-imap-to-mariadb:
    image: debian:12
    init: true
    stop_grace_period: 1m
    stop_signal: SIGINT
    user: 1000:1000
    environment:
      - TZ=Europe/Berlin
    volumes:
      - ./backend-imap-to-mariadb/data/:/data/
    command: >
      bash -c "cd /data/ && ./executable"
    labels:
      - "traefik.enable=false"

Das muss natürlich noch angepasst und erweitert werden. Außerdem braucht man die Kontrolle über die Domain.

traefik kümmert sich u. a. um das https. mailserver stellt den eigenen Mailserver dar, insofern kein bestehender (externer) Mailserver verwendet werden soll. mariadb ist die db, in der hinterher die Abwesenheiten stehen, auch hier kann natürlich eine andere db gewählt werden. website-1 ist die eigentliche (statische) Website, und (neben post-to-email) der einzige Zugangspunkt von außen. Der User, der website-1 aufruft, sendet einen Post an post-to-email. post-to-email sendet über mailserver eine E-Mail an mailserver. Als backend-imap-to-mariadb kann ein beliebiges Backend eingesetzt werden, dessen Aufgabe es ist, (periodisch) neue E-Mails von mailserver abzuholen, zu parsen und in mariadb einzutragen. Optional kann dabei eine Benachrichtigung an die Person gesendet werden, um den Eintrag zu bestätigen.

Die eigentliche Programmierarbeit liegt also im Erstellen von website-1 und dem Backend, das neue Einträge in die Datenbank eintragen soll.

Vorteile sind, dass lediglich ein gesicherter Port nach außen geöffnet ist (wenn man einmal von den Ports für den eigenen Mailserver absieht).

---

Das war jetzt aber nur ein Vorschlag für eine mögliche Vorgehensweise, wie ich es vielleicht gemacht hätte.