Sichere Web-Apps: Zehn Tipps für den Code Review

Von: Computerwoche / Dr. Bruce Sams, Optima Business Information Technology GmbH

Schlüsselfertige Tools für Code Reviews gibt es nicht. Wer sichere Anwendungen entwickeln will, sollte zehn Best Practices beachten.

Zahlreiche erfolgreiche Angriffe gegen Schwachstellen in Anwendungen haben gezeigt, dass die meisten IT-Sicherheitslücken in der Anwendungsentwicklung verwurzelt sind. Durch unachtsame Programmierung, schlechtes Design oder schlichtes Unwissen werden jedes Jahr unzählige Zeilen gefährlicher Programmtexte geschrieben, die dann zu Sicherheitsproblemen führen. Die Schlussfolgerung ist klar: Wenn ein Unternehmen sichere Software haben will, muss es zuerst die Sicherheit des Codes garantieren. Die beste Möglichkeit hierfür ist ein Code Review.

Dies ist besonders relevant für Web-Anwendungen, bei denen rechtliche Vorgaben eine Rolle spielen: Code Reviews sind jetzt vom Standard PCI-DSS, der für den sicheren Umgang mit Kreditkarten sorgen soll, verpflichtend vorgesehen. Abschnitt 6.6 dieses Standards legt fest, dass kreditkartenverarbeitende Software entweder durch einen Code Review oder durch die Installation einer Web-Application-Firewall gesichert werden muss.

Daher wundert es nicht, dass die Nachfrage nach Code Reviews, entsprechender Expertenberatung und zugehörigen Tools steigt. Angesichts der allgemeinen Notwendigkeit sicherer Anwendungen und konkreter rechtlicher Vorgaben gehören Code Reviews mittlerweile zur Anwendungsentwicklung vieler Unternehmen.

Tool-Unterstützung im Trend

In seiner einfachsten Form liefert ein Review eine Liste der im Code erkannten Probleme, die zur Qualitäts- und Sicherheitsverbesserung des Codes verwendet werden kann. Die Untersuchung des Codes kann verschiedene Ziele haben, so zum Beispiel die Einhaltung des Programmdesigns oder die Erkennung von Flaschenhälsen, die zu Performance-Verlusten führen. Außerdem sind Reviews eine ausgezeichnete Möglichkeit, um die Sicherheit des Codes zu überprüfen.

Reviews, die nur auf visueller Inspektion des Codes basieren, sind sehr zeitaufwendig - auch die erfahrensten Reviewer können nur ungefähr 100 Codezeilen pro Stunde analysieren, so dass schon für die Überprüfung einer mittelgroßen Anwendung mit 20.000 Zeilen rund 200 Stunden benötigt werden, und das ohne Dokumentation, Korrektur etc. Daher geht der Trend stark zu Tool-gestützten, formalisierten Reviews, die sich wiederholt auf große Codemengen anwenden lassen.

Die besten automatischen Review-Tools erkennen häufige Programmierprobleme wie Endlosschleifen, Null-Pointer-Exceptions, fehlende Methoden oder den ungenügenden Gebrauch von Thread-Synchronisierung sehr gut. Auch bei Architekturproblemen sind sie relativ zuverlässig. Die Aufdeckung von Sicherheitsproblemen stellt jedoch eine schwierige und komplexe Aufgabe dar. Die aktuelle Generation der Code-Review-Tools kann Sicherheitsschwachstellen wie Cross Site Scripting oder SQL-Injection erkennen, zwei der häufigsten und gefährlichsten Schwachstellen in Web-Anwendungen. Sicherheitsprobleme, die auf Umgehung der Business-Logik beruhen, entdecken die Tools aber meist nicht.

Die meisten Werkzeuge sind in Entwicklungsumgebungen integrierbar, verfügen über Ticketing- und Bug-Tracking-Systeme, können mit zentralen Code Repositories verbunden werden und erstellen Management-Reports mit farbigen Grafiken. Um einen Nutzen aus den Ergebnissen zu ziehen, müssen diese aber von einem kompetenten Experten interpretiert und verstanden werden (Motto: "A Fool with a Tool is still a Fool!"). Die Folgerung ist, dass ein professioneller Review automatische und manuelle Analyse kombiniert. Der menschliche Beitrag wird gebraucht, da sogar die besten Tools manchmal unsinnige oder falsche Ergebnisse liefern. Nur ein Experte kann die Spreu vom Weizen trennen.

Code Review - Tipp 1 bis 5

1. Gute Behandlung von False Positives

False Positives sind Befunde, denen keine tatsächlichen Schwachstellen im Quelltext entsprechen. Egal was die Hersteller behaupten, alle Tools produzieren solche Falschmeldungen, die zu einer erheblichen Last für die Entwickler werden können. Programmierer, die mit vielen False-Positive-Meldungen konfrontiert werden, kommen kaum mehr zum Arbeiten, da sie mit dem vergeblichen Bemühen beschäftigt sind, nichtexistente Fehler zu korrigieren.

 

2. Passende Integration

Die gängigen Tools lassen sich gut in verbreitete Entwicklungsumgebungen (IDEs) integrieren. Benutzt man Eclipse oder Visual Studio, gibt es keine Probleme mit der nahtlosen Anbindung. Bei weniger verbreiteten IDEs wie Netbeans sind die Möglichkeiten der Tool-Integration allerdings schon beschränkter. Ähnliches gilt für Code-Repositories wie Subversion und Clear Case.

 

3. Tools können den Projektlauf beeinflussen

In Features und Prozessen unterscheiden sich Tools gewaltig. Wählen Sie also sorgfältig aus, denn die meisten Tools folgen einer bestimmten Arbeitsweise oder erzwingen sie sogar. Das beeinflusst stark, wie man Software schreibt, testet und korrigiert. Obwohl alle Tools in der Regel den Phasen Erkennung, Analyse und Korrektur folgen, gibt es Unterschiede in der Funktionsweise dieser Phasen.

 

4. Überlasten Sie die Entwickler nicht

Zu viele Informationen sind fast genauso schlecht wie zu wenige. Wenn ein Tool einen Entwickler mit gegenstandslosen Informationen überschüttet - auch wenn diese im Einzelnen interessant sein mögen -, leidet darunter die Produktivität, und das hat einen negativen Einfluss auf das Entwicklungsprojekt. Reduzieren Sie unnötige Nebengeräusche: Die erfolgreiche Integration eines Tools in den Softwareentwicklungs-Zyklus erfordert die richtige Balance zwischen Informationen aus dem Tool und Freiräumen für Ihr Entwicklungsteam, damit es seine Arbeit machen und gleichzeitig sicheren Code schreiben kann.

 

5. Mit einer langen Einarbeitungsphase rechnen

Um Code Reviews sinnvoll und effektiv in die Entwicklung zu integrieren, braucht man Erfahrung, die Sie am Anfang nicht haben. Deshalb sollte für diese Arbeit der Hersteller oder ein kompetenter Partner herangezogen werden. Ob mit oder ohne externe Unterstützung, werden Sie wahrscheinlich viel Zeit brauchen, bis der Prozess und die Konfiguration des Tools sitzen und die Entwickler alles akzeptiert haben. Die Aufwände für die Konfiguration eines Tools und die Veränderungen im Projektlauf sollten nicht unterschätzt werden.

Code Review - Tipp 6 bis 10

6. Reviews besser in Intervallen oder kontinuierlich?

Ob ein Code Review kontinuierlich, zum Beispiel im Rahmen eines Nightly Build, oder nur zu bestimmten Zeitpunkten (monatlich oder zu bestimmten Meilensteinen) vorgenommen werden soll, ist eine grundlegende strategische Entscheidung. Der Großteil der Herstellerliteratur bevorzugt eine kontinuierliche Strategie, aber dies muss nicht unbedingt besser sein. Praktische Erfahrung zeigt, dass es oft effektiver ist, Code Reviews in bestimmten Intervallen zu planen, die Ergebnisse dann zu sortieren und auf False Positives zu untersuchen, bevor die Entwickler mit Korrekturmaßnahmen beauftragt werden. Dies hat viele Vorteile, nicht zuletzt eine geringere Belastung der Entwickler. Das passende Intervall hängt von der Größe und Komplexität des jeweiligen Projekts ab. Es sollte jedoch mindestens zwei Reviews geben, je eines im ersten und im letzten Drittel der Entwicklung.

 

7. Code Review oder Penetrationstest?

Was ist besser - ein Code Review oder ein Penetrationstest? Diese Frage lässt sich nicht pauschal beantworten, denn beide Techniken sind komplementär und überschneiden sich. Es gibt Probleme, die nur im Penetrationstest oder nur im Code Review ans Licht kommen. Um die höchste Anwendungssicherheit zu gewährleisten, sollte man im Idealfall beide Verfahren nutzen.

 

8. Versteckte Kosten

Die Lizenzkosten für viele Code-Review-Tools können schnell die Hunderttausend-Euro-Grenze überschreiten. Dazu kommen die Kosten für Training, Wartung und die Aufstellung eines Teams, das in der Lage ist, einen Code Review schnell und effektiv zu unterstützen.

 

9. Setzen Sie auf ein unabhängiges Review-Team

Obwohl ein Tool theoretisch neutral ist, profitiert der Code Review erheblich von der Ausführung durch unabhängige Auditoren, die den Code nicht geschrieben haben. Dies gehört im Allgemeinen zur Best Practice. Es gibt einen weiteren Beweggrund für ein unabhängiges Team: Wenn Sie einen Code Review einsetzen, um PCI-DSS-Compliance zu erlangen, dann muss das Review-Team unabhängig sein. Die eigene Entwicklungsmannschaft und andere interne Experten sind das kaum.

 

10. Inhouse oder extern?

Kosten und Aufwand für ein komplettes internes Programm können beträchtlich sein. Deshalb ist oft die Einbindung eines externen Anbieters, der über Fachwissen, Tools und Personal verfügt, der effektivere und günstigere Weg zum Code Review. Ein externer Anbieter ist auch neutral und kann die Feinheiten komplexer Tools gut ausnutzen, um die relevanten Punkte in einer möglicherweise enormen Menge an entdeckten "Fehlern" zu finden und zu präsentieren. (ue)

 

Quelle: http://www.computerwoche.de/security/1911699/

---