Wenn es um mobile Sicherheit geht, sind Sie möglicherweise nicht damit vertraut, da die Forschung in diesem Bereich erst in den letzten Jahren populär geworden ist. Was ist also mobile Sicherheit? Zunächst einmal wissen wir, dass mobile Sicherheit nichts anderes ist als einige Sicherheitsprobleme auf der iOS- und Android-Plattform, darunter einige Probleme im Plattformsystem selbst und Probleme auf Anwendungsebene. Natürlich müssen bei der Interaktion zwischen Client und Server einige Kommunikationsprotokolle beteiligt sein, hauptsächlich http- und https-Protokolle und natürlich einige andere Protokolle wie Websocket usw. Wir werden den Mängeln dieser Protokolle selbst nicht allzu viel Aufmerksamkeit schenken. Wir müssen darauf achten, ob die Datenpakete bei Bedarf während der Übertragung verschlüsselt werden, ob der Server die Betriebsberechtigungen des Benutzers und einige Dienste auf dem Server kontrolliert . Ob es Fehler in der logischen Verarbeitung usw. gibt. Die Ideen in diesem Aspekt ähneln im Wesentlichen der Web-Penetration, es gibt jedoch einige Unterschiede.
Wenn es um mobile Sicherheit geht, sind Viren und Trojaner-Angriffe natürlich unverzichtbar, darunter Droidjack, SpyNote usw. sowie vor einiger Zeit aufgetauchte Telefonsperrsoftware .
Abbildung 1 Droidjack
Abbildung 2 Sperrsoftware
Angreifer können Software wie Droidjack verwenden, um Trojaner zu generieren. Diese Art von bösartigen Trojanern gibt es im Allgemeinen auf einigen drittklassigen APK-Märkten. Im Allgemeinen werden Angreifer einige verlockende Informationen in diese APKs einfügen, wie z. B. das kostenlose Ansehen von bestimmten Schönheitsvideos, einen werbefreien Client für bestimmte Videos, einen bestimmten coolen Bildbrowser usw. Nachdem der Angreifer diese APKs mit verlockenden Informationen im Internet veröffentlicht hat, startet er ein Serverprogramm auf dem Remote-Server. Sobald der Benutzer dieses Schadprogramm installiert und ausführt, kann der Hacker das Mobiltelefon des Benutzers auf dem Remote-Server überwachen. verschiedene Verhaltensweisen und stehlen die privaten Daten der Benutzer.
Letztendlich sind diese Angriffe auf Trojaner-Virenebene hauptsächlich auf das schwache Sicherheitsbewusstsein der Benutzer zurückzuführen, sodass sie nicht das Hauptthema der Diskussion sein werden. Wir werden hauptsächlich die Sicherheit von Android-Anwendungen diskutieren.
Wie ermitteln wir also App-Schwachstellen? Erstens möchten Sicherheitsmitarbeiter, die von Web-Sicherheit auf mobiles Schwachstellen-Mining umgestiegen sind, natürlich nach Schwachstellen suchen, die ihrem eigenen Bereich ähneln. Die Serverseite der App ist im Grunde die gleiche wie die Serverseite in der App Der Unterschied besteht darin, dass es sich bei dem Client eher um einen Browser handelt, während mobile Anwendungen im Allgemeinen über ein App-Programm verfügen, das auf einem mobilen Gerät installiert werden kann. Daher können wir für das Mining von Schwachstellen auf App-Servern weiterhin unsere bisherigen Web-Erfahrungen nutzen, um einige der Schwachstellen wie XSS, SSRF, SQL-Injection und das Lesen beliebiger Dateien zu ermitteln.
Bei der Suche nach Schwachstellen in Webanwendungen können wir einen Proxy im Browser konfigurieren, um Pakete zu erfassen und unsere Webanwendungen zu analysieren. Wie sollten wir also eine Paketanalyse für mobile Anwendungen durchführen?
Tatsächlich basiert die Paketanalyse von Android-Anwendungen auch auf Proxys, die Proxy-Konfiguration ist jedoch relativ kompliziert. Nachdem wir die entsprechenden Agenten in Burptsuit oder Fiddler konfiguriert haben, können wir diese zum Abfangen und Wiedergeben von Datenpaketen verwenden. Die einzelnen Schritte werden hier nicht im Detail erläutert. Es gibt Online-Tutorials, die Sie selbst ausprobieren können.
Auf einige klassische Schwachstellen wie XSS und SQL-Injection werde ich hier nicht näher eingehen. Hier werde ich hauptsächlich auf die nicht autorisierten Schwachstellen mobiler Anwendungen eingehen. Wir wissen, dass in der Web-Sicherheit Schwachstellen durch unbefugten Zugriff normalerweise dadurch verursacht werden, dass der Server keine Berechtigungsüberprüfung für Benutzeranfragen durchführt und Benutzeranfragen nur auf der Grundlage von Benutzer-IDs ausführt. Was ist also der richtige Authentifizierungsprozess? Eine kurze Textbeschreibung lautet: Nachdem sich der Benutzer erfolgreich angemeldet und authentifiziert hat, schreibt der Server die Identität der Benutzerberechtigungen in ein Cookie und gibt sie dann an den Browser zurück. Der Browser speichert dieses Cookie Wenn Sie dieses Cookie in nachfolgenden Anforderungspaketen verwenden, überprüft der Server das Cookie im Datenpaket, um Benutzerberechtigungen zu identifizieren und Vorgänge mit entsprechenden Berechtigungen auszuführen.
Abbildung 3 Cookie-Authentifizierungsprozess
Natürlich gibt es noch eine andere Authentifizierungsmethode, nämlich die Sitzungsauthentifizierung. Sowohl die Sitzungsauthentifizierung als auch die Cookie-Authentifizierung können die Identität des Benutzers authentifizieren. Was ist also der Unterschied zwischen Sitzungsauthentifizierung und Cookie-Authentifizierung?
Einfach ausgedrückt werden Cookies auf der Clientseite und Sitzungen auf der Serverseite gespeichert. Aus Sicherheitsgründen sind Cookies relativ unsicher, während Sitzungen relativ sicher sind, da Cookies auf der Clientseite gespeichert werden und Angreifer Cookies auf der Clientseite erhalten können. Wenn das zur Identifizierung der Benutzeridentität verwendete Feld nicht verschlüsselt ist, ist dies der Fall Wenn die Aufzählung einfach ist, kann der Angreifer Cookies fälschen und nicht autorisierte Vorgänge ausführen. Wenn die Sitzungsauthentifizierung aktiviert ist, erhält der Client die entsprechende Sitzungs-ID erst nach erfolgreicher Anmeldung. Diese ID ist eine verschlüsselte Zeichenfolge und kann nicht durchlaufen werden.
Wie sieht also der Zertifizierungsprozess aus? Zunächst müssen wir wissen, dass die Sitzungsauthentifizierung auch auf Cookies basiert. Nachdem sich der Benutzer erfolgreich angemeldet hat, schreibt der Server die entsprechende Sitzung des Benutzers in die Datenbank des Servers dann wird der Server Die dieser Sitzung entsprechende ID wird an den Client gesendet, sodass der Inhalt des Cookies im Client im Allgemeinen nur eine Zeichenfolge von sessionid = xxxxxx ist. Der Benutzer muss diese Sitzungs-ID in nachfolgenden Anforderungen mitbringen. Der Server identifiziert die Sitzungs-ID, fragt dann die Datenbank ab, um die entsprechenden Benutzerberechtigungsinformationen zu erhalten, und bestimmt dann, ob der Benutzer über die Berechtigung zum Ausführen des Antwortvorgangs verfügt.
Natürlich ist der Sitzungsmechanismus relativ sicherer, aber die andere Seite der Sicherheit hat auch ihren Preis. Im Vergleich zu Cookies verbraucht der Sitzungsmechanismus mehr Serverleistung.
Abbildung 4 Sitzungsauthentifizierungsprozess
Auf der mobilen Seite verwendet die Benutzeridentitätsauthentifizierung jedoch keine Cookies, sondern basiert auf der Token-Identifizierung. Um welche Authentifizierungsmethode handelt es sich also? Um es kurz auszudrücken: Der Authentifizierungsprozess ist im Allgemeinen wie folgt: Nach erfolgreicher Client-Anmeldeüberprüfung gibt der Server eine Token-Zeichenfolge zurück. Der Benutzer interagiert dann mit dem Server. Sie müssen diesen Token mitbringen, damit die Identität des Benutzers identifiziert werden kann.
Abbildung 5 Token-Authentifizierungsprozess
Wenn wir bei der Analyse des Datenpakets eine Anfrage ohne Token finden, weist dieses Datenpaket wahrscheinlich eine Schwachstelle für unbefugten Zugriff auf. Natürlich muss es mit dem spezifischen Szenario kombiniert werden . Analysieren und bestimmen Sie, ob es Auswirkungen auf die Geschäftslogik hat. Dies ist unsere allgemeine Haltung zum Aufspüren nicht autorisierter Schwachstellen auf dem mobilen Endgerät. Diese Haltung ist jedoch zu geistig zurückgeblieben. Grundsätzlich kann jeder, der darauf stößt, sie ertragen.
Es gibt eine andere Möglichkeit, nach Schwachstellen bei unbefugtem Zugriff zu suchen, die ziemlich seltsam erscheint. Die Hauptursache dieser Schwachstelle bei unbefugtem Zugriff ist der Fehler in der Authentifizierungsstrategie selbst. Ich erinnere mich, dass ich vor langer Zeit eine Protokollanalyse einer Live-Übertragungssoftware durchgeführt habe und festgestellt habe, dass die Authentifizierungslogik wie folgt lautet: Nach erfolgreicher Überprüfung der Benutzeranmeldung gibt der Server die Benutzer-ID zurück und erstellt dann lokal das Benutzertoken . Bringen Sie bei nachfolgenden Anfragen dieses Token als Nachweis der Benutzeridentität mit. Dies ist offensichtlich fehlerhaft, da die Benutzer-ID durchquert werden kann und der Token-Generierungsalgorithmus lokal ist, sodass der Angreifer das Token selbst berechnen kann, solange er die IDs anderer Benutzer erhält und den lokalen Token-Generierungsalgorithmus extrahiert dann hat sich der gefälschte Benutzer angemeldet.
Natürlich ist es immer noch relativ schwierig, solche nicht autorisierten Schwachstellen zu entdecken, was erfordert, dass Schwachstellengräber über relativ tiefgreifende Reverse-Analyse- und Codierungsfunktionen verfügen. Als Entwickler dürfen Sie jedoch aufgrund dieser Schwierigkeit die Verstärkung der Anwendungssicherheit nicht lockern. Insbesondere die Benutzerauthentifizierung, ein sehr wichtiges Funktionsmodul, muss aus Sicherheitsgründen gut geschützt werden.
Was Client-Schwachstellen betrifft, besteht die Hauptmethode darin, den App-Client mithilfe von Dekompilierungstools zu dekompilieren, um dann etwas Erfahrung und Sicherheitswissen zu kombinieren zum statischen Quellcode-Audit. Zu den gängigen Dekompilierungstools gehören Apkide, Jeb, Apktools usw. Machen wir zum besseren Verständnis einen Screenshot:
Bild 6 Prinzip der Veränderung
Bild 7 Jeb
Mein Favorit ist natürlich der Android-Rückfahrassistent, der sehr praktisch ist.
Abbildung 8 Android-Rückwärtsassistent
In Kombination mit Jeb kann es grundsätzlich die tägliche Rückwärtsanalyse erfüllen.
Die Android-Anwendungsplattform ist hauptsächlich in native Layer und Java-Layer unterteilt. Für die Java-Schicht können wir die oben genannten Tools zur Analyse verwenden, und für die native Schicht müssen wir ida zur Analyse verwenden. Ida ist ein sehr einfach zu verwendendes Demontagetool. Wir können die so-Datei der APK über ida zerlegen und dann die f5-Funktion verwenden, um den Arm-Assemblercode in C++-Pseudocode umzuwandeln und den logischen Algorithmus zu analysieren. Es unterstützt auch dynamisches Debuggen und kann APK-Anwendungen aus der Ferne debuggen. Wir können das dynamische Debuggen von ida verwenden, um einige Überprüfungen in der So-Schicht zu umgehen, z. B. die Überprüfung der sekundären Verpackung, oder dynamisches Debuggen und Shelling durchzuführen.
Apropos Anwendungs-Shelling, dies ist während des APK-Analyseprozesses sehr wichtig. Bevor wir über das Auspacken sprechen, wollen wir zunächst verstehen, was Packen ist. Packen bedeutet, zunächst die Kontrolle über das Programm zu erlangen, bevor die Anwendung ausgeführt wird, und dann die Kontrolle über das Programm an das ursprüngliche Programm zu übertragen. Die Packimplementierung auf der Android-Plattform besteht darin, die ursprüngliche Dex-Datei zu verschlüsseln und zu verbergen und dann die ursprüngliche Dex-Datei über das Shell-Programm abzurufen und sie dann wiederherzustellen. Eine andere Methode besteht darin, die Funktionsanweisungen zu extrahieren und Hooks zu verwenden, um beim Ausführen zu reagieren. Die Klassenladefunktion füllt die Anweisungen zurück.
Bei gepackten Anwendungen ist die Logik des Originalprogramms grundsätzlich nicht erkennbar und wir können keine Sicherheitsanalyse über das gepackte Programm durchführen. Daher müssen wir die Anwendung entpacken. Zu den gängigen Tools zum automatischen Entpacken gehören Drizzledump und Dexhunter. Dexhunter ist einfach zu verwenden, erfordert jedoch ein Flashen und wurde von vielen Verschlüsselungsanbietern überprüft. Daher funktioniert es nicht, wenn Sie es direkt verwenden. Sie müssen einige Änderungen vornehmen und einige Erkennungsfunktionen umgehen. Zur detaillierten Verwendung finden Sie Online-Tutorials, daher werde ich hier nicht näher darauf eingehen. Wenn das Tool nicht funktioniert, müssen Sie am Ende zu ida gehen.
Werfen wir einen detaillierten Blick auf die Probleme, auf die bei der Sicherheitserkennung auf Quellcodeebene geachtet werden muss.
Komponentensicherheit
Das erste ist das Sicherheitsproblem von Komponenten. Wir wissen, dass Android-Anwendungen vier Hauptkomponenten haben, nämlich Aktivität und Dienst , Inhaltsanbieter, Rundfunkempfänger. Wenn diese Komponenten nicht unbedingt erforderlich sind, sollte ihr Exportattribut exported auf false gesetzt werden, d. h. der Export ist verboten. Wenn es auf „true“ gesetzt ist, wird es von externen Anwendungen aufgerufen, was zu Informationsverlust, Berechtigungsumgehung und anderen Schwachstellen führen kann. Darüber hinaus kann es bei der Verwendung von Intent.getXXXExtra() zum Abrufen oder Verarbeiten von Daten zu einer Denial-of-Service-Sicherheitslücke kommen, wenn try...catch nicht für die Ausnahmebehandlung verwendet wird. Zu diesen Ausnahmen gehören unter anderem: Nullzeiger-Ausnahmen, Typkonvertierungsausnahmen und Array-Ausnahmen. Ausnahmen für den Zugriff außerhalb der Grenzen, Ausnahmen für undefinierte Klassen, Serialisierungs- und Deserialisierungsausnahmen.
Wie die oben erwähnte Komponentensicherheit beurteilen wir sie normalerweise anhand der Analyse der androidManifest.xml-Datei von Android. AndroidManifest.xml ist die Eintragsdatei für Android-Anwendungen. Sie beschreibt die im Paket bereitgestellten Komponenten (Aktivitäten, Dienste usw.), ihre jeweiligen Implementierungsklassen, verschiedene Daten, die verarbeitet werden können, und den Startort. Zusätzlich zur Deklaration von Aktivitäten, ContentProvidern, Diensten und Absichtsempfängern im Programm können auch Berechtigungen und Instrumentierung (Sicherheitskontrolle und Tests) angegeben werden. Durch die Analyse dieser manifest.xml-Datei können wir auch Schwachstellen wie die Sicherung von Anwendungsdaten und die Optimierung der Anwendung entdecken. Natürlich handelt es sich bei diesen Schwachstellen im Allgemeinen um Schwachstellen mit relativ geringem Risiko, das heißt, sie haben keine großen Auswirkungen auf die Geschäftslogik des Programms. Aufgrund der Schwachstelle bei der Debugging-Funktion von Anwendungen werden Angreifer nicht daran gehindert, die Anwendung zu debuggen, selbst wenn Debuggable so eingestellt ist, dass sie Angreifern das Debuggen der Anwendung verbieten, da Entwickler nur das Debuggen der Anwendung selbst steuern können, nicht jedoch das System des Benutzers . Ein Angreifer kann alle Anwendungen im System debuggen, indem er eine Eigenschaft im Speicher festlegt, unabhängig davon, ob die Anwendung zum Debuggen eingestellt ist. Es ist jedoch dennoch erforderlich, diese Einstellung vorzunehmen, um das Debuggen hier zu deaktivieren, da nicht alle Reverse-Analysten wissen, dass diese Einstellung umgangen werden kann.
Webview-Sicherheitsproblem
Um zu sagen, dass es in Android-Clientanwendungen schwerwiegendere Schwachstellen gibt, muss es sich um Webview-Schwachstellen handeln. Viele Apps verfügen mittlerweile über integrierte Webseiten, wie zum Beispiel viele E-Commerce-Plattformen, Taobao, JD.com, Juhuasuan usw., wie unten gezeigt:
Man kann sagen, dass die Webview-Komponente ein zweiseitiges Schwert ist. Einerseits kann ihr Aussehen die Belastung der Client-Entwicklung verringern und die Hauptlogik des Programms zur lokalen Implementierung bereitstellen webview, um die entsprechende Webseite zu laden. Bei unsachgemäßer Konfiguration können jedoch Sicherheitslücken bei der Remote-Befehlsausführung bestehen. Zu den relevanten CVEs gehören CVE-2012-6636, CVE-2014-1939 und CVE-2014-7224.
cve-2012-6636 Diese Sicherheitslücke wird dadurch verursacht, dass das Programm die Verwendung der WebView.addJavascriptInterface-Methode nicht korrekt einschränkt. Ein entfernter Angreifer könnte diese Schwachstelle ausnutzen, um mithilfe der Java Reflection API beliebige Java-Objektmethoden auszuführen.
cve-2014-1939 Diese Sicherheitslücke ist darauf zurückzuführen, dass java/android/webkit/BrowserFrame.java die API addJavascriptInterface verwendet und ein Objekt der SearchBoxImpl-Klasse erstellt, um beliebigen Java-Code auszuführen, indem er auf die Schnittstelle searchBoxJavaBridge_ zugreift .
cve-2014-7224 Der Angreifer nutzt hauptsächlich die beiden Java Bridges Accessibility und AccessibilityTraversal, um Remote-Angriffscode auszuführen.
Die Generierung der Ausführung von Webview-Remotebefehlen basiert auch auf dem Reflexionsmechanismus von Java. Die addJavascriptInterface-Methode in Webview kann ein Java-Objekt in WebView einfügen, und auf die Methoden dieses Java-Objekts kann über Javascript zugegriffen werden. Der Grund, warum addJavascriptInterface bereitgestellt wird, besteht darin, dass Javascript in WebView mit der lokalen App kommunizieren kann. Dies ist in der Tat eine sehr leistungsstarke Funktion. Der Vorteil besteht darin, dass das Programm aktualisiert werden kann, ohne die App zu aktualisieren, und die entsprechende Webseite geändert werden kann. In den frühen Versionen von Android gab es jedoch keine Einschränkungen hinsichtlich der zugänglichen Methoden. Mithilfe des Reflexionsmechanismus von Java können Sie jede Methode eines beliebigen Objekts aufrufen. Dies ist die grundlegende Ursache der WebView-Sicherheitslücke.
Apk-Update-Paket-Angriff (Man-in-the-Middle-Angriff)
Die oben genannten Schwachstellen kommen in Android-Anwendungen relativ häufig vor und haben relativ große Auswirkungen. Es gibt jedoch auch einige Schwachstellen, die relativ geringe Auswirkungen haben Bei richtiger Anwendung können sie dennoch schädlich sein. Beispielsweise erfordert ein Man-in-the-Middle-Angriff, dass sich Angreifer und Opfer im selben LAN befinden und der Datenverkehr des Opfers vom Angreifer kontrolliert wird. Was kann ein Man-in-the-Middle-Angriff bewirken? XSS spielen? Benutzer-Cookie erhalten? Natürlich ist es hier offensichtlich sinnlos, das Benutzer-Cookie abzurufen, es sollten die Token-Informationen sein. Bei mobilen Angriffen können richtig ausgenutzte Man-in-the-Middle-Angriffe sogar zur Remote-Befehlsausführung führen. Beispielsweise wird das heruntergeladene Update-Paket beim Aktualisieren der Anwendung kontrolliert und durch ein böswilliges Angriffsdatenpaket ersetzt. Die Anwendung führt das Update-Programm im vom Angreifer geänderten Rückgabepaket aus, ohne die erforderliche Signaturüberprüfung für das Update-Paket durchzuführen Problem. Kann dazu führen, dass Schadprogramme ausgeführt werden.
Lassen Sie mich unten über meine Implementierungsidee sprechen. Zunächst wissen wir, dass unsere Hauptanalyseobjekte AndroidManifest.xml- und Dex-Dateien sind, aber diese beiden sind kompilierte Binärdateien und wir müssen sie dekompilieren. Das zum Dekompilieren von AndroidManifest.xml benötigte Tool ist AXMLPrinter.jar und die zum Dekompilieren von Dex-Dateien benötigte Datei ist baksmali.jar. Tatsächlich werden diese beiden JAR-Pakete auch häufig von einigen Reverse-Engineering-Tools verwendet. Werfen wir einen Blick auf das Programmverzeichnis des Android Reverse Assistant-Dekompilierungstools:
Abbildung 10 Programmverzeichnis des Android Reverse Assistant
Dieses Reverse-Tool namens Android Reverse Assistant verwendet hauptsächlich diese beiden Tools, um die mit der Dex-Datei dekompilierte AndroidManifest zu implementieren .
Solange wir die entsprechende Logik in unser automatisiertes Leak-Scan-Tool schreiben und diese beiden Tools aufrufen, um die AndroidManifest- und Dex-Dateien zu dekompilieren, können wir die Schwachstelle erkennen, indem wir einige Schwachstellenmerkmale abgleichen.
Das Folgende ist eine kurze Einführung in die Projektverzeichnisstruktur:
Abbildung 11 Apk-Schwachstellenscan-Projektverzeichnis und Einführung
Zuerst benötigen wir den Paketnamen der Anwendung und ermitteln dann einige Einstellungen der Anwendung, z. B. ob die Sicherung zulässig ist, ob sie einstellbar ist usw. Anschließend erhalten wir einige Konfigurationsinformationen zu den vier Komponenten Aktivität, Dienst und Inhalt Anbieter, Rundfunkempfänger und bestimmen, ob es exportiert werden kann. Anschließend werden die von der Anwendung angewendeten Berechtigungen ermittelt, um festzustellen, ob die von der Anwendung selbst erstellten Berechtigungen zu hoch sind.
Führen Sie als Nächstes die Erkennung von Schwachstellenfunktionen für die dekompilierte Smali-Datei durch. Dies beruht hauptsächlich auf den Schwachstellenmerkmalen, die wir im Voraus gesammelt haben. Hier schreibe ich die Schwachstellenmerkmale in eine XML-Datei und lade sie beim Starten des Schwachstellenscans in den Speicher, damit das Programm sie aufruft. Wir können diese Schwachstellenmerkmale anpassen, sodass unser Programm mehr Schwachstellen scannen kann. Derzeit unterstützt die Definition von Schwachstellenmerkmalen Zeichenfolgen und reguläre Formen. Dieses Projekt befindet sich noch in der Wartung, aber die Grundfunktionen wurden implementiert und können die täglichen Scans und Erkennungen durchführen. Führen Sie einfach einige Fehlerbehebungen an den Scan-Ergebnissen durch.
3. Sicherheitslücke bei der erzwungenen Typkonvertierung Lokale Denial-of-Service-Schwachstellen5, Schwachstelle im Intent-Schema-URL6, Schwachstelle in der Inhaltsanbieterkomponente, lokale SQL-Injection7, Sicherheitserkennung beim dynamischen Laden von Code8, Schwache Überprüfung des Zertifikats9, Schwache Überprüfung des Hostnamens 10, Schwachstelle beim Hijacking sensibler HTTPS-Daten11, Hash-Algorithmus ist unsicher12, AES schwache Verschlüsselung13, Locat gibt private Informationen preis14, Protokollverlustrisiko15, PendingIntent-Missbrauchsrisiko16, Absicht implizit Rufen Sie 17 auf. Beliebiges Lesen und Schreiben von Datenbankdateien18. Erkennung von Sicherheitslücken in WebView-Komponenten aus der Ferne20. WebView ignoriert die Erkennung von SSL-Zertifikatfehlern Speicherpasswort22. Das Lesen und Schreiben von Dateien ist unsicher25. Überprüfen Sie, ob die Anwendung anpassbar ist 27. Prüfung der Anwendungsberechtigungen 2. Klicken Sie auf AndroidCodeCheck.exe oder führen Sie Python aus. AndroidCodeCheck.py kann zum Durchführen von Schwachstellenscans verwendet werden. Der Berichtsausgabepfad befindet sich im TXT-Format des Berichts gilt als Laufprotokoll des Programms und kann auch als Referenz für die Scan-Ergebnisse verwendet werden.2) HTML-Format
Der Bericht im HTML-Format verfügt über ein Verzeichnis. Klicken Sie auf den Schwachstellennamen im Verzeichnis, um zur entsprechenden Schwachstellentypbeschreibung zu springen. In der Typbeschreibung können Sie auf „Zurück zum Verzeichnis“ klicken, um zur Schwachstellenverzeichnisliste zurückzukehren und die Schwachstellenüberprüfung zu erleichtern. Abschließend gebe ich Ihnen einen Screenshot des Schwachstellen-Scan-Berichts. Er ist etwas grob und wird später schrittweise verbessert.首 Abbildung 12 Berichtsverzeichnis-HomepageAbbildung 13 Schwachstellen
5, Projektadresse
APK Static Source Code Sweeping Tool Projektadresse:
https://github.com/zsdlove/ApkVulCheckNach dem Login kopieren
Das obige ist der detaillierte Inhalt vonSo analysieren Sie die APK-Sicherheit und automatisieren die Prüfung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
