O.Cryp 1: Unterschied zwischen den Versionen
D.hack (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
|||
(49 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
== Beschreibung == | == Beschreibung == | ||
[[Beschreibung:: | |||
Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden. | Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden. | ||
]] | |||
== Kurzfassung == | == Kurzfassung == | ||
[[Kurzfassung:: | |||
Keine fest einprogrammierten Schlüssel oder anderweitige Geheimnisse. | Keine fest einprogrammierten Schlüssel oder anderweitige Geheimnisse. | ||
]] | |||
== | == Testcharakteristik == | ||
==== Prüftiefe ==== | ==== Prüftiefe ==== | ||
{|class="wikitable" style="width:50%; border: 1px solid black;" | |||
:: | |- | ||
! style="background-color: #f2f2f2;" | Bezeichnung | |||
! style="background-color: #f2f2f2;" | Mindestanforderungen an die Prüfung | |||
|- | |||
| [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A65%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C725%2C0%5D EXAMINE] | |||
| Der Evaluator untersucht (englisch „examine“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die betreffende Testcharakteristik. Der Evaluator [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A15%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C243%2C0%5D MUSS] in seiner Prüfung über die Mindestanforderungen für „[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A65%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C725%2C0%5D CHECK]“ hinausgehen: In der Regel wird dies durch umfassende Quelltextanalyse der relevanten Implementierungsanteile und Penetrationstests geschehen. Die Unterstützung durch den Hersteller kann genutzt werden. „EXAMINE“ erfordert in jedem Fall eine eigenständige Beurteilung durch den Evaluator. | |||
|} | |||
<br /> | <br /> | ||
==== Ergänzende Informationen für Evaluatoren ==== | |||
[[Anmerkungen:: | |||
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. | 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 datetime | ||
import random | import random | ||
Zeile 37: | Zeile 54: | ||
# Beispielaufruf | # Beispielaufruf | ||
grant_JIT_privileges("Alice", "example_resource", 3600) # Zugriff für eine Stunde gewähren | grant_JIT_privileges("Alice", "example_resource", 3600) # Zugriff für eine Stunde gewähren | ||
</ | </syntaxhighlight> | ||
{{#set: has ProgrammingLanguage=Python}} | |||
<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. | 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;"> | ||
[https:// | // 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> | |||
{{#set: has ProgrammingLanguage=JavaScript}} | |||
<br /> | |||
==== Tools ==== | |||
Verwendung von Drittanbieter-Diensten wie [https://docs.aws.amazon.com/de_de/secretsmanager/latest/userguide/intro.html AWS Secrets Manager] {{#set: use Framework=AWS Secrets Manager}},[https://learn.microsoft.com/en-us/azure/key-vault/general/developers-guide Azure Key Vault] {{#set: use Framework=Azure Key Vault}} oder [https://cloud.google.com/secret-manager/docs Google Cloud Secret Manager] {{#set: use Framework=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] {{#set: use Framework=Okta}} oder [https://developer.hashicorp.com/vault/docs?product_intent=vault Vault] {{#set: use Framework=Vault}} hinzuziehen, um Sicherheitsstandards wie [https://www.pcisecuritystandards.org/ PCI DSS] {{#set: use SecurityStandard=PCI DSS}} oder [https://www.hhs.gov/hipaa/index.html HIPAA] {{#set: use SecurityStandard=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 == | |||
== 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 {{#set: has Literacy=Amine Mesbahi: Finding And Validating Hardcoded Keys and Secrets}} | |||
[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 {{#set: has Literacy=CWE-321: Use Of Hard-coded Cryptographic Key}} | |||
[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 {{#set: has Literacy=Approov: How to Eliminate Hardcoded API Keys from Your App}} | |||
== Weblinks == | |||
[https://community.sap.com/t5/application-development-blog-posts/credential-digger-using-machine-learning-to-identify-hardcoded-credentials/ba-p/13446068 Credential Digger ] {{#set: has Literacy=Credential Digger}} | |||
[https://docs.aws.amazon.com/de_de/secretsmanager/latest/userguide/intro.html AWS Secrets Manager] {{#set: has Literacy=AWS Secrets Manager}} | |||
[https://learn.microsoft.com/en-us/azure/key-vault/general/developers-guide Azure Key Vault] {{#set: has Literacy=Azure Key Vault}} | |||
[https://cloud.google.com/secret-manager/docs Google Cloud Secret Manager] {{#set: has Literacy=Google Cloud Secret Manager}} | |||
[https://developer.okta.com/blog/2021/02/03/api-key-best-practices-and-examples Okta] {{#set: has Literacy=Okta}} | |||
[https://developer.hashicorp.com/vault/docs?product_intent=vault Vault] {{#set: has Literacy=Vault}} | |||
{{#set:Status=angelegt}} | |||
[[Category:EXAMINE]] | |||
[[Category: Cryp]] |
Aktuelle Version vom 6. August 2024, 13:33 Uhr
Beschreibung
Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden.
Kurzfassung
Keine fest einprogrammierten Schlüssel oder anderweitige Geheimnisse.
Testcharakteristik
Prüftiefe
Bezeichnung | Mindestanforderungen an die Prüfung |
---|---|
EXAMINE | Der Evaluator untersucht (englisch „examine“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die betreffende Testcharakteristik. Der Evaluator MUSS in seiner Prüfung über die Mindestanforderungen für „CHECK“ hinausgehen: In der Regel wird dies durch umfassende Quelltextanalyse der relevanten Implementierungsanteile und Penetrationstests geschehen. Die Unterstützung durch den Hersteller kann genutzt werden. „EXAMINE“ erfordert in jedem Fall eine eigenständige Beurteilung durch den Evaluator. |
Ergänzende Informationen für Evaluatoren
Der Evaluator prüft, ob fest einprogrammierte geheime, bzw. private Schlüssel eingesetzt werden.
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.
# 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
- 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.
// 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"
Tools
Verwendung von Drittanbieter-Diensten wie AWS Secrets Manager ,Azure Key Vault oder Google Cloud Secret Manager zur Verwaltung von Schlüsseln. Weiterhin könnte man die Verwendung von Frameworks wie Okta oder Vault hinzuziehen, um Sicherheitsstandards wie PCI DSS oder 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.
# 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....................."
Da allerdings nicht alle Schlüssel eine Sicherheitslücke bedeuten, müssen die gefundenen Schlüssel anschließend auch validiert werden.
# 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>
# 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"}%
Siehe auch
Ressourcen und Einzelnachweise
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
CWE-321: Use Of Hard-coded Cryptographic Key CWE-321: Use Of Hard-coded Cryptographic Key, aufgerufen am 02.05.2020
Approov: How to Eliminate Hardcoded API Keys from Your App Whitepaper Approov.io, aufgerufen am 02.05.2024