|
|
Zeile 13: |
Zeile 13: |
| Der Evaluator prüft, ob fest einprogrammierte geheime, bzw. private Schlüssel eingesetzt werden. | | Der Evaluator prüft, ob fest einprogrammierte geheime, bzw. private Schlüssel eingesetzt werden. |
| == Lösungsansätze == | | == Lösungsansätze == |
| === Implementierung ===
| |
| ==== Best Practices und Standards ====
| |
| # 1.
| |
| Just-in-Time-Bereitstellung (JIT): Die Implementierung von JIT-Privilegien ermöglicht es, erweiterte Berechtigungen nur für die Dauer einer Sitzung oder Aufgabe zu gewähren, was die potenzielle Angriffsfläche erheblich reduziert und sicherstellt, dass keine fest einprogrammierten Schlüssel verwendet werden.
| |
|
| |
| <syntaxhighlight lang="python" style="border: 3px dashed blue;">
| |
| # Python
| |
| import datetime
| |
| import random
| |
|
| |
| def grant_JIT_privileges(user, resource, duration):
| |
| temporary_credentials = generate_temporary_credentials()
| |
| expiry_time = datetime.datetime.now() + datetime.timedelta(seconds=duration)
| |
| grant_access(resource, temporary_credentials, expiry_time)
| |
| return "Access granted successfully"
| |
|
| |
| def generate_temporary_credentials():
| |
| # Beispielhafte Generierung zufälliger Anmeldeinformationen
| |
| username = "user_" + str(random.randint(1000, 9999))
| |
| password = ''.join(random.choices('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890', k=12))
| |
| return {"username": username, "password": password}
| |
|
| |
| def grant_access(resource, credentials, expiry_time):
| |
| # Hier würde die eigentliche Logik stehen, um dem Benutzer Zugriff auf die Ressource zu gewähren
| |
| print(f"Granted access to resource {resource} with credentials {credentials} until {expiry_time}")
| |
|
| |
| # Beispielaufruf
| |
| grant_JIT_privileges("Alice", "example_resource", 3600) # Zugriff für eine Stunde gewähren
| |
| </syntaxhighlight>
| |
|
| |
| <br />
| |
| # 2.
| |
| Zero Standing Privileges: Das Prinzip des ZSP besagt, dass niemand oder nichts dauerhaften Zugriff auf Ihre Cloud-Konten und -Daten haben sollte. Dies schließt die Verwendung fest einprogrammierter geheimer Schlüssel aus.
| |
|
| |
| <syntaxhighlight lang="javascript" style="border: 3px dashed blue;">
| |
| // JavaScript
| |
| // Simulation einer Datenbank für Benutzerkonten
| |
| const userAccountsDB = [
| |
| { username: "user1", role: "user", hasPermanentAccess: true },
| |
| { username: "user2", role: "user", hasPermanentAccess: false }
| |
| ];
| |
|
| |
| // Klasse für die Verwaltung von Benutzerkonten
| |
| class UserAccountManager {
| |
| constructor() {
| |
| this.userAccountsDB = userAccountsDB;
| |
| }
| |
|
| |
| // Methode zum Überprüfen und Umschreiben von Benutzerrechten gemäß ZSP-Prinzipien
| |
| enforceZSP(username) {
| |
| const user = this.userAccountsDB.find(user => user.username === username);
| |
| if (user) {
| |
| if (user.hasPermanentAccess) {
| |
| this.revokePermanentAccess(username);
| |
| return `${username} hatte dauerhaften Zugriff erfolgreich widerrufen`;
| |
| } else {
| |
| return `Keine Aktion erforderlich für ${username}, Benutzer entspricht bereits den ZSP-Prinzipien`;
| |
| }
| |
| } else {
| |
| return `Benutzer ${username} nicht gefunden`;
| |
| }
| |
| }
| |
|
| |
| // Methode zum Entzug dauerhafter Zugriffsrechte
| |
| revokePermanentAccess(username) {
| |
| // Hier würde die eigentliche Logik stehen, um dauerhafte Zugriffsrechte zu entziehen,
| |
| // z. B. eine Datenbankaktualisierung
| |
| const user = this.userAccountsDB.find(user => user.username === username);
| |
| if (user) {
| |
| user.hasPermanentAccess = false;
| |
| }
| |
| }
| |
| }
| |
|
| |
| // Beispielaufrufe
| |
| const userManager = new UserAccountManager();
| |
| console.log(userManager.enforceZSP("user1")); // Output: "user1 hatte dauerhaften Zugriff erfolgreich widerrufen"
| |
| console.log(userManager.enforceZSP("user2")); // Output: "Keine Aktion erforderlich für user2, Benutzer entspricht bereits den ZSP-Prinzipien"
| |
|
| |
| </syntaxhighlight>
| |
|
| |
| <br />
| |
|
| |
| ==== Tools ====
| |
| Verwendung von Drittanbieter-Diensten wie [https://docs.aws.amazon.com/de_de/secretsmanager/latest/userguide/intro.html AWS Secrets Manager],[https://learn.microsoft.com/en-us/azure/key-vault/general/developers-guide Azure Key Vault]
| |
| oder [https://cloud.google.com/secret-manager/docs Google Cloud Secret Manager] zur Verwaltung von Schlüsseln.
| |
| Weiterhin könnte man die Verwendung von Frameworks wie [https://developer.okta.com/blog/2021/02/03/api-key-best-practices-and-examples Okta] oder [https://developer.hashicorp.com/vault/docs?product_intent=vault Vault] hinzuziehen, um Sicherheitsstandards wie [https://www.pcisecuritystandards.org/ PCI DSS] oder [https://www.hhs.gov/hipaa/index.html HIPAA] einzuhalten und sicherzustellen, dass die Verwaltung von Geheimnissen den geltenden Vorschriften und Best Practices entspricht.
| |
|
| |
| === Validierung ===
| |
| ==== Maßnahmen ====
| |
| # 1.
| |
| Das Testen auf festprogrammierte Schlüssel sollte sich mithilfe von regulären Ausdrücken als relativ einfach gestalten.
| |
| <syntaxhighlight lang="bash" style="border: 3px dashed blue;">
| |
| # bash
| |
| $ app8 egrep -r 'AIza[0-9A-Za-z\\-_]{35}' .
| |
| Binary file ./resources.arsc correspondant
| |
| Binary file ./app.apk correspondant
| |
| Binary file ./classes.dex correspondant
| |
| ./assets/google-services-desktop.json: "current_key": "AIzaSy....................."
| |
| </syntaxhighlight>
| |
|
| |
| <br />
| |
| Da allerdings nicht alle Schlüssel eine Sicherheitslücke bedeuten, müssen die gefundenen Schlüssel anschließend auch validiert werden.
| |
| <syntaxhighlight lang="bash" style="border: 3px dashed blue;">
| |
| # bash
| |
| $ curl -s -X POST --header "Authorization: key=AIzaS........." --header "Content-Type:application/json" 'https://fcm.googleapis.com/fcm/send' -d '{"registration_ids":["1"]}'
| |
| <HTML>
| |
| <HEAD>
| |
| <TITLE>INVALID_KEY_TYPE</TITLE>
| |
| </HEAD>
| |
| <BODY BGCOLOR="#FFFFFF" TEXT="#000000">
| |
| <H1>INVALID_KEY_TYPE</H1>
| |
| <H2>Error 401</H2>
| |
| </BODY>
| |
| </HTML>
| |
| </syntaxhighlight>
| |
|
| |
| <br />
| |
|
| |
| <syntaxhighlight lang="python" style="border: 3px dashed blue;">
| |
| # bash
| |
| $ curl https://graph.facebook.com/oauth/access_token\?client_id\=51XXXX\&client_secret\=0cbd4XXXXX\&redirect_uri\=\&grant_type\=client_credentials
| |
| {"access_token":"5181XXXXXXXXXXXXXX","token_type":"bearer"}%
| |
| </syntaxhighlight>
| |
|
| |
| <br />
| |
|
| |
| == Siehe auch ==
| |
|
| |
|
| | == Weblinks == |
|
| |
|
| == Ressourcen und Einzelnachweise == | | == Ressourcen und Einzelnachweise == |
| [https://blog.ostorlab.co/hardcoded-secrets.html Amine Mesbahi: Finding And Validating Hardcoded Keys and Secrets] A.Mesbahi, Finding And Validating Keys And Secrets, 30.11.2020, aufgerufen am 02.05.2020
| |
|
| |
| [https://cwe.mitre.org/data/definitions/321.html CWE-321: Use Of Hard-coded Cryptographic Key] CWE-321: Use Of Hard-coded Cryptographic Key, aufgerufen am 02.05.2020
| |
|
| |
| [https://2449407.fs1.hubspotusercontent-na1.net/hubfs/2449407/WP-%20How%20to%20Eliminate%20Hardcoded%20API%20Keys%20from%20Your%20App%20v2.2.pdf Approov: How to Eliminate Hardcoded API Keys from Your App] Whitepaper Approov.io, aufgerufen am 02.05.2024
| |
|
| |
| == Weblinks ==
| |
| [https://community.sap.com/t5/application-development-blog-posts/credential-digger-using-machine-learning-to-identify-hardcoded-credentials/ba-p/13446068 Credential Digger ]
| |
|
| |
| [https://docs.aws.amazon.com/de_de/secretsmanager/latest/userguide/intro.html AWS Secrets Manager]
| |
|
| |
| [https://learn.microsoft.com/en-us/azure/key-vault/general/developers-guide Azure Key Vault]
| |
|
| |
| [https://cloud.google.com/secret-manager/docs Google Cloud Secret Manager]
| |
|
| |
| [https://developer.okta.com/blog/2021/02/03/api-key-best-practices-and-examples Okta]
| |
|
| |
|
| [https://developer.hashicorp.com/vault/docs?product_intent=vault Vault] | | [[Category:Pruefaspekt]] |
| | [[Category:EXAMINE]] |