Subresource Integrity für IIS konfigurieren
Schritt-für-Schritt-Anleitung: SRI-Hashes generieren, integrity-Attribute setzen, Fallback-Strategien in ASP.NET Razor Views und Build-Pipeline-Automatisierung.
Subresource Integrity in IIS
Subresource Integrity (SRI) schützt gegen manipulierte CDN-Ressourcen. Der Browser prüft den Hash einer externen Datei, bevor er sie ausführt. Mit 15 von 166 Punkten im Wolf-Agents Web Security Check ist SRI ein wichtiger Schutz gegen Supply-Chain-Angriffe.
SRI ist kein Server-Header, sondern ein HTML-Attribut (integrity) auf <script>- und <link>-Tags. In IIS-gehosteten Anwendungen generieren Sie die Hashes per PowerShell und setzen die Attribute in ASP.NET Razor Views, statischen HTML-Seiten oder Ihrem Build-Prozess. Die ASP.NET Core TagHelpers bieten zusätzlich automatisches Fallback auf lokale Dateien.
Besonders in Windows-Umgebungen mit IIS ist SRI kritisch: Viele Unternehmensanwendungen laden Bibliotheken von öffentlichen CDNs. Ein kompromittiertes CDN könnte schadhaften Code in Ihre Anwendung einschleusen — SRI verhindert das zuverlässig.
SRI-Hashes per PowerShell generieren
Berechnen Sie SHA-384 Hashes für jede externe Ressource. PowerShell bietet native Crypto-Funktionen dafür. Für mehrere Bibliotheken nutzen Sie das Batch-Script, das alle URLs auf einmal verarbeitet.
# PowerShell — SRI-Hash generieren
# SHA-384 Hash für eine externe Ressource berechnen
$url = "https://cdn.example.com/lib.min.js"
$content = (Invoke-WebRequest -Uri $url).Content
$bytes = [System.Text.Encoding]::UTF8.GetBytes($content)
$hash = [System.Security.Cryptography.SHA384]::Create().ComputeHash($bytes)
$base64 = [Convert]::ToBase64String($hash)
Write-Host "sha384-$base64"
# Alternative mit openssl (Git Bash auf Windows):
# curl -s https://cdn.example.com/lib.min.js \
# | openssl dgst -sha384 -binary | openssl base64 -A # PowerShell — Mehrere Ressourcen auf einmal hashen
# Nuetzlich für Projekte mit vielen CDN-Abhaengigkeiten
$resources = @(
"https://cdn.example.com/jquery-3.7.1.min.js",
"https://cdn.example.com/bootstrap-5.3.3.min.css",
"https://cdn.example.com/alpine-3.14.min.js"
)
foreach ($url in $resources) {
$content = (Invoke-WebRequest -Uri $url).Content
$bytes = [System.Text.Encoding]::UTF8.GetBytes($content)
$hash = [System.Security.Cryptography.SHA384]::Create().ComputeHash(
$bytes)
$sri = "sha384-$([Convert]::ToBase64String($hash))"
Write-Host "$url"
Write-Host " integrity=$sri"
Write-Host ""
} integrity-Attribute in HTML einfügen
Fügen Sie integrity und crossorigin="anonymous" zu jedem externen Script und Stylesheet hinzu. Das crossorigin-Attribut ist zwingend für SRI bei Cross-Origin-Ressourcen. Ohne dieses Attribut ignoriert der Browser den Hash komplett.
<!-- HTML — SRI-Attribute in Script- und Link-Tags -->
<!-- Externes JavaScript mit SRI -->
<script
src="https://cdn.example.com/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"></script>
<!-- Externes Stylesheet mit SRI -->
<link
rel="stylesheet"
href="https://cdn.example.com/style.min.css"
integrity="sha384-abc123def456..."
crossorigin="anonymous">
<!-- Mehrere Hash-Algorithmen für Abwaertskompatibilitaet -->
<script
src="https://cdn.example.com/legacy.js"
integrity="sha256-abc... sha384-xyz..."
crossorigin="anonymous"></script> ASP.NET Razor Fallback-Strategie
ASP.NET Core TagHelpers bieten asp-fallback-src für automatisches Fallback auf lokale Dateien, wenn der SRI-Check fehlschlaegt. So bleibt Ihre Anwendung auch bei CDN-Ausfall funktionsfaehig. Die TagHelpers injizieren automatisch einen Test, der prüft, ob die CDN-Ressource geladen wurde.
// ASP.NET Razor View — SRI mit TagHelper
// In _ViewImports.cshtml:
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
// In der View — Script mit Fallback:
<script
src="https://cdn.example.com/lib.min.js"
asp-fallback-src="~/js/lib.min.js"
asp-fallback-test="window.myLib"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6..."
crossorigin="anonymous"></script>
// Stylesheet mit Fallback:
<link
rel="stylesheet"
href="https://cdn.example.com/bootstrap.min.css"
asp-fallback-href="~/css/bootstrap.min.css"
asp-fallback-test-class="sr-only"
asp-fallback-test-property="position"
asp-fallback-test-value="absolute"
integrity="sha384-..."
crossorigin="anonymous"> SRI in der Build-Pipeline automatisieren
Manuelle Hash-Pflege ist fehleranfaellig. Automatisieren Sie die SRI-Hash-Generierung als Teil Ihres Build-Prozesses. Das PowerShell-Script kann als MSBuild PostBuild-Event, Azure DevOps Pipeline-Step oder GitHub Actions-Schritt eingebunden werden.
# PowerShell Build-Script — SRI-Hashes automatisch generieren
# Einbinden als MSBuild PostBuild-Event oder CI/CD-Step
param(
[string]$HtmlPath = "C:\inetpub\wwwroot\index.html"
)
$html = Get-Content $HtmlPath -Raw
$updated = $false
# Alle externen Script-URLs finden
$matches = [regex]::Matches(
$html, 'src="(https://[^"]+\.js)"')
foreach ($m in $matches) {
$url = $m.Groups[1].Value
$content = (Invoke-WebRequest -Uri $url).Content
$bytes = [System.Text.Encoding]::UTF8.GetBytes(
$content)
$hash = [Convert]::ToBase64String(
[System.Security.Cryptography.SHA384]::Create()
.ComputeHash($bytes))
Write-Host "Hash: $url → sha384-$hash"
$updated = $true
}
if ($updated) {
Write-Host "SRI-Hashes aktualisiert." -ForegroundColor Green
} SRI-Konfiguration verifizieren
Prüfen Sie, ob alle externen Ressourcen SRI-Attribute haben. Öffnen Sie die Browser DevTools (F12) und die Console — bei fehlerhaften Hashes erscheint eine Fehlermeldung, und die Ressource wird blockiert. Das PowerShell-Script prüft einzelne Hashes gegen den aktuellen CDN-Inhalt.
# PowerShell — SRI-Konfiguration verifizieren
# Methode 1: HTML-Quelltext prüfen
$response = Invoke-WebRequest -Uri "https://ihre-domain.de"
$hasIntegrity = $response.Content -match 'integrity="sha'
Write-Host "SRI-Attribute vorhanden: $hasIntegrity"
# Methode 2: Einzelnen Hash verifizieren
$url = "https://cdn.example.com/lib.min.js"
$expected = "sha384-oqVuAfXRKap7fdgcCY5..."
$content = (Invoke-WebRequest -Uri $url).Content
$bytes = [System.Text.Encoding]::UTF8.GetBytes($content)
$actual = "sha384-$([Convert]::ToBase64String(
[System.Security.Cryptography.SHA384]::Create()
.ComputeHash($bytes)))"
if ($expected -eq $actual) {
Write-Host "Hash korrekt" -ForegroundColor Green
} else {
Write-Host "Hash stimmt nicht!" -ForegroundColor Red
Write-Host " Erwartet: $expected"
Write-Host " Aktuell: $actual"
} Häufige Fehler
crossorigin-Attribut fehlt
Ohne crossorigin="anonymous" bei Cross-Origin-Ressourcen ignoriert der Browser den SRI-Hash und laedt die Datei ohne Prüfung. Dies ist der häufigste Fehler bei der SRI-Implementierung in IIS-Anwendungen.
CDN-Update ändert Hash
Wenn das CDN eine Bibliothek aktualisiert, ändert sich der Hash. Der Browser blockiert die neue Version. Pinnen Sie CDN-URLs auf exakte Versionen (z.B. /3.7.1/ statt /latest/).
SRI für dynamische Ressourcen
SRI funktioniert nur für statische Dateien mit konstantem Inhalt. Dynamisch generierte Scripts (z.B. per ASP.NET) ändern sich bei jedem Request — SRI ist hier nicht einsetzbar. Nutzen Sie stattdessen CSP-Nonces.
Application Pool Recycling
Wenn der IIS Application Pool während eines Downloads recycelt wird, kann eine unvollständige Ressource geladen werden. Der SRI-Hash stimmt dann nicht. Konfigurieren Sie das Recycling außerhalb der Hauptnutzungszeiten.
Compliance-Relevanz
PCI DSS 4.0 (Anforderung 6.4.3) fordert die Kontrolle aller externen Scripts auf Zahlungsseiten. SRI ist die technische Umsetzung dieser Anforderung. NIS2 verlangt Schutz der Software-Lieferkette — SRI verhindert, dass kompromittierte CDN-Ressourcen ausgeführt werden. Der Wolf-Agents Web Security Check bewertet SRI mit bis zu 15 Punkten.
Wie steht Ihre Domain bei SRI?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.