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.