Hauptseite

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

---

Sicherheitsanalyse-Bericht (MeinCMS) - 21.03.2026

Dieser Bericht dokumentiert die aktuelle Sicherheitslage von MeinCMS nach der ersten Entwicklungsphase. Er identifiziert bestehende Schutzmechanismen und potenzielle Schwachstellen, die noch nicht behoben wurden.

---

1. Übersicht der Schutzmechanismen (Ist-Zustand)

• XSS-Schutz: Verwendung von Ganss.Xss.HtmlSanitizer im PageController vor dem Speichern von Wiki-Inhalten.
• CSRF-Schutz: [ValidateAntiForgeryToken] ist auf den HttpPost-Methoden (Create, Edit) im PageController vorhanden.
• Authentifizierung: ASP.NET Core Identity wird verwendet.
• Autorisierung: Rollenbasierte Zugriffskontrolle ([Authorize(Roles = "Admin")]) für administrative Aufgaben (Erstellen, Bearbeiten, Historie).
• SQL-Injection: Verwendung von Entity Framework Core (LINQ), was standardmäßig gegen SQL-Injection schützt (keine Verwendung von FromSqlRaw mit unsicheren Parametern gefunden).
• Eingabevalidierung: Slugs werden mittels Regex im PageController validiert (IstSlugGueltig).

---

2. Identifizierte Schwachstellen & Risiken (Offen)

2.1 Password Policy & Account Lockout

• Schwachstelle: In Program.cs ist die Passwort-Mindestlänge auf nur 6 Zeichen eingestellt (options.Password.RequiredLength = 6).
• Risiko: Erhöhte Anfälligkeit für Brute-Force-Angriffe auf Admin-Accounts.
• Status: Lockout-Mechanismen (LockoutOnFailure) sind im Login.cshtml.cs standardmäßig auf false gesetzt.
• Empfehlung: Passwortkomplexität erhöhen (mind. 10-12 Zeichen) und Account Lockout nach X Fehlversuchen aktivieren.

2.2 Fehlender CSRF-Schutz in Razor-Formularen

• Schwachstelle: In Neuformular.cshtml wird das Tag-Helper <form asp-action="Create" ...> verwendet, welches automatisch ein Anti-Forgery-Token einfügt. In Edit.cshtml wird jedoch ein direktes HTML-Tag <form action="~/Edit/@Model.Slug" ...> verwendet.
• Risiko: Wenn der @Html.AntiForgeryToken()-Aufruf im manuellen Formular fehlen würde, wäre die Aktion angreifbar. In Edit.cshtml ist er vorhanden, aber die Inkonsistenz ist eine potenzielle Fehlerquelle für zukünftige Formulare.
• Empfehlung: Konsistente Verwendung von ASP.NET Core Tag-Helpern.

2.3 Sensitive Daten in Konfigurationsdateien

• Schwachstelle: Der Connection String wird direkt aus der appsettings.json gelesen.
• Risiko: Wenn diese Dateien versehentlich ins Repository eingecheckt werden (was oft passiert, trotz .gitignore), sind die Datenbank-Zugangsdaten exponiert.
• Empfehlung: Nutzung von Environment Variables oder User Secrets für die lokale Entwicklung und Azure Key Vault / HashiCorp Vault für Produktion.

2.4 Mass Assignment (Overposting)

• Schwachstelle: Im PageController.Create und Edit werden Parameter wie string slug und string markdownInhalt einzeln entgegengenommen. Das ist sicher, solange keine komplexen Objekte direkt an Models gebunden werden.
• Risiko: Zukünftige Erweiterungen, die direkt WikiArtikel oder WikiArtikelVersion als Parameter binden, könnten dazu führen, dass Angreifer Felder wie Id oder Zeitpunkt manipulieren.
• Empfehlung: Einsatz von spezifischen ViewModels (DTOs) anstelle von direkter Bindung an Datenbank-Models.

2.5 Clickjacking

• Schwachstelle: Es fehlen explizite Security-Header wie X-Frame-Options oder eine Content-Security-Policy (CSP).
• Risiko: Die Anwendung könnte in einem Iframe auf einer bösartigen Seite eingebettet werden, um Benutzer zu Aktionen zu verleiten.
• Empfehlung: Middleware hinzufügen, die X-Frame-Options: DENY oder SAMEORIGIN setzt.

2.6 Informations-Leakage durch Fehlerseiten

• Schwachstelle: Die Error.cshtml zeigt im Development-Modus detaillierte Fehler an.
• Risiko: Wenn die Umgebung fälschlicherweise auf “Development” in Produktion steht, werden Stack-Traces und interne Pfade preisgegeben.
• Status: Die Standard-Abfrage if (app.Environment.IsDevelopment()) in Program.cs ist vorhanden, was das Risiko mindert, aber die Fehlermeldung in Error.cshtml selbst ist sehr generisch.

---

3. Administrative Tools (UserAdmin)

• Sicherheit: Das Tool UserAdmin liest Passwörter per Console.ReadLine() im Klartext ein.
• Risiko: Passwörter sind während der Eingabe auf dem Bildschirm sichtbar (Schulterblick-Gefahr).
• Empfehlung: Verwendung einer Methode zur maskierten Eingabe (Sterne statt Klartext).

---

4. Fazit

MeinCMS verfügt bereits über eine solide Basis an Sicherheitsmechanismen (Sanitization, CSRF-Tokens, Identity). Die kritischsten Punkte für die nächste Iteration sind die Verschärfung der Password Policy, die Absicherung der Konfigurationsdaten und die Einführung von Security-Headern (CSP, HSTS-Tuning).

---

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).