Jaap Karan Singh ist Director of Customer Strategy, Chief Singh und ein Mitbegründer von Secure Code Warrior. Nach Sicherheitstests bei BAE Systems in Australien wechselte Jaap vom Hacken von Webanwendungen zur Schulung von Entwicklern, wie sie ihre eigenen Anwendungen schützen können. Jaap entwirft und implementiert die gesamte Kundenstrategie, die Customer Success, Renewals, Support, Ops und Customer Marketing umfasst.
Von Sydney aus hat Jaap Schulungen zu Software-Sicherheitskonzepten durchgeführt und Workshops bei führenden Finanz- und Telekommunikationsunternehmen auf der ganzen Welt geleitet. Er ist spezialisiert auf Javascript-Technologien wie HTML5, Node, Express und Mongo.
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher werden, in die Anwendung einzudringen. jIn diesem Beitrag erfahren Sie, was die Preisgabe von Informationen ist, warum sie gefährlich ist und wie Sie sie verhindern können.
Die überwiegende Mehrheit der Websites verwendet XML-Datenbanken, um kritische Funktionen auszuführen, wie z.B. das Speichern von Benutzeranmeldeinformationen, Kundendaten, persönlichen Identitätsinformationen und vertraulichen oder sensiblen Daten, wodurch XQuery-Angriffe eine ziemlich große Angriffsfläche haben.
Code-Injection-Angriffe gehören zu den häufigsten und auch gefährlichsten Angriffen, denen viele Websites und Anwendungen ausgesetzt sind. Sie variieren sowohl in Bezug auf die Raffinesse als auch auf die Gefahr, die von ihnen ausgeht, aber fast jede Website oder Anwendung, die Benutzereingaben akzeptiert, kann anfällig sein.
Im Gegensatz zu vielen anderen Schwachstellen erfordert das Ausnutzen lokaler Dateieinschluss- und Pfadüberquerungsprozesse für schändliche Zwecke einen ausreichend geschickten Angreifer, eine gehörige Portion Zeit und vielleicht auch ein bisschen Glück.
Es ist üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Und die meisten Leute denken dabei nicht einmal an ein potenzielles Sicherheitsrisiko.
Probleme können auftreten, wenn böswillige Benutzer eine LDAP-Abfrage manipulieren können. Dadurch kann der empfangende Server dazu gebracht werden, ungültige Abfragen auszuführen, die normalerweise nicht erlaubt wären, oder sogar ungültigen oder unsicheren Benutzern ohne Kennwort Zugang auf hoher Ebene oder als Administrator zu gewähren.
Angreifer nutzen SQL-Injection - eine der ältesten (seit 1998!) und lästigsten Datenschwachstellen, die es gibt - um sensible Informationen zu stehlen und zu verändern, die in Millionen von Datenbanken auf der ganzen Welt vorhanden sind.
In vielerlei Hinsicht ist die Sicherheitslücke bei der Einbindung entfernter Dateien viel gefährlicher und auch leichter auszunutzen als ihr Gegenstück bei lokalen Dateien. Als solche sollte sie so schnell wie möglich gefunden und behoben werden.
Unzureichende Protokollierung und Überwachung ist eine der gefährlichsten Bedingungen, die innerhalb der Verteidigungsstruktur einer Anwendung bestehen können. Wenn diese Schwachstelle oder Bedingung existiert, dann wird fast jeder fortgeschrittene Angriff, der gegen sie durchgeführt wird, letztendlich erfolgreich sein.
Sensible Daten liegen immer dann vor, wenn Informationen, die nur für eine autorisierte Ansicht bestimmt sind, in unverschlüsseltem, ungeschütztem oder schwach geschütztem Zustand einer nicht autorisierten Person zugänglich gemacht werden.
Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig abgesichert haben, kann die Kommunikation bei unzureichendem Schutz der Transportschicht immer noch anfällig für Schnüffeleien sein.
Wenn Sie eine Geschäftsanwendung erstellen, sei es für den internen Gebrauch oder die externe Nutzung durch Ihre Kunden, lassen Sie wahrscheinlich nicht jeden Benutzer jede einzelne Funktion ausführen. Wenn Sie das tun, sind Sie möglicherweise anfällig für eine fehlerhafte Zugriffskontrolle.
Cross-Site-Scripting (XSS) nutzt das Vertrauen von Browsern und die Unwissenheit der Benutzer aus, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr hässlich werden kann. Lassen Sie uns einen Blick darauf werfen, wie XSS funktioniert, welchen Schaden es anrichten kann und wie man es verhindern kann.
Die Codierung einer Website oder Anwendung mit der Möglichkeit, nicht validierte Um- und Weiterleitungen zu verarbeiten, kann sowohl für Ihre Benutzer als auch für Ihr Unternehmen extrem gefährlich sein.
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und den einfachen Umgang mit unstrukturierten Daten zu leugnen, aber mit der zunehmenden Verbreitung kommen unweigerlich auch mehr Schwachstellen ans Tageslicht.
Eine direkte Objektreferenz liegt vor, wenn ein bestimmter Datensatz (das "Objekt") innerhalb einer Anwendung referenziert wird. Er hat normalerweise die Form eines eindeutigen Bezeichners und kann in einer URL erscheinen.
Eine unsichere Deserialisierung kann immer dann auftreten, wenn eine Anwendung die zu deserialisierenden Daten als vertrauenswürdig behandelt. Wenn ein Benutzer in der Lage ist, die neu rekonstruierten Daten zu ändern, kann er alle Arten von böswilligen Aktivitäten wie Code-Injektionen, Denial-of-Service-Angriffe oder die Erhöhung seiner Privilegien durchführen.
Wir werden eines der häufigsten Probleme behandeln, mit denen Organisationen konfrontiert sind, die entweder Websites betreiben oder Mitarbeitern den Fernzugriff auf Computerressourcen erlauben - was so ziemlich jeder ist. Und ja, Sie haben wahrscheinlich erraten, dass wir über Authentifizierung sprechen werden.
XML-Injection-Angriffe sind fiese kleine Exploits, die von Hackern erfunden wurden, um Systeme zu kompromittieren, die XML-Datenbanken hosten. Dazu gehören die Dinge, die einem in den Sinn kommen, wenn man an traditionelle Datenbanken denkt - detaillierte Informationsspeicher über alles Mögliche, von Medikamenten bis zu Filmen.
Da ich auf beiden Seiten des Zauns gestanden habe, kenne ich nur zu gut die Spannungen, die zwischen dem Entwicklungsteam und den AppSec-Spezialisten entstehen können, wenn es um die Einhaltung von Best Practices im Bereich Sicherheit geht. Es gibt jedoch einen besseren Ansatz.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter und lukrativer Angriffsvektor.
Wenn ein Angreifer einen CR- oder LF-Code in eine bestehende Anwendung einfügen kann, kann er manchmal deren Verhalten ändern. Die Auswirkungen sind im Vergleich zu den meisten Angriffen weniger leicht vorherzusagen, können aber nicht weniger gefährlich für die Zielorganisation sein.
Wenn eine Anwendung keine ausreichenden Anti-Automatisierungsprüfungen hat, können Angreifer einfach so lange Passwörter erraten, bis sie eine Übereinstimmung finden. Hier erfahren Sie, wie Sie sie aufhalten können.
OS-Befehlsinjektionsangriffe können von Einsteigern und weniger erfahrenen Hackern durchgeführt werden, was sie zu einer der häufigsten Schwachstellen macht, die Sicherheitsteams erfahren. Zum Glück gibt es einige sehr wirksame Möglichkeiten, diese Angriffe zu verhindern.
Es ist wirklich erstaunlich, dass viele Unternehmen immer noch auf Klassenzimmer, trockene Lehrbücher und langweilige Videotrainings setzen, um ihre besten und klügsten Köpfe mit neuen Initiativen vertraut zu machen, vor allem, wenn es eine viel bessere, ansprechendere und wertvollere Art des Lernens gibt: kontextbezogenes Training.
Da alle Anwendungen Komponenten verwenden, von denen Sie die meisten nicht geschrieben haben, können Schwachstellen in den von Ihnen verwendeten Komponenten zu Verbindlichkeiten werden. Lassen Sie uns besprechen, was die Verwendung von Komponenten mit bekannten Schwachstellen bedeutet, wie gefährlich sie ist und wie man sie beheben kann.
