Microsofts SDL, Phase 3 (Design) und 4 (Implementation)
Microsofts Security Development Lifecycle besteht aus 7 Phasen, von denen ich die ersten beiden bereits beschrieben habe. Weiter geht es mit
Microsofts Security Development Lifecycle besteht aus 7 Phasen, von denen ich die ersten beiden bereits beschrieben habe. Weiter geht es mit
Im Windows Developer 1.19 ist ein Artikel über die Sicherheit von SOAP erschienen.
Eine Leseprobe des Artikels gibt es auf entwickler.de.
SOAP war ursprünglich die Abkürzung für "Simple Object Access Protocol", aber seit der Version 1.2 wird diese Erklärung nicht mehr verwendet. Denn SOAP ist nicht unbedingt "Simple", und auf keinen Fall nur auf den Zugriff auf "Objects" beschränkt. Nun sagt uns die Erfahrung aber ganz eindeutig: Wenn etwas nicht einfach ist wird es schnell zur Gefahrenquelle. Entweder weil die Implementierungen Schwachstellen aufweisen oder eine sichere Nutzung unnötig erschwert wird. Wie sieht es denn in der Hinsicht bei SOAP aus?
"Drucksache: Windows Developer 1.19 - Wie sicher ist SOAP?" vollständig lesenMicrosofts Security Development Lifecycle besteht aus 7 Phasen, die ich ab dieser Folge vorstelle. Los geht es natürlich mit
Alles, was ein Admin zur Verwaltung eines Rechners oder Netzes verwendet, ist für einen Angreifer von besonderem Interesse. Zum einen, weil diese Tools im Allgemeinen mit erhöhten Rechten laufen – und die möchten die Angreifer natürlich auch haben. Zum anderen, weil sie für genau die Aufgaben zuständig sind, die die Angreifer benötigen, um die vollständige Kontrolle über System und/oder Netzwerk zu erlangen.
Dass diese Tools von besonderem Interesse für Angreifer sind, wissen natürlich auch die Sicherheitsforscher, weshalb sie immer wieder prüfende Blicke auf diese Tools werfen.
Was sie dabei herausgefunden haben erfahren Sie in meinem Artikel auf entwickler.de!
Dank des Security Development Lifecycle, kurz SDL, konnte Microsoft die Anzahl an nach der Veröffentlichung einer Software entdeckten Schwachstellen drastisch reduzieren. Und das ist eigentlich gar nicht so schwer, wie es auf den ersten Blick scheint.
In dieser Folge geht es mit der Entwicklung der Sicherheitsrichtline (Security Policy) für das Beispielunternehmen "Bratkartoffel KG" weiter.
Die technischen Schutzmaßnahmen für Web-, Application- und Datenbankserver haben wir bereits festgelegt, ebenso die dazu gehörenden organisatorischen Schutzmaßnahmen sowie der Schutz der internen Server. Jetzt ist der Schutz des restlichen Netzes an der Reihe.
In dieser Folge geht es mit der Entwicklung der Sicherheitsrichtline (Security Policy) für das in der vorherigen Folge vorgestellte Beispielunternehmen weiter.
Die technischen Schutzmaßnahmen für Web-, Application- und Datenbankserver haben wir bereits festgelegt, jetzt sind die dazu gehörenden organisatorischen und administrativen Schutzmaßnahmen an der Reihe.
Wie angekündigt werde ich ab dieser Woche die Entwicklung einer Sicherheitsrichtlinie (Security Policy) an einem Beispiel beschreiben. Da das ein sehr komplexer Vorgang ist werde ich jedoch "nur" das Netzwerk betrachten, und auch kann ich nur Teilaspekte berücksichtigen.
"Security Policy - Ein einfaches Beispiel, Teil 1" vollständig lesenIm PHP Magazin 1.2019 ist der fünfte und letzte Artikel einer kleinen Serie zu den OWASP Top 10, den 10 gefährlichsten Bedrohungen für Webanwendungen, erschienen. Und darin geht es um Platz 9 und 10 der Top 10: "Using Components with Known Vulnerabilities" und "Insufficient Logging".
Das Open Web Application Security Project (OWASP) hat im Herbst 2017 seine Top 10 der größten Bedrohungen für Webanwendungen veröffentlicht. In diesem Artikel im PHP Magazin lernen Sie den neunten und zehnten Platz kennen.
"Drucksache: PHP Magazin 1.19 - OWASP Top 10, Platz 9 und 10 - "Components with Known Vulnerabilities" und "Insufficient Logging"" vollständig lesenIm Windows Developer 12.18 ist ein Artikel über die Sicherheit der REST-Architektur erschienen.
Gibt es beim REST, dem "Representional State Transfer" eigentlich irgend was zu schützen? Und wenn ja, wo und wie? Und wieso?
"Drucksache: Windows Developer 12.18 - Was tun gegen die REST-Unsicherheit?" vollständig lesenDie in der vorherigen Folge vorgestellten technischen Möglichkeiten zum Schutz eines Netzwerks sind ziemlich nutzlos ohne ein passendes organisatorisches Konzept: Die Sicherheitsrichtlinie (Security Policy).
In dieser Folge geht es um den Zusammenhang zwischen Firewalls, Intrusion Detection- und -Prevention-Systemen und Honeypots. Zum einen, weil ich das Material als Link-Ziel brauche, zum anderen als kleiner Vorgriff auf das nächste Thema: Die Security Policy.
Der erste Schritt beim Schutz eines Netzes besteht darin, keine unnötigen Dienste anzubieten, also vor allem keine nicht benötigten Ports offen zu haben. Beim Schutz eines Gebäudes würde das bedeuten, keine unbenutzten Türen oder Fenster offen stehen zu lassen.
Über die vorgestellten Relay-Angriffe sind EMV-Karte zumindest theoretisch gefährdet, und es gab auch schon Angriffe "in the Wild" auf das kontaktbehaftete Chip&PIN-Verfahren. Aber das ist nur die eine Seite der Medaille, bzw. des Point-of-Sale-Terminals. Das kommuniziert ja nicht nur mit der Karte, sondern auch mit dem Kassensystem des Händlers und dem Server des zugehörigen Zahlungsdienstleisters.
Eine E-Mail ist wie eine Postkarte in der Briefpost: Wer sie sieht, kann sie lesen. Deshalb sollte man eigentlich nur verschlüsselte E-Mails verschicken, die das unbefugte Lesen verhindern. Zusätzlich (aber auch unabhängig davon) kann man seine Mails mit einer digitalen Signatur vor unerkannten Manipulationen schützen und seine Identität als Absender beweisen.
Wie die E-Mail-Verschlüsselung allgemein funktioniert erfahren Sie in meinem Artikel auf entwickler.de!
Nach den Grundlagen des kontaktlosen Bezahlens mit Smartphone oder NFC-fähiger Zahlkarte habe ich zunächst einige wenig aussichtsreichen Angriffe vorgestellt. Danach ging es um die mehr Erfolg versprechenden Relay-Angriff sowie deren Optimierung. Diese Relay-Angriffe erfordern den koordinierten Einsatz von zwei Kriminellen, aber auch Relay-Angriff ohne 2. Mann sind möglich.