{"id":571,"date":"2024-03-04T13:21:45","date_gmt":"2024-03-04T12:21:45","guid":{"rendered":"https:\/\/sparrow365.de\/?p=571"},"modified":"2024-11-04T20:20:51","modified_gmt":"2024-11-04T19:20:51","slug":"du-brauchst-wahrscheinlich-kein-application-readwrite-all","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/2024\/03\/04\/du-brauchst-wahrscheinlich-kein-application-readwrite-all\/","title":{"rendered":"Du brauchst (wahrscheinlich) kein Application.ReadWrite.All"},"content":{"rendered":"

Als Microsoft den Midnight Blizzard-Angriff vom Januar<\/strong> zum ersten Mal bekannt gab<\/a> und ihre darauf folgende tiefere Analyse ver\u00f6ffentlichte<\/a>, verfolgte ich den resultierenden Inhalt mit gro\u00dfem Interesse \u2013 Risiken, die von Enterprise Applikationen ausgehen<\/strong>, sind ein Herzensthema f\u00fcr mich.<\/p>\n

Wenn Sie Microsoft 365 auf einem vern\u00fcnftigen Niveau nutzen, werden Sie unweigerlich<\/em><\/strong> Enterprise Applikationen mit einem gro\u00dfen Umfang an Berechtigungen in Ihrem Tenant<\/strong> haben (denken Sie an Backup-L\u00f6sungen, Skriptautomatisierungen usw.) – deshalb sollten Sie die Entra ID Rolle "(Cloud) App Administrator"<\/em> wie einen Globalen Administrator<\/strong> behandeln. Durch das Setzen von Anmeldeinformationen f\u00fcr Applikationen, k\u00f6nnen sie sich mit den zugeh\u00f6rigen APIs in dessen Namen verbinden und Privilegien nutzen, die Sie den Benutzern vielleicht nie gew\u00e4hrt h\u00e4tten. Das gilt auch f\u00fcr den Graph API Scope "Application.ReadWrite.All".<\/p>\n

Da ich nichts zu den Hauptinteressenspunkten des Breach hinzuzuf\u00fcgen habe, lateral movement zwischen Tenants<\/a> durch Unternehmensanwendungen und wie man richtig API-Berechtigungen in Exchange Online erteilt<\/a>, werde ich diese Themen nicht erneut betrachten. Es gibt jedoch einen Bereich, in dem ich gerne mehr Informationen sehen w\u00fcrde – einmal in Ihrem Tenant entdeckt<\/em>, ist es manchmal nicht einfach zu finden, wie man sich von hochprivilegierten API-Rollen befreit oder sie vermeidet<\/strong>. Ein solches Beispiel ist Application.ReadWrite.All<\/a>.<\/p>\n

Die gesamte Midnight Blizzard Angriffskette k\u00f6nnte direkt mit einem App-Besitzer der Multi-Tenant-App begonnen haben, aber es h\u00e4tte leicht eine Anwendung im Test-Mandanten mit dieser Berechtigung sein k\u00f6nnen, durch die der Angreifer zur Multi-Tenant-App wechselte (Microsoft ist hier\u00fcber nicht ganz klar).<\/p>\n

Schauen wir uns also einige Anwendungsf\u00e4lle an, bei denen der erste Reflex<\/strong> sein k\u00f6nnte, "Application.ReadWrite.All" zu verwenden, es aber bessere L\u00f6sungen gibt<\/strong>:<\/p>\n

\n

Ich werde in meinen Demos PowerShell verwenden, aber da Graph eine REST-API ist, k\u00f6nnen Beispiele auf jede Programmiersprache mit Unterst\u00fctzung f\u00fcr HTTP-Anfragen \u00fcbertragen werden
\nI hold these truths to be self evident: Delegierte Berechtigungen sind vorzuziehen gegen\u00fcber Anwendungsberechtigungen, und wenn Sie nur Read ben\u00f6tigen, verwenden Sie keinen ReadWrite Scope<\/em><\/p>\n<\/blockquote>\n


<\/p>\n

Allgemeine Konfigurationsverwaltung<\/h2>\n

Im Gro\u00dfteil der F\u00e4lle wollen wir nicht alle<\/strong> Anwendungen im Tenant verwalten, sondern nur eine begrenzte Auswahl. Beginnen wir mit einer Enterprise App, die ihre eigene Konfiguration verwalten m\u00f6chte.<\/p>\n

\n

Denken Sie daran: In der Graph API sind App Registrations<\/em> auf dem application<\/strong> Endpunkt, eine Enterprise App<\/em> ist ein servicePrincipal<\/strong> – Kurze Zusammenfassung des Unterschieds<\/em><\/a>
\nWenn ich es zu oft schreibe, k\u00f6nnte ich App Registrations als "AppRegs<\/strong>" und Enterprise Apps als "EApps<\/strong>" k\u00fcrzen.<\/p>\n<\/blockquote>\n

Erster Versuch<\/h3>\n

Wenn wir uns die Graph API Dokumentation<\/a> f\u00fcr die Verwaltung von App Registrations ansehen, k\u00f6nnen wir bereits eine potenzielle Option sehen (das Gleiche gilt f\u00fcr Enterprise Apps<\/a>):<\/p>\n

\"DocumentedLeastPrivileges\"<\/p>\n

Also f\u00fcgen wir den Scope unserer App Registration hinzu, gew\u00e4hren die Berechtigungen auf der Enterprise App und sind fertig, richtig?<\/p>\n

\"activeScopes\"<\/p>\n

Jetzt, da ich den Scope in meiner Graph Session habe, versuche ich, meine EApp so zu \u00e4ndern, dass ein Benutzer zugewiesen sein muss, bevor er sich anmelden kann:
\nInvoke-MgGraphRequest "PATCH" "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals(appId='$($graphConfig.clientID)')" -Body @{ appRoleAssignmentRequired = $true }<\/code><\/p>\n

Und werde prompt abgelehnt:<\/strong><\/p>\n

\"ErrorMessageSelfPatch\"<\/p>\n

Owner Rechte hinzuf\u00fcgen<\/h3>\n

Das ist logisch, wenn wir dar\u00fcber nachdenken. Wir haben der Enterprise App die Berechtigung gegeben, Anwendungen zu verwalten, die sie besitzt<\/strong>, aber wir besitzen nichts<\/strong> (Hier klicken f\u00fcr Microsofts \u00dcbersicht \u00fcber Anwendungsbesitz)<\/a>. Wie k\u00f6nnen wir das also beheben? Zum Zeitpunkt des Verfassens (Feb. 2024) bietet das Entra Portal keine EApps an, wenn wir versuchen, einen Owner zu einer Enterprise App oder einer App Registration hinzuzuf\u00fcgen.<\/p>\n

Wenn wir uns jedoch mit dem delegierten<\/strong> Scope "Application.ReadWrite.All" als Benutzer mit mindestens Application Administrator (oder Owner) gegen die Graph API authentifizieren, k\u00f6nnen wir den notwendigen Besitz hinzuf\u00fcgen – ein Objekt kann sogar sich selbst besitzen.<\/p>\n

\n

Denken Sie daran – Auch wenn Anmeldeinformationen auf der App Registration konfiguriert sind, h\u00e4lt die Enterprise App \/ der service Principal alle Berechtigungen im Tenant<\/strong><\/p>\n

Siehe auch die Microsoft Dokumentation zum Hinzuf\u00fcgen von Ownern zu Enterprise Apps<\/a><\/p>\n<\/blockquote>\n

# Objekt-ID unserer EApp \u00fcber App \/ Client ID abrufen\n$enterpriseAppID    = ( Invoke-MgGraphRequest "GET" "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals(appId='$($graphConfig.clientID)')?select=id" ).id\n\n# Die EApp als ihren eigenen Owner hinzuf\u00fcgen\n$params = @{ "@odata.id" = "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals\/$enterpriseAppID" }\nInvoke-MgGraphRequest "POST" "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals\/$enterpriseAppID\/owners\/`$ref" -Body $params<\/code><\/pre>\n

<\/p>\n
Versuchen wir es also erneut:
\nInvoke-MgGraphRequest "PATCH" "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals(appId='$($graphConfig.clientID)')" -Body @{ appRoleAssignmentRequired = $true }<\/code><\/p>\n
\"alt\"<\/p>\n
Erfolg! Und wir k\u00f6nnen den gesamten Tenant von hier aus nicht \u00fcbernehmen, da wir nur eine Anwendung besitzen<\/strong> \ud83e\udd73<\/p>\n
Interessanterweise, obwohl wir Enterprise Apps nicht \u00fcber die UI als Owner hinzuf\u00fcgen k\u00f6nnen, sobald wir sie hinzugef\u00fcgt haben, sind sie sichtbar:<\/p>\n
\"PortalOwnerView\"<\/p>\n

<\/p>\n
Wenn wir die Eigenschaften unserer App Registration \u00e4ndern m\u00fcssen, k\u00f6nnen wir auch dort Owner wie folgt hinzuf\u00fcgen:<\/p>\n
\n
In diesem Beispiel verwende ich immer noch die App \/ Client ID der EApp, als die ich angemeldet bin, ersetzen Sie sie bei Bedarf<\/p>\n
Siehe auch die Microsoft Dokumentation zum Hinzuf\u00fcgen von Ownern zu App Registrations<\/a><\/p>\n<\/blockquote>\n
# Die ID der EApp abrufen, die wir f\u00fcr das Management verwenden m\u00f6chten\n$enterpriseAppID    = (Invoke-MgGraphRequest "GET" "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals(appId='$($graphConfig.clientID)')?select=id").id\n$appRegistrationID  = (Invoke-MgGraphRequest "GET" "https:\/\/graph.microsoft.com\/v1.0\/applications(appId='$($graphConfig.clientID)')?select=id").id\n\n# Wir f\u00fcgen unsere EApp als den Owner der AppReg hinzu\n$params = @{ "@odata.id" = "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals\/$enterpriseAppID" }\nInvoke-MgGraphRequest "POST" "https:\/\/graph.microsoft.com\/v1.0\/applications\/$appRegistrationID\/owners\/`$ref" -Body $params<\/code><\/pre>\n

<\/p>\n
Und wieder sind wir erfolgreich:<\/p>\n
\"appRegEditSuccess\"<\/p>\n

<\/p>\n
App Credentials verwalten<\/h2>\n
Einer der h\u00e4ufigsten Anfragen im Anwendungsmanagement ist wahrscheinlich, selbstverwaltung von Anmeldeinformationen<\/strong>. Das konsistente Ablaufen von Geheimnissen und Zertifikaten erfordert entweder eine genaue \u00dcberwachung oder, vorzugsweise, Automatisierung.<\/p>\n
Mit "Application.ReadWrite.OwnedBy<\/strong>" und unserer Enterprise App, die bereits im letzten Kapitel Owner an der App Registration erhalten hat, k\u00f6nnen wir Anmeldeinformationen aktualisieren – es handelt sich schlie\u00dflich nur um eine weitere Eigenschaft.<\/p>\n
Secrets<\/h3>\n
\n
Siehe auch die Microsoft Dokumentation zum Aktualisieren von App Registrations<\/a><\/p>\n<\/blockquote>\n
$appRegistrationID  = (Invoke-MgGraphRequest "GET" "https:\/\/graph.microsoft.com\/v1.0\/applications(appId='$($graphConfig.clientID)')?select=id").id\n$params = @{\n    passwordCredential = @{\n        displayName = "Secret$(get-date -f "ddMMyy")"\n    }\n}\n# Je nachdem, wo Sie das Geheimnis ben\u00f6tigen, ist es wahrscheinlich eine gute Idee, es so schnell wie m\u00f6glich dort abzulegen ;)\n$response = Invoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/applications\/$appRegistrationID\/addPassword" -Body $params<\/code><\/pre>\n
\n
Wenn ich tats\u00e4chlich Secrets nutzen muss, bevorzuge ich, sie nur in SecureStrings zu speichern, da sie im Speicher besser gesch\u00fctzt sind:<\/em>
\n$secret = ConvertTo-SecureString $(Invoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/applications\/$appRegistrationID\/addPassword" -Body $params).secretText -AsPlainText -Force<\/code><\/p>\n<\/blockquote>\n
In unserer Antwort erhalten wir das secret als secretText, zusammen mit einigen Metadaten (denken Sie daran, es irgendwo zu speichern, sonst ist es f\u00fcr immer verloren):<\/p>\n
\"secretMetadata\"<\/p>\n
Wir k\u00f6nnen das Geheimnis auch in der UI sehen (nur nicht den Wert):<\/p>\n
\"secretUI\"<\/p>\n

<\/p>\n
Keys \/ Zertifikate<\/h3>\n
Ich bin mir jedoch sicher, niemand ben\u00f6tigt noch Secrets<\/strong>. Sie sind einfach so viel schlechter als asymmetrische Authentifizierungsmethoden<\/strong>, also haben offensichtlich alle Anwendungen auf Zertifikate f\u00fcr die Authentifizierung umgestellt<\/strong>, nicht wahr? RICHTIG? Ein Mann darf tr\u00e4umen…<\/p>\n
Theoretisch br\u00e4uchten wir f\u00fcr Zertifikatrotation nicht mal<\/strong> "Application.ReadWrite.OwnedBy<\/em>"<\/a> Berechtigungen, aber es ist mir nicht gelungen<\/a>, dies in PowerShell umzusetzen – ich werde zu dem Thema vermutlich sp\u00e4ter zur\u00fcck kehren oder w\u00fcrde mich sehr \u00fcber einen Hinweis auf eine funktionierende Implementierung in der offenen Q&A-Frage<\/a> freuen…<\/p>\n
Da ich die wirklich coole<\/em> L\u00f6sung (vorerst) nicht demonstrieren kann, habe ich nicht viel zur Microsoft Dokumentation<\/a> hinzuzuf\u00fcgen. Ich verwende jedoch das Zertifikat aus dem Zertifikatsspeicher:<\/p>\n
\n
Beachten Sie, dass dieser Befehl auf der App Registration ALLE DERZEIT KONFIGURIERTEN ZERTIFIKATE ERSETZT<\/strong>.<\/p>\n<\/blockquote>\n
$Certificate = Get-Item "Cert:\\CurrentUser\\My\\$($graphConfig.newThumb)" -ErrorAction Stop\n$params = @{\n    keyCredentials = @(\n        @{\n            type = "AsymmetricX509Cert"\n            usage = "Verify"\n            key = [convert]::ToBase64String($Certificate.GetRawCertData())\n            displayName = "CN=20240228"\n        }\n    )\n}\nInvoke-MgGraphRequest PATCH "https:\/\/graph.microsoft.com\/v1.0\/applications(appId='$($graphConfig.clientID)')" -Body $params<\/code><\/pre>\n

<\/p>\n
Skalieren<\/h2>\n
Wir haben nun ein gutes Verst\u00e4ndnis davon, wie wir einzelne Anwendungen verwalten k\u00f6nnen. Aber wie k\u00f6nnen wir unseren Scope erweitern<\/strong>? Es gibt Anwendungsf\u00e4lle, bei denen wir die Kontrolle \u00fcber viele Enterprise Apps \/ App Registrations behalten wollen (ich werde ab jetzt "Apps"<\/strong> als Kurzform f\u00fcr beide verwenden)<\/em>.<\/p>\n
Denken Sie an Infrastructure as Code-L\u00f6sungen wie Terraform oder vielleicht haben wir ein Backup-System, das Graph API-Ratenlimits<\/a> umgehen m\u00f6chte, indem mehr EApps erstellt werden<\/a>.<\/p>\n
Im Wesentlichen ben\u00f6tigen wir mindestens eine "Manager"-App und eine Reihe von "Worker"-Apps. Die l\u00e4stige<\/em> L\u00f6sung w\u00e4re, im Voraus eine Reihe von Apps zu erstellen – und danach die Basis-Zuweisung der Owner<\/a> durchzuf\u00fchren. Nicht ideal, aber gl\u00fccklicherweise ist es viel einfacher – wenn wir "Application.ReadWrite.OwnedBy<\/strong>" auf unserer "Head"-App verwenden, k\u00f6nnen wir sie dann nutzen, um bei Bedarf Apps zu erstellen<\/strong>.<\/p>\n
\n
Wir k\u00f6nnen auch den servicePrincipal-Endpoint aufrufen, um zugeh\u00f6rige Enterprise Apps zu erstellen, aber das sieht im Grunde gleich aus<\/em><\/p>\n<\/blockquote>\n
Invoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/applications" -body @{ displayName = "CreatedByApp" }<\/code><\/p>\n
Die ausf\u00fchrende Enterprise App wird automatisch als Owner<\/strong> der neuen App hinzugef\u00fcgt:<\/p>\n
\"newAppReg\"<\/p>\n

<\/p>\n
Allerdings wird es eine Herausforderung sein, den \u00dcberblick \u00fcber all unsere Owner Verh\u00e4ltnisse zu behalten. Die L\u00f6sungen, die mir derzeit bekannt sind, sind den Aufbau einer Automatisierung<\/strong> basierend auf Custom Security Attributes<\/a> oder die Erstellung eines Tracking-Systems<\/strong> in directory extensions<\/a>. In jedem Fall sind dies keine gro\u00dfartigen Optionen – sind wir also dazu verdammt, entweder viel zu breite Berechtigungen<\/strong> zu vergeben oder zu versuchen, ein potenziell komplexes Netz von Besitzverh\u00e4ltnissen<\/strong> im Auge zu behalten?<\/p>\n

<\/p>\n
Die "Beste" Option<\/h2>\n
Wenn wir wirklich<\/strong> den Ansatz von "least privilege" verfolgen wollen, sind Graph API Scopes nicht der Weg. Im Kern sind Apps Entra ID Objekte, was custom roles<\/a> zu einer deutlich granulareren Option f\u00fcr das Berechtigungsmanagement macht. "Application.ReadWrite.OwnedBy<\/strong>" ist zuf\u00e4llig fast ein direkter Ersatz<\/strong> f\u00fcr das h\u00e4ufig verwendete "Application.ReadWrite.All<\/strong>".<\/p>\n
\n
OAuth Scopes haben den Vorteil, dass sie leicht zwischen Tenants \u00fcbertragbar sind – wenn eine Anwendung nur f\u00fcr Ihren Tenant erstellt wird, ist das kein stichhaltiges Argument, und wenn sie einer Multi-Tenant-App diese Rechte geben sollen m\u00fcssen sie dem Entwickler wirklich WIRKLICH vertrauen…<\/p>\n<\/blockquote>\n
Sobald wir uns die in Entra ID verf\u00fcgbaren Optionen anschauen, gibt es eine schmerzlich offensichtliche L\u00f6sung: F\u00fcr Benutzer, Gruppen und Ger\u00e4te k\u00f6nnen wir bereits Administrative Units<\/strong><\/a> erstellen. Diese erm\u00f6glichen das Einschr\u00e4nken von integrierten und benutzerdefinierten Rollen auf Teilbereiche eines Tenants<\/strong>, einschlie\u00dflich der Erstellung neuer Objekte innerhalb des Geltungsbereichs.
\nSomit h\u00e4tten wir eine leicht skalierbare und nachvollziehbare Sammlung<\/strong> von Apps.
\nLeider wird die Verwendung von AUs zur Verwaltung von Apps derzeit (M\u00e4rz 2024) von Microsoft nicht unterst\u00fctzt<\/strong>…<\/p>\n

<\/p>\n
Abschlie\u00dfende Worte<\/h2>\n
Bei Ihrer n\u00e4chsten \u00dcberpr\u00fcfung der App-Berechtigungen<\/a> fragen Sie Entwickler, ob es m\u00f6glich w\u00e4re, weniger Berechtigungen<\/strong> zu verwenden. Denken Sie daran, dass Sicherheit oft sekund\u00e4r<\/strong> im Entwicklungsprozess ist. Fordern Sie die Behauptung ‚wir brauchen das einfach<\/em>‚ heraus, indem Sie nach den spezifischen Anwendungsf\u00e4llen suchen, die abgedeckt werden m\u00fcssen – vielleicht gibt es L\u00f6sungen, die noch nicht in Betracht gezogen wurden.<\/p>\n
Andererseits, auch wenn ich erl\u00e4utere, wie wir Application.ReadWrite.All<\/em> ersetzen k\u00f6nnen und sollten, ist dies nicht immer<\/em> eine gute Idee. Wenn es ein System gibt, das 90% der Apps besitzt, rechtfertigt der Verwaltungsaufwand<\/strong> normalerweise nicht die geringf\u00fcgig erh\u00f6hte Sicherheit.
\nAu\u00dferdem, wenn Sie die Option von Entra ID benutzerdefinierten Rollen interessant finden, ist es nicht einfach<\/strong> zu verstehen, welche Entra ID Berechtigungen f\u00fcr eine bestimmte Graph-Operation notwendig sind – Sie m\u00fcssen bereit sein, ein wenig Trial and Error in Kauf zu nehmen.<\/p>\n

<\/p>\n
Habe ich einen g\u00e4ngigen Anwendungsfall \u00fcbersehen oder m\u00f6chten Sie diskutieren, warum man Application.ReadWrite.All<\/strong> ben\u00f6tigen k\u00f6nnte? Ich m\u00f6chte Ihre E-Mail-Adresse nicht, also bitte diskutieren Sie in meinem zugeh\u00f6rigen LinkedIn-Post<\/a>.<\/p>\n
Wenn Sie an den Dingen interessiert sind, die ich mache, folgen Sie mir auf LinkedIn.<\/p>\n","protected":false},"excerpt":{"rendered":"
Als Microsoft den Midnight Blizzard-Angriff vom Januar zum ersten Mal bekannt gab und ihre darauf folgende tiefere Analyse ver\u00f6ffentlichte, verfolgte ich den resultierenden Inhalt mit gro\u00dfem Interesse \u2013 Risiken, die von Enterprise Applikationen ausgehen, sind ein Herzensthema f\u00fcr mich. Wenn Sie Microsoft 365 auf einem vern\u00fcnftigen Niveau nutzen, werden Sie unweigerlich Enterprise Applikationen mit einem… » weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":562,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,48],"tags":[72,74,243,245,247,70,156,249,251,64,52,60,56,253,58,160,150,255],"class_list":["post-571","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-me-id","category-powershell","tag-aad","tag-aad-connect","tag-administrative-units-de","tag-application-readwrite-all-de","tag-application-readwrite-ownedby-de","tag-azure-ad","tag-best-practices","tag-custom-roles-de","tag-enterprise-app-ownership-de","tag-entra","tag-entra-id","tag-graph","tag-graph-api","tag-least-privilege-de","tag-microsoft-graph","tag-minimize-access","tag-overprivilege","tag-security-de"],"_links":{"self":[{"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/posts\/571","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/comments?post=571"}],"version-history":[{"count":5,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/posts\/571\/revisions"}],"predecessor-version":[{"id":580,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/posts\/571\/revisions\/580"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/media\/562"}],"wp:attachment":[{"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/media?parent=571"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/categories?post=571"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sparrow365.de\/index.php\/wp-json\/wp\/v2\/tags?post=571"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}