So verwenden Sie das MASVS von OWASP, um sicherzustellen, dass Ihre Anwendungen sicher sind

Um  Entwerfen Sie eine sichere Anwendung, müssen Sie der Grundlage vertrauen, auf der die Anwendung aufgebaut ist. Ob es sich um eine App und ihr Betriebssystem, um Firmware und ihre Hardware oder um eine Webseite im Browser handelt – was passiert, wenn die Grundlage selbst nicht sicher ist?   

R – Resilienz ist ein wichtiges Thema im MASVS, und einige sehen „R“ als Empfehlung. Bei Digital.ai Wir glauben, dass Resilienz die eigentliche sichere Grundlage in einer ansonsten unsicheren Umgebung ist. Die Stufe „R“ ist von grundlegender Bedeutung für den Schutz der L1-Stufe „Standardsicherheit“. Warum? Denn die in L-1 beschriebenen Standardsicherheitsmaßnahmen können zu leicht gebrochen werden, wenn Apps in unsicheren Umgebungen ausgeführt werden. Zu unsicheren Umgebungen gehören mobile Geräte mit Jailbreak oder Root, Emulatoren und sogar mit Malware infizierte Geräte. Alle diese Umgebungen sind üblich. Tatsächlich ergab eine Metaanalyse der Millionen von App-Instanzen, dass Digital.ai Wir haben herausgefunden, dass in jeder Woche mehr als die Hälfte der von uns geschützten Apps in Un-Schutz geratensafe Umgebungen. 

Im folgenden Blogbeitrag besprechen wir die Ausfallsicherheitsanforderungen und wie man diese erfüllt Code-Verschleierung, Überwachung und RASP-Tools. Wir teilen außerdem Einblicke und Meinungen zu den L1-Standard-Sicherheitsempfehlungen, den entsprechenden Angriffsvektoren und den Möglichkeiten, wie Sie diese abschwächen können. Abschließend besprechen wir einige Herausforderungen, die auftreten, wenn Anwendungsingenieure nur die L-1-Empfehlungen befolgen. Wir beginnen mit den Anforderungen der obersten Ebene oder „Resilienz“, die im MASVS besprochen werden.  

Was ist MASVS?

Die Mobil Application Security Verifizierungsstandardoder „MASVS“ ist eine zusammengestellte Liste verschiedener Empfehlungen, die sich über mehrere Bereiche wie Netzwerk, Speicher, Integrität und mehr verteilen. Diese Empfehlungen werden in drei Hauptmodelle eingeteilt: 

• MASVS-L1 – Standardsicherheit: Besteht aus den besten Sicherheitspraktiken wie Codequalität, Umgang mit sensiblen Daten und Interaktion mit der mobilen Umgebung. 
• MASVS-L2 – Tiefenverteidigung: Dieses Modell umfasst alles, was in MASVS-L1 enthalten ist, sowie zusätzliche Empfehlungen basierend auf dem Bedrohungsmodell für Branchen wie Banken und Gesundheitswesen, die besonders sensible Daten verarbeiten. 
• MASVS-R – Widerstandsfähigkeit gegen Reverse Engineering und Manipulation: Schutz vor spezifischen clientseitigen Angriffen wie Manipulation oder Modding, oder Reverse Engineering.

So erfüllen Sie Ausfallsicherheitsanforderungen  

MSTG-RESILIENCE-1  

Die App erkennt und reagiert auf das Vorhandensein eines gerooteten oder jailbreakten Geräts, indem sie entweder den Benutzer benachrichtigt oder die App beendet. 

Digital.ai App-Sicherheit erkennt viele ausgefeilte Rooting- und Jailbreak-Erkennungsmethoden. Wir sind sogar in der Lage, Manipulationen am eigenen Code des Betriebssystems zu erkennen. 

MSTG-RESILIENCE-2  

Die App verhindert das Debuggen und/oder erkennt und reagiert darauf, wenn ein Debugger angeschlossen ist. Alle verfügbaren Debugging-Protokolle müssen abgedeckt sein.  

Digital.ai App Security bietet vollständigen Schutz vor Debuggern. 

MSTG-RESILIENCE-3  

Die App erkennt und reagiert auf Manipulationen an ausführbaren Dateien und kritischen Daten in ihrer eigenen Sandbox. 

Open-Source-Kryptografiebibliotheken wie OpenSSL und Mbed-TLS sind für Angreifer leicht zu erkennen. Denn unsere Schutzmaßnahmen bieten ein Arsenal an White-Box-Kryptographie Algorithmen mit proprietärer Implementierung, Digital.ai Kunden können Integritätsprüfungen effizient durchführen, ohne für Angreifer erkennbare Spuren zu hinterlassen. 

MSTG-RESILIENCE-4  

Die App erkennt das Vorhandensein weit verbreiteter Reverse-Engineering-Tools und Frameworks auf dem Gerät und reagiert darauf. 

Digital.ai Application Security Erkennt das Vorhandensein dynamischer Instrumentierungs-Toolkits, Frameworks und Reverse-Engineering-Tools wie FRIDA, FRIDA-gadget und cycript.

MSTG-RESILIENCE-5 

Die App erkennt die Ausführung in einem Emulator und reagiert darauf. 

Digital.ai Application Security kann Emulatoren wie QEMU erkennen, indem es die CPU testet, auf der die geschützte App ausgeführt wird. 

MSTG-RESILIENCE-6  

Die App erkennt und reagiert auf Manipulationen des Codes und der Daten in ihrem eigenen Speicherbereich. 

Digital.ai Application Security erkennt und ermöglicht es Kunden Erstellen Sie benutzerdefinierte Reaktionen auf Manipulationsereignisse. Darüber hinaus können wir Versuche erkennen, die Manipulationserkennung abzuwehren. Wir erkennen auch Speichereditoren wie GameGuardian und iGameGod – und wir können Speicherscans erkennen, wenn Manipulationshandlungen ausgesetzt werden. 

MSTG-RESILIENCE-7  

Die App implementiert mehrere Mechanismen in jeder Verteidigungskategorie (8.1 bis 8.6). Beachten Sie, dass die Ausfallsicherheit mit der Menge und Vielfalt der Originalität der verwendeten Mechanismen skaliert. 

Digital.ai Application Security Kunden entscheiden, wann und wie sie a implementieren und aufrufen Vielzahl von Nachweismethoden. Wenn beispielsweise ein Manipulationsereignis erkannt wurde, sei es durch einen versteckten Hintergrundprozess oder eine schlichte Integritätsverletzung, kann der Kunde die gewünschte (RASPEL) Antwort. Der Kunde könnte die Anwendung beenden, den Endbenutzer zu einer erneuten Authentifizierung mit Zwei-Faktor-Authentifizierung zwingen oder die Schwerkrafteinstellung in einem Spiel auf Null zurücksetzen und so das Spiel für den Betrüger ruinieren, ohne Spuren des ursprünglichen Manipulationserkennungscodes zu hinterlassen. 

MSTG-RESILIENCE-8  

Die Erkennungsmechanismen lösen Reaktionen unterschiedlicher Art aus, einschließlich verzögerter und heimlicher Reaktionen.  

Digital.ai Application Security Überlässt es dem Kunden, mit benutzerdefinierten Handlern und verdeckten Planern zu steuern, wann und wo Schutzmaßnahmen aufgerufen werden. Wir bieten sogar eine „Absturz“-Funktion an, die die Anwendung abrupt beendet, ohne den Ursprung des Codes preiszugeben, der den Absturz verursacht hat.

MSTG-RESILIENCE-9  

Verschleierung wird auf programmatische Abwehrmaßnahmen angewendet, die wiederum eine Entschleierung durch dynamische Analyse behindern.  

Code-Verschleierung ist die ursprüngliche Basis unserer Technologie. Wir halten 6 Patente im Zusammenhang mit der Code-Verschleierung, darunter das erste Patent, das jemals für die Code-Verschleierung erteilt wurde. Digital.ai Application Security Bietet eine Lösung zur Codereduzierung, die den Code stark verschleiert. Darüber hinaus werden unsere White-Box-Kryptografievariablen und -konstanten für kurze Zeit verschleiert und „leben“ im Speicher, sodass Prozess-Dumping oder automatische Krypto-Scanner keine Vorteile bringen können. Wir bieten außerdem einen Schutz vor der Verschleierung von Laufzeitzeichenfolgen sowie eine vollständige Verschleierung von Textlaufzeiten wie Java und Objective-C.   

MSTG-RESILIENCE-11  

Alle zur App gehörenden ausführbaren Dateien und Bibliotheken werden entweder auf Dateiebene verschlüsselt und/oder wichtige Code- und Datensegmente innerhalb der ausführbaren Dateien werden verschlüsselt oder gepackt. Eine triviale statische Analyse enthüllt keinen wichtigen Code oder wichtige Daten.  

Wir bieten verschiedene Verschlüsselungslösungen sowohl für Code als auch für Daten. Beispielsweise auf Android: Digital.ai Application Security Die Unterstützung von DEX-Verschlüsselung und nativer Shared-Library-Verschlüsselung, gepaart mit unserer White-Box-Kryptografie und unseren Anti-Debugging- und Instrumentierungsfunktionen, würde das Produkt sowohl statisch als auch dynamisch abdecken und den Angreifer ahnungslos machen. 

 MSTG-RESILIENCE-12  

Wenn das Ziel der Verschleierung darin besteht, sensible Berechnungen zu schützen, wird unter Berücksichtigung aktuell veröffentlichter Forschungsergebnisse ein Verschleierungsschema verwendet, das sowohl für die Aufgabe geeignet als auch robust gegenüber manuellen und automatisierten Entschleierungsmethoden ist. Die Wirksamkeit des Verschleierungsschemas muss durch manuelle Tests überprüft werden. Beachten Sie, dass hardwarebasierte Isolationsfunktionen nach Möglichkeit der Verschleierung vorgezogen werden. 

Jede Verschleierung kann irgendwann besiegt werden, aber gute Verschleierer können nicht automatisch entschleiert werden. Unsere Verschleierungstechniken umfassen viele aktive Schutzmaßnahmen gegen De-Obfuscators und Emulatoren und werden mit allen öffentlich verfügbaren Lösungen, einschließlich JEB-Decompilern, getestet.

MSTG-RESLIENCE-13

Als Tiefenverteidigung kann neben einer soliden Absicherung der kommunizierenden Parteien auch eine Nutzdatenverschlüsselung auf Anwendungsebene eingesetzt werden, um das Abhören weiter zu verhindern.  

Um die Kommunikation abzuhören, stehen einem Angreifer drei Hauptmethoden zur Verfügung:  

1. Führen Sie einen MITM-Angriff (Man in the Middle) durch (z. B. Entfernen des Zertifikat-Pinnings) 
2. Manipulation der Kryptografiefunktionen
3. Manipulation der Netzwerkfunktion 

Unsere Application Security Die Lösung erkennt jede Art von Manipulation, einschließlich Manipulationen am eigenen Code des Betriebssystems. Unser Schlüssel- und Datenschutzprodukt kann mit öffentlich verfügbaren Tools nicht automatisch erkannt werden. Zusammen verhindern diese beiden Lösungen die drei oben beschriebenen Methoden.  

L1-Anforderungen

MSTG-ARCH-1 

Alle App-Komponenten sind identifiziert und als notwendig bekannt.  

Als Softwareentwickler möchten wir, dass unser Code so schlank und effizient wie möglich ist. Aus Sicherheitsgründen könnte das Entfernen unnötigen Codes jedoch Ihre Angriffsfläche vergrößern. Bei mobilen Anwendungen könnte schlanker Code eine schlechte Sache sein. Kleinere identifizierbare Komponenten sind ein Jackpot für Angreifer. Code-Verschleierung ist die erste Verteidigungslinie gegen statisches Reverse Engineering und eine schlanke und logische Codierung macht Angreifern leider das Leben leichter.

MSTG-ARCH-10  

Sicherheit wird in allen Teilen des Softwareentwicklungslebenszyklus berücksichtigt. Es ist sehr einfach, einen Scheck zu markieren und mit dem nächsten fortzufahren.  

Bei Sicherheit geht es vor allem um Aufmerksamkeit, und sie bringt Sie immer an Orte, die Sie am wenigsten erwartet haben. Digital.ai Application Security schützt Ihre App sowohl als Blackbox, die nicht manipuliert werden kann, und bietet gleichzeitig strategische Funktionen, mit denen Sie sich auf defekte Umgebungen verlassen können.

MSTG-SPEICHER-1  

Für die Speicherung sensibler Daten wie PII und Benutzeranmeldeinformationen müssen Speichereinrichtungen für Systemanmeldeinformationen verwendet werden, oder kryptografische Schlüssel.  

Im Idealfall sind Systemzugangsdaten die einzige zuverlässige Möglichkeit, sensible Daten zu speichern. Wenn jedoch das Betriebssystem manipuliert wurde, sind Ihre Speichereinrichtungen möglicherweise nicht mehr zuverlässig. Sie sollten sich nicht blind auf solche sicheren Speicher verlassen, um Geheimnisse aufzubewahren. Angesichts vieler verschiedener Techniken zur Identifizierung von Rooting und JB, Emulation und mehr – und angesichts benutzerdefinierter Aktionen pro Bedrohung – könnte ein Angreifer mit dem Ziel zu kämpfen haben, während die nächste Version eingeführt wird, die über völlig andere Schutzmechanismen verfügt, was den Angreifer frustriert. 

MSTG-SPEICHER-10  

Die App speichert vertrauliche Daten nicht länger als nötig im Speicher und der Speicher wird nach der Verwendung explizit gelöscht.  

Unsere White-Box-Kryptographie bietet eine automatische Verwaltung des Sitzungsschlüssels und dessen Evakuierung. Neben der Kryptographie Digital.ai Application Security könnte auch das gesamte Betriebssystem auf unzulässige Speicherzugriffe überwachen, sodass der Kunde mit einer maßgeschneiderten Logik reagieren kann. 

MSTG-CRYPTO-2  

Die App nutzt bewährte Implementierungen kryptografischer Grundelemente. 

Kryptographie-Implementierungen bergen viele potenzielle Fallstricke, und man muss ein Experte auf diesem Gebiet sein, um solche Algorithmen mit der richtigen Vorsicht zu implementieren. Glücklicherweise, Digital.ai Application Security bietet viele verschiedene kryptografische Algorithmen, denen Sie vertrauen und die Sie sofort verwenden können. Es gibt einige Probleme mit bekannten und bewährten Kryptografiebibliotheken. Einige Bibliotheken wie OpenSSL, Mbed-TLS und die von den Betriebssystemen Android und iOS bereitgestellten Bibliotheken haben identifizierbare binäre Signaturen, die es Angreifern ermöglichen, sensible Bereiche im Code zu lokalisieren und sogar einige Prozesse wie das Aufheben von Zertifikaten zu automatisieren. Unsere Manipulationsschutz Die Lösung schützt vor Manipulationsszenarien, in denen der Zielcode solche öffentlichen Bibliotheken verwendet, und bietet gleichzeitig eine vollständig eingebettete, geschützte und versteckte Kryptografielösung im Code, die verhindert, dass Angreifer Spuren unserer kryptografischen Lösung sehen. 

MSTG-PLATTFORM-1  

Die App fordert nur die erforderlichen Mindestberechtigungen an. 

Unsere Technologie gewährt viele Sicherheitsfunktionen, ohne dass eine besondere Genehmigung erforderlich ist.

MSTG-CODE-1  

Die App wird signiert und mit einem gültigen Zertifikat versehen, dessen privater Schlüssel ordnungsgemäß geschützt ist. 

Neben den betriebssystemeigenen Integritätsmechanismen, Digital.ai Application Security Bietet Techniken zur Erkennung und zum Schutz vor Neuverpackung und In-Memory-Patching.

Schlussfolgerungen und weitere Denkanstöße

Das MASVS ist ein echtes Dokument, das von Freiwilligen verfasst wurde und für Anbieter mobiler Softwaresicherheit, deren Interessenten und Kunden unverzichtbar ist. Wir hoffen, dass der obige Text unseren Lesern einen Leitfaden zu den Empfehlungen in den Abschnitten L1 und R des Dokuments bietet. Im Folgenden finden Sie einige Kommentare zu einigen Positionen, die das MASVS im „Forward“ vertritt, insbesondere zu den Abschnitten, in denen zwischen „Sicherheitsschutz“ und „Sicherheitskontrollen“ unterschieden wird und die unserer Meinung nach einer weiteren Diskussion bedürfen. 

Wie in der Einleitung erwähnt, bilden die von MASVS spezifizierten L1-Anforderungen eine Grundlage dafür application security und insbesondere Sicherheit in Bezug auf den Datenschutz. Wir glauben, dass das Fundament, das das MASVS identifiziert, im Wesentlichen dadurch erschüttert werden kann, dass Bedrohungsakteure sich einiger allgemein verfügbarer und häufig verwendeter Emulatoren, Debugger und dynamischer Instrumentierungs-Toolkits bedienen. Wenn zum Beispiel im MASVS „Forward“ steht: „Software-Schutzmaßnahmen sind nicht nutzlos, aber sie können letztendlich umgangen werden, daher dürfen sie niemals als Ersatz für Sicherheitskontrollen verwendet werden.“ Wir entgegnen dem, selbst wenn Programmierer sich in puncto Sicherheit auf das Betriebssystem verlassen und alle L-1-Anforderungen bis ins kleinste Detail befolgen, die L-1-Anforderungen keine grundlegende Sicherheitsfunktionalität bieten, wenn das zugrunde liegende Betriebssystem defekt ist (z. B. mit Jailbreak oder Root). ). In diesem Fall ist das Gegenteil der Fall – die Verwendung von Softwareschutzmaßnahmen wie der Manipulationserkennung, wie im Abschnitt „Ausfallsicherheit“ beschrieben, ist der einzige zuverlässige Weg zur Sicherheit. Warum glauben wir, dass dies der Fall ist? Nehmen Sie zum Beispiel Ihren Keystore.  Wenn Ihr Keystore vollständig verfügbar ist, ist dies auch für die Sandbox Ihrer Anwendung der Fall. In diesem Fall könnten die App und ihre Dateien manipuliert, neu verpackt und instrumentiert werden – was einige Prozesse automatisieren könnte, wie etwa das Entfernen von Zertifikaten und die Ressourcenextraktion. Darüber hinaus gibt es Fälle, in denen L-1 die Privatsphäre nicht ausreichend schützt.  Malware für mobile Geräte kann beispielsweise das mobile Betriebssystem beschädigen und es Angreifern leicht machen, Instant Messaging- oder VOIP-Apps abzuhören, indem sie strategische APIs oder öffentliche Frameworks durch die Identifizierung ihrer Binärsignaturen einbindet.

Auch im Forward behauptet das MASVS „Bei mobiler Sicherheit dreht sich alles um Datenschutz“.  Das trifft oft zu, aber nicht immer. Wenn Sie mit vertraulichen Informationen wie kurzlebigen Token arbeiten, müssen Sie sicherstellen, dass diese Informationen nicht zugänglich sind. Sicherheit ist mehr als Datenschutz – sie ist oft mit Geschäftskontinuität und Umsatz verbunden. Spiele beispielsweise, bei denen viele Transaktionen im Spiel stattfinden, wirken sich möglicherweise nur auf die Clientseite aus. Darüber hinaus zwingen viele Spielereignisse den Server aus Latenzgründen dazu, Benutzereingaben zu vertrauen. Beispielsweise erfordern Schüsse in einem FPS-Spiel viele Optimierungen aufgrund der inhärenten Häufigkeit dieses bestimmten Ereignisses – normalerweise ein Ereignis pro Kugel. 

Clientseitige Sicherheit ist ein fortlaufendes Katz-und-Maus-Spiel. Wenn App-Entwickler/Programmierer ausreichend Schutz bieten, wird der Angreifer aus Frustration ein anderes Ziel wählen. Darüber hinaus macht die Veröffentlichung häufiger Client-Updates mit polymorpher Verschleierung die laufende Recherche aktueller Anwendungen wertlos und frustriert Angreifer dadurch noch mehr.

Für weitere Informationen über Digital.ai Application Security, klicken hier.