Sichere Kodierungstechnik: Das Problem der benutzerdefinierten Berechtigung
Bei der Entwicklung für Mobiltelefone müssen Anwendungen oft einige Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, auf die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu senden. Alle oben genannten Berechtigungen sind Plattformberechtigungen, die durch das Android-Framework definiert sind.
Aber es gibt Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigene benutzerdefinierte Berechtigung definieren muss. Ich nehme unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die einige private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Und wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihr die Erlaubnis dazu gibt. Dies sind sensible Daten, der Benutzer möchte sicherlich nicht, dass irgendjemand diese Daten kennt, aber die SCWApp sollte sie nicht komplett verstecken und schützen, da sie nützlich sein könnten. Also möchten wir dem Benutzer die Kontrolle darüber geben. Hier kommen die benutzerdefinierten Berechtigungen ins Spiel.
Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf White-Listed-Anwendungen zu beschränken.
Leider gibt es einige unintuitive Verhaltensweisen rund um benutzerdefinierte Berechtigungen, die sie aus Sicherheitsaspekten riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App zu jeder Zeit definiert werden, und "der Erste gewinnt", und diese Strategie hat einige Konsequenzen.
Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind zu Demonstrationszwecken fiktiv):
1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mit dieser Berechtigung verteidigt.
2. DevTrainer: diese App definiert die gleiche Berechtigung wie SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung besitzen möchte.
Dies ist ein häufiges Szenario, das als "Peer Apps Case" bezeichnet wird. Wenn die DevTrainer-App nur ein Plugin für die SCWApp wäre, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer irgendwie DevTrainer zuerst installiert, wird der Benutzer nicht über die Anforderung der Berechtigung informiert. Wenn der Benutzer dann später SCWApp installiert, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die gesicherte Komponente zu verwenden, fehlschlagen.
Hier kommt der Fall der Peers-App ins Spiel. In manchen Fällen können Sie nicht erwarten, dass eine App vor der anderen installiert wird. Sagen wir, wenn Facebook und Twitter beide die Komponenten des jeweils anderen nutzen wollen, müssen sie die benutzerdefinierten Berechtigungen des jeweils anderen definieren.
An dieser Stelle wird es jedoch knifflig. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über seine Anfrage nach der benutzerdefinierten Berechtigung informiert. Zu diesem Zeitpunkt, obwohl der Benutzer nicht informiert wurde, besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die gesicherte Komponente zugreifen.
Es wird noch kniffliger. Die DevTrainer-App kann die Berechtigungsschutzstufe ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die Schutzstufe, die zuerst definiert wurde, d.h. diejenige App, die zuerst installiert wurde, kann diese definieren. Das bedeutet, wenn DevTrainer die Berechtigungsstufe auf normal ändert, dann müssen alle zukünftigen Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.
Dieses Szenario wurde durch die Erklärung für dieses Problem inspiriert, die auf dem cwac-security github gefunden wurde.
Die "Wer zuerst kommt, mahlt zuerst"-Strategie hat einige gefährliche Konsequenzen. Wenn der Entwickler das Verhalten nicht kennt, könnte er Sicherheitsentscheidungen auf der Grundlage von nicht vertrauenswürdigen Eingaben treffen und unbeabsichtigten Apps den Zugriff auf sensible Daten oder geschützte Dienste ermöglichen. Um mehr über die Vermeidung von Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben zu erfahren, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da aber derzeit noch mehr als 22 % der Android-Geräte mit einer niedrigeren Version von Android laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie, ob die Berechtigung bereits beim ersten Start Ihrer App definiert wurde und ergreifen Sie in diesem Fall entsprechende Maßnahmen, um eventuelle Sicherheitsrisiken zu beheben.
Viel Glück beim Codieren und bis nächste Woche!
Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.
https://developer.android.com/guide/topics/permissions/defining.html
Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Bei der Entwicklung für Mobiltelefone müssen Anwendungen oft einige Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, auf die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu senden. Alle oben genannten Berechtigungen sind Plattformberechtigungen, die durch das Android-Framework definiert sind.
Aber es gibt Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigene benutzerdefinierte Berechtigung definieren muss. Ich nehme unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die einige private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Und wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihr die Erlaubnis dazu gibt. Dies sind sensible Daten, der Benutzer möchte sicherlich nicht, dass irgendjemand diese Daten kennt, aber die SCWApp sollte sie nicht komplett verstecken und schützen, da sie nützlich sein könnten. Also möchten wir dem Benutzer die Kontrolle darüber geben. Hier kommen die benutzerdefinierten Berechtigungen ins Spiel.
Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf White-Listed-Anwendungen zu beschränken.
Leider gibt es einige unintuitive Verhaltensweisen rund um benutzerdefinierte Berechtigungen, die sie aus Sicherheitsaspekten riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App zu jeder Zeit definiert werden, und "der Erste gewinnt", und diese Strategie hat einige Konsequenzen.
Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind zu Demonstrationszwecken fiktiv):
1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mit dieser Berechtigung verteidigt.
2. DevTrainer: diese App definiert die gleiche Berechtigung wie SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung besitzen möchte.
Dies ist ein häufiges Szenario, das als "Peer Apps Case" bezeichnet wird. Wenn die DevTrainer-App nur ein Plugin für die SCWApp wäre, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer irgendwie DevTrainer zuerst installiert, wird der Benutzer nicht über die Anforderung der Berechtigung informiert. Wenn der Benutzer dann später SCWApp installiert, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die gesicherte Komponente zu verwenden, fehlschlagen.
Hier kommt der Fall der Peers-App ins Spiel. In manchen Fällen können Sie nicht erwarten, dass eine App vor der anderen installiert wird. Sagen wir, wenn Facebook und Twitter beide die Komponenten des jeweils anderen nutzen wollen, müssen sie die benutzerdefinierten Berechtigungen des jeweils anderen definieren.
An dieser Stelle wird es jedoch knifflig. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über seine Anfrage nach der benutzerdefinierten Berechtigung informiert. Zu diesem Zeitpunkt, obwohl der Benutzer nicht informiert wurde, besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die gesicherte Komponente zugreifen.
Es wird noch kniffliger. Die DevTrainer-App kann die Berechtigungsschutzstufe ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die Schutzstufe, die zuerst definiert wurde, d.h. diejenige App, die zuerst installiert wurde, kann diese definieren. Das bedeutet, wenn DevTrainer die Berechtigungsstufe auf normal ändert, dann müssen alle zukünftigen Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.
Dieses Szenario wurde durch die Erklärung für dieses Problem inspiriert, die auf dem cwac-security github gefunden wurde.
Die "Wer zuerst kommt, mahlt zuerst"-Strategie hat einige gefährliche Konsequenzen. Wenn der Entwickler das Verhalten nicht kennt, könnte er Sicherheitsentscheidungen auf der Grundlage von nicht vertrauenswürdigen Eingaben treffen und unbeabsichtigten Apps den Zugriff auf sensible Daten oder geschützte Dienste ermöglichen. Um mehr über die Vermeidung von Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben zu erfahren, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da aber derzeit noch mehr als 22 % der Android-Geräte mit einer niedrigeren Version von Android laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie, ob die Berechtigung bereits beim ersten Start Ihrer App definiert wurde und ergreifen Sie in diesem Fall entsprechende Maßnahmen, um eventuelle Sicherheitsrisiken zu beheben.
Viel Glück beim Codieren und bis nächste Woche!
Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.
https://developer.android.com/guide/topics/permissions/defining.html
Bei der Entwicklung für Mobiltelefone müssen Anwendungen oft einige Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, auf die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu senden. Alle oben genannten Berechtigungen sind Plattformberechtigungen, die durch das Android-Framework definiert sind.
Aber es gibt Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigene benutzerdefinierte Berechtigung definieren muss. Ich nehme unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die einige private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Und wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihr die Erlaubnis dazu gibt. Dies sind sensible Daten, der Benutzer möchte sicherlich nicht, dass irgendjemand diese Daten kennt, aber die SCWApp sollte sie nicht komplett verstecken und schützen, da sie nützlich sein könnten. Also möchten wir dem Benutzer die Kontrolle darüber geben. Hier kommen die benutzerdefinierten Berechtigungen ins Spiel.
Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf White-Listed-Anwendungen zu beschränken.
Leider gibt es einige unintuitive Verhaltensweisen rund um benutzerdefinierte Berechtigungen, die sie aus Sicherheitsaspekten riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App zu jeder Zeit definiert werden, und "der Erste gewinnt", und diese Strategie hat einige Konsequenzen.
Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind zu Demonstrationszwecken fiktiv):
1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mit dieser Berechtigung verteidigt.
2. DevTrainer: diese App definiert die gleiche Berechtigung wie SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung besitzen möchte.
Dies ist ein häufiges Szenario, das als "Peer Apps Case" bezeichnet wird. Wenn die DevTrainer-App nur ein Plugin für die SCWApp wäre, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer irgendwie DevTrainer zuerst installiert, wird der Benutzer nicht über die Anforderung der Berechtigung informiert. Wenn der Benutzer dann später SCWApp installiert, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die gesicherte Komponente zu verwenden, fehlschlagen.
Hier kommt der Fall der Peers-App ins Spiel. In manchen Fällen können Sie nicht erwarten, dass eine App vor der anderen installiert wird. Sagen wir, wenn Facebook und Twitter beide die Komponenten des jeweils anderen nutzen wollen, müssen sie die benutzerdefinierten Berechtigungen des jeweils anderen definieren.
An dieser Stelle wird es jedoch knifflig. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über seine Anfrage nach der benutzerdefinierten Berechtigung informiert. Zu diesem Zeitpunkt, obwohl der Benutzer nicht informiert wurde, besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die gesicherte Komponente zugreifen.
Es wird noch kniffliger. Die DevTrainer-App kann die Berechtigungsschutzstufe ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die Schutzstufe, die zuerst definiert wurde, d.h. diejenige App, die zuerst installiert wurde, kann diese definieren. Das bedeutet, wenn DevTrainer die Berechtigungsstufe auf normal ändert, dann müssen alle zukünftigen Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.
Dieses Szenario wurde durch die Erklärung für dieses Problem inspiriert, die auf dem cwac-security github gefunden wurde.
Die "Wer zuerst kommt, mahlt zuerst"-Strategie hat einige gefährliche Konsequenzen. Wenn der Entwickler das Verhalten nicht kennt, könnte er Sicherheitsentscheidungen auf der Grundlage von nicht vertrauenswürdigen Eingaben treffen und unbeabsichtigten Apps den Zugriff auf sensible Daten oder geschützte Dienste ermöglichen. Um mehr über die Vermeidung von Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben zu erfahren, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da aber derzeit noch mehr als 22 % der Android-Geräte mit einer niedrigeren Version von Android laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie, ob die Berechtigung bereits beim ersten Start Ihrer App definiert wurde und ergreifen Sie in diesem Fall entsprechende Maßnahmen, um eventuelle Sicherheitsrisiken zu beheben.
Viel Glück beim Codieren und bis nächste Woche!
Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.
https://developer.android.com/guide/topics/permissions/defining.html
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Bei der Entwicklung für Mobiltelefone müssen Anwendungen oft einige Berechtigungen vom System anfordern. Sie benötigen möglicherweise Zugriff auf die Kontakte des Benutzers, auf die Bluetooth-Verbindung oder die Möglichkeit, SMS-Nachrichten zu senden. Alle oben genannten Berechtigungen sind Plattformberechtigungen, die durch das Android-Framework definiert sind.
Aber es gibt Fälle, in denen diese nicht ausreichen und die Anwendung ihre eigene benutzerdefinierte Berechtigung definieren muss. Ich nehme unser eigenes Unternehmen als Beispiel. Secure Code Warrior könnte eine App erstellen, die einige private Daten als Teil eines Profils speichert, einschließlich der Leistung des Benutzers auf der SCW-Plattform. Und wir möchten einer anderen Sicherheitsschulungs-App, sagen wir DevTrainer, erlauben, diese Daten zu verwenden, wenn der Benutzer ihr die Erlaubnis dazu gibt. Dies sind sensible Daten, der Benutzer möchte sicherlich nicht, dass irgendjemand diese Daten kennt, aber die SCWApp sollte sie nicht komplett verstecken und schützen, da sie nützlich sein könnten. Also möchten wir dem Benutzer die Kontrolle darüber geben. Hier kommen die benutzerdefinierten Berechtigungen ins Spiel.
Die SCWApp erstellt eine benutzerdefinierte Berechtigung, DevTrainer fordert diese Berechtigung an und der Benutzer kann entscheiden, ob er dies zulassen möchte oder nicht. Dies ist eine gängige Praxis und eine gute Möglichkeit, den Zugriff auf White-Listed-Anwendungen zu beschränken.
Leider gibt es einige unintuitive Verhaltensweisen rund um benutzerdefinierte Berechtigungen, die sie aus Sicherheitsaspekten riskant machen. Konkret können benutzerdefinierte Berechtigungen von jeder App zu jeder Zeit definiert werden, und "der Erste gewinnt", und diese Strategie hat einige Konsequenzen.
Für das folgende Szenario definieren wir zwei App-Profile, die wir oben vorgestellt haben (alle diese Anwendungen sind zu Demonstrationszwecken fiktiv):
1. SCWApp: die App, die eine benutzerdefinierte Berechtigung definiert und eine Komponente mit dieser Berechtigung verteidigt.
2. DevTrainer: diese App definiert die gleiche Berechtigung wie SCWApp und erklärt dem Benutzer, dass sie diese Berechtigung besitzen möchte.
Dies ist ein häufiges Szenario, das als "Peer Apps Case" bezeichnet wird. Wenn die DevTrainer-App nur ein Plugin für die SCWApp wäre, müsste sie die benutzerdefinierte Berechtigung nicht definieren. Die Annahme ist in diesem Fall, dass SCWApp vor DevTrainer installiert wird und kein unerwartetes Verhalten auftritt. Wenn der Benutzer irgendwie DevTrainer zuerst installiert, wird der Benutzer nicht über die Anforderung der Berechtigung informiert. Wenn der Benutzer dann später SCWApp installiert, wird DevTrainer die Berechtigung nicht rückwirkend erteilt, sodass die Versuche der DevTrainer-App, die gesicherte Komponente zu verwenden, fehlschlagen.
Hier kommt der Fall der Peers-App ins Spiel. In manchen Fällen können Sie nicht erwarten, dass eine App vor der anderen installiert wird. Sagen wir, wenn Facebook und Twitter beide die Komponenten des jeweils anderen nutzen wollen, müssen sie die benutzerdefinierten Berechtigungen des jeweils anderen definieren.
An dieser Stelle wird es jedoch knifflig. Wenn die DevTrainer-App zuerst installiert wird, wird der Benutzer nicht über seine Anfrage nach der benutzerdefinierten Berechtigung informiert. Zu diesem Zeitpunkt, obwohl der Benutzer nicht informiert wurde, besitzt DevTrainer die benutzerdefinierte Berechtigung und kann auf die gesicherte Komponente zugreifen.
Es wird noch kniffliger. Die DevTrainer-App kann die Berechtigungsschutzstufe ändern. Android verwendet nicht die Schutzstufe des Verteidigers, sondern die Schutzstufe, die zuerst definiert wurde, d.h. diejenige App, die zuerst installiert wurde, kann diese definieren. Das bedeutet, wenn DevTrainer die Berechtigungsstufe auf normal ändert, dann müssen alle zukünftigen Apps, die diese Berechtigung anfordern, nicht vom Benutzer bestätigt werden, sondern erhalten automatisch Zugriff.
Dieses Szenario wurde durch die Erklärung für dieses Problem inspiriert, die auf dem cwac-security github gefunden wurde.
Die "Wer zuerst kommt, mahlt zuerst"-Strategie hat einige gefährliche Konsequenzen. Wenn der Entwickler das Verhalten nicht kennt, könnte er Sicherheitsentscheidungen auf der Grundlage von nicht vertrauenswürdigen Eingaben treffen und unbeabsichtigten Apps den Zugriff auf sensible Daten oder geschützte Dienste ermöglichen. Um mehr über die Vermeidung von Sicherheitsentscheidungen durch nicht vertrauenswürdige Eingaben zu erfahren, besuchen Sie unsere Plattform. Dieses Verhalten wurde ab Android 5.0 (Lollipop) geändert. Da aber derzeit noch mehr als 22 % der Android-Geräte mit einer niedrigeren Version von Android laufen, ist es wichtig, die Risiken des ursprünglichen Verhaltens in Ihrer App zu mindern. Prüfen Sie, ob die Berechtigung bereits beim ersten Start Ihrer App definiert wurde und ergreifen Sie in diesem Fall entsprechende Maßnahmen, um eventuelle Sicherheitsrisiken zu beheben.
Viel Glück beim Codieren und bis nächste Woche!
Durch die Definition von benutzerdefinierten Berechtigungen kann eine App ihre Ressourcen und Fähigkeiten mit anderen Apps teilen.
https://developer.android.com/guide/topics/permissions/defining.html
Inhaltsübersicht
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
