Einleitung
Wir erhalten oft die Frage nach unseren sicheren Entwicklungspraktiken und was wir tun, um die Sicherheit der WP STAGING Anwendung zu gewaehrleisten.
Im Allgemeinen folgen wir den OWASP Secure Coding Practices. (Siehe auch die OWASP Testing Checkliste).
Einige wichtige Punkte sind:
- Reduzierung der Nutzung externer Bibliotheken. Wenn wir sie verwenden, aktualisieren wir sie regelmaessig.
- Akzeptanz- und Unit-Tests. Bisher wurden mehr als 1000 Tests geschrieben. Video, das einen kleinen Teil unserer Tests zeigt: https://www.youtube.com/watch?v=Tf9C9Pgu7Bs
- Einhaltung der PSR-Code-Spezifikationen, um industriell akzeptierten Konventionen zu entsprechen.
- Open-Source-Code. Du kannst also Deine eigenen Sicherheitspruefungen durchfuehren auf https://github.com/wp-staging/wp-staging
Dieses technologieunabhaengige Dokument definiert eine Reihe allgemeiner Software-Sicherheits-Programmierpraktiken in einem Checklistenformat, die in den Softwareentwicklungslebenszyklus von WP STAGING integriert werden muessen. Die Umsetzung dieser Praktiken wird die haeufigsten Software-Schwachstellen mindern.
Im Allgemeinen ist es weitaus kostenguenstiger, sichere Software zu entwickeln, als Sicherheitsprobleme nach Fertigstellung des Softwarepakets zu beheben, ganz zu schweigen von den Kosten, die mit einer Sicherheitsverletzung verbunden sein koennen.
Die Absicherung kritischer Software-Ressourcen ist wichtiger denn je, da sich der Fokus der Angreifer stetig auf die Anwendungsebene verlagert hat. Eine SANS-Studie von 2009 ergab, dass Angriffe auf Webanwendungen mehr als 60% aller im Internet beobachteten Angriffsversuche ausmachen.
Bei der Nutzung dieses Leitfadens sollten Entwicklungsteams zunaechst den Reifegrad ihres sicheren Softwareentwicklungslebenszyklus und das Wissensniveau ihrer Entwickler bewerten. Da dieser Leitfaden nicht die Details der Implementierung jeder Programmierpraktik abdeckt, muessen Entwickler ueber Vorkenntnisse oder ausreichende Ressourcen verfuegen, um die notwendige Anleitung zu bieten. Dieser Leitfaden bietet Programmiertechniken, die in Programmieranforderungen uebersetzt werden koennen, ohne dass der Entwickler ein tiefes Verstaendnis von Sicherheitsschwachstellen und Exploits benoetigt. Andere Teammitglieder sollten jedoch die Verantwortung, angemessene Schulungen, Werkzeuge und Ressourcen haben, um zu validieren, dass Design und Implementierung des gesamten Systems sicher sind.
Ein Glossar wesentlicher Begriffe in diesem Dokument, einschliesslich Abschnittsueberschriften und kursiv dargestellter Woerter, findet sich in Anhang B.
Anleitungen zur Implementierung eines sicheren Softwareentwicklungs-Frameworks gehen ueber den Umfang dieses Dokuments hinaus, jedoch werden die folgenden zusaetzlichen allgemeinen Praktiken und Ressourcen empfohlen:
• Rollen und Verantwortlichkeiten klar definieren
• Entwicklungsteams angemessene Software-Sicherheitsschulungen bieten
• Einen sicheren Softwareentwicklungslebenszyklus implementieren
• Sichere Programmierstandards etablieren
• Eine wiederverwendbare Objektbibliothek aufbauen
• Die Wirksamkeit der Sicherheitskontrollen ueberpruefen
• Sichere ausgelagerte Entwicklungspraktiken etablieren, einschliesslich der Definition von Sicherheitsanforderungen und Verifizierungsmethoden sowohl in der Ausschreibung (RFP) als auch im Vertrag.
Ueberblick ueber Software-Sicherheits- und Risikoprinzipien
Der Aufbau sicherer Software erfordert ein grundlegendes Verstaendnis von Sicherheitsprinzipien. Obwohl eine umfassende Ueberpruefung der Sicherheitsprinzipien den Rahmen dieses Leitfadens sprengen wuerde, wird ein kurzer Ueberblick gegeben.
Software-Sicherheit zielt darauf ab, die Vertraulichkeit, Integritaet und Verfuegbarkeit von Informationsressourcen aufrechtzuerhalten, um erfolgreiche Geschaeftsablaeufe zu ermoeglichen. Dieses Ziel wird durch die Implementierung von Sicherheitskontrollen erreicht. Dieser Leitfaden konzentriert sich auf die technischen Kontrollen zur Minderung des Auftretens gaengiger Software-Schwachstellen. Waehrend der primaere Fokus auf Webanwendungen und deren unterstuetzender Infrastruktur liegt, kann der Grossteil der Anleitung auf jede Software-Bereitstellungsplattform angewendet werden.
Es ist hilfreich zu verstehen, was mit Risiko gemeint ist, um das Unternehmen vor inakzeptablen Risiken zu schuetzen, die mit seiner Abhaengigkeit von Software verbunden sind. Risiko ist eine Kombination von Faktoren, die den Erfolg des Unternehmens bedrohen. Das laesst sich konzeptionell wie folgt beschreiben: Ein Bedrohungsakteur interagiert mit einem System, das eine Schwachstelle haben kann, die ausgenutzt werden kann, um eine Auswirkung zu verursachen. Auch wenn dies wie ein abstraktes Konzept erscheinen mag, stell es Dir so vor: Ein Autoeinbrecher (Bedrohungsakteur) geht ueber einen Parkplatz und prueft Autos (das System) auf unverschlossene Tueren (die Schwachstelle), und wenn er eine findet, oeffnet er die Tuer (der Exploit) und nimmt, was darin ist (die Auswirkung). All diese Faktoren spielen eine Rolle bei der sicheren Softwareentwicklung.
There is a fundamental difference between the approach taken by a development team and that taken by someone attacking an application. A development team typically approaches an application based on what it is intended to do. In other words, they are designing an application to perform specific tasks based on documented functional requirements and use cases. An attacker, on the other hand, is more interested in what an application can be made to do and operates on the principle that „any action not specifically denied, is allowed“. To address this, some additional elements need to be integrated into the early stages of the software lifecycle. These new elements are security requirements and abuse cases. This guide is designed to help identify high-level security requirements and address many common abuse scenarios.
Webentwicklungsteams muessen verstehen, dass clientseitige Kontrollen wie clientbasierte Eingabevalidierung, versteckte Felder und Interface-Kontrollen (z.B. Dropdowns und Radio-Buttons) wenig bis keinen Sicherheitsvorteil bieten. Ein Angreifer kann Tools wie clientseitige Web-Proxys (z.B. OWASP WebScarab, Burp) oder Netzwerk-Paketerfassungstools (z.B. Wireshark) verwenden, um den Anwendungsverkehr zu analysieren und speziell erstellte Anfragen zu senden, wobei die Benutzeroberflaeche komplett umgangen wird. Flash, Java Applets und andere clientseitige Objekte koennen dekompiliert und auf Schwachstellen analysiert werden. Software-Sicherheitsmaengel koennen in jeder Phase des Softwareentwicklungslebenszyklus eingefuehrt werden, einschliesslich:
• Nichtidentifizierung von Sicherheitsanforderungen im Voraus
• Erstellung konzeptioneller Designs mit Logikfehlern
• Verwendung schlechter Programmierpraktiken, die technische Schwachstellen einfuehren
• Unsachgemaesse Bereitstellung der Software
• Einfuehrung von Maengeln waehrend der Wartung oder Aktualisierung
Darueber hinaus ist es entscheidend zu verstehen, dass Software-Schwachstellen einen Umfang haben koennen, der ueber die Software selbst hinausgeht. Abhaengig von der Art der Software, der Exposition und der unterstuetzenden Infrastruktur koennen die Auswirkungen einer erfolgreichen Ausnutzung Kompromittierungen von einem oder allen der folgenden Bereiche umfassen:
• Die Software und ihre zugehoerigen Informationen
• Die Betriebssysteme der zugehoerigen Server
• Die Backend-Datenbank
• Andere Anwendungen in einer gemeinsamen Umgebung
• The user’s system
• Andere Software, mit der der Benutzer interagiert
Checkliste fuer sichere Programmierpraktiken
Eingabevalidierung:
• Fuehre alle Datenvalidierungen auf einem vertrauenswuerdigen System durch (z.B. dem Server)
• Identifiziere alle Datenquellen und klassifiziere sie in vertrauenswuerdig und nicht vertrauenswuerdig. Validiere alle Daten aus nicht vertrauenswuerdigen Quellen (z.B. Datenbanken, Datenstroeme usw.)
• Es sollte eine zentrale Eingabevalidierungsroutine fuer die Anwendung geben
• Lege geeignete Zeichensaetze, wie UTF-8, fuer alle Eingabequellen fest
• Kodiere Daten in einen gemeinsamen Zeichensatz vor der Validierung (Kanonisierung)
• Alle Validierungsfehler sollten zur Ablehnung der Eingabe fuehren
• Stelle fest, ob das System erweiterte UTF-8-Zeichensaetze unterstuetzt, und falls ja, validiere nach Abschluss der UTF-8-Dekodierung
• Validiere alle vom Client bereitgestellten Daten vor der Verarbeitung, einschliesslich aller Parameter, URLs und HTTP-Header-Inhalte (z.B. Cookie-Namen und -Werte). Stelle sicher, dass automatische Postbacks von JavaScript, Flash oder anderem eingebetteten Code einbezogen werden
• Stelle sicher, dass Header-Werte sowohl in Anfragen als auch in Antworten nur ASCII-Zeichen enthalten
• Validiere Daten von Weiterleitungen (Ein Angreifer kann boesartige Inhalte direkt an das Ziel der
Weiterleitung senden und so die Anwendungslogik und jede vor der Weiterleitung durchgefuehrte Validierung umgehen)
• Validiere auf erwartete Datentypen
• Validiere den Datenbereich
• Validiere die Datenlaenge
• Validate all input against a „white“ list of allowed characters, whenever possible
• Wenn potenziell gefaehrliche Zeichen als Eingabe zugelassen werden muessen, stelle sicher, dass Du zusaetzliche Kontrollen wie Output Encoding, sichere aufgabenspezifische APIs und die Beruecksichtigung der Datennutzung in der gesamten Anwendung implementierst. Beispiele fuer gaengige gefaehrliche Zeichen sind:
< > “ ‚ % ( ) & + ‚ „
• Wenn Deine Standard-Validierungsroutine die folgenden Eingaben nicht abdecken kann, sollten sie separat geprueft werden
einzeln
o Auf Null-Bytes pruefen (%00)
o Auf Zeilenumbruchzeichen pruefen (%0d, %0a, r, n)
o Check for “dot-dot-slash“ (../ or ..) path alterations characters. In cases where UTF-8 extended character set encoding is supported, address alternate representation like: %c0%ae%c0%ae/ (Utilize canonicalization to address double encoding or other forms of obfuscation attacks)
Ausgabekodierung:
• Fuehre alle Kodierungen auf einem vertrauenswuerdigen System durch (z.B. dem Server)
• Verwende eine standardisierte, getestete Routine fuer jede Art der ausgehenden Kodierung
• Contextually output encode all data returned to the client that originated outside the application’s trust
grenze der Anwendung entstanden sind. HTML-Entity-Kodierung ist ein Beispiel, funktioniert aber nicht in allen Faellen
• Kodiere alle Zeichen, es sei denn, sie sind fuer den beabsichtigten Interpreter als sicher bekannt
• Bereinige kontextbezogen alle Ausgaben nicht vertrauenswuerdiger Daten fuer Abfragen an SQL, XML und LDAP
• Bereinige alle Ausgaben nicht vertrauenswuerdiger Daten fuer Betriebssystembefehle
Authentifizierung und Passwort-Management:
• Erfordere Authentifizierung fuer alle Seiten und Ressourcen, ausser jenen, die ausdruecklich oeffentlich sein sollen
• Alle Authentifizierungskontrollen muessen auf einem vertrauenswuerdigen System durchgesetzt werden (z.B. dem Server)
• Etabliere und nutze standardisierte, getestete Authentifizierungsdienste, wann immer moeglich
• Verwende eine zentrale Implementierung fuer alle Authentifizierungskontrollen, einschliesslich Bibliotheken, die externe Authentifizierungsdienste aufrufen
• Trenne die Authentifizierungslogik von der angeforderten Ressource und verwende Weiterleitungen zur und von der
zentralen Authentifizierungskontrolle
• Alle Authentifizierungskontrollen sollten sicher fehlschlagen
• Alle administrativen und Kontoverwaltungsfunktionen muessen mindestens so sicher sein wie der primaere Authentifizierungsmechanismus
• Wenn Deine Anwendung einen Anmeldedatenspeicher verwaltet, sollte sie sicherstellen, dass nur kryptografisch starke Einweg-gesalzene Hashes von Passwoertern gespeichert werden und dass die Tabelle/Datei, die die Passwoerter und Schluessel speichert, nur von der Anwendung beschreibbar ist. (Vermeide den MD5-Algorithmus, wenn moeglich)
• Passwort-Hashing muss auf einem vertrauenswuerdigen System implementiert werden (z.B. dem Server).
• Validiere die Authentifizierungsdaten erst nach Abschluss aller Dateneingaben, insbesondere bei sequenziellen Authentifizierungsimplementierungen
• Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of „Invalid username“ or „Invalid password“, just use „Invalid username and/or password“ for both. Error responses must be truly identical in both display and source code
• Verwende Authentifizierung fuer Verbindungen zu externen Systemen, die sensible Informationen oder Funktionen beinhalten
• Authentifizierungs-Zugangsdaten fuer den Zugriff auf externe Dienste sollten verschluesselt und an einem geschuetzten Ort auf einem vertrauenswuerdigen System gespeichert werden (z.B. dem Server). Der Quellcode ist KEIN sicherer Speicherort
• Verwende nur HTTP-POST-Anfragen zur Uebertragung von Authentifizierungs-Zugangsdaten
• Sende nicht-temporaere Passwoerter nur ueber eine verschluesselte Verbindung oder als verschluesselte Daten, z.B. in einer verschluesselten E-Mail. Temporaere Passwoerter im Zusammenhang mit E-Mail-Zuruecksetzungen koennen eine Ausnahme sein
• Setze Passwort-Komplexitaetsanforderungen durch, die durch Richtlinien oder Vorschriften festgelegt sind. Authentifizierungs-Zugangsdaten sollten ausreichend sein, um Angriffen standzuhalten, die typisch fuer die Bedrohungen in der eingesetzten Umgebung sind. (z.B. Verwendung von Buchstaben sowie Ziffern und/oder Sonderzeichen)
• Setze Passwortlaengen-Anforderungen durch, die durch Richtlinien oder Vorschriften festgelegt sind. Acht Zeichen sind ueblich, aber 16 sind besser, oder erwaege die Verwendung von Passphrasen aus mehreren Woertern
• Password entry should be obscured on the user’s screen. (e.g., on web forms use the input type „password“)
• Setze die Kontodeaktivierung nach einer festgelegten Anzahl ungueltiger Anmeldeversuche durch (z.B. fuenf Versuche sind ueblich). Das Konto muss fuer einen Zeitraum deaktiviert werden, der ausreicht, um Brute-Force-Erraten von Zugangsdaten zu unterbinden, aber nicht so lang, dass ein Denial-of-Service-Angriff durchgefuehrt werden kann
• Passwortzuruecksetzungs- und -aenderungsoperationen erfordern das gleiche Kontrollniveau wie Kontoerstellung und Authentifizierung.
• Password reset questions should support sufficiently random answers. (e.g., „favorite book“ is a bad question because „The Bible“ is a very common answer)
• Bei E-Mail-basierten Zuruecksetzungen nur E-Mails an eine vorregistrierte Adresse mit einem temporaeren Link/Passwort senden
• Temporaere Passwoerter und Links sollten eine kurze Ablaufzeit haben
• Erzwinge die Aenderung temporaerer Passwoerter bei der naechsten Verwendung
• Benachrichtige Benutzer, wenn eine Passwortzuruecksetzung erfolgt
• Verhindere die Wiederverwendung von Passwoertern
• Passwoerter sollten mindestens einen Tag alt sein, bevor sie geaendert werden koennen, um Angriffe auf Passwort-Wiederverwendung zu verhindern
• Erzwinge Passwortaenderungen basierend auf Anforderungen aus Richtlinien oder Vorschriften. Kritische Systeme koennen haeufigere Aenderungen erfordern. Die Zeit zwischen Zuruecksetzungen muss administrativ kontrolliert werden
• Disable „remember me“ functionality for password fields
• Die letzte Nutzung (erfolgreich oder erfolglos) eines Benutzerkontos sollte dem Benutzer bei seiner naechsten erfolgreichen Anmeldung mitgeteilt werden
• Implementiere Ueberwachung, um Angriffe auf mehrere Benutzerkonten mit demselben Passwort zu identifizieren. Dieses Angriffsmuster wird verwendet, um Standard-Sperren zu umgehen, wenn Benutzer-IDs gesammelt oder erraten werden koennen
• Aendere alle herstellerseitig voreingestellten Standard-Passwoerter und Benutzer-IDs oder deaktiviere die zugehoerigen Konten
• Authentifiziere Benutzer erneut vor der Durchfuehrung kritischer Operationen
• Verwende Multi-Faktor-Authentifizierung fuer hochsensible oder hochwertige Transaktionskonten
• Wenn Drittanbieter-Code fuer die Authentifizierung verwendet wird, pruefe den Code sorgfaeltig, um sicherzustellen, dass er nicht von schadhaftem Code betroffen ist
Session-Management:
• Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid
• Die Erstellung von Session-Identifikatoren muss immer auf einem vertrauenswuerdigen System erfolgen (z.B. dem Server)
• Session-Management-Kontrollen sollten gut ueberprueft Algorithmen verwenden, die ausreichend zufaellige Session-Identifikatoren gewaehrleisten
• Setze Domain und Pfad fuer Cookies mit authentifizierten Session-Identifikatoren auf einen angemessen eingeschraenkten Wert fuer die Website
• Die Logout-Funktionalitaet sollte die zugehoerige Session oder Verbindung vollstaendig beenden
• Die Logout-Funktionalitaet sollte von allen durch Autorisierung geschuetzten Seiten verfuegbar sein
• Lege ein Session-Inaktivitaets-Timeout fest, das so kurz wie moeglich ist, basierend auf der Abwaegung von Risiko und geschaeftlichen Funktionsanforderungen. In den meisten Faellen sollte es nicht mehr als einige Stunden betragen
• Verbiete dauerhafte Anmeldungen und erzwinge periodische Session-Beendigungen, auch wenn die Session aktiv ist. Besonders fuer Anwendungen, die umfangreiche Netzwerkverbindungen unterstuetzen oder sich mit kritischen Systemen verbinden. Beendigungszeiten sollten Geschaeftsanforderungen unterstuetzen und der Benutzer sollte ausreichende Benachrichtigung erhalten, um negative Auswirkungen zu mindern
• Wenn eine Session vor dem Login eingerichtet wurde, schliesse diese Session und richte nach einem erfolgreichen Login eine neue Session ein
• Generiere bei jeder erneuten Authentifizierung einen neuen Session-Identifikator
• Erlaube keine gleichzeitigen Anmeldungen mit derselben Benutzer-ID
• Stelle Session-Identifikatoren nicht in URLs, Fehlermeldungen oder Logs dar. Session-Identifikatoren sollten nur im HTTP-Cookie-Header enthalten sein. Uebergib beispielsweise keine Session-Identifikatoren als GET-Parameter
• Schuetze serverseitige Session-Daten vor unberechtigtem Zugriff durch andere Benutzer des Servers, indem Du geeignete Zugriffskontrollen auf dem Server implementierst
• Generiere periodisch einen neuen Session-Identifikator und deaktiviere den alten. (Dies kann bestimmte Session-Hijacking-Szenarien mindern, bei denen der urspruengliche Identifikator kompromittiert wurde)
• Generiere einen neuen Session-Identifikator, wenn sich die Verbindungssicherheit von HTTP auf HTTPS aendert, wie es waehrend der Authentifizierung vorkommen kann. Innerhalb einer Anwendung wird empfohlen, konsistent HTTPS zu verwenden, anstatt zwischen HTTP und HTTPS zu wechseln.
• Ergaenze das Standard-Session-Management fuer sensible serverseitige Operationen, wie Kontoverwaltung, durch die Verwendung von pro-Session starken zufaelligen Tokens oder Parametern. Diese Methode kann verwendet werden, um Cross Site Request Forgery-Angriffe zu verhindern
• Ergaenze das Standard-Session-Management fuer hochsensible oder kritische Operationen durch die Verwendung von pro-Anfrage, im Gegensatz zu pro-Session, starken zufaelligen Tokens oder Parametern
• Set the „secure“ attribute for cookies transmitted over an TLS connection
• Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie’s value
Zugriffskontrolle:
• Verwende nur vertrauenswuerdige Systemobjekte, z.B. serverseitige Session-Objekte, fuer Zugriffsentscheidungen
• Verwende eine einzelne websiteweite Komponente zur Pruefung der Zugriffsautorisierung. Das umfasst Bibliotheken, die externe Autorisierungsdienste aufrufen
• Zugriffskontrollen sollten sicher fehlschlagen
• Verweigere jeden Zugriff, wenn die Anwendung nicht auf ihre Sicherheitskonfigurationsinformationen zugreifen kann
• Enforce authorization controls on every request, including those made by server-side scripts, „includes“ and requests from rich client-side technologies like AJAX and Flash
• Trenne privilegierte Logik von anderem Anwendungscode
• Restrict access to files or other resources, including those outside the application’s direct control, to only authorized users
• Beschraenke den Zugriff auf geschuetzte URLs auf nur autorisierte Benutzer
• Beschraenke den Zugriff auf geschuetzte Funktionen auf nur autorisierte Benutzer
• Beschraenke direkte Objektreferenzen auf nur autorisierte Benutzer
• Beschraenke den Zugriff auf Dienste auf nur autorisierte Benutzer
• Beschraenke den Zugriff auf Anwendungsdaten auf nur autorisierte Benutzer
• Beschraenke den Zugriff auf Benutzer- und Datenattribute sowie Richtlinieninformationen, die von Zugriffskontrollen verwendet werden
• Beschraenke den Zugriff auf sicherheitsrelevante Konfigurationsinformationen auf nur autorisierte Benutzer
• Serverseitige Implementierung und Darstellungsschicht-Repraesentationen von Zugriffskontrollregeln muessen uebereinstimmen
• Wenn Zustandsdaten auf dem Client gespeichert werden muessen, verwende Verschluesselung und Integritaetspruefung auf der Serverseite, um Zustandsmanipulationen zu erkennen.
• Setze Anwendungslogik-Ablaeufe durch, die den Geschaeftsregeln entsprechen
• Begrenze die Anzahl der Transaktionen, die ein einzelner Benutzer oder ein Geraet in einem bestimmten Zeitraum durchfuehren kann. Die Transaktionen/Zeit sollten ueber der tatsaechlichen Geschaeftsanforderung liegen, aber niedrig genug sein, um automatisierte Angriffe abzuschrecken
• Use the „referer“ header as a supplemental check only, it should never be the sole authorization check, as it is can be spoofed
• If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate
• Implement account auditing and enforce the disabling of unused accounts (e.g., After no more than 30 days from the expiration of an account’s password.)
• Die Anwendung muss die Deaktivierung von Konten und Beendigung von Sessions unterstuetzen, wenn die Autorisierung endet (z.B. Aenderungen an Rolle, Beschaeftigungsstatus, Geschaeftsprozess usw.)
• Service-Konten oder Konten, die Verbindungen zu oder von externen Systemen unterstuetzen, sollten die geringstmoeglichen Berechtigungen haben
• Create an Access Control Policy to document an application’s business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources
Kryptografische Praktiken:
• Alle kryptografischen Funktionen, die zum Schutz von Geheimnissen vor dem Anwendungsbenutzer verwendet werden, muessen auf einem vertrauenswuerdigen System implementiert werden (z.B. dem Server)
• Schuetze Master-Geheimnisse vor unbefugtem Zugriff
• Kryptografische Module sollten sicher fehlschlagen
• All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator when these random values are intended to be un-guessable
• Von der Anwendung verwendete kryptografische Module sollten FIPS 140-2 oder einem gleichwertigen Standard entsprechen. (Siehe http://csrc.nist.gov/groups/STM/cmvp/validation.html)
• Etabliere und nutze eine Richtlinie und einen Prozess fuer die Verwaltung kryptografischer Schluessel
Fehlerbehandlung und Protokollierung:
• Gib keine sensiblen Informationen in Fehlerantworten preis, einschliesslich Systemdetails, Session-Identifikatoren oder Kontoinformationen
• Verwende Fehlerbehandler, die keine Debugging- oder Stack-Trace-Informationen anzeigen
• Implementiere allgemeine Fehlermeldungen und verwende benutzerdefinierte Fehlerseiten
• Die Anwendung sollte Anwendungsfehler behandeln und sich nicht auf die Serverkonfiguration verlassen
• Gib zugewiesenen Speicher ordnungsgemaess frei, wenn Fehlerbedingungen auftreten
• Fehlerbehandlungslogik im Zusammenhang mit Sicherheitskontrollen sollte standardmaessig den Zugriff verweigern
• Alle Protokollierungskontrollen sollten auf einem vertrauenswuerdigen System implementiert werden (z.B. dem Server)
• Protokollierungskontrollen sollten sowohl Erfolg als auch Misserfolg bestimmter Sicherheitsereignisse unterstuetzen
• Stelle sicher, dass Logs wichtige Log-Ereignisdaten enthalten
• Stelle sicher, dass Log-Eintraege mit nicht vertrauenswuerdigen Daten nicht als Code in der vorgesehenen Log-Anzeige-Schnittstelle oder -Software ausgefuehrt werden
• Beschraenke den Zugriff auf Logs auf nur autorisierte Personen
• Verwende eine Master-Routine fuer alle Protokollierungsoperationen
• Speichere keine sensiblen Informationen in Logs, einschliesslich unnuetiger Systemdetails, Session-Identifikatoren oder Passwoerter
• Stelle sicher, dass ein Mechanismus zur Durchfuehrung von Log-Analysen existiert
• Protokolliere alle Eingabevalidierungsfehler
• Protokolliere alle Authentifizierungsversuche, insbesondere Fehlschlaege
• Protokolliere alle Zugriffskontrollfehler
• Protokolliere alle offensichtlichen Manipulationsereignisse, einschliesslich unerwarteter Aenderungen an Zustandsdaten
• Protokolliere Verbindungsversuche mit ungueltigen oder abgelaufenen Session-Tokens
• Protokolliere alle System-Ausnahmen
• Protokolliere alle administrativen Funktionen, einschliesslich Aenderungen an den Sicherheitskonfigurationseinstellungen
• Protokolliere alle Backend-TLS-Verbindungsfehler
• Protokolliere Ausfaelle kryptografischer Module
• Verwende eine kryptografische Hash-Funktion zur Validierung der Log-Eintrag-Integritaet
Datenschutz:
• Implementiere das Prinzip der geringsten Berechtigung, beschraenke Benutzer auf nur die Funktionalitaet, Daten und Systeminformationen, die zur Ausfuehrung ihrer Aufgaben erforderlich sind
• Schuetze alle zwischengespeicherten oder temporaeren Kopien sensibler Daten, die auf dem Server gespeichert sind, vor unbefugtem Zugriff und loesche diese temporaeren Arbeitsdateien, sobald sie nicht mehr benoetigt werden.
• Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see „Cryptographic Practices“ for additional guidance
• Schuetze serverseitigen Quellcode davor, von einem Benutzer heruntergeladen zu werden
• Speichere keine Passwoerter, Verbindungszeichenketten oder andere sensible Informationen im Klartext oder auf eine nicht kryptografisch sichere Weise auf der Clientseite. Dies umfasst die Einbettung in unsichere Formate wie: MS viewstate, Adobe Flash oder kompilierten Code
• Entferne Kommentare in benutzerzugaenglichem Produktionscode, die Backend-System- oder andere sensible Informationen offenlegen koennten
• Entferne unnoetige Anwendungs- und Systemdokumentation, da diese nuetzliche Informationen fuer Angreifer offenlegen kann
• Fuege keine sensiblen Informationen in HTTP-GET-Anfrageparameter ein
• Deaktiviere Auto-Vervollstaendigungs-Funktionen in Formularen, die sensible Informationen enthalten sollen, einschliesslich Authentifizierung
• Disable client side caching on pages containing sensitive information. Cache-Control: no-store, may be used in conjunction with the HTTP header control „Pragma: no-cache“, which is less effective, but is HTTP/1.0 backward compatible
• Die Anwendung sollte die Entfernung sensibler Daten unterstuetzen, wenn diese Daten nicht mehr benoetigt werden. (z.B. persoenliche Informationen oder bestimmte Finanzdaten)
• Implementiere geeignete Zugriffskontrollen fuer sensible Daten, die auf dem Server gespeichert sind. Dies umfasst zwischengespeicherte Daten, temporaere Dateien und Daten, die nur fuer bestimmte Systembenutzer zugaenglich sein sollten
Kommunikationssicherheit:
• Implementiere Verschluesselung fuer die Uebertragung aller sensiblen Informationen. Dies sollte TLS zum Schutz der Verbindung umfassen und kann durch diskrete Verschluesselung sensibler Dateien oder nicht-HTTP-basierter Verbindungen ergaenzt werden
• TLS-Zertifikate sollten gueltig sein, den korrekten Domainnamen haben, nicht abgelaufen sein und bei Bedarf mit Zwischenzertifikaten installiert werden
• Fehlgeschlagene TLS-Verbindungen sollten nicht auf eine unsichere Verbindung zurueckfallen
• Verwende TLS-Verbindungen fuer alle Inhalte, die authentifizierten Zugriff erfordern, und fuer alle anderen sensiblen Informationen
• Verwende TLS fuer Verbindungen zu externen Systemen, die sensible Informationen oder Funktionen beinhalten
• Verwende eine einzelne Standard-TLS-Implementierung, die angemessen konfiguriert ist
• Lege Zeichenkodierungen fuer alle Verbindungen fest
• Filtere Parameter mit sensiblen Informationen aus dem HTTP-Referer beim Verlinken auf externe Websites
Systemkonfiguration:
• Stelle sicher, dass Server, Frameworks und Systemkomponenten die neueste genehmigte Version ausfuehren
• Stelle sicher, dass Server, Frameworks und Systemkomponenten alle fuer die verwendete Version herausgegebenen Patches haben
• Deaktiviere Verzeichnisauflistungen
• Beschraenke den Webserver, Prozess- und Service-Konten auf die geringstmoeglichen Berechtigungen
• Bei Ausnahmen sicher fehlschlagen
• Entferne alle unnoetige Funktionalitaet und Dateien
• Entferne Testcode oder jede nicht fuer die Produktion vorgesehene Funktionalitaet vor der Bereitstellung
• Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then „Disallow“ that entire parent directory in the robots.txt file rather than Disallowing each individual directory
• Definiere, welche HTTP-Methoden, Get oder Post, die Anwendung unterstuetzen wird und ob sie auf verschiedenen Seiten der Anwendung unterschiedlich behandelt werden
• Deaktiviere unnoetige HTTP-Methoden, wie WebDAV-Erweiterungen. Wenn eine erweiterte HTTP-Methode erforderlich ist, die Dateiverarbeitung unterstuetzt, verwende einen gut ueberprueften Authentifizierungsmechanismus
• Wenn der Webserver sowohl HTTP 1.0 als auch 1.1 verarbeitet, stelle sicher, dass beide aehnlich konfiguriert sind, oder stelle sicher, dass Du etwaige Unterschiede verstehst (z.B. Behandlung erweiterter HTTP-Methoden)
• Entferne unnoetige Informationen aus HTTP-Antwort-Headern in Bezug auf das Betriebssystem, die Webserver-Version und Anwendungs-Frameworks
• Der Sicherheitskonfigurationsspeicher der Anwendung sollte in menschenlesbarer Form ausgegeben werden koennen, um Audits zu unterstuetzen
• Implementiere ein Asset-Management-System und registriere Systemkomponenten und Software darin
• Isoliere Entwicklungsumgebungen vom Produktionsnetzwerk und gewaehre nur autorisierten Entwicklungs- und Testgruppen Zugriff. Entwicklungsumgebungen sind oft weniger sicher konfiguriert als Produktionsumgebungen, und Angreifer koennen diesen Unterschied nutzen, um gemeinsame Schwachstellen zu entdecken oder als Angriffsweg
• Implementiere ein Software-Aenderungskontrollsystem, um Aenderungen am Code sowohl in der Entwicklung als auch in der Produktion zu verwalten und aufzuzeichnen
Datenbanksicherheit:
• Verwende stark typisierte parametrisierte Abfragen
• Verwende Eingabevalidierung und Ausgabekodierung und stelle sicher, dass Metazeichen beruecksichtigt werden. Wenn diese fehlschlagen, fuehre den Datenbankbefehl nicht aus
• Stelle sicher, dass Variablen stark typisiert sind
• Die Anwendung sollte beim Zugriff auf die Datenbank die geringstmoegliche Berechtigungsstufe verwenden
• Verwende sichere Zugangsdaten fuer den Datenbankzugriff
• Verbindungszeichenketten sollten nicht hart in die Anwendung kodiert werden. Verbindungszeichenketten sollten in einer separaten Konfigurationsdatei auf einem vertrauenswuerdigen System gespeichert und verschluesselt werden.
• Verwende Stored Procedures, um den Datenzugriff zu abstrahieren und die Entfernung von Berechtigungen fuer die Basistabellen in der Datenbank zu ermoeglichen
• Schliesse die Verbindung so schnell wie moeglich
• Entferne oder aendere alle Standard-Datenbank-Administratorpasswoerter. Verwende starke Passwoerter/Passphrasen oder implementiere Multi-Faktor-Authentifizierung
• Deaktiviere alle unnoetige Datenbankfunktionalitaet (z.B. unnoetige Stored Procedures oder Dienste, Hilfspakete, installiere nur den minimal erforderlichen Funktions- und Optionssatz (Reduzierung der Angriffsflaeche))
• Entferne unnoetige Standard-Herstellerinhalte (z.B. Beispiel-Schemata)
• Deaktiviere alle Standardkonten, die nicht zur Unterstuetzung geschaeftlicher Anforderungen erforderlich sind
• Die Anwendung sollte sich mit unterschiedlichen Zugangsdaten fuer jede Vertrauensstufe mit der Datenbank verbinden (z.B. Benutzer, Nur-Lese-Benutzer, Gast, Administratoren)
Dateiverwaltung:
• Uebergib keine vom Benutzer bereitgestellten Daten direkt an eine dynamische Include-Funktion
• Erfordere Authentifizierung, bevor ein Datei-Upload erlaubt wird
• Beschraenke die Dateitypen, die hochgeladen werden koennen, auf nur jene, die fuer geschaeftliche Zwecke benoetigt werden
• Validiere, dass hochgeladene Dateien den erwarteten Typ haben, indem Du Datei-Header pruefst. Die Pruefung des Dateityps allein anhand der Erweiterung ist nicht ausreichend
• Speichere Dateien nicht im selben Web-Kontext wie die Anwendung. Dateien sollten entweder auf den Content-Server oder in die Datenbank gehen.
• Verhindere oder beschraenke das Hochladen von Dateien, die vom Webserver interpretiert werden koennten.
• Deaktiviere Ausfuehrungsberechtigungen fuer Datei-Upload-Verzeichnisse
• Implementiere sicheres Hochladen in UNIX, indem Du das Ziel-Dateiverzeichnis als logisches Laufwerk ueber den zugehoerigen Pfad oder die chroot-Umgebung einhaengst
• Verwende beim Referenzieren vorhandener Dateien eine Whitelist erlaubter Dateinamen und -typen. Validiere den Wert des uebergebenen Parameters und lehne ihn ab, wenn er nicht einem der erwarteten Werte entspricht, oder verwende stattdessen einen hart kodierten Standard-Dateiwert fuer den Inhalt
• Uebergib keine vom Benutzer bereitgestellten Daten in eine dynamische Weiterleitung. Wenn dies erlaubt sein muss, sollte die Weiterleitung nur validierte, relative Pfad-URLs akzeptieren
• Uebergib keine Verzeichnis- oder Dateipfade, verwende Indexwerte, die einer vordefinierten Liste von Pfaden zugeordnet sind
• Sende nie den absoluten Dateipfad an den Client
• Stelle sicher, dass Anwendungsdateien und -ressourcen schreibgeschuetzt sind
• Scanne vom Benutzer hochgeladene Dateien auf Viren und Malware
Speicherverwaltung:
• Verwende Eingabe- und Ausgabekontrolle fuer nicht vertrauenswuerdige Daten
• Pruefe doppelt, dass der Puffer so gross ist wie angegeben
• Beachte bei der Verwendung von Funktionen, die eine Anzahl von Bytes zum Kopieren akzeptieren, wie strncpy(), dass der String moeglicherweise nicht NULL-terminiert wird, wenn die Ziel-Puffergroesse gleich der Quell-Puffergroesse ist
• Pruefe Puffergrenzen, wenn die Funktion in einer Schleife aufgerufen wird, und stelle sicher, dass keine Gefahr besteht, ueber den zugewiesenen Speicherplatz hinaus zu schreiben
• Kuerze alle Eingabezeichenketten auf eine angemessene Laenge, bevor Du sie an die Kopier- und Verkettungsfunktionen uebergibst
• Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)
• Verwende nicht-ausfuehrbare Stacks, wenn verfuegbar
• Vermeide die Verwendung bekannter anfaelliger Funktionen (z.B. printf, strcat, strcpy usw.)
• Gib zugewiesenen Speicher ordnungsgemaess frei nach Abschluss von Funktionen und an allen Ausstiegspunkten
Allgemeine Programmierpraktiken:
• Verwende getesteten und genehmigten verwalteten Code, anstatt neuen nicht verwalteten Code fuer gaengige Aufgaben zu erstellen
• Verwende aufgabenspezifische integrierte APIs zur Durchfuehrung von Betriebssystemaufgaben. Erlaube der Anwendung nicht, Befehle direkt an das Betriebssystem zu erteilen, insbesondere nicht durch die Verwendung von anwendungsinitiierten Befehlsshells
• Verwende Pruefsummen oder Hashes zur Ueberpruefung der Integritaet von interpretiertem Code, Bibliotheken, ausfuehrbaren Dateien und Konfigurationsdateien
• Verwende Sperrmechanismen, um mehrere gleichzeitige Anfragen zu verhindern, oder verwende einen Synchronisierungsmechanismus zur Vermeidung von Race Conditions
• Schuetze gemeinsam genutzte Variablen und Ressourcen vor ungeeignetem gleichzeitigem Zugriff
• Initialisiere alle Deine Variablen und andere Datenspeicher explizit, entweder bei der Deklaration oder unmittelbar vor der ersten Verwendung
• In Faellen, in denen die Anwendung mit erhoehten Berechtigungen laufen muss, erhoehe die Berechtigungen so spaet wie moeglich und entziehe sie so frueh wie moeglich
• Avoid calculation errors by understanding your programming language’s underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, „not-a-number“ calculations, and how your language handles numbers that are too large or too small for its underlying representation
• Uebergib keine vom Benutzer bereitgestellten Daten an dynamische Ausfuehrungsfunktionen
• Hindere Benutzer daran, neuen Code zu generieren oder bestehenden Code zu aendern
• Ueberpruefen alle sekundaeren Anwendungen, Drittanbieter-Code und Bibliotheken, um die geschaeftliche Notwendigkeit zu bestimmen und sichere Funktionalitaet zu validieren, da diese neue Schwachstellen einfuehren koennen
• Implementiere sicheres Aktualisieren. Wenn die Anwendung automatische Updates verwenden wird, nutze kryptografische Signaturen fuer Deinen Code und stelle sicher, dass Deine Download-Clients diese Signaturen verifizieren. Verwende verschluesselte Kanaele, um den Code vom Host-Server zu uebertragen
Anhang A:
Externe Referenzen:
1. Cited Reference
Sans and TippingPoint „The Top Cyber Security Risks“
http://www.sans.org/top-cyber-security-risks/
• Web Application Security Consortium
http://www.webappsec.org/
• Common Weakness Enumeration (CWE)
http://cwe.mitre.org/
• Department of Homeland Security
Build Security In Portal
https://buildsecurityin.us-cert.gov/daisy/bsi/home.html
• CERT Secure Coding
http://www.cert.org/secure-coding/
• MSDN Security Developer Center
http://msdn.microsoft.com/en-us/security/default.aspx
• SQL Injection Cheat Sheet
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
• Cross Site Scripting (XSS) Cheat Sheet
http://ha.ckers.org/xss.htmlSecurity Advisory Sites:
Nuetzliche Ressourcen zur Pruefung auf bekannte Schwachstellen in der unterstuetzenden Infrastruktur und
Frameworks
Secunia Citrix Schwachstellenliste:
• http://secunia.com/advisories/search/?search=citrix
Security Focus Vulnerability Search:
• http://www.securityfocus.com/vulnerabilities
Open Source Vulnerability Database (OSVDB):
• http://osvdb.org/search/web_vuln_search
Common Vulnerability Enumeration:
• http://www.cve.mitre.org/
Anhang B:
Glossar
Missbrauchsfall (Abuse Case): Beschreibt den absichtlichen und unbeabsichtigten Missbrauch der Software. Missbrauchsfaelle sollten die Annahmen des Systemdesigns in Frage stellen.
Zugriffskontrolle (Access Control): Eine Reihe von Kontrollen, die einem Benutzer oder einer anderen Entitaet den Zugriff auf eine Systemressource gewaehren oder verweigern. Dies basiert normalerweise auf hierarchischen Rollen und individuellen Berechtigungen innerhalb einer Rolle, umfasst aber auch System-zu-System-Interaktionen.
Authentifizierung (Authentication): Eine Reihe von Kontrollen zur Verifizierung der Identitaet eines Benutzers oder einer anderen Entitaet, die mit der Software interagiert.
Availability: A measure of a system’s accessibility and usability.
Kanonisieren (Canonicalize): Verschiedene Kodierungen und Darstellungen von Daten auf eine einzelne einfache Form reduzieren.
Kommunikationssicherheit (Communication Security): Eine Reihe von Kontrollen, die sicherstellen, dass die Software das Senden und Empfangen von Informationen auf sichere Weise handhabt.
Vertraulichkeit (Confidentiality): Sicherstellen, dass Informationen nur an autorisierte Parteien weitergegeben werden.
Kontextbezogene Ausgabekodierung (Contextual Output Encoding): Kodierung von Ausgabedaten basierend darauf, wie sie von der Anwendung verwendet werden. Die spezifischen Methoden variieren je nach Art der Verwendung der Ausgabedaten. Wenn die Daten in die Antwort an den Client aufgenommen werden sollen, beruecksichtige Einbindungsszenarien wie: den Body eines HTML-Dokuments, ein HTML-Attribut, innerhalb von JavaScript, innerhalb von CSS oder in einer URL. Du musst auch andere Anwendungsfaelle wie SQL-Abfragen, XML und LDAP beruecksichtigen.
Cross Site Request Forgery: Eine externe Website oder Anwendung zwingt einen Client, eine unbeabsichtigte Anfrage an eine andere Anwendung zu stellen, mit der der Client eine aktive Session hat. Anwendungen sind anfaellig, wenn sie bekannte oder vorhersagbare URLs und Parameter verwenden; und wenn der Browser automatisch alle erforderlichen Session-Informationen mit jeder Anfrage an die anfaellige Anwendung uebertraegt. (Dies ist einer der wenigen Angriffe, die in diesem Dokument ausdruecklich diskutiert werden, und ist nur enthalten, weil die zugehoerige Schwachstelle sehr verbreitet und schlecht verstanden ist.)
Kryptografische Praktiken (Cryptographic Practices): Eine Reihe von Kontrollen, die sicherstellen, dass kryptografische Operationen innerhalb der Anwendung sicher gehandhabt werden.
Datenschutz (Data Protection): Eine Reihe von Kontrollen, die sicherstellen, dass die Software die Speicherung von Informationen auf sichere Weise handhabt.
Datenbanksicherheit (Database Security): Eine Reihe von Kontrollen, die sicherstellen, dass Software auf sichere Weise mit einer Datenbank interagiert und dass die Datenbank sicher konfiguriert ist.
Fehlerbehandlung und Protokollierung (Error Handling and Logging): Eine Reihe von Praktiken, die sicherstellen, dass die Anwendung Fehler sicher behandelt und eine ordnungsgemaesse Ereignisprotokollierung durchfuehrt.
Exploit: To take advantage of a vulnerability. Typically this is an intentional action designed to compromise the software’s security controls by leveraging a vulnerability.
Dateiverwaltung (File Management): Eine Reihe von Kontrollen, die die Interaktion zwischen dem Code und anderen Systemdateien abdecken.
Allgemeine Programmierpraktiken (General Coding Practices): Eine Reihe von Kontrollen, die Programmierpraktiken abdecken, die nicht einfach in andere Kategorien passen.
Gefaehrliches Zeichen (Hazardous Character): Jedes Zeichen oder kodierte Darstellung eines Zeichens, das den beabsichtigten Betrieb der Anwendung oder des zugehoerigen Systems beeinflussen kann, indem es als mit einer besonderen Bedeutung ausserhalb der beabsichtigten Verwendung des Zeichens interpretiert wird. Diese Zeichen koennen verwendet werden fuer:
• Aenderung der Struktur von bestehendem Code oder Anweisungen
• Einfuegen von neuem unbeabsichtigtem Code
• Aenderung von Pfaden
• Verursachung unerwarteter Ergebnisse von Programmfunktionen oder -routinen
• Verursachung von Fehlerbedingungen
• Ausuebung jeglicher der obigen Auswirkungen auf nachgelagerte Anwendungen oder Systeme
HTML Entity Encode: The process of replacing certain ASCII characters with their HTML entity equivalents. For example, encoding would replace the less than character „< „with the HTML equivalent „<“. HTML entities are ‚inert‘ in most interpreters, especially browsers, which can mitigate certain client-side attacks.
Auswirkung (Impact): Ein Mass fuer die negative Auswirkung auf das Unternehmen, die aus dem Eintreten eines unerwuenschten Ereignisses resultiert; was waere das Ergebnis, wenn eine Schwachstelle ausgenutzt wuerde.
Eingabevalidierung (Input Validation): Eine Reihe von Kontrollen, die ueberpruefen, ob die Eigenschaften aller Eingabedaten den Erwartungen der Anwendung entsprechen, einschliesslich Typen, Laengen, Bereichen und akzeptablen Zeichensaetzen, und keine bekannten gefaehrlichen Zeichen enthalten.
Integritaet (Integrity): Die Sicherstellung, dass Informationen genau, vollstaendig und gueltig sind und nicht durch eine unberechtigte Aktion veraendert wurden.
Log-Ereignisdaten (Log Event Data): Diese sollten Folgendes enthalten:
1. Zeitstempel von einer vertrauenswuerdigen Systemkomponente
2. Schweregrad-Bewertung fuer jedes Ereignis
3. Kennzeichnung sicherheitsrelevanter Ereignisse, wenn sie mit anderen Log-Eintraegen vermischt sind
4. Identitaet des Kontos/Benutzers, der das Ereignis verursacht hat
5. Quell-IP-Adresse, die mit der Anfrage verbunden ist
6. Ereignisergebnis (Erfolg oder Misserfolg)
7. Beschreibung des Ereignisses
Speicherverwaltung (Memory Management): Eine Reihe von Kontrollen, die sich mit Speicher- und Puffernutzung befassen.
Mindern (Mitigate): Massnahmen zur Reduzierung des Schweregrads einer Schwachstelle. Dazu koennen das Entfernen einer Schwachstelle, das Erschweren der Ausnutzung einer Schwachstelle oder die Reduzierung der negativen Auswirkungen einer erfolgreichen Ausnutzung gehoeren. Multi-Faktor-Authentifizierung: Ein Authentifizierungsprozess, der vom Benutzer verlangt, mehrere unterschiedliche Arten von Zugangsdaten vorzulegen. Typischerweise basiert dies auf etwas, das er hat (z.B. Smartcard), etwas, das er weiss (z.B. eine PIN), oder etwas, das er ist (z.B. Daten von einem biometrischen Leser).
Ausgabekodierung (Output Encoding): Eine Reihe von Kontrollen, die die Verwendung von Kodierung adressieren, um sicherzustellen, dass die Datenausgabe der Anwendung sicher ist.
Parametrisierte Abfragen (Prepared Statements): Halten Abfrage und Daten durch die Verwendung von Platzhaltern getrennt. Die Abfragestruktur wird mit Platzhaltern definiert, die SQL-Anweisung wird an die Datenbank gesendet und vorbereitet, und dann wird die vorbereitete Anweisung mit den Parameterwerten kombiniert. Dies verhindert, dass die Abfrage veraendert wird, da die Parameterwerte mit der kompilierten Anweisung und nicht mit einem SQL-String kombiniert werden.
Datenbereinigung (Sanitize Data): Der Prozess, potenziell schaedliche Daten durch Datenentfernung, -ersetzung, Kodierung oder Escaping der Zeichen sicher zu machen.
Sicherheitskontrollen (Security Controls): Eine Massnahme, die eine potenzielle Schwachstelle mindert und sicherstellt, dass die Software nur auf die erwartete Weise funktioniert.
Sicherheitsanforderungen (Security Requirements): Eine Reihe von Design- und Funktionsanforderungen, die sicherstellen, dass die Software auf sichere Weise erstellt und bereitgestellt wird.
Sequenzielle Authentifizierung (Sequential Authentication): Wenn Authentifizierungsdaten auf aufeinanderfolgenden Seiten angefordert werden, anstatt alle auf einer einzelnen Seite angefordert zu werden.
Session-Management: Eine Reihe von Kontrollen, die sicherstellen, dass Webanwendungen HTTP-Sessions auf sichere Weise handhaben.
State Data: When data or parameters are used, by the application or server, to emulate a persistent connection or track a client’s status across a multi-request process or transaction.
System: A generic term covering the operating systems, web server, application Frameworks, and related infrastructure.
Systemkonfiguration (System Configuration): Eine Reihe von Kontrollen, die sicherstellen, dass die die Software unterstuetzenden Infrastrukturkomponenten sicher bereitgestellt werden.
Threat Agent: Any entity which may have a negative impact on the system. This may be a malicious user who wants to compromise the system’s security controls; however, it could also be accidental misuse of the system or a more physical threat like fire or flood.
Vertrauensgrenzen (Trust Boundaries): Typischerweise umfasst eine Vertrauensgrenze die Komponenten des Systems unter Deiner direkten Kontrolle. Alle Verbindungen und Daten von Systemen ausserhalb Deiner direkten Kontrolle, einschliesslich aller Clients und von Dritten verwalteter Systeme, sollten als nicht vertrauenswuerdig betrachtet und an der Grenze validiert werden, bevor weitere Systeminteraktion erlaubt wird.
Schwachstelle (Vulnerability): Eine Schwaeche, die das System anfaellig fuer Angriffe oder Schaeden macht.
Urheberrecht und Lizenz
Originaltext Copyright © 2010 von The OWASP Foundation. Modifiziert von WP STAGING 2022.
Dieses Dokument wird unter der Creative Commons Attribution ShareAlike 3.0 Lizenz veroeffentlicht. Bei jeder Wiederverwendung oder Verbreitung musst Du anderen die Lizenzbedingungen dieses Werks deutlich machen.
http://creativecommons.org/licenses/by-sa/3.0/