droptix hat geschrieben:Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren.
Auch Unternehmen sind vor Fehlern nicht gefeigt. Die Leute, die das Geld für Technik verwalten bzw. ausgeben, sind nämlich in den seltensten Fälle auch Leute, die wirklich Ahnung von Technik haben.
Tatsache ist schlichtweg, dass Script"schutz" nicht existiert. Ein "geschütztes" Script ist nicht sicherer als ein ungeschütztes. Der einzige Schutz gegen Missbrauch des Quellcodes ist das Gesetz. Dekompilierung und Reverse Engineering sind in Deutschland Urheberrechtsverstöße. Auf diesem Wege gewonnenes Wissen ist für Firmen nicht zu gebrauchen, es sei denn, sie wollen sich dem Vorwurf der Urheberrechtsverletztung aussetzen.
Zudem stellt sich die Frage, ob Code in Programmen wirklich schützenswert ist. Ideen äußern sich nicht so sehr im Quellcode wie in der äußeren Erscheinung. Beispiel Aero: Es sieht toll aus, aber wen interessiert schon der Code? Eine Aero-ähnliche Oberfläche kann man leicht nachprogrammieren, egal ob der Code nun geschützt ist oder nicht.
Der Schutz hat zudem auch noch eine weitere positive Eigenschaft: das Einschränken von Risiko. Die Hürde, um eine Sicherheitslücke im Programm zu finden, ist weitaus niedriger, wenn der Quellcode verfügbar ist.
Security by obscurity funktioniert nicht. Die wenigen Firmen, die noch immer daran glauben (z.B. Microsoft), werden regelmäßig von katastrophalen Lücken heimgesucht. Das liegt daran, dass nur die wenigsten Lücken direkt aus dem Quelltext ersichtlich sind. Das sind vor allem Buffer-Fehler und ähnliches, was durch die unsichere Verwendung von C-Standardfunktionen verursacht wird.
Diese Sicherheitslücken sollten es bei einem entsprechend modernen Entwicklungsprozess aber eigentlich gar nicht mehr in die Öffentlichkeit schaffen, da entsprechende Security-Tools existieren, mit denen man derartiges aufspüren kann. Auch braucht man den Quelltext nicht, um diese Lücken von außen aufzuspüren. Da reicht es schon, wenn man verdächtigen Stellen (z.B. Nutzereingaben) einfach ein bisschen experimentiert. Dann sieht man meist recht schnell, ob dort eine Sicherheitslücke verborgen sein könnte.
Zudem sind Programme in High-Level-Sprachen wie Python oder Java davon sowieso nicht wirklich betroffen, da Speicherallokation und Manipulation im Interpreter bzw. Jit-Compiler geschieht. Problematisch sind nur Lücken in der Runtime, auf die man aber wenig Einfluss hat.
Richtig schlimm sind Sicherheitslücken, die durch logische Fehler im Programm auftreten. Ein Beispiel ist z.B. die WMF-Lücke, die es ermöglichte, Code aus Bilddateien heraus auszuführen. Solche Lücken erkennt man aber gerade in komplexen Systemen nicht aus dem Quellcode.
Der umgekehrte Schluss, dass offener Code die Sicherheit erhöht, ist der richtige. Zum einen macht man damit professionellen Experten die Arbeit leichter, was die Chance erhöht, dass Lücken von der "guten" Seite gefunden und beseitigt werden, bevor sie von der "bösen" ausgenützt werden können. Zum anderen überträgt man damit das bewährte Kerckhoffs-Prinzip aus der Kryptographie auf Software: Sicherheit muss selbst dann garantiert werden, wenn dem Angreifer alles bekannt ist!
