Wie schnelle Entwicklungstechnologien zu unangenehmen Sicherheitslücken führen können

Sicherheit mit Beispielen aus der Praxis ist immer interessanter.

Als Penetrationstester finde ich es toll, wenn Projekte auf der Basis von Rapid Development Frameworks wie Ruby-on-Rails, Django, AdonisJs, Express usw. eingehen. Sie ermöglichen es Ihnen, ein System sehr schnell aufzubauen, da Geschäftsmodelle sofort auf alle Ebenen springen, einschließlich des Client-Browsers. Model (Modelle von Geschäftsobjekten in der Datenbank) und ViewModel (Vertrag für die Interaktion mit Kunden) solcher Frameworks werden häufig miteinander kombiniert, um unnötige Wechsel von Model zu ViewModel und umgekehrt zu vermeiden. REST-Services werden automatisch generiert. Aus Sicht der Entwicklung können Sie einfach ein Geschäftsmodell auf dem Server entwickeln und es dann sofort auf dem Client verwenden, was zweifellos die Entwicklungsgeschwindigkeit erhöht.

Ich sage noch einmal nicht, dass die oben genannten Frameworks schlecht sind oder etwas mit ihnen nicht stimmt. Sie verfügen über die Mittel und Werkzeuge des richtigen Schutzes. Entwickler machen nur die meisten Fehler mit ihnen. Dies wurde auch in einem ASP.NET MVC-Projekt beobachtet, in dem Entwickler dieselben Sicherheitslücken machten, indem sie Models anstelle von ViewModels verfügbar machten ...

Sicherheitsanfälligkeit: Aufgrund der schwachen Validierung der Felder eingehender Modelle vom Client können Felder eingefügt werden, die nicht von der Funktionalität bereitgestellt werden, sich jedoch im Geschäftsmodell befinden. Beispielsweise gibt es eine Methode, mit der Sie nur den Benutzernamen ändern und ein Benutzerprofilobjekt zurückgeben können. Was passiert, wenn ich das zurückgegebene Objekt kopiere, alle darin enthaltenen Eigenschaften ändere und es erneut an die Eingabe sende? Es kann sich herausstellen, dass Sie jede Eigenschaft des Objekts (Kennwort, Rolle) unter Umgehung des Standardworkflows ändern können.

Von den verschiedenen Projekten, die wir auf Sicherheit getestet haben, werde ich echte Beispiele geben. Alle diese Problembereiche wurden behoben und zusätzliche Informationen in den Screenshots werden ausgeblendet.

System 1

Auf diesem System konnte nur der Benutzername im Profil geändert werden. Durch Ersetzen einer anderen E-Mail konnte ich das Login des Benutzers ändern. Darüber hinaus haben Einladungen an andere Benutzer diese Seife jetzt verlassen.



System 2

In diesem Beispiel gelang es einem einfachen Benutzer, die Rolle zum Administrator zu ändern, indem er das Rollenfeld hinzufügte und über URL / Administrator einfach das Systemadministrationsfenster mit allen Transaktionen, Benutzern, Berichten usw. öffnete.



System 3

In diesem System war es möglich, ein kostenloses Abonnement auf unbestimmte Zeit zu verlängern. Es ist klar, dass der Standardansatz eine Zahlung erforderte.



Die Eingabemethode würde anscheinend nur die ausgewählte Farbe gemäß dem Branding des Arbeitsbereichs verwenden und das Objekt des gesamten Arbeitsbereichs zurückgeben, einschließlich eines vollständigen Speicherauszugs des StripeCustomer-Objekts, der die Zahlung widerspiegelt. Es war möglich, nicht nur ein Feld, sondern ein riesiges Unterobjekt StripeCustomer einzufügen und infolgedessen einmal oder von einem anderen Benutzer bezahlt zu haben, um dieses Objekt zu erfassen und es in alle seine Arbeitsbereiche zu duplizieren.



System 4

Und schließlich. Dieses System hatte das gleiche Problem: Es war möglich, das Passwort und den Passkey unter Umgehung des erfundenen Workflows zu ändern. Der mangelnde Schutz vor CSRF und die Speicherung von Authentifizierungscookies über einen langen Zeitraum erhöhten das Risiko dieser Anfälligkeit für den Himmel. Ein böswilliger Benutzer könnte ein Skript in eine beliebte Ressource einfügen, um das Kennwort des aktuellen Benutzers dieses Systems zu ändern, und alle Benutzer, die diese Ressource öffnen würden, würden den Zugriff auf das System verlieren.



Das Ausblenden des Servercodes in den Metadaten für dieses Feld ermöglichte es, dieses Feld in der Antwort nicht an den Client zurückzugeben, aber dieses Feld wurde ohne Probleme in den Eingabedaten verarbeitet.



Die Nachricht:

1. Vertraue niemals eingehenden Daten von Benutzern, sie können alles mit ihnen machen
2. Seien Sie vorsichtig mit Systemen, die keine separate ViewModel-Ebene haben, und arbeiten Sie direkt mit den Basismodellen
3. Informieren Sie sich ausführlicher über den Schutz, den Ihr Framework bietet.

Die oben genannten Informationen werden nur zu Bildungs- und Bildungszwecken bereitgestellt. Eine Vorgehensweise für ihre Systeme ist nicht erforderlich.

Denis Koloshko, Penetrationstester, CISSP