Ob erreichbar oder nicht: Schwachstellen sind gefährlich

Illustration: Lou Reade

Stellen Sie sich vor, Sie haben einen Teich im Garten mit einem Holzsteg. Eines Tages entdecken Sie beim Hinausgehen, dass ein Brett gesprungen ist. Es ist kurz davor, zu brechen. Sie müssen entscheiden: Reparieren Sie es oder lassen Sie es erst einmal liegen und kümmern sich später darum? Wenn nur Sie den Steg benutzen, ist das nicht unbedingt ein großes Problem. Sie wissen, dass das Brett kaputt ist, und werden darauf achten – sofern Sie daran denken. Aber was ist mit dem Rest Ihrer Familie? Oder mit Freunden, die zu Besuch kommen? Selbst wenn Sie alle informieren, gibt es keine Garantie, dass sich alle daran erinnern. Irgendwann wird jemand auf das Brett treten und ungewollt ein Bad nehmen. Es braucht nur eine Person und einen Schritt. Oft weist eine Bibliothek eine bekannte Schwachstelle auf. Doch solange die betreffende Website oder Anwendung keinen bestimmten Methodenaufruf verwendet, ist diese Schwachstelle nicht erreichbar. In diesem Fall wäre es verständlich, wenn Sie die Schwachstelle ignorieren – sie wirkt sich schlicht nicht auf Ihr aktuelles System aus. Doch entscheidend ist hier das Wort „aktuell“. Schwachstellen sind in der Regel nicht offensichtlich. Die anfällige Methode heißt schließlich nicht etwa „unsicher_nicht_verwenden“. Schwachstellen sind meist subtil. Eine Änderung Ihrer Einstellungen, ein harmlos wirkender Methodenaufruf – mehr braucht es nicht, um von sicher zu unsicher zu wechseln. Ob eine Schwachstelle heute erreichbar ist oder nicht, spielt eine Rolle, aber nicht so sehr, wie manche vielleicht denken. Bei der Priorisierung kann das durchaus ausschlaggebend sein. Wenn Sie zwei Schwachstellen beheben müssen und eine davon erreichbar ist, die andere nicht, priorisieren Sie die erreichbare. Doch auch die nicht erreichbaren Schwachstellen müssen Sie unbedingt schnell beheben. Bis dahin stellen sie eine Schwachstelle in Ihrer Anwendung dar, eine Lücke in der Rüstung. Es braucht nur eine Codeänderung durch einen Entwickler, damit sie ausnutzbar wird. Resilienz ist wichtig, und eine nicht erreichbare, aber nicht behobene Schwachstelle macht Ihr System unnötig anfällig. Ein Großteil der Sicherheitsarbeit ist reaktiv: Die Verteidiger versuchen, mit den unzähligen Angriffsmethoden Schritt zu halten, mit denen Angreifer ihre Systeme attackieren. Bekannte Schwachstellen, die in Ihrer Anwendung noch nicht erreichbar sind, sollten Sie nicht ignorieren. Vielmehr bieten sie Ihnen eine seltene Gelegenheit, einen Schritt voraus zu sein und alles abzusichern, bevor etwas schiefgeht. Angesichts all der Herausforderungen, denen wir uns beim Schutz unserer Websites und Anwendungen stellen müssen, sollten wir jede Gelegenheit nutzen, proaktiv für die Sicherheit unserer Entwicklungen zu sorgen.