Mit Xamarin positioniert sich Microsoft mit einer Plattform, die es Entwicklern ermöglicht, iOS-, Android- und Windows-Anwendungen mit Hilfe von .NET zu erstellen. .NET als einheitliche Basis bietet interessante Entwicklungsansätze, speziell mit Xamarin.Forms, weshalb Xamarin gerne als Cross-Plattform-Technologie angesehen wird.

Der Beitrag soll aufzeigen, wieso es sich lohnen kann, Xamarin als Framework für neue Projekte in die Auswahl miteinzubeziehen. Dabei richtet er sich insbesondere an diejenigen, die sich mit der Entwicklung einer mobilen App beschäftigen und vor der Auswahl einer Technologie stehen.

Woher kommt Xamarin?

Xamarin ist mit der Übernahme durch Microsoft fester Bestandteil der .NET-Familie geworden und adressiert hier strategisch den Mobile-App-Markt, speziell Android und iOS als die gängigsten mobilen Betriebssysteme. Die Idee hinter der Plattform ist es, C#-Entwicklern die Entwicklung von Mobile Apps zu ermöglichen und die Stärken des .NET-Ökosystems zu nutzen.

Xamarin bietet Wrapper für plattformabhängige Befehle an, so dass diese auch in C# genutzt werden können. Die plattformunabhängige Code-Basis kann so leicht von den plattformabhängigen Befehlen getrennt werden, so dass diese dann für mehrere Plattformen gleichzeitig genutzt werden kann.

In Xamarin.Forms werden darüber hinaus auch die UI-Beschreibungen plattformunabhängig realisiert, so dass auch diese nur einmal erstellt werden müssen. Die Standard-Bedienelemente wie Textfelder, Buttons oder Radiobuttons und UI-Layouts sind in einheitlichem Markup gebündelt. Das Framework übersetzt diese dann in konkrete, native UI entsprechend des Betriebssystems, für das das App-Paket gebaut wird. Xamarin (wird auch als Xamarin Native bezeichnet) und Xamarin.Forms sind damit unterschiedliche App-Modelle.

Eine UI für alle Plattformen

Xamarin.Forms abstrahiert nicht nur die App-Logik, sondern vereinheitlicht auch die Benutzeroberfläche.
Indem das Aussehen üblicher UI-Elemente einmalig durch Templates, Styles und Ressourcen beschrieben wird, erscheint die App rasch in einheitlichem Design.

Vorgegebene Style-Guides, die das Corporate Design abbilden, können in XAML einmal definiert und überall verwendet werden. Änderungen an den Unternehmensrichtlinien sind im XAML daher direkt auf alle betreffenden UI-Komponenten angewendet. Auch die Integration des immer beliebter werdenden Dark Modes geht so einfach von der Hand.

Das beschleunigt die initiale Entwicklung, hilft aber auch, auf Änderungswünsche zügig reagieren zu können.

Xamarin ist Enterprise-ready

Apps sollen zwar einfach sein, sie können aber mit der Zeit recht schnell komplex werden. Daher muss von Beginn an auf eine gute Erweiterbarkeit und Modifizierbarkeit geachtet werden. Mit der Verwendung des Model-View-ViewModel¹ (MVVM) Patterns ist es möglich, die Programmlogik strikt vom UI-Code zu trennen.

Die konsequente Einhaltung der Struktur ermöglicht automatisierte Komponententests, um die korrekte Programmfunktionalität sicherzustellen. Das wiederum reduziert den manuellen Testaufwand erheblich.

Xamarin.Forms wurde lange Zeit nachgesagt, dass es eher für Prototypen oder nur einfache Apps geeignet ist. Diese Zeiten sind aber vorbei. Xamarin.Forms ist mittlerweile so ausgereift, dass es auch bei komplexen Apps eingesetzt werden kann.

Nutzersicht

Alternativlösungen wie PhoneGap² oder Cordova³ bilden eine Webseite innerhalb eines Web-View-Containers ab. Was aus Entwicklersicht vielversprechend sein mag, nämlich eine bereits existierende Webseite innerhalb einer App anzubieten, stört die Nutzerfreundlichkeit.

Hierbei punktet Xamarin damit, wie die App schlussendlich auf dem Mobilgerät angezeigt wird: Der geschriebene Code wird als native App ausgeliefert. Die Bedienelemente werden dabei in die plattformspezifischen Komponenten gerendert.

Der OS-spezifische Look & Feel bleibt bestehen und kommt besser beim Endnutzer an, da er seine eingeprägten Klicks und Gesten einsetzen kann.

Community & Third-Party

Auch Xamarin kann nicht alle Problemstellungen adressieren und so spielt für die Entscheidung pro oder contra Xamarin natürlich auch die Erweiterbarkeit mit Third-Party-Libraries eine wichtige Rolle.

Xamarin als Framework profitiert von der Übernahme durch Microsoft und erhält dadurch mehr Aufmerksamkeit. Vergleichsweise klein ist aber die Community gegenüber Alternativen wie React Native.

Deshalb ist die Auswahl an Third-Party-Libraries, die Lösungen speziell für Xamarin-Apps bieten, nicht so zahlreich wie bei alternativen Lösungen im JavaScript-Umfeld.

Es sollte also schon im Vorfeld geprüft werden, ob benötigte Libraries existieren. Mit .NET als Basis gibt es jedoch auch Zugriff auf eine Vielzahl von NuGet-Paketen für alle möglichen Szenarien. Einige wenige Firmen haben sich auch auf die Erstellung von Xamarin UI- und Bedienelementen spezialisiert.

Einstieg in Xamarin

Verfügbares Know-how sollte bei der Technologie-Auswahl definitiv berücksichtigt werden, aber auch Xamarin-Neueinsteigern fällt der Beginn denkbar einfach: Die App-Logik wird in C# entwickelt und basiert auf dem etablierten .NET Framework.

Für die Darstellung der Oberflächen wird in Xamarin.Forms die deklarative Markup-Sprache XAML – die eXtensible Application Markup Language – verwendet.

XAML ist keine Exklusivtechnik von Xamarin, sondern findet bereits jahrelang Anwendung in der .NET-Welt. Gängige Steuerelemente und Layouts entstammen aus WPF und unterstützen daher auch in Xamarin vollumfängliche Features wie Data-Binding und die Referenzierung appinterner Komponenten.

Wer bereits durch WPF mit XAML vertraut ist, wird also sehr schnell die App-Entwicklung mit Xamarin meistern.

Einen vollwertigen, visuellen XAML-Designer für die Xamarin-Entwicklung gibt es gegenwärtig nicht, jedoch wurde die Developer Experience mit der Einführung von Hot-Reload⁴ deutlich verbessert. Mit Hot-Reload werden Änderungen am User Interface an der laufenden Applikation angewendet, was die Entwicklungsdauer stark verringert.

Entwickleraufwand

Abzuwägen ist vor allem auch der finanzielle Aspekt, der im Bereich der Entwicklung mit Xamarin fällig wird. Für Visual Studio fallen Lizenzkosten an, gegebenenfalls ist jedoch die kostenfreie Community-Edition ausreichend. Die Standard-Entwicklungsumgebungen für native Apps – Android Studio und Apples XCode – sind kostenfrei.

Teams, die bereits in der .NET-Welt unterwegs sind, verfügen sicherlich bereits über eine Lizenz von Visual Studio oder nutzen die Rider IDE von JetBrains. Für .NET-Entwicklerteams ist daher nicht mit zusätzlichen Lizenzkosten zu rechnen. Besteht das Entwicklerteam vor allem aus .NET Entwicklern, sind auch erheblich weniger Schulungskosten notwendig, da keine neuen Programmiersprachen (Android: Java oder Kotlin; iOS: ObjectiveC oder Swift) erlernt werden müssen.

In der nativen App-Entwicklung kommen zwei verschiedene Entwicklungsumgebungen mit unterschiedlichen Tools zum Einsatz. Apples XCode und Android Studio sind zwar kostenfrei, die Werkzeuge verlangen aber unterschiedliche Bedienung.

Üblicherweise ist die Entwicklung nativer Apps für mehrere Plattformen nicht einem Entwickler zuzumuten, daher ist hier mit höheren Personalkosten für zwei oder mehrere Entwickler auszugehen.

Auch perspektivisch sind mehrere Entwickler für die Pflege und Weiterentwicklung der nativen Apps einzukalkulieren. Unterschiedliche Implementierungen der Funktionalitäten bergen umso mehr Fehlerpotentiale.

Die Vereinheitlichung der Funktionalitäten in Xamarin reduziert den Aufwand gegenüber der nativen Entwicklung.

Ausgaben und Aufwand in der Vergangenheit sollten sicherlich auch beachtet werden: Bestehender und wiederverwendbarer Code sollte in der Auswahl der Technologie berücksichtigt werden.

Von Xamarin.Forms zu .NET MAUI

Microsoft plant für Ende 2021 die Veröffentlichung von .NET MAUI (.NET Multi-Platform App UI). Hierbei handelt es sich um eine Weiterentwicklung von Xamarin.Forms, in der neben Android-, iOS- und Windows- auch macOS-Anwendungen mithilfe des Frameworks entwickelt werden können.

Ziel ist es also, mehr Zielplattformen ansprechen zu können, die Xamarin-Technologie nachhaltig für die Zukunft zu rüsten und noch mehr Vereinheitlichung zu schaffen.

Bei MAUI gibt es daher nur noch ein einziges Projekt, statt einem Hauptprojekt, sowie für jede Zielplattform ein weiteres. Populäre Design Patterns und Funktionen werden noch besser integriert. Hot-Reload reagiert beispielsweise dann auch auf Änderungen an der Code-Logik.

Trotz Änderungen an der Projektstruktur wird der Migrationsprozess zu MAUI leicht zu bewältigen sein. Bis dahin kann deshalb weiterhin Xamarin.Forms zum Einsatz kommen.

Fazit

Xamarin ist keine Hybrid-Lösung für mobile Apps auf Basis von Webtechnologien. Vielmehr bekommen wir native Apps, die aus einem einheitlichen Crossplattform-Projekt entstehen.

Wer sich für ein App-Framework entscheiden muss und bereits Expertise in .NET-Technologien mitbringt, sollte Xamarin in Erwägung ziehen.

Darüber hinaus sollte geprüft werden, ob Bestandscode eingebracht werden kann: technisches Know-how und bestehende Logik weiterzuverwenden ergibt hier überaus Sinn.

Besonders geeignet zeigt sich Xamarin, wenn eine schnelle Auslieferung wichtiger ist als die Komplexität der App im ersten Schritt. Speziellere Features, die plattformabhängig implementiert werden müssen, lassen sich trotzdem noch im weiteren Verlauf einbauen.

Perspektivisch gesehen ist es empfehlenswert, die Applikation von Beginn an auf Xamarin.Forms aufzubauen. So fällt der Umstieg auf MAUI einfacher.

¹ https://docs.microsoft.com/de-de/xamarin/xamarin-forms/enterprise-application-patterns/mvvm

² https://de.wikipedia.org/wiki/Adobe_PhoneGap

³ https://cordova.apache.org

⁴ https://docs.microsoft.com/de-de/xamarin/xamarin-forms/xaml/hot-reload

Der Beitrag Xamarin – eine gute Wahl? erschien zuerst auf EXXETA BLOG.

Zu testen war eine digitale Plattform, die einen Produktpreis sowie einen Rabattfaktor mit vertretungsberechtigten Personen verknüpft, sodass diese Personen dann mit den verknüpften Daten ein Geschäft abschließen können. Dem Auftragnehmer wird durch die verifizierte Identität des Käufers die Möglichkeit geboten, seine Zahlungsbedingungen mittels des Rabattfaktors anzupassen.

Wir starteten also mit dem Test und verschafften uns zunächst einen Überblick über offene Ports und eventuell auffindbare Verzeichnisse, aber hier war alles in Ordnung. Anschließend versuchten wir, über eigentlich nicht zulässige HTTP-Methoden auf URLs eigene Daten ins System zu bringen – auch das schlug fehl.

Also nahmen wir die Aufrufe beim Verifizieren der Daten gegenüber dem Shop-Betreiber genauer unter die Lupe. Der prinzipielle Ablauf gestaltet sich wie folgt:

Die Einbindung der Kunden-API erfolgt über ein Javascript-SDK. Dort wird ein Objekt erzeugt, welches einen Eventhandler für den Abschluss des Vorgangs im “Kunden UI” besitzt, sodass die API den Shop-Betreiber benachrichtigt, wenn die Informationen freigegeben werden oder nicht.

Um die Anwendung sicher zu machen, setzt das Entwicklungsteam auf JWT, sodass die Daten jeder Anfrage signiert werden können. Das sah konkret dann so aus:

Man sieht, dass ein JWT mitgesendet wird, welches dieselben Daten aus den Parametern price und discount in signierter Form enthält. Dementsprechend beschränkt waren die Angriffsmöglichkeiten, da die JWT selbst korrekt implementiert waren. Uns fielen sofort die Variablen price und discount ins Auge, sodass wir diese Anfrage mit unserem HTTP-Proxy unterbrochen und manipuliert haben. Mit erschreckendem Ergebnis: Der Server akzeptierte die Anfrage und wir erhielten als Antwort ein JSON-Objekt mit dem Status “VALID”. So könnte ein Kunde die Preise der Produkte, die er bestellen möchte, zu seinen Gunsten manipulieren.

Also mussten wir das Javascript-SDK überprüfen, ob dieses die Manipulation tatsächlich so an den Shopbetreiber weitergeben würde. Nach ein wenig Suche und Debugging im Browser haben wir die betreffende Codestelle gefunden. Mit Entsetzen nahmen wir folgendes zur Kenntnis:

Nachdem der Server unsere Manipulation bereits akzeptiert hatte, erklärt nun auch das Javascript-SDK diese Manipulation für gültig.

Beim Kunden herrschte natürlich blankes Entsetzen – wie konnte das passieren? Man setze doch bereits diverse Tools für Security und Codequalität in Sonar ein. Es stellte sich heraus, dass die falsche Funktion aufgerufen wurde.

Dieses Beispiel zeigt wunderbar, warum selbst das beste Tool keinen echten Penetrationstest ersetzen kann: Ein Tool kann eben nicht herausfinden, ob der Softwareentwickler die semantisch korrekte Funktion aufgerufen hat.

Ohne unseren Penetrationstest wäre diese Sicherheitslücke, mit der sich die gesamte Funktionalität der Anwendung umgehen ließe, wahrscheinlich in Produktion gegangen.

Der Beitrag Warum selbst das beste Tool einen echten Penetrationstest nicht ersetzen kann erschien zuerst auf EXXETA BLOG.

SAST ist im Security-Kontext den Whitebox-Tests zuzuordnen, da der Quellcode zwingend benötigt wird. Dafür wird beim Whitebox-Test allerdings kein laufendes Programm benötigt. Im Gegensatz hierzu setzt die dynamische Analyse (dynamic application security testing) ein laufendes Programm voraus, benötigt dafür aber keinen Quellcode.

Statische Codeanalyse lässt sich in verschiedenen Detailstufen durchführen, von einfachen Mustererkennungen (wie zum Beispiel SpotBugs) bis hin zur detaillierten Datenflussanalyse

Um statische Codeanalyse durchführen zu können, muss das eingesetzte Programm den Quellcode auf verschiedene Probleme prüfen. Hierfür haben sich verschiedene Techniken wie die Datenflussanalyse in Kombination mit der Taint-Analyse etabliert. Dort wird die Aufrufhierarchie des Quellcodes analysiert und mit einer weiteren Information angereichert: An welchem Punkt gelangen möglicherweise kritische Eingaben in eine Anwendung und wie werden diese Eingaben weiterverarbeitet.

@RestController
public class RestController{
    @Autowired
    private databaseService;
@GetMapping("/login")
public boolean login(@RequestParam(value="username", default="") String username, @RequestParam(value="password", default="") String password) {
    return databaseService.checkCredentials(username, password);
}
}

Somit ergibt sich für die statische Codeanalyse der Vorteil (im Vergleich zur dynamischen Analyse), dass das Verfahren schnell, einfach und automatisiert durchführbar ist. So ist SAST ideal für tägliche Tests, zum Beispiel während eines nightly builds, geeignet.

Allerdings sollten bei der Auswahl eines SAST-Tools einige Punkte beachtet werden:

– Das Tool muss die zu untersuchende Sprache unterstützen.
– Welche Arten von Schwachstellen kann das Tool erkennen und welche Arten von Schwachstellen sind im Projekt besonders wichtig?
– Muss der Quellcode in kompilierter Form vorliegen oder kann das Tool auch nur mit reinen .java-Dateien arbeiten?
– Kann das Tool in IDEs integriert werden?
– Lizenzkosten: Freeware, per-User usw.

Bewertungskriterien

Zwei der bekanntesten Tools für statische Codeanalyse sind Xanitizer und RIPS. Um eine möglichst realitätsnahe Bewertung der Tools vornehmen zu können, sollen verschiedene Problemstellungen aus der Praxis analysiert werden. Dazu zählen konkret SQL-Injection, Cross-Site-Scripting und NoSQL-Injection. Alle drei Problemstellungen werden in verschiedenen „Schwierigkeitsgraden“ ausgeführt. So werden SQL-Injections als einfache Query mit Stringkonkatenation von Nutzereingaben, als PreparedStatement mit Stringkokatenation von Nutzereingaben sowie als korrektes PreparedStatement getestet werden. Zudem wird getestet, wie gut die Software-Tools selbst geschriebene Sanitizer bewerten können. Hierzu wird ein eigens entwickelter Sanitizer (welcher nicht alle schädlichen Zeichen korrekt entfernt) eingesetzt. Die Software sollte erkennen, dass hier keine korrekte Bereinigung durchgeführt wird.

Für Cross-Site-Scripting soll sowohl persistentes als auch reflektiertes Cross-Site-Scripting getestet werden. Es sollen Nutzerkommentare in eine Datenbank gespeichert werden. Auch hier soll zusätzlich ein unvollständiger Sanitizer zum Einsatz kommen.

Ergebnisse

Sowohl Xanitizer als auch RIPS haben alle eingebauten Schwachstellen korrekt erkannt. Unvollständige Sanitizer haben beide Tools nicht erkannt, da sie aber die betreffenden Methodenaufrufe als Schwachstelle erkannt haben, fällt dies nicht sonderlich schwer ins Gewicht. Auch das reflektierte Cross-Site-Scripting haben beide Tools erkannt. Somit haben beide Tools alle Schwachstellen zuverlässig erkannt und dabei keine false-positives erzeugt. Auch bei der Analyse von echten Projekten erzeugen beide Tools erstaunlich wenige false-positives; false-negatives konnten bisher nicht festgestellt werden

Analysierbare Sprachen in Xanitizer und RIPS

Während Xanitizer aktuell nur Java analysieren kann, bietet RIPS zusätzlich die Möglichkeit, PHP zu analysieren. Bei PHP wird eine große Anzahl Frameworks untersützt, sodass auch Erweiterungen für CMS problemlos und zuverlässig analysiert werden können.

Xanitizer bereitet aktuell eine Unterstützung für Javascript vor, ebenso RIPS.

Einrichtung und Nutzung von Xanitizer und RIPS

Um Xanitizer beziehungsweise RIPS optimal nutzen zu können, können diverse Einstellungen vorgenommen werden. Die Installation der beiden Tools ist sehr einfach. Während Xanitizer als Programm gestartet wird, liefert RIPS ein Installationsskript, das alle Docker-Container von RIPS herunterlädt und entsprechend einrichtet. Auch weitere Anpassungen wie URLs, Ports und Benutzer können später über dieses Installer-Skript einfach und unkompliziert vorgenommen werden.

SAST mit Xanitizer

Xanitizer erzeugt zu jedem Projekt einen sogenannten Workspace, in welchem alle relevanten Konfigurationen vorgenommen werden können.

Hierzu zählen unter anderem die Einstiegspunkte in die Applikation, die zu berücksichtigenden Klassen sowie die zu analysierenden Sicherheitsprobleme. Hierbei sollte erwähnt werden, dass Xanitizer ausschließlich mit class-Dateien arbeitet, java-Dateien werden nur für die Quellcodedarstellung der Resultate benötigt. Daher ist für Xanitizer zwingend ein kompilierfähiges Projekt notwendig, es sei denn, das Projekt liegt als fertige JAR/WAR-Datei vor.

Sollte Xanitizer nicht alle Klassen in den Workspace aufgenommen haben, können die entsprechenden include patterns im Workspace ergänzt werden. Weiterhin können nicht benötigte Klassen, wie zum Beispiel Unit-Tests, entfernt werden.

Anschließend kann der Call-Graph berechnet werden. Falls in diesem Schritt nicht alle Einstiegspunkt in die Anwendung gefunden wurden, können diese über konfigurierbare Patterns in den Einstellungen des Workspaces nachgetragen werden. Es können viele Parameter definiert und etwa Methodennamen, Parameter, Rückgabewert oder Annotations konfiguriert werden. Anschließend kann die Analyse der Sicherheitslücken beginnen. Hierfür transformiert Xanitizer den Quellcode zunächst in eine von Xanitizer entwickelte Zwischensprache, um die Analyse zu vereinfachen und später neue Sprachen einfacher integrieren zu können. Nach diesem Schritt meldet Xanitizer, welche Sicherheitslücken gefunden wurden. Hier können nun eigene Sanitizer oder false positives markiert werden, sodass diese bei der nächsten Analyse nicht mehr beachtet werden. Findings können kategorisiert und mit Kommentaren versehen werden, sodass auch mehrere Personen an einem Projekt arbeiten können.

Für automatisierte Workflows steht ein Headless-Mode zur Verfügung. In diesem läuft Xanitizer ohne GUI, benötigt aber einen korrekt konfigurierten Workspace. So kann Xanitizer regelmäßig ausgeführt werden, zum Beispiel während Nightly-Builds oder in CI/CD-Pipelines auf einem Buildserver.

SAST mit RIPS

Ein weiteres SAST-Tool, welches ähnlich arbeitet wie Xanitizer, ist RIPS. RIPS verfolgt einen anderen Architekturansatz und ist als klassische Client-Server-Architektur aufgebaut: Um Quellcode zu analysieren, verbindet man sich per Browser mit der Web-GUI von RIPS und meldet sich mit seinen Zugangsdaten an.

Anschließend kann ein ZIP-Archiv hochgeladen werden. Im Gegensatz zu Xanitizer benötigt RIPS keine class-Dateien, der normale Quellcode aus der Versionskontrolle reicht somit aus.

Anschließend kann ein Analyseprofil definiert werden, in welchem zu prüfende Sicherheitslücken eingestellt werden können.

Auch in RIPS können eigene Sanitizer, Sources und false positives markiert werden. Anschließend analysiert RIPS das Projekt und zeigt die Ergebnisse nach Kategorien sortiert an. Im Gegensatz zu Xanitizer wird bei RIPS der Quellcode nicht transformiert, es kommt für jede Sprache eine eigens entwickelte Analyse-Engine zum Einsatz. Auch in RIPS können Findings markiert und kommentiert werden.

Integration in den SDLC

Sowohl RIPS als auch Xanitizer lassen sich hervorragend in bestehende SDLC eingliedern. So können sie als Jenkins-Plugin oder GitLab-Pipeline eingebunden werden. RIPS bietet zusätzlich noch Plugins für Eclipse und IntelliJ an, sodass Entwickler noch vor einem Commit lokal eine Prüfung durchführen können. Auch können beide Tools als Maven-Goal eingebunden werden. RIPS unterstützt zusätzlich noch Gradle, während Xanitizer noch ANT unterstützt.

Allerdings müssen beide Tools für einen sinnvollen Einsatz im SDLC entsprechend konfiguriert werden, was zumindest anfänglich etwas Zeit in Anspruch nimmt.

RIPS und Xanitizer im Vergleich

Die nachfolgende Tabelle fasst die bereits in den vorausgegangenen Ausführungen erläuterten Unterschiede zwischen RIPS und Xanitizer noch einmal zusammen:

Fazit

Statische Codeanalyse eignet sich hervorragend, um bereits in der Entwicklungsphase einer Software mögliche Schwachstellen zu erkennen und noch vor einer Auslieferung in die Produktivumgebung zu beheben. Hier unterstützt RIPS besonders mit einem Plugin für gängige IDEs. Sowohl RIPS als auch Xanitizer bieten eine gute Integration in die Versionsverwaltung. Das Markieren von false-positives funktioniert bei beiden Tools einwandfrei und beide Tools können diese Markierungen auch beim Zusammenführen von Branches der Versionskontrolle beibehalten.

Allerdings hat SAST einen entscheidenden Nachteil: Der Code wird nicht ausgeführt, sodass anhand verschiedener Heuristiken entschieden werden muss, ob eine potentielle Sicherheitslücke vorliegt, oder nicht. Dadurch kann vor allem in der Einführungsphase eines solchen Tools ein erhöhter Aufwand entstehen, da möglicherweise etliche false-positives markiert werden müssen. Dieser Aufwand sollte auf jeden Fall erbracht werden, da nur so eine sinnvolle Nutzung von SAST möglich ist, denn: Wenn ein Softwareentwickler ein Security-Tool als lästig empfindet, wird er es nicht benutzen oder die vielen Findings nicht beachten.

Weiterhin stellen Bibliotheken und Frameworks eine Hürde für SAST-Tools dar, da sich hier häufig Aufrufhierarchien ändern oder der Quellcode teilweise gar nicht vorliegt (meist bei selbst entwickelten Frameworks) und somit keine verlässliche Aussage getroffen werden kann, ob hier sicherheitsrelevante Methoden oder ähnliches aufgerufen werden.

Daher sollte SAST immer mit einer dynamischen Analyse kombiniert werden, um möglichst viele Schwachstellen einer Anwendung erkennen zu können.

Der Beitrag Statische Codeanalyse: Xanitizer und RIPS im Vergleich erschien zuerst auf EXXETA BLOG.

SDLC steht für Software Development Lifecycle (dt. Software-Lebenszyklus). Ein SDLC ist im Wesentlichen eine Reihe von Schritten oder Phasen, die einen Rahmen für die Entwicklung von Software und deren Verwaltung über den gesamten Lebenszyklus bieten. Obwohl es nicht nur eine Technik oder Möglichkeit gibt, Anwendungen und Softwarekomponenten zu entwickeln, gibt es etablierte Methoden, die von Unternehmen verwendet werden und Modelle, um unterschiedliche Herausforderungen und Ziele zu bewältigen. Diese Methoden und Modelle basieren typischerweise auf einer Norm, wie beispielsweise ISO/IEC 12207, die Richtlinien für die Entwicklung, Beschaffung und Konfiguration von Softwaresystemen festlegt.

Um ein qualitativ hochwertiges Softwareprodukt zu entwickeln, das die Anforderungen des Kunden oder des Endverbrauchers erfüllt, müssen Unternehmen den für sie besten Software Development Lifecycle wählen. Es gibt unterschiedliche SDLC’s. Die Wahl des SDLC variiert von Unternehmen zu Unternehmen. Jedes Unternehmen hat seine eigenen Verfahren und Richtlinien, die sich auch in Bezug auf die Anforderungen und die Infrastruktur unterscheiden. Ein Softwareentwicklungsprozess beschreibt eine theoretische und konzeptionelle Darstellung der Softwareentwicklung. Die Softwareentwicklung durchläuft eine Reihe von verschiedenen Phasen wie Anforderungsanalyse, Designspezifikation, Programmierung, Test und Wartung. Mit Hilfe von Entwicklungsprozessen können Unternehmen die Arbeit effizient aufteilen, verschiedene Aktivitäten dem Softwareentwicklungsteam zuordnen, Budgets und Termine oder den Zeitraum schätzen. Um auf dem globalen Markt konkurrenzfähig zu sein, haben in den letzten vier Jahrzehnten die Unternehmen und Organisationen verschiedene Softwareentwicklungsprozesse wie Wasserfall, Spiralmodell, “Rapid Prototyping”, Agilität und weitere praktiziert. (JAGLI & Yeddu, 2017)

Secure SDLC

Ein sicherer SDLC ist für Unternehmen aller Branchen von entscheidender Bedeutung. Schwache oder gar keine Sicherheitspraktiken führen zu unsicherem und verwundbarem Code. Durch die Integration von Aktivitäten, welche die Sicherheitspraktiken beschreiben, kann die Architektur verbessert werden. Synonym für Secure SDLC ist der sichere Software-Lebenszyklus, auch bekannt als S-SDLC. Außerdem gibt es noch das bekannte Secure Development Lifecycle (SDL)-Framework von Microsoft, auf das wir ebenfalls verweisen.

Eine stärkere Fokussierung auf die Anwendungssicherheit ist wirtschaftlich sinnvoll. Dies betrifft nicht nur die nun aufgezeigten, recht hohen Kosten, die ein IT-Sicherheitsvorfall verursacht, sondern hilft auch, den Unternehmenswert zu steigern. Es ist bekannt, dass die erst späte Behebung von Schwachstellen im SDLC zu höheren IT-Ausgaben und Opportunitätskosten führt.

Von verschiedenen Unternehmen wurden mehrere Herausforderungen im Rahmen des SDLC beobachtet. Einige dieser Beobachtungen sind:

• – Laut eines Sicherheitsberichtes von Microsoft waren etwa 10% der bis Oktober 2016 offenbarten Schwachstellen auf Betriebssysteme (OS) und die anderen 90% auf die Anwendungsebene ausgerichtet.
• – Der IBM Internet Security Systems X-Force-Bericht 2016 ergab, dass nur 11% aller im Jahr 2008 offenbarten Schwachstellen zu den fünf führenden Softwareanbietern (Microsoft, Oracle, IBM, Apple und Cisco) gehören.
• – Das National Institute of Standards & Technology (NIST) schätzt, dass Code-Fixes, die nach der Veröffentlichung durchgeführt werden, 30 Mal mehr kosten als die Code-Fixes, die während der Designphase durchgeführt werden.
• – Das NIST schätzt, dass 92% aller Sicherheitsvorfälle auf Softwareprobleme zurückzuführen sind.
• – Ein Bericht von Cigitial zeigt, dass die Ursachen für Schwachstellen in der Anwendungssicherheit fast gleichmäßig auf Programmierfehler und Designfehler verteilt sind.

Diese Ergebnisse zeigen, wie stark die Anwendungsebene von Angriffen betroffen ist.

Eine solide SDLC-Strategie bietet qualitativ hochwertige Software, weniger Schwachstellen, sowie besser eingesetzte Zeit und Ressourcen. Eine Strategie hilft bei der Entwicklung und Wartung von Software. Tools ermöglichen die Integration automatisierter Sicherheitstests in den SDLC-Prozess.

In der Literatur gibt es unterschiedliche Einteilungen der Phasen des SDLC. Diese unterschiedlichen Einteilungen reichen von vier recht allgemein gefassten Phasen bis zu den in der Abbildung 1 gezeigten sechs Phasen. Das liegt daran, dass oftmals die Phasen vier und fünf als “Test und Wartung” zusammengefasst sind. Auch eine Einteilung in sieben Phasen ist möglich. Da der Software-Lebenszyklus als vollständige Endlosschleife betrachtet wird, sind auch die Aktivitäten nach der Bereitstellung, also während des Betriebs, für ein vollständiges Bild sinnvoll. In dieser Grafik wurde die sechste Phase “Betrieb und Wartung” für den Secure SDLC hinzugefügt, um die Sicherheitsmaßnahmen, die nach dem Bereitstellen (Deployment) auftreten, mit aufzunehmen und ein ganzheitliches Bild des Secure SDLC zu vermitteln.

Ein wesentliches Merkmal, das den Secure SDLC vom herkömmlichen Entwicklungsprozess unterscheidet, ist, dass Tests kontinuierlich und automatisiert im gesamten SDLC stattfinden.

OWASP SAMM

Zur Entwicklung einer ganzheitlichen Sicherheitsstrategie kann das OpenSAMM Projekt eingesetzt werden. Das OWASP Software Assurance Maturity Model (SAMM) unterstützt den gesamten Software-Lebenszyklus, einschließlich Entwicklung und Beschaffung, und ist technologie- und prozessunabhängig. Es ist bewusst so konzipiert, dass es entwicklungsfähig und risikoorientiert ist (Deleersnyder, Win, & Glas, 2017, S. 2). SAMM definiert die einzelnen Sicherheitsmaßnahmen anhand der Unternehmensfunktionen und kann daher bereits zu Beginn in der Planungsphase verwendet werden, um den Prozess zur kontinuierlichen Verbesserung der Sicherheit phasenübergreifend aufzusetzen (Tatlı, 2012, S. 805).

Abbildung 2 veranschaulicht die Unternehmensfunktionen nach SAMM und die jeweiligen Sicherheitsmaßnahmen. Die vier Geschäftsfunktionen (Governance, Construction, Verification und Operations) befinden sich in der höchsten Ebene. In jeder Geschäftsfunktion sollen bestimmte Sicherheitsmaßnahmen umgesetzt werden, um ein bestimmtes Sicherheitsniveau in dieser Geschäftsfunktion zu erreichen. Unter jeder Geschäftsfunktion gibt es drei „Security Practices“. (Tatlı, 2012, S. 805)

Phasen des Secure SDLC

Dieses Kapitel orientiert sich an den Phasen des Secure Development Lifecycle. In den nun folgenden Unterkapiteln werden die einzelnen Phasen erklärt und jeweils die Maßnahmen zur Integration von Sicherheit erläutert.

Phase 1: Anforderungsanalyse (Requirement Analysis)

Der erste Schritt ist die Abbildung eines Planungsprozesses. Während dieser Phase muss ein Unternehmen das Release-Thema, den Inhalt und die Zeitleiste identifizieren. Dazu gehören typischerweise Aktivitäten wie das Sammeln von Endbenutzeranforderungen, das Bestimmen von User Stories, die in das Release aufgenommen werden sollen, und das Planen von Release-Phasen.

Zu den Schlüsselaspekten in dieser Phase gehört das Sicherstellen, dass eine Anwendung den Geschäftsanforderungen entspricht.

Festlegung der Security & Privacy Anforderungen

Die Notwendigkeit, Sicherheit und Datenschutz zu berücksichtigen, ist ein grundlegender Aspekt bei der Entwicklung sicherer Anwendungen und Systeme. Unabhängig von der verwendeten Entwicklungsmethodik müssen die Sicherheitsanforderungen kontinuierlich aktualisiert werden, um Änderungen der erforderlichen Funktionalität und Änderungen der Bedrohungslandschaft Rechnung zu tragen. Der optimale Zeitpunkt für die Definition der Sicherheitsanforderungen liegt natürlich bereits in der ersten Entwurfs- und Planungsphase, da Entwicklungsteams die Sicherheit so integrieren können, dass Störungen minimiert werden. Zu den Faktoren, die die Sicherheitsanforderungen beeinflussen, gehören die gesetzlichen und branchenspezifischen Anforderungen, Standards wie Verschlüsselungsverfahren, die Überprüfung früherer Vorfälle und bekannte Bedrohungen. (Microsoft, 2019b)

Phase 2: Designspezifikation (Design)

Ganz im Gegensatz zum Prinzip „Security by Design“ wird Sicherheit bei der Entwicklung von Anwendungen häufig vernachlässigt. Dabei können durch die Designphase laut Gartner bis zu 50% der Schwachstellen vermieden werden (Stackpole & Oksendahl, 2010, S. 199).

Während der Designphase werden Architektur und Design der Lösung mit Hilfe von Threat Modeling-Techniken überprüft. Für jede der Komponenten sollten Bedrohungsakteure und mögliche Bedrohungsszenarien aufgezählt werden. Beispielsweise könnte ein Bedrohungsszenario ein mögliches Problem der Datenintegrität sein, da es keine Authentifizierungskontrollen auf dem Gerät gibt. Nach der Aufzählung der Bedrohungen können Gegenmaßnahmen bewertet und empfohlen werden.

Zu den Schlüsselaspekten in dieser Phase gehören:

• – Das Engagement in der Bedrohungsmodellierung und im Sicherheitsdesign
• – Die Wahl der Programmiersprachen, Frameworks und der Bibliotheken, die im Entwicklungsprozess verwendet werden sollen

Bedrohungsmodellierung (engl. Threat Modeling)

Threat Modeling ist ein Prozess, mit dem potenzielle Bedrohungen aus der Sicht eines hypothetischen Angreifers identifiziert, aufgezählt und priorisiert werden können. Microsoft bietet als Hilfsmittel kostenfrei das Microsoft Threat Modeling Tool an.

Das Threat Modeling Tool ist ein Kernelement im Microsoft Security Development Lifecycle (SDL). Es ermöglicht Softwarearchitekten, potenzielle Sicherheitslücken früh zu identifizieren und zu entschärfen, wenn sie relativ einfach und kostengünstig gelöst werden können. (Microsoft, 2019a)

Security Design Review (SDR)

Ein SDR ist eine detaillierte Analyse der wichtigsten Systeme mit Blick auf die Gesamtsystemsicherheit. Dazu gehört beispielsweise die Einhaltung von Best Practices. Werden zum Beispiel Authentifizierungsverfahren mit Standards wie OAuth umgesetzt und Schutzmechanismen wie 2-Faktor unterstützt und werden technische Schutzmechanismen, wie die OWASP Proactive Controls, von Beginn an in die Applikationsarchitektur integriert, entstehen in der Implementierungsphase weniger Fehler (Stackpole & Oksendahl, 2010, S. 199).

Phase 3: Implementierung (Development)

Diese Phase umfasst die eigentliche Entwicklung und die Erstellung der Anwendung – bei gleichzeitiger Erfüllung aller in der Planungsphase festgelegten Anforderungen.

Zu den Schlüsselaspekten in dieser Phase gehören:

• – Die Schulung von Entwicklern in sicherer Programmierung
• – Das Auffinden und Beheben von Fehlern und Sicherheitsschwachstellen im Code während des Schreibens
• – Die Open-Source-Komponenten auf sichere Weise nutzen

Statische Codeanalyse

Eine wichtige Sicherheitsmaßnahme ist die statische Codeanalyse. Ziel ist es, den Quellcode nach unsicheren Methoden, wie veralteten Hashing-Algorithmen oder ungeprüften Benutzereingaben, zu untersuchen. Unter anderem mit Hilfe von Pattern Matching können Schwachstellen im Quellcode erkannt werden. Es gibt zahlreiche Tools, die statische Codeanalysen auch vollautomatisch im CI/CD-Build-Prozess durchführen. Bereits in der Entwicklungsumgebung (IDE) können statische Codeanalysetools wie .NET Security Code Scan unterstützen.

Code Review

Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem (Peer Review) oder mehreren Gutachtern (Mehr-Augen-Prinzip) Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Code Reviews sind ein etabliertes und adäquates Mittel der Softwareentwicklung. Ziel dieser Sicherheitsmaßnahme ist die Einhaltung von Secure Coding Guidelines, die beispielsweise durch Secure Coding Schulungen vermittelt werden, zu überprüfen. Von OWASP gibt es als nützliches Hilfsmittel die OWASP Secure Coding Praktiken und das OWASP Code Review Projekt.

Phase 4: Test (Testing)

Während dieser Phase testet das Team den Code anhand der Anforderungen, um sicherzustellen, dass das Produkt diese erfüllt und wie erwartet funktioniert. Die vierte Phase umfasst die Durchführung aller Arten von Leistungs-, Qualitätssicherungs- und Funktionstests sowie nicht-funktionale Tests, wie z. B. UX-Tests. Während das Testen traditionell nach der Entwicklungsphase stattgefunden hat, gehen Unternehmen, die einen Best-Practice-Ansatz verfolgen, zu kontinuierlichen automatisierten Tests im gesamten SDLC über.

Zu den Schlüsselaspekten in dieser Phase gehören:

• – Das Testen der Anwendung anhand von Sicherheitsrichtlinien mit verschiedenen Testmethoden, darunter statische, dynamische, Software-Zusammensetzungsanalyse und manuelle Penetrationstests
• – Die Durchführung eines umfassenden Spektrums von Leistungs-, Funktions-, Einheits- und Integrationstests unter Verwendung der gleichen Sprache und Protokolle der zu testenden Systeme
• – Das Hinzufügen von Sicherheitstests als Teil der abschließenden Qualitätsprüfungen

Security Test Cases

Zu den Security Test Cases gehört das Prüfen von bestimmten Testfällen, die auch ein Angreifer anwenden würde. Hilreiches Material liefert hierzu der OWASP Testing Guide und die OWASP Cheat Sheets. Damit können per Checkliste häufige Angriffe ausprobiert und abgearbeitet werden. Ein Beispielhafter Testfall wäre die Schwachstelle “Error Handling: Disclosure of sensitive informations”. Diese Schwachstelle tritt dann auf, wenn Fehler in der Applikation provoziert werden. Ein weiterer Testfall ist das Ausspähen von eingesetzten Bibliotheken (auch Footprinting/Banner Grabbing genannt) und die darauf aufbauene Untersuchung nach bereits gemeldeten CVE (Common Vulnerabilities and Exposures) Einträgen.

Dynamische Analysen

Mittels Vulnerability Scanning-Tools und Fuzzing-Angriffen kann automatisiert die Applikation von außen angegriffen werden. Schwachstellenscanner wie OWASP ZAP und w3af können die laufende Anwendung angreifen. Diese Scanner verwenden verschiedene Angriffsvektoren und geben sie als Benutzereingaben ein (Fuzzing), die dann von der Anwendung verarbeitet werden. Mithilfe von Scanning Tools wie der OWASP ZAP API oder dem Netsparker können dynamische Analysen automatisiert in den Entwicklungsprozess eingebaut werden.

Phase 5: Bereitstellung (Deployment)

In der Release-Phase setzt ein Team die Software auf Produktionsservern ein. Dazu gehört das Bündeln, Verwalten und Bereitstellen mehrerer komplexer Releases in verschiedenen Umgebungen, einschließlich privater Rechenzentren und Clouds, sowie Public Cloud-Ressourcen.

Zu den Schlüsselaspekten in dieser Phase gehören:

• – Die Überwachung des Fortschritts eines Releases und seiner Komponenten
• – Weg von manuellen Freigabeprozessen hin zu einem automatisierten Prozess, bei dem die Freigabe von Software auf einer Geschäftsentscheidung basiert
• – Das Erstellen von Sicherheitstests als Teil der abschließenden Qualitätsprüfungen

Final Security Review (FSR)

Da sich das Produkt dem Fertigstellungszeitpunkt nähert, muss eine wichtige Frage beantwortet werden: Ist das Produkt aus Sicherheits- und Datenschutzsicht einsatzbereit? Ziel des Final Security Review (FSR) ist es, diese Frage zu beantworten. Das FSR wird vom zentralen Sicherheitsteam durchgeführt und ist ein kritischer Teil des Secure SDLC. Ein hilfreiches Mittel ist ein unabhängiger Penetration Test, welcher von einem externen Dienstleister ausgeführt werden kann.

Application Security & Monitoring Response Plan

Bestandteil dieser Sicherheitsmaßnahme ist die Erstellung eines Incident Response Plan (IRP) und die Implementierung eines Incident Response and Management System (IRMS). Ein IRP ist eine Reihe von Anweisungen, die das IT-Team bei der Erkennung, Reaktion auf und Wiederherstellung von Sicherheitsvorfällen unterstützen. Die Informationen des Unternehmens, und damit auch seine Reputation, können durch eine Infrastruktur eingedämmt werden, für welche eine Reaktion auf Störungen entwickelt und implementiert wird. Dies kann zum Beispiel durch Pläne, definierte Rollen, Training, Kommunikation erfolgen, um einen Angriff schnell zu entdecken und den Schaden effektiv einzudämmen. So kann die Anwesenheit des Angreifers beseitigt und die Integrität des Netzwerks und der Systeme wiederhergestellt werden. Angegliedert an das Risikomanagement kann ein Incident Response and Management System (IRMS) implementiert werden.

Phase 6: Betrieb und Wartung (Operations and Maintenance)

Während dieser Phase befindet sich ein Produkt in der Produktion und wird von den Kunden genutzt. Die Überwachung der Leistung und der Benutzererfahrung der Anwendung ist entscheidend für die kontinuierliche Verbesserung. Ein Unternehmen stellt sicher, dass Betriebsdaten Entwicklern und Testern zur Verfügung gestellt werden.

Zu den Schlüsselaspekten in dieser Phase gehören:

• – Die fortlaufende Prüfung und Überwachung von Anwendungen in der Produktion.
• – Die Neubewertung von Anwendungen hinsichtlich Leistung, Sicherheit und Benutzerfreundlichkeit, sobald diese aktualisiert oder geändert werden.

Incident Forensics

Incident Forensics beinhaltet unter anderem, die Vorgehensweise eines Angreifers Schritt für Schritt zurückzuverfolgen und die forensische Analyse möglicher Sicherheitsverletzungen. Im Falle eines Cyberangriffes geht es darum, Beweismittel gerichtsverwertbar zu sichern und aufzubereiten. Im Ernstfall helfen nicht kompromittierte Logfiles, um den Angreifer aufzugreifen.

Security Monitoring

Beim Security Monitoring geht es darum, die potentiellen Bedrohungen zu erkennen, bevor es zu bedrohlichen Einbrüchen kommt. Dazu werden Ereignisdaten aus unterschiedlichen operativen Ebenen gesammelt und in Echtzeit analysiert. Auf Applikationsebene kann der OWASP AppSensor integriert werden. Dieser Verteidigungsmechanismus wird als Runtime Application Self-Protection (RASP) bezeichnet. RASP ist eine Sicherheitssoftware, die mit in die Anwendung integriert wird oder an die Umgebung geknüpft ist. So können Angriffe auf Anwendungsebene erkannt und direkt blockiert werden. Da RASP auf Anwendungsebene läuft, hat zum Beispiel AppSensor Einblick über die Vorgänge innerhalb der Anwendung. Das Anwendungsverhalten kann genau analysiert werden. Somit wird ermöglicht, dass in Echtzeit reagiert werden kann.

.

Quellen

Deleersnyder, S., Win, B. D., & Glas, B. (2017). SOFTWARE ASSURANCE MATURITY MODEL. A GUIDE TO BUILDING SECURITY INTO SOFTWARE DEVELOPMENT, OWASP Foundation. Abgerufen von https://github.com/OWASP/samm/raw/master/Supporting Resources/v1.5/Final/SAMM_How_To_V1-5_FINAL.pdf

JAGLI, D., & Yeddu, S. (2017). CloudSDLC: Cloud Software Development Life Cycle. International Journal of Computer Applications, 168, 6–10. https://doi.org/10.5120/ijca2017914468

Kesäniemi, A. (2009). Code Analysis. Automatic vs Manual, OWASP Foundation. Abgerufen von https://www.owasp.org/images/5/53/Ari_kesaniemi_nixu_manual-vs-automatic-analysis.pdf

Lobačevski, J., & Arteau, P. (2019). Security Code Scan. Security static code analyzers for .NET. Abgerufen von https://security-codescan.github.io

Microsoft. (2019a). Microsoft Threat Modeling Tool. Abgerufen von https://docs.microsoft.com/de-de/azure/security/azure-security-threat-modeling-tool

Microsoft. (2019b). What are the Microsoft SDL practices? Abgerufen von https://www.microsoft.com/en-us/securityengineering/sdl/practices

Stackpole, B., & Oksendahl, E. (2010). Security Strategy: From Requirements to Reality. CRC Press. Abgerufen von https://books.google.de/books?id=ziGJGMhryA0C

Subramanian, S., & M., B. S. (2017). Security Assurance in the SDLC for the Internet of Things. Secure SDLC Steps to Address Common Coding Flaws and Software Vulnerabilities. Abgerufen von https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/security-assurance-in-the-sdlc-for-the-internet-of-things.aspx

Tatlı, E. İ. (2012). OWASP Anleitungen und Tools für Secure SDLC. Datenschutz und Datensicherheit – DuD, 36(11), 805–809. https://doi.org/10.1007/s11623-012-0276-2

Der Beitrag So sorgen Sie für mehr Sicherheit im Software Development Lifecycle erschien zuerst auf EXXETA BLOG.