Security/OWASP: Anleitungen und Praxiswissen | Seite 8 | mironsoft Blog
Security/OWASP
-
13.11.2025
Deployment-Skripte laufen in der Praxis oft mit deutlich mehr Rechten als nötig, meist weil ein globaler sudo-Zugriff bequemer wirkt als eine präzise Regel. Wer Least Privilege ernst nimmt, schreibt gezielte sudoers-Einträge pro Skript und verzichtet auf das SUID-Bit auf Shell-Skripten, das moderne Linux-Kernel aus gutem Grund ignorieren.
-
12.11.2025
Der Login-Prozess ist für praktisch jede Magento-Anwendung der Eintrittspunkt zu allen personalisierten Funktionen, vom Bestellverlauf über gespeicherte Adressen bis zum Wunschzettel, und gleichzeitig einer der am häufigsten stillschweigend kaputten Bereiche einer Testsuite, weil Login-Tests besonders anfällig für verwaiste Testnutzer, abgelaufene Test-Sessions und versehentlich eingecheckte Zugangsdaten sind. Ein sauber aufgebauter Authentifizierungs-Testflow behandelt Login, Logout, Session-Timeout und Zwei-Faktor-Authentifizierung als eigenständige, klar voneinander getrennte Testfälle mit einer durchdachten Testnutzer-Verwaltung im Hintergrund, statt alle Aspekte in einem einzigen, unübersichtlichen Testfall zu vermischen.
-
10.11.2025
Encryption at Rest schuetzt Daten auf gestohlenen Festplatten, in offenen Backups und in falsch konfigurierten Cloud-Storage-Buckets, aber sie ersetzt keine Anwendungssicherheit, denn eine laufende Applikation entschluesselt Daten fuer den Zugriff. Dieser Artikel zeigt, wie Datenbank-, Dateisystem- und Feld-Verschluesselung zusammenspielen und warum Key-Management dabei die eigentliche Herausforderung ist.
-
08.11.2025
Wer Formulare und State-Change-Endpunkte ohne echten CSRF-Schutz betreibt, verlässt sich allein auf die Session-Cookie des Browsers und öffnet damit ein Einfallstor für fremdgesteuerte Requests. Synchronizer Token, Double-Submit-Cookie, SameSite-Attribut und Magentos form_key zeigen, wie sich das zuverlässig schließen lässt.
-
07.11.2025
Volume-Verschluesselung schuetzt Daten nur gegen gestohlene Festplatten, nicht aber gegen einen kompromittierten Datenbank-Account, der ganz normal per SQL liest. Datenverschluesselung auf Spaltenebene schuetzt genau diese Luecke, verlangt aber durchdachte Entscheidungen bei Schluesselverwaltung, Suchbarkeit und Indizierung, die pauschale Volume-Verschluesselung nie stellen muss.
-
02.11.2025
Die Bash-History ist nach einem Sicherheitsvorfall oft die erste Datenquelle, die ein Administrator prueft. Richtig konfiguriert mit HISTFILE, HISTSIZE und HISTTIMEFORMAT liefert sie eine Zeitleiste ausgefuehrter Befehle. Wer sich aber allein darauf verlaesst, uebersieht, dass jeder Nutzer mit Shell-Zugriff seine eigene History jederzeit loeschen oder manipulieren kann. Deshalb gehoert auditd als unabhaengige Ergaenzung in jede ernsthafte Haertung.
-
28.10.2025
Ein Rate-Limit pro IP-Adresse klingt nach solidem Schutz gegen Brute-Force und API-Missbrauch, doch Angreifer umgehen es routinemäßig durch IP-Rotation, verteilte Botnetze und gefälschte Header. Wir zeigen die gängigen Umgehungstechniken und robustere Gegenmaßnahmen, die auf Nutzerkonten statt reiner IP-Adressen setzen.
-
28.10.2025
Wer allen Anwendungen und Entwicklern denselben Datenbank-Account mit vollen Rechten gibt, macht jede zukuenftige Sicherheitsluecke automatisch zu einem Totalschaden. Granulare Datenbank-Benutzerrechte, aufgebaut aus GRANT-Anweisungen, Rollenhierarchien und dem Least-Privilege-Prinzip, begrenzen den Schaden eines einzelnen kompromittierten Accounts auf genau das, was dieser Account wirklich braucht.
-
22.10.2025
Wer Login-Formulare, API-Schlüssel oder Signatur-Header authentifizieren muss, die kein Standard-Bundle abdeckt, kommt an einem eigenen Authenticator nicht vorbei. Mit AuthenticatorInterface, Passport und Badges lässt sich jede Authentifizierungslogik sauber, testbar und ohne Umwege über veraltete Guard-Klassen umsetzen.
-
21.10.2025
Das Standardprofil von PhpStorm ist fuer generisches PHP gedacht und passt selten eins zu eins zu den Konventionen eines gewachsenen Magento-Projekts. Wird jedes Inspection-Profil nur lokal angepasst, sieht jeder Entwickler andere Warnungen, was Code-Reviews unnoetig erschwert. Dieser Artikel zeigt, wie ein eigenes Profil als Team-Standard definiert und ueber .idea/inspectionProfiles im Projekt-Repository versioniert wird, damit alle Entwickler beim Checkout automatisch dieselben Code-Qualitaets-Warnungen sehen.