Die Republik ist nur so stark wie ihre Community. Werden Sie ein Teil davon und lassen Sie uns miteinander reden. Kommen Sie jetzt an Bord!

DatenschutzFAQErste-Hilfe-Team: kontakt@republik.ch.



· editiert

Danke für die Ausführungen.

Leider kann ich dem Abschnitt zu PHP nicht zustimmen.

Mit aktuellen Versionen lässt sich Typensicherheit einfach umsetzen. Früher war das, in der Tat, aufwändiger.

Es ist immer eine Frage der Anwendung, nicht des Werkzeugs.

Edit:
Daher würde ich mir wünschen, dass der letzte Abschnitt allgemeiner verfasst wird.

2
/
0

Es ist natürlich grundsätzlich korrekt, dass Sicherheit immer eine Frage der Anwendung ist und weniger eine des Werkzeugs. Andererseits ist es mit einigen Werkzeugen leichter internet-sichere Applikationen zu entwickeln als mit anderen.

Die Zusammenfassung entstand vor dem Hintergrund des im Artikeln erwähnten PHP3. Es ist unbestritten, dass PHP seither bezüglich impliziter Sicherheit Fortschritte gemacht hat. Andererseits zeigen Auswertungen wie zum Beispiel der in https://nvd.nist.gov/vuln/search gesammelten Schwachstellen, dass es neben Typensicherheit noch einige weitere Bereiche gibt, in welchen man mit PHP bei unsorgfältiger Entwicklung Schwachstellen erzeugen kann welche mit anderen Werkzeugen in dieser Form nicht möglich sind.

Man kann daher durchaus hinterfragen, ob PHP für via Internet erreichbare Applikationen mit hohen Sicherheitsanforderungen die beste Wahl darstellt.

1
/
0
· editiert

Wie Sie schreiben: "bei unsorgfältiger Entwicklung".

Was würden Sie denn für "via Internet erreichbare Applikationen" verwenden?

Bei der hohen Verbreitung von PHP finden Sie natürlich auch mehr Schwachstellen.

Würde das nicht auf eine Sprache reduzieren, mit javascript, go, python, ruby etc. steht man vor ähnlichen Herausforderungen. Das Web ist komplex und nicht deterministisch.

1
/
0
Leser/Informatikstudent
·

Will nur kurz anmerken, dass ich diese Ausführungen (Aus Sicht eines Informatikstudenten) sehr gelungen finde. Sie sind inhaltlich korrekt und weder zu tief noch zu flach. Vielen Dank für die Mühen, sie technisch interessierten Lesern zur Verfügung zu stellen.

9
/
0
Chefredaktion
·

Lieber Herr Wey, Ihnen vielen Dank für Ihre motivierenden Zeilen.

3
/
0
· editiert

Aus dem Glossar-Eintrag zu MITM:

Um solchen Attacken vorzubeugen, werden Daten zwischen Browser und Webserver heute meist mittels eines Public/Private-Key-Verfahrens verschlüsselt.

Wenn der Angreifer auch über ein von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiertes Zertifikat verfügt, dann hilft die asymmetrische Verschlüsselung des Datenverkehrs nicht gegen eine MITM-Attacke. Solange die beiden ursprünglichen Kommunikationspartner (Alice, Bob) nur die Zertifikatskette prüfen und dabei das Root-Zertifikat der vertrauenswürdiges CA sehen, werden sie zum Schluss kommen, dass der Angreifer ein gültiger Kommunikationspartner ist. Hier hilft nur Zusatz-Wissen über den erwarteten Kommunikationspartner (z.B. Certificate Pinning). Auch 2FA kann helfen. Halt irgend ein Stück Information, das nicht über den komprommitierten Kommunikationskanal ausgetauscht wird. Auch noch denkbar: Eine organisations-interne CA, von der der Angreifer sich kein Zertifikat signieren lassen kann. Das bedarf dann aber natürlich auch wieder besonderer Vorkehrungen, dass die gängigen CAs (VeriSign und so) für Alice und Bob nicht mehr als vertrauenswürdig gelten.

Ich bin vielleicht ein wenig pingelig hier, aber da es sich hier um einen explizit technischen Artikel handelt sollte das Glossar schon auch korrekte technische Fakten enthalten.

PS (und damit der hoffentlich letzte Edit): Super-Artikel und -Recherche, vielen Dank!!

5
/
0
Leiter IT Operations
·

Sehr gelungen, die Zweiteilung in einen "normalen" und in einen technischen Artikel.

2
/
0

Die korrekten Begriffe im Jahr 2020 sind person-in-the-middle attack, allow list und deny list.

1
/
2
seit 2018

Republik AG
Sihlhallenstrasse 1
8004 Zürich
Schweiz

kontakt@republik.ch
Medieninformationen

Der Republik Code ist Open Source