[vc_row full_width=“stretch_row“ css=“.vc_custom_1486976078563{margin-bottom: 54px !important;}“][vc_column][vc_empty_space height=“55px“][vc_custom_heading text=“Angriffsmethoden 2017: Sicherheit von Webanwendungen“ font_container=“tag:h3|text_align:center“ google_fonts=“font_family:Montserrat%3Aregular%2C700|font_style:700%20bold%20regular%3A700%3Anormal“][vc_row_inner][vc_column_inner width=“1/12″][/vc_column_inner][vc_column_inner width=“10/12″][vc_column_text]Die Sicherheit von Webanwendungen ist ein unabdingbarer Aspekt der Entwicklung von Webanwendungen. Ohne Berücksichtigung der Sicherheit, werden Angreifer Sie schnell übernehmen.

Bei der Sicherheit von Webanwendungen kommen unter anderem verschiedene Aspekte bei der Entwicklung in Betracht. Seit 2013 wird bei Angriffsmethoden auf Webanwendungen, unter anderem die OWASP Top 10 Liste als Anhaltspunkt für Webentwickler zurate gezogen.

Beachtung der Sicherheit für Webanwendungen im Jahr 2017

Aus dem OWASP Top 10 für 2017 vom Open Web Application Security Project geht unter anderem hervor, das Microservices  in Node.js und Spring Boot von Entwicklern erstellt werden. Außerdem erstellen Entwickler verstärkt Single Page Applications (SPAs) mit JavaScript-Frameworks wie dem beliebten Angular und React. JavaScript  ist dabei die vorherrschende Sprache im Internet und damit eine bevorzugte Websprache auch für Angreifer. Serverseitig steht Node.js im Mittelpunkt, und für die Client-Entwicklung kommen  Webframeworks wie Bootstrap, Electron, Angular und React zum Einsatz.

Aktualisierte OWASP Top 10 Liste

Im Jahr 2017 OWASP Top 10 2017 Im Jahr 2013
1 Injection wie SQL Injetion u.a. 1
2 Broken Authentication 2
3 Sensitive Data Exposure 6
4 XML External Entity-Angriff (XXE) (Neu in OWASP Top 10 für 2017 )
5 Broken Access Control (Manipulierbare Zugriffskontrolle) 4 & 7
6 Security Misconfiguration 5
7 Cross-Site Scripting (XSS) 3
8 Insecure Deserialization (Neu in OWASP Top 10 für 2017 )
9 Komponente mit unbekannten Sicherheitslücken 9
10 Unzureichende Protokollierung und Überwachung

Insufficient Logging & Monitoring

 

(Neu in OWASP Top 10 für 2017 )

Diese und weitere Angriffsmethoden, auch in unseren Hacking Schulungen lernen>

Angriffsmethoden auf Webanwendundungen, OWASP Top 10 erklärt.

 

SQL-Injection

Siehe auch Wikipedia: SQL-Injection

SQL-Injection bezeichnet das Ausnutzen von Sicherheitslücken in Zusammenhang mit SQL-Datenbanken in Webanwendungen, die durch mangelnde Maskierung oder Überprüfung von Metazeichen in Benutzereingaben entsteht. Angreifer versuchen dabei, über die Anwendung, die den Zugriff auf die Datenbank bereitstellt, eigene Datenbankbefehle einzuschleusen. Sein Ziel ist es, Daten auszuspähen, in seinem Sinne zu verändern, die Kontrolle über den Server zu erhalten oder einfach größtmöglichen Schaden anzurichten.

 

Broken Authentication

  • Szenario 1: Die Airline-Reservierungsanwendung unterstützt das Umschreiben von URLs und gibt die entsprechende Sitzungs-IDs an der  URL aus:http://example.com/verkauf/seite?sessionid=55591485214&dest=SESSIONHAPAK

Ein authentifizierter Nutzer der Website möchte seine Freunde über den Verkauf informieren. Er sendet den obigen Link per E-Mail, ohne zu wissen, dass er auch seine Sitzungs-ID mitgesendet hat. Wenn seine Freunde den Link verwenden, werden sie seine Sitzung und seine Kreditkarte verwenden und Daten ausspähen.

  • Szenario # 2: Die Timeouts der Anwendung sind nicht korrekt eingestellt. Benutzer verwendet einen öffentlichen Computer, um auf die Website zuzugreifen. Anstatt „Abmelden“ auszuwählen, schließt der Benutzer einfach die Browser-Registerkarte und verlässt den Computer. Der Angreifer verwendet eine Stunde später denselben Browser, dieser Browser ist weiterhin authentifiziert.
  • Szenario 3: Ein Insider oder ein externer Angreifer erhält Zugriff auf die Passwortdatenbank des Systems. Benutzerkennwörter werden nicht ordnungsgemäß gehasht, sodass das Kennwort jedes Benutzers dem Angreifer angezeigt wird.

Sensitive Data Exposure

  • Szenario 1: Eine Anwendung verschlüsselt Kreditkartennummern in einer Datenbank mithilfe der automatischen Datenbankverschlüsselung. Dies bedeutet jedoch, dass auch diese Daten beim Abrufen automatisch entschlüsselt werden, sodass ein SQL-Injection-Fehler Kreditkartennummern im Klartext abrufen kann. Das System sollte die Kreditkartennummern mit einem öffentlichen Schlüssel verschlüsseln und nur Backend-Anwendungen erlauben, sie mit dem privaten Schlüssel zu entschlüsseln.
  • Szenario 2: Eine Website verwendet SSL nicht für alle authentifizierten Seiten. Der Angreifer überwacht einfach den Netzwerkverkehr (wie ein offenes drahtloses Netzwerk) und stiehlt das Sitzungscookie des Benutzers. Der Angreifer gibt dann dieses Cookie wieder und entführt die Sitzung des Benutzers, wobei er auf die privaten Daten des Benutzers zugreift.
  • Szenario # 3: Die Kennwortdatenbank der Webanwendung oder Anwendung verwendet ungesalzene Hashes, um die Kennwörter aller Benutzer zu speichern. Ein Dateiupload-Fehler ermöglicht es einem Angreifer, die Passwortdatei abzurufen. Alle ungesalzenen Hashes können mit einer Regenbogen-Tabelle von vorberechneten Hashes belichtet werden.

 

XML External Entity-Angriff

Ein XML External Entity-Angriff ist eine Art Angriff auf eine Anwendung, die eine XML-Eingabe analysiert. Dieser Angriff kann durchgeführt werden, wenn eine XML-Eingabe, die einen Verweis auf eine externe Entität enthält, der von einem schwach konfigurierten XML-Parser verarbeitet wird. Dieser Angriff kann zur Offenlegung von vertraulichen Daten, Denial-of-Service, serverseitiger Anforderungsfälschung, Port-Scanning aus der Perspektive der Maschine, auf der sich der Parser befindet, und anderen Kritischen-Systemauswirkungen führen.

Der XML 1.0-Standard definiert die Struktur eines XML-Dokuments. Der Standard definiert ein Konzept, das als Entität bezeichnet wird und eine Speichereinheit eines bestimmten Typs ist. Es gibt ein paar verschiedene Arten von Entitäten, eine externe, allgemein / parameter-analysierte Entität, die oft zu einer externen Entität verkürzt wird, die über einen deklarierten Systembezeichner auf lokalen oder fernen Inhalt zugreifen kann. Es wird angenommen, dass die Systemkennung eine URI ist, die beim Verarbeiten der Entität vom XML-Prozessor dereferenziert (Zugriff) werden kann. Der XML-Prozessor ersetzt dann die Vorkommen der benannten externen Entität durch die Inhalte, die durch die Systemkennung dereferenziert wurden. Wenn die Systemkennung verdorbene Daten enthält und der XML-Prozessor diese verdorbenen Daten dereferenziert, kann der XML-Prozessor vertrauliche Informationen preisgeben, die normalerweise nicht von der Anwendung zugänglich sind. Ähnliche Angriffsvektoren wenden die Verwendung von externen DTDs, externen Stylesheets, externen Schemata usw. an, die, wenn sie enthalten sind, ähnliche externe Ressourceneinschluss-Stilangriffe erlauben.

Manipulierbare Zugriffskontrolle

Zugriffskontrolle, manchmal Autorisierung genannt, ist die Art und Weise, wie eine Webanwendung einigen und nicht anderen Benutzern Zugriff auf Inhalte und Funktionen gewährt. Diese Überprüfungen werden nach der Authentifizierung durchgeführt und regeln, was „autorisierte“ Benutzer tun dürfen. Zugriffskontrolle klingt wie ein einfaches Problem, ist aber schleichend schwierig zu implementieren. Das Zugriffskontrollmodell einer Webanwendung ist eng mit dem Inhalt und den Funktionen der Website verknüpft. Darüber hinaus können die Benutzer in eine Reihe von Gruppen oder Rollen mit unterschiedlichen Fähigkeiten oder Privilegien fallen.

Entwickler unterschätzen häufig die Schwierigkeit, einen zuverlässigen Zugriffskontrollmechanismus zu implementieren. Viele dieser Programme wurden nicht absichtlich entworfen, sondern haben sich einfach zusammen mit der Website entwickelt. In diesen Fällen werden Zugriffssteuerungsregeln an verschiedenen Stellen im gesamten Code eingefügt. Wenn sich die Site der Bereitstellung nähert, wird die Ad-hoc-Sammlung von Regeln so unhandlich, dass es fast unmöglich ist, sie zu verstehen.

Viele dieser fehlerhaften Zugriffskontrollsysteme sind nicht schwer zu entdecken und zu nutzen. Häufig ist es nur erforderlich, eine Anfrage für Funktionen oder Inhalte zu erstellen, die nicht erteilt werden sollten. Sobald ein Fehler entdeckt wurde, können die Konsequenzen eines fehlerhaften Zugriffskontrollsystems verheerend sein. Neben der Anzeige nicht autorisierter Inhalte kann ein Angreifer Inhalte ändern oder löschen, nicht autorisierte Funktionen ausführen oder sogar die Websiteverwaltung übernehmen

 

Security Misconfiguration

  • Szenario 1: Die Admin-Konsole des App-Servers wird automatisch installiert und nicht entfernt. Standardkonten werden nicht geändert. Der Angreifer entdeckt die standardmäßigen Administrationsseiten auf Ihrem Server, meldet sich mit Standardkennwörtern an und übernimmt die Aufgabe.
  • Szenario 2: Die Verzeichnisliste ist auf Ihrem Server nicht deaktiviert. Der Angreifer entdeckt, dass er einfach Verzeichnisse auflisten kann, um eine Datei zu finden. Der Angreifer findet und lädt alle kompilierten Java-Klassen herunter, die er dekompiliert und die Ingenieure rückgängig macht, um Ihren gesamten benutzerdefinierten Code zu erhalten. Sie findet dann einen schwerwiegenden Zugriffskontrollfehler in Ihrer Anwendung.
  • Szenario 3: Die Konfiguration des App-Servers ermöglicht die Rückgabe von Stack-Traces an Benutzer, wodurch möglicherweise zugrunde liegende Fehler aufgedeckt werden. Angreifer lieben die zusätzlichen Informationen, die Fehlermeldungen liefern.
  • Szenario # 4: Der Anwendungsserver enthält Beispielanwendungen, die nicht von Ihrem Produktionsserver entfernt wurden. Diese Beispielanwendungen haben bekannte Sicherheitslücken, die Angreifer verwenden können, um Ihren Server zu kompromittieren.

 

Cross-Site-Scripting (XSS)

 

Siehe auch Wikipedia: Cross-Site-Scripting

Hinter der Bezeichnung Cross-Site-Scripting (XSS) verbergen sich zwei (manchmal wird noch ein dritter Typ unterschieden) grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie z. B. JavaScript, in eine Webseite ein, die in dem Webbrowser des Opfers ausgeführt wird. Dieser Angriff nutzt dabei Sicherheitslücken bei der lokalen Ausführung der Skripte aus oder leitet eine Cross-Site-Request-Forgery ein. Unter serverseitigem XSS versteht man das Einschleusen von manipulierten Informationen in eine auf dem Webserver ausgeführte Scriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei (ggf. sogar von einem anderen Server) ausführt.

Insecure Deserialization

Von früheren Remote Method Invocation (RMI) – oder CORBA-Implementierungen ist Serialization / Deserialization ein Schlüsselmechanismus, der für die Übertragung eines Codezustands von einem Ende zu einem anderen verwandt wird. Die Serialisierung / Deserialisierung findet sowohl während des Prozesses als auch während des Prozesses und zwischen den Netzwerken zwischen denselben oder unterschiedlichen Frameworks statt.

Es gibt APIs, die bereits serialisierte Klasseninstanzen wie unten deserialisieren können;

                         
BinaryFormatter serializer = new BinaryFormatter();

byte [] content = File.ReadAllBytes(userInputFilePath);
MemoryStream ms = new MemoryStream(content);

OrderedItem i = (OrderedItem) serializer.Deserialize(ms);
i.Register();  
                  

Using Components with Known Vulnerabilities (Komponenten mit unbekannten Sicherheitslücken)

  • Schwachstellen von Komponenten können fast jedes erdenkliche Risiko verursachen, angefangen von der einfachen bis hin zu ausgefeilter Malware, die auf eine bestimmte Organisation abzielt. Komponenten laufen fast immer mit dem vollen Privileg der Anwendung, so dass Schwachstellen in jeder Komponente schwerwiegend sein können. Die folgenden beiden anfälligen Komponenten wurden 2011 22 Millionen Mal heruntergeladen.
  • Apache CXF-Authentifizierungsumgehung – Durch die fehlgeschlagene Bereitstellung eines Identitätstokens können Angreifer jeden Webdienst mit voller Berechtigung aufrufen. (Apache CXF ist ein Service-Framework, das nicht mit dem Apache Application Server verwechselt werden darf.)
  • Spring Remote Code Execution – Der Missbrauch der Expression Language-Implementierung im Frühjahr ermöglichte es Angreifern, beliebigen Code auszuführen und den Server effektiv zu übernehmen.Jede Anwendung, die eine dieser anfälligen Bibliotheken verwendet, ist anfällig für Angriffe, da auf beide Komponenten direkt von Anwendungsbenutzern zugegriffen werden kann. Andere anfällige Bibliotheken, die tiefer in einer Anwendung verwendet werden, sind möglicherweise schwerer auszunutzen.

 

Insufficient Logging & Monitoring, Unzureichende Überwachung

  • Szenario 1: Angreifer verwendet automatisierte Tools wiwe SQLMap, um Schwachstellen zu erkennen und sie möglicherweise auszunutzen. Die Angriffserkennung sollte erkennen, dass die Anwendung mit ungewöhnlichen Anforderungen und hoher Lautstärke angegriffen wird. Automatisierte Scans sollten leicht vom normalen Datenverkehr zu unterscheiden sein.
  • Szenario 2: Ein erfahrener menschlicher Angreifer sucht sorgfältig nach potenziellen Schwachstellen und findet schließlich einen obskuren Fehler. Dieser Angriff ist zwar schwieriger zu erkennen, umfasst aber immer noch Anforderungen, die ein normaler Benutzer niemals senden würde, wie z. B. eine Eingabe, die von der Benutzeroberfläche nicht zugelassen wird. Bei der Verfolgung dieses Angreifers muss möglicherweise im Laufe der Zeit ein Fall erstellt werden, der böswillige Absichten aufzeigt.
  • Szenario # 3: Der Angreifer nutzt eine Schwachstelle in Ihrer Anwendung aus, die Ihr aktueller Angriffsschutz nicht blockieren kann.Wie schnell können Sie einen echten oder virtuellen Patch bereitstellen, um die weitere Ausnutzung dieser Sicherheitsanfälligkeit zu blockieren?

https://www.janotta-partner.de/2017/11/schwachstellenscan/[/vc_column_text][vc_column_text]Nach einem Cyberangriff – Cybersicherheit

Nach einem Cyberangriff, bietet Janotta Partner Security Consulting verschiedene Dienste an, um Unternehmen dabei zu unterstützen, Ihre IT-Systeme abzusichern, wieder zum laufen zu bringen und Netzwerke, Anwendungen sowie Maschinen abzusichern.

Ist ein Cyberangriff eingetreten, besteht die Möglichkeit, einen Incident-Response anzumelden. Wird uns ein Incident-Response gemeldet, gehen wir im Anschluss wie folgt vor:

 

  • Vorbereitung: Sowohl die Anwender als auch die IT-Mitarbeiter müssen geschult oder in Kenntnis gesetzt werden, dass potenzielle Vorfälle passieren können.
  • Identifikation: Bestimmung, ob es sich bei einem Ereignis tatsächlich um einen Sicherheitsvorfall handelt.
  • Eindämmung: Den durch den Vorfall verursachten Schaden begrenzen und die betroffenen Systeme isolieren, um weiteren Schaden zu vermeiden.
  • Ausmerzung: Die Ursache oder den Auslöser des Vorfalls finden und die betroffenen Systeme aus der produktiven Umgebung entfernen.
  • Wiederherstellung: Betroffene Systeme wieder in die produktive Umgebung integrieren, nachdem sichergestellt ist, dass keine weiteren Bedrohungen bestehen.
  • Gewonnene Erkenntnisse: Vervollständigung der Vorfalldokumentation und Analyse.
  • Was können die Mitarbeiter und das Unternehmen aus dem Vorfall lernen? Auf diese Weise lassen sich künftige Reaktionen unter Umständen verbessern.

Erfahren Sie mehr zum Incident-Response>

Was passiert nach dem Incident-Response?

Ist der Incident-Response Fall abgeschlossen und IT-Systeme wiederherstellt, werden wir einen Penetrationstest durchführen um mögliche Sicherheitslücken zu schließen.

Dabei testen wir Ihre Systeme auf Schwachstellen und decken Sicherheitslücken so auf, wie Sie es von einem Angreifer erwarten würden. Wir sind in der Lage sie bei Cyberangriffen auf Netzwerke, Websites, Anwendungen, Webanwendungen, Anlagen und Maschinen sowie Endpunkte zu unterstützen.

[/vc_column_text][/vc_column_inner][vc_column_inner width=“1/12″][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row][vc_row][vc_column][/vc_column][/vc_row]