Autor: Stefan

  • Teil 5 – Ausblick und weiterführende Ressourcen

    IDOR im Kontext von Broken Access Control IDOR ist ein Spezialfall von etwas Größerem: Broken Access Control. Während IDOR meist darum geht, dass man durch Manipulation einer ID fremde Daten sieht oder verändert, beschreibt Broken Access Control allgemein alle Schwachstellen, bei denen Autorisierungsprüfungen fehlen oder falsch umgesetzt sind. Das bedeutet: Wer IDOR versteht, hat schon…

  • Teil 3 – Wie man IDOR findet und testet

    Der erste Schritt: genauer hinschauen Um eine IDOR-Schwachstelle zu entdecken, braucht es keine Profi-Hacker-Skills. Alles beginnt damit, die Kommunikation zwischen Browser oder App und dem Server zu beobachten. Jede Aktion – sei es das Laden einer Profilseite, das Bearbeiten eines Dokuments oder das Abrufen einer Bestellung – erzeugt HTTP-Requests. Genau dort verstecken sich die Hinweise.…

  • Teil 5 – Ausblick und weiterführende Ressourcen

    Broken Access Control als Dauerbrenner Kaum eine Schwachstelle taucht so beständig in Sicherheitsberichten auf wie Broken Access Control (BAC). In den OWASP Top 10 steht sie seit Jahren ganz oben – zuletzt sogar auf Platz 1. Das zeigt: Auch wenn Entwickler*innen immer mehr über SQL-Injections, XSS und Co. wissen, ist die fehlerhafte Zugriffskontrolle nach wie…

  • Teil 1 – Was ist Broken Access Control?

    Türen ohne Türsteher Stell dir vor, ein Bürogebäude hat zwar viele Türen, aber niemand prüft, wer welche Räume betreten darf. Jeder, der einmal ins Gebäude kommt, kann plötzlich ins Chefbüro, ins Archiv oder in die Personalakte.Genau das passiert im digitalen Raum, wenn Anwendungen keine sauberen Zugriffskontrollen haben – und diese Schwachstelle trägt den Namen Broken…

  • Teil 1 – Was ist Injection?

    Ein einfacher Gedankentrick Stell dir vor, du gehst in ein Restaurant und bestellst: „Einmal Pizza Margherita.“ Der Kellner schreibt das auf. Alles normal.Jetzt stell dir vor, du sagst: „Einmal Pizza Margherita und öffne die Kasse.“ Der Kellner führt beides aus – weil er deine Bestellung nicht von echten Befehlen unterscheiden kann.Genau das ist Injection in…

  • Teil 5 – Schutzmaßnahmen & Best Practices

    Das gemeinsame Muster aller Injection-Arten Ob SQL, Command, NoSQL, Template oder LDAP Injection – das Grundproblem ist immer gleich: Nutzereingaben werden nicht als Daten behandelt, sondern als Befehle interpretiert.Die wichtigste Lehre lautet also: Trenne strikt zwischen Daten und Code. Parametrisierung ist der Goldstandard Die sicherste Methode gegen Injection ist die Verwendung von parametrisierten Abfragen oder…

  • Teil 2 – SQL Injection (SQLi)

    Der Klassiker unter den Web-Schwachstellen SQL Injection gehört zu den bekanntesten und gefährlichsten Sicherheitslücken überhaupt. Bereits seit Ende der 1990er-Jahre taucht sie in Angriffen auf – und bis heute findet man sie in modernen Web-Apps, APIs und sogar mobilen Anwendungen. Der Grund: SQL-Datenbanken sind das Rückgrat vieler Systeme, und fehlerhafte Abfragen öffnen Hackern Tür und…

  • Teil 5 – Ausblick und weiterführende Ressourcen

    Insecure Design bleibt ein Dauerproblem Insecure Design ist nicht so „sichtbar“ wie ein klassischer Bug – kein Syntaxfehler, keine offene Datenbank. Es ist subtiler: Die Lücken stecken im Bauplan selbst.Genau deshalb bleibt es ein Dauerproblem: Solange Teams Sicherheit nur als „Add-on“ betrachten, schleichen sich falsche Annahmen in Architektur und Prozesse ein. Häufige Missverständnisse Bei Insecure…

  • Teil 1 – Was ist Insecure Design?

    Ein Haus mit falschem Bauplan Stell dir vor, du planst ein Haus. Die Türen sind stabil, die Fenster sind sicher, aber der Architekt hat vergessen, eine Wand zwischen Garage und Schlafzimmer einzuzeichnen. Egal wie solide die Handwerker später bauen – jeder, der durch die Garage kommt, steht plötzlich direkt im Schlafzimmer.Genau so ist es mit…

  • Teil 2 – Typische Fehler bei der Transportverschlüsselung

    Wenn Daten auf der Reise abgehört werden Stell dir vor, du schickst einen Brief mit wichtigen Informationen – aber statt ihn zu versiegeln, steckst du ihn einfach offen in den Umschlag. Jeder Postbote kann mitlesen.Genauso unsicher ist es, wenn eine Anwendung sensible Daten ohne Transportverschlüsselung überträgt. HTTP statt HTTPS Noch immer gibt es Login-Seiten oder…