Auf TechEd Europe 2012 hielt Aaron Margosis von Microsoft eine Session mit diesem reißerischen Titel. Dabei geht es vor allem darum, alte Web-Applikationen (Legacy Apps) sicher zu machen und sicher zu betreiben. Die Session-Beschreibung ist auf der TechEd Website hier zu finden.
Die Session mit den Tags Security & Identityadressiert IT-Verantwortliche LOB-Apps sicher zu machen. Hier wurden nicht die üblichen Top-Web-Sicherheitslöcher wie Cross Site Scripting und SQL Injection & Co betrachtet, sondern Sicherheits-Themen, die weniger bekannt sind.
Aaron empfiehlt gleich zu Beginn einige Literatur für Developer:
24 Deadly Sins, Writing Secure Code, etc.
Die folgende Grafik zeigt eine Statistik der häufigsten bekannten Angriffe in verschiedenen Software-Applikationen. Interessant.
Hier einige wichtige Themen zur Prüfung von Legacy-Websites, Apps und Browser-Settings im eigenen Unternehmen:
Java Runtime-Problem: Frameworks, die side-by-side (also in verschiedenen Versionen) auf einer Windows Maschine laufen können, laufen in Gefahr nie mehr gepatcht zu werden. Man stelle sich ein Windows System vor, das seit 2 Jahren nicht mehr gepatcht wurde… heutzutage undenkbar.
142 separate Vulberabilities in JRE. Unbedingt Patches einspielen (sollte recht problemlos sein – aber danach Apps testen; wie gewohnt). Ich habe selten einen Speaker von Microsoft so viel über Java sprechen gehört.
regedit /s ie-settings.reg – alte Unternehmens-IE Settings weiter zu übernehmen ist ein Risiko (vor allem ist das REG File nicht selbsterklärend).
IE Zone Analyzerist ein tolles Tool zur Anzeige und Vergleichen von Internet Explorer Einstellungen.
Protected Mode (gibt es seit IE7) ist in Intranet und Trusted Sites aus, an in Internet Umgebungen – PM nicht umgehen oder ausschalten!
VMMap – Sysinternals- Tool zur Prüfung von Buffer Overruns in Software.
ActiveX (baut auf COM und OLE auf). IE verwendet ein “plug-in” Model zur Ausführung solcher Komponenten. Bei IE7 musste der User entscheiden, ob die ActiveX Komponente ausgeführt werden soll oder nicht – auch keine gute Lösung.
Nicht für Scripting sicher: Microsoft Word, Windows Scripting Host, … nicht verwenden!
Wie können Sicherheitslöscher gefixt werden?
Beispielsweise SiteLocks, durch Logik in custom functions kapseln, Office-Dokumente am Server ohne Automation erzeugen, ActiveX vermeiden. etc.
Falls es unbedingt ein ActiveX sein muss: C++ oder VB6 (ernst gemeint).
Aaron zeigte sogar eine Demo mit VB6 (ui, ist das alt: aus 1998) und PowerShell Script.Natürlich gilt: Wenn möglich moderne Technologien verwenden, klar.
Weitere Ressourcen für Developer:
www.microsoft.com/twc
www.microsoft.com/security
www.microsoft.com/privacy
www.microsoft.com/reliability
In diesem Sinne: Die unsicheren Apps (Zeiten) sind vorbei. Die Session zeigte einige Punkte, die es in alten Web-Applikationen zu beachten gilt: Developer müssen (alte) Funktionen sicher machen bzw. umbauen. Nichts Neues. Aber auch wichtig.