Webanwendungssicherheit: Die Architektur erklärt für Anfänger

Diejenigen, die anfangen, für das Web zu entwickeln, neigen dazu, sich Sicherheit als etwas vorzustellen, das am Ende hinzugefügt wird: ein Antivirenprogramm, eine Firewall, ein Plugin. Das ist ein angenehmes Bild und völlig falsch. Sicherheit ist kein Bestandteil des fertigen Produkts, sondern eine Eigenschaft der Art und Weise, wie das Produkt hergestellt wurde.

Der Unterschied ist grundlegend. Eine Webanwendung ist wie ein Haus. Sie machen ein Haus nicht sicher, indem Sie ein teures Schloss an der Haustür anbringen, wenn die Wände aus Pappe sind und die Fenster nicht schließen. Sicherheit entsteht durch die Struktur, nicht durch ein aufgeklebtes Accessoire.

Dieser Artikel erklärt, ohne Vorkenntnisse vorauszusetzen, wie die Architektur einer Webanwendung deren Sicherheit bestimmt. Es richtet sich an Anfänger, die von Anfang an die richtigen Grundlagen verstehen möchten, bevor sie sich Gewohnheiten aneignen, deren Abschaffung später kostspielig ist.

Die Anatomie einer Webanwendung

Um über Sicherheit zu sprechen, müssen Sie zunächst die Parteien verstehen. Eine Webanwendung besteht, vereinfacht gesagt, aus drei Ebenen, und jede davon hat ihre eigene Rolle bei der Sicherheit.

Der Client ist das, was im Browser des Benutzers läuft: die Bildschirme, die Schaltflächen, was die Person sieht und berührt. Auf dem Server geschieht die eigentliche Logik, außerhalb der Augen des Benutzers. Und in der Datenbank werden die Informationen gespeichert.

Zwischen diesen Schichten werden Daten über das Netzwerk übertragen. Diese einfache Struktur enthält bereits die wichtigste Sicherheitslektion für Anfänger, und hier beginnen wir.

Die goldene Regel: Vertraue niemals dem Kunden

Wenn Sie sich nur an einen Grundsatz aus diesem Artikel erinnern, denken Sie daran: Alles, was im Browser des Benutzers ausgeführt wird, steht unter der Kontrolle des Benutzers und kann daher manipuliert werden. Der Kunde ist Feindgebiet.

Anfänger machen den Fehler, den Kunden einer Sicherheitskontrolle zu unterziehen. Sie validieren das Formular im Browser, verbergen eine Schaltfläche für diejenigen, die keine Berechtigung haben, prüfen, ob der Wert auf dem Bildschirm gültig ist. All dies ist gut für das Benutzererlebnis und absolut nutzlos für die Sicherheit. Ein Angreifer ignoriert einfach den Bildschirm, spricht direkt mit dem Server und sendet ihm, was er will.

Die architektonische Konsequenz ist klar: Jede Sicherheitsentscheidung muss auf dem Server getroffen werden. Datenvalidierung, Berechtigungsprüfung, Geschäftsregeln, all dies befindet sich auf dem Server, den der Benutzer nicht erreichen kann. Der Kunde schlägt vor; Der Server entscheidet. Diese Trennung ist das Rückgrat der Web-Sicherheit.

Die zwei Säulen: wer du bist und was du kannst

Praktisch jede Anwendungssicherheit basiert auf zwei Konzepten, die Anfänger oft verwechseln.

Authentifizierung bedeutet, zu beweisen, wer Sie sind. Es ist der Login: Benutzername und Passwort, vielleicht ein zweiter Faktor. Es beantwortet die Frage „Bist du wirklich der, für den du dich ausgibst?“

Autorisierung definiert, was Sie nach der Identifizierung tun können. Es beantwortet die Frage „Dürfen Sie das tun?“

Die Verwechslung zwischen beiden führt zu einem der häufigsten Fehler, die es gibt. Ein System bestätigt die Anmeldung (Authentifizierung), vergisst jedoch bei jeder Aktion zu prüfen, ob dieser Benutzer das Recht auf diese Daten hat (Autorisierung). Das Ergebnis ist der klassische Angriff, bei dem eine Nummer in der URL geändert und auf die Informationen einer anderen Person zugegriffen wird – ein Fehler, der seit Jahren ganz oben auf der Liste von OWASP steht.

In der Architektur bedeutet dies zwei unterschiedliche Prüfungen. Die Bestätigung der Identität am Eingang reicht nicht aus. Die Berechtigung muss bei jedem Zugriff auf eine Ressource überprüft werden. Das zweite zu vergessen ist so, als würde man den Ausweis desjenigen überprüfen, der das Gebäude betritt, aber alle Räume unverschlossen lassen.

Schutz von Daten während der Übertragung und im Ruhezustand

Die Daten einer Anwendung liegen in zwei Zuständen vor und beide müssen geschützt werden.

Unterwegs liegt vor, wenn Daten zwischen dem Client und dem Server über das Netzwerk übertragen werden. Hier liegt der Schutz in der Verschlüsselung der Kommunikation, über HTTPS. Ohne diese Möglichkeit kann jeder in einem gemeinsam genutzten Netzwerk, beispielsweise einem öffentlichen WLAN, die übertragenen Daten, einschließlich Passwörter, abfangen und lesen. HTTPS ist heute ein grundlegender und nicht verhandelbarer Standard.

Im Ruhezustand werden die Daten in der Datenbank gespeichert. Der wichtigste Schutz, den Anfänger verstehen sollten, ist der Umgang mit Passwörtern: Sie sollten niemals so gespeichert werden, wie der Benutzer sie eingegeben hat. Sie durchlaufen einen Prozess namens Hash, der sie in etwas Unumkehrbares umwandelt. Selbst wenn die Bank geleakt wird, sind die Passwörter nicht lesbar. Das Speichern von Passwörtern im Klartext ist vielleicht die häufigste Todsünde für Anfänger.

Die klassischen Bedrohungen, die die Architektur verhindert

Einige Angriffskategorien sind so verbreitet, dass jeder Anfänger sie beim Namen kennen sollte. Sie erscheinen auf der OWASP-Liste, der globalen Referenz für Webanwendungsrisiken.

Injektion erfolgt, wenn vom Benutzer gesendete Daten vom System als Befehle interpretiert werden. Der klassische Fall ist die SQL-Injection, bei der ein Formularfeld verwendet wird, um die Datenbank auszutricksen. Die architektonische Verteidigung besteht darin, Benutzerdaten niemals direkt mit Befehlen zu vermischen und Eingaben immer als Daten und niemals als Anweisungen zu behandeln.

Cross-Site-Scripting (XSS) tritt auf, wenn von einem Benutzer gesendeter Schadcode schließlich im Browser eines anderen Benutzers ausgeführt wird. Die Verteidigung besteht darin, alles, was von außen kommt, zu behandeln und zu umgehen, bevor es auf dem Bildschirm angezeigt wird.

Das gemeinsame Muster dieser Bedrohungen ist das gleiche Prinzip wie zuvor: Von außen kommende Daten sind nicht vertrauenswürdig und müssen vor jeder Verwendung auf dem Server validiert und verarbeitet werden. Sichere Architektur ist weitgehend eine Architektur, die Eingaben systematisch misstraut.

Reflexion für diejenigen, die gerade erst anfangen

Die gefährlichste mentale Falle des Anfängers ist: „Mein Projekt ist zu klein, um es anzugreifen.“ Es ist genau das Gegenteil. Bei den meisten Angriffen werden keine Ziele ausgewählt, sondern automatisierte Bots, die das Internet nach bekannten Schwachstellen durchsuchen. Ein kleines, schlecht geschütztes Projekt ist genau das einfachste Ziel für diese Scans. Niemand muss Sie angreifen wollen; Alles, was es dazu braucht, ist eine offene Tür, die zufällig gefunden wird.

Hinzu kommt die rechtliche Dimension, die Anfänger ignorieren. In Brasilien macht LGPD diejenigen, die personenbezogene Daten sammeln, für deren Schutz verantwortlich, unabhängig von der Größe des Projekts. Von Anfang an sicher zu bauen, ist nicht nur eine gute technische Praxis, sondern eine rechtliche und ethische Verantwortung gegenüber den Menschen, die Ihnen ihre Daten anvertraut haben.

Sie müssen nicht alles beherrschen, um richtig anzufangen. Die architektonischen Grundlagen, niemals dem Kunden zu vertrauen, Authentifizierung von Autorisierung zu trennen, Kommunikation zu verschlüsseln, Passwörter zu schützen, alle Eingaben zu validieren, verschaffen einem Anfänger bereits einen Vorsprung vor einer Vielzahl von Anwendungen auf dem Markt. Bei der Sicherheit geht es am Anfang weniger um fortgeschrittene Techniken als vielmehr darum, nicht die grundlegenden Fehler zu machen, die man zu vermeiden weiß.

Das Erlernen des sicheren Zeichnens vom ersten Projekt an ist eine Investition, die sich um ein Vielfaches amortisiert. Die Neugestaltung eines Systems ohne diese Grundlagen ist teuer und mühsam; Es von Anfang an aufzubauen, ist reine Gewohnheitssache.

Wenn Sie mit der Entwicklung für das Web beginnen und auf der richtigen Grundlage aufbauen möchten, gibt es weitere Blog-Artikel zu Authentifizierung, OWASP, LGPD und sicherer Architektur, die detaillierter auf jeden dieser Punkte eingehen. Wenn es sich in Ihrer Organisation um einen Moment des Lernens oder der Entscheidungsfindung handelt, lohnt es sich, darüber zu sprechen.