Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
bluemonday — bluemonday: ein schneller HTML-Sanitizer für Golang (inspiriert vom OWASP Java HTML Sanitizer), um nutzergenerierte Inhalte von XSS zu bereinigen | Kitploit
Tools/GitHubGitHub/microcosm-cc/bluemonday
DefensivwerkzeugeStatische AnalyseSchwachstellenanalyseCode-AnalyseWebsicherheitAPI-Sicherheit
GitHubmicrocosm-cc/bluemonday

bluemonday

bluemonday: ein schneller HTML-Sanitizer für Golang (inspiriert vom OWASP Java HTML Sanitizer), um nutzergenerierte Inhalte von XSS zu bereinigen

Repository anzeigen
3.7k1955vor 1 JahrVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

bluemonday GoDoc Sourcegraph

bluemonday ist ein in Go implementierter HTML-Sanitizer. Er ist schnell und in hohem Maße konfigurierbar.

bluemonday nimmt nicht vertrauenswürdige, nutzergenerierte Inhalte als Eingabe und gibt HTML zurück, das anhand einer Allowlist zugelassener HTML-Elemente und -Attribute bereinigt wurde, sodass du die Inhalte sicher in deine Webseite einbinden kannst.

Wenn du nutzergenerierte Inhalte akzeptierst und dein Server Go verwendet, brauchst du bluemonday.

Die Standard-Policy für nutzergenerierte Inhalte (bluemonday.UGCPolicy().Sanitize()) macht aus diesem:

root@kitploit:~
Hello <STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A>World

Ein harmloses:

root@kitploit:~
Hello World

Und es macht aus diesem:

root@kitploit:~
<a href="javascript:alert('XSS1')" onmouseover="alert('XSS2')">XSS<a>

Dieses:

root@kitploit:~
XSS

Während es weiterhin dieses:

root@kitploit:~
<a href="http://www.google.com/">
  <img src="https://ssl.gstatic.com/accounts/ui/logo_2x.png"/>
</a>

weitgehend unverändert durchlässt (es erhält ein rel="nofollow", was bei nutzergenerierten Inhalten eine gute Sache ist):

root@kitploit:~
<a href="http://www.google.com/" rel="nofollow">
  <img src="https://ssl.gstatic.com/accounts/ui/logo_2x.png"/>
</a>

Es schützt Webseiten vor XSS-Angriffen. Es gibt viele Vektoren für einen XSS-Angriff, und der beste Weg, das Risiko zu verringern, ist, Nutzereingaben anhand einer bekannten sicheren Liste von HTML-Elementen und -Attributen zu bereinigen.

Du solltest bluemonday immer nach jeder anderen Verarbeitung ausführen.

Wenn du blackfriday oder Pandoc verwendest, sollte bluemonday nach diesen Schritten ausgeführt werden. So wird sichergestellt, dass später in deinem Prozess kein unsicheres HTML eingeführt wird.

bluemonday ist stark vom OWASP Java HTML Sanitizer und vom HTML Purifier inspiriert.

Technische Zusammenfassung

Allowlist-basiert: Du musst entweder eine Policy erstellen, die die zu erlaubenden HTML-Elemente und -Attribute beschreibt (sowie die regexp-Muster der Attribute), oder eine der mitgelieferten Policies verwenden, die gute Standardwerte darstellen.

Die Policy mit der Allowlist wird mithilfe eines schnellen, nicht validierenden, nur vorwärts gerichteten, tokenbasierten Parsers angewendet, der im Go net/html Paket vom Go-Kernteam implementiert wurde.

Wir erwarten wohlgeformtes HTML (schließende Elemente für jedes zutreffende offene Element, korrekt verschachtelt) und konzentrieren uns daher nicht darauf, schlecht verschachteltes oder unvollständiges HTML zu reparieren. Wir stellen lediglich sicher, dass alle vorhandenen Elemente in der Policy-Allowlist beschrieben sind und dass Attribute und Links für die Verwendung auf deiner Webseite sicher sind. GIGO gilt auch hier: Wenn du schlechtes HTML eingibst, ist es nicht die Aufgabe von bluemonday, herauszufinden, wie man es wieder gut macht.

Ist es produktionsreif?

Ja

Wir verwenden bluemonday in der Produktion, nachdem wir vom weit verbreiteten und intensiv getesteten OWASP Java HTML Sanitizer migriert sind.

Wir bestehen unsere umfangreiche Testsuite (einschließlich AntiSamy-Tests sowie Tests für alle gemeldeten Probleme). Prüfe die ungelösten Issues, um zu sehen, ob etwas für dich ein Hindernis sein könnte.

Wir laden zu Pull Requests und Issues ein, um sicherzustellen, dass wir umfassenden Schutz gegen verschiedene Angriffe über nutzergenerierte Inhalte bieten.

Verwendung

Installation mit go get github.com/microcosm-cc/bluemonday

Danach aufrufen:

root@kitploit:~
package main

import (
	"fmt"

	"github.com/microcosm-cc/bluemonday"
)

func main() {
	// Do this once for each unique policy, and use the policy for the life of the program
	// Policy creation/editing is not safe to use in multiple goroutines
	p := bluemonday.UGCPolicy()

	// The policy can then be used to sanitize lots of input and it is safe to use the policy in multiple goroutines
	html := p.Sanitize(
		`<a onblur="alert(secret)" href="http://www.google.com">Google</a>`,
	)

	// Output:
	// <a href="http://www.google.com" rel="nofollow">Google</a>
	fmt.Println(html)
}

Wir bieten drei Möglichkeiten, Sanitize aufzurufen:

root@kitploit:~
p.Sanitize(string) string
p.SanitizeBytes([]byte) []byte
p.SanitizeReader(io.Reader) bytes.Buffer

Wenn du auf Performance stehst, gibt p.SanitizeReader(r).Bytes() ein []byte zurück, ohne unnötige Typumwandlungen der Ein- oder Ausgaben vorzunehmen. Der Unterschied ist jedoch so vernachlässigbar, dass du dich nie darum kümmern musst.

Du kannst deine eigenen Policies erstellen:

root@kitploit:~
package main

import (
	"fmt"

	"github.com/microcosm-cc/bluemonday"
)

func main() {
	p := bluemonday.NewPolicy()

	// Require URLs to be parseable by net/url.Parse and either:
	//   mailto: http:// or https://
	p.AllowStandardURLs()

	// We only allow <p> and <a href="">
	p.AllowAttrs("href").OnElements("a")
	p.AllowElements("p")

	html := p.Sanitize(
		`<a onblur="alert(secret)" href="http://www.google.com">Google</a>`,
	)

	// Output:
	// <a href="http://www.google.com">Google</a>
	fmt.Println(html)
}

Wir liefern zwei Standard-Policies mit:

  1. bluemonday.StrictPolicy(), die als Äquivalent zum Entfernen aller HTML-Elemente und ihrer Attribute betrachtet werden kann, da ihre Allowlist leer ist. Ein Beispielszenario wären Blog-Post-Titel, bei denen HTML-Tags überhaupt nicht erwartet werden; falls sie doch vorkommen, sollten die Elemente und der Inhalt der Elemente entfernt werden. Dies ist eine sehr strenge Policy.
  2. bluemonday.UGCPolicy(), die eine breite Auswahl an HTML-Elementen und -Attributen erlaubt, die für nutzergenerierte Inhalte sicher sind. Beachte, dass diese Policy keine iframes, object, embed, Styles, script usw. erlaubt. Ein Beispielszenario wären Blog-Post-Inhalte, bei denen eine Vielzahl von Formatierungen sowie die Möglichkeit von TABLEs und IMGs erwartet wird.

Policy-Erstellung

Das Wesentliche beim Erstellen einer Policy ist zu bestimmen, welche HTML-Elemente und -Attribute für dein Szenario als sicher gelten. OWASP bietet einen Spickzettel zur XSS-Prävention an, um die Risiken zu erklären, aber im Wesentlichen:

  1. Vermeide alles andere als die standardmäßigen HTML-Elemente
  2. Vermeide script-, style-, iframe-, object-, embed-, base-Elemente, die es ermöglichen, dass Code vom Client ausgeführt wird oder dass Inhalte Dritter eingebunden werden, die Code ausführen können
  3. Vermeide alles andere als einfache HTML-Attribute, deren Werte mit einem Regexp übereinstimmen.

Grundsätzlich solltest du in der Lage sein zu beschreiben, welches HTML für dein Szenario in Ordnung ist. Wenn du dir nicht sicher bist, dass du deine Policy beschreiben kannst, ziehe in Betracht, eine der mitgelieferten Policies wie bluemonday.UGCPolicy() zu verwenden.

Um eine neue Policy zu erstellen:

root@kitploit:~
p := bluemonday.NewPolicy()

Um Elemente zu einer Policy hinzuzufügen, füge entweder nur die Elemente hinzu:

root@kitploit:~
p.AllowElements("b", "strong")

Oder mit einem Regex:

Hinweis: Wenn ein Element wie oben gezeigt mit Namen hinzugefügt wird, wird ein passendes Regex ignoriert

Außerdem wird empfohlen, sicherzustellen, dass mehrere Muster sich nicht überschneiden, da die Ausführungsreihenfolge nicht garantiert ist und einige Regeln übersehen werden können.

root@kitploit:~
p.AllowElementsMatching(regex.MustCompile(`^my-element-`))

Oder füge Elemente durch das Hinzufügen eines Attributs hinzu:

root@kitploit:~
// Note the recommended pattern, see the recommendation on using .Matching() below
p.AllowAttrs("nowrap").OnElements("td", "th")

Auch hier wird eine Alternative mit Regex-Musterabgleich unterstützt:

root@kitploit:~
p.AllowAttrs("nowrap").OnElementsMatching(regex.MustCompile(`^my-element-`))

Attribute können entweder zu allen Elementen hinzugefügt werden:

root@kitploit:~
p.AllowAttrs("dir").Matching(regexp.MustCompile("(?i)rtl|ltr")).Globally()

Oder Attribute können zu bestimmten Elementen hinzugefügt werden:

root@kitploit:~
// Not the recommended pattern, see the recommendation on using .Matching() below
p.AllowAttrs("value").OnElements("li")

Es wird immer empfohlen, Attribute an ein Muster zu koppeln. Andernfalls ist XSS in HTML-Attributen sehr leicht möglich:

root@kitploit:~
// \p{L} matches unicode letters, \p{N} matches unicode numbers
p.AllowAttrs("title").Matching(regexp.MustCompile(`[\p{L}\p{N}\s\-_',:\[\]!\./\\\(\)&]*`)).Globally()

Du kannst jederzeit aufhören und .Sanitize() aufrufen:

root@kitploit:~
// string htmlIn passed in from a HTTP POST
htmlOut := p.Sanitize(htmlIn)

Und du kannst jede vorhandene Policy nehmen und erweitern:

root@kitploit:~
p := bluemonday.UGCPolicy()
p.AllowElements("fieldset", "select", "option")

Inline-CSS

Obwohl es möglich ist, Inline-CSS mit AllowAttrs und einer Matching-Regel zu behandeln, ist das Schreiben eines einzigen monolithischen regulären Ausdrucks, der das gesamte Inline-CSS, das du erlauben möchtest, sicher verarbeitet, keine triviale Aufgabe. Anstatt dies zu versuchen, kannst du das style-Attribut für die gewünschten Elemente erlauben und Style-Policies verwenden, um Inline-Styles zu kontrollieren und zu bereinigen.

Es wird dringend empfohlen, Matching (mit einem geeigneten regulären Ausdruck) MatchingEnum oder MatchingHandler zu verwenden, um sicherzustellen, dass jeder Style deinen Anforderungen entspricht, aber für die am häufigsten verwendeten Styles sind Standard-Handler enthalten.

Ähnlich wie bei Attributen kannst du erlauben, dass bestimmte CSS-Eigenschaften inline gesetzt werden:

root@kitploit:~
p.AllowAttrs("style").OnElements("span", "p")
// Allow the 'color' property with valid RGB(A) hex values only (on any element allowed a 'style' attribute)
p.AllowStyles("color").Matching(regexp.MustCompile("(?i)^#([0-9a-f]{3,4}|[0-9a-f]{6}|[0-9a-f]{8})$")).Globally()

Zusätzlich kannst du erlauben, dass eine CSS-Eigenschaft nur auf einen erlaubten Wert gesetzt wird:

root@kitploit:~
p.AllowAttrs("style").OnElements("span", "p")
// Allow the 'text-decoration' property to be set to 'underline', 'line-through' or 'none'
// on 'span' elements only
p.AllowStyles("text-decoration").MatchingEnum("underline", "line-through", "none").OnElements("span")

Oder du kannst Elemente basierend auf einem Regex-Musterabgleich angeben:

root@kitploit:~
p.AllowAttrs("style").OnElementsMatching(regex.MustCompile(`^my-element-`))
// Allow the 'text-decoration' property to be set to 'underline', 'line-through' or 'none'
// on 'span' elements only
p.AllowStyles("text-decoration").MatchingEnum("underline", "line-through", "none").OnElementsMatching(regex.MustCompile(`^my-element-`))

Wenn du eine genauere Prüfung benötigst, kannst du einen Handler erstellen, der einen String entgegennimmt und einen bool zurückgibt, um die Werte für eine bestimmte Eigenschaft zu validieren. Der String-Parameter wurde in Kleinbuchstaben umgewandelt und Unicode-Codepunkte wurden konvertiert.

root@kitploit:~
myHandler := func(value string) bool{
	// Validate your input here
	return true
}
p.AllowAttrs("style").OnElements("span", "p")
// Allow the 'color' property with values validated by the handler (on any element allowed a 'style' attribute)
p.AllowStyles("color").MatchingHandler(myHandler).Globally()

Links

Links sind schwierige Kandidaten, um sie sicher zu bereinigen, und zudem einer der größten Angriffsvektoren für bösartige Inhalte.

Es ist möglich, Folgendes zu tun:

root@kitploit:~
p.AllowAttrs("href").Matching(regexp.MustCompile(`(?i)mailto|https?`)).OnElements("a")

Das wird dich jedoch nicht schützen, da der reguläre Ausdruck in diesem Fall nicht ausreicht, um zu verhindern, dass ein fehlerhafter Wert etwas Unerwartetes tut.

Wir bieten einige zusätzliche globale Optionen für die sichere Arbeit mit Links.

RequireParseableURLs stellt sicher, dass URLs mit dem net/url-Paket von Go geparst werden können:

root@kitploit:~
p.RequireParseableURLs(true)

Wenn du parsbare URLs aktiviert hast, erlaubt die folgende Option AllowRelativeURLs. Standardmäßig ist dies deaktiviert (bluemonday ist ein Allowlist-Tool ... du musst uns explizit mitteilen, was erlaubt sein soll). Wenn deaktiviert, werden alle lokalen und schema-relativen URLs verhindert (d. h. href="localpage.html", href="../home.html" und sogar href="//www.google.com" sind relativ):

root@kitploit:~
p.AllowRelativeURLs(true)

Wenn du parsbare URLs aktiviert hast, kannst du die zulässigen Schemata (bei http und https auch Protokoll genannt) erlauben. Beachte, dass das Erlauben relativer URLs in der obigen Option ein leeres Schema zulässt:

root@kitploit:~
p.AllowURLSchemes("mailto", "http", "https")

Unabhängig davon, ob du parsbare URLs aktiviert hast, kannst du erzwingen, dass alle URLs ein rel="nofollow"-Attribut haben. Dieses wird hinzugefügt, wenn es nicht vorhanden ist, aber nur, wenn der href gültig ist:

root@kitploit:~
// This applies to "a" "area" "link" elements that have a "href" attribute
p.RequireNoFollowOnLinks(true)

Ebenso kannst du erzwingen, dass alle URLs "noreferrer" in ihrem rel-Attribut haben.

root@kitploit:~
// This applies to "a" "area" "link" elements that have a "href" attribute
p.RequireNoReferrerOnLinks(true)

Wir bieten eine Komfortmethode, die all das oben Genannte anwendet, aber du musst weiterhin die verlinkbaren Elemente erlauben, damit die URL-Regeln angewendet werden:

root@kitploit:~
p.AllowStandardURLs()
p.AllowAttrs("cite").OnElements("blockquote", "q")
p.AllowAttrs("href").OnElements("a", "area")
p.AllowAttrs("src").OnElements("img")

Eine weitere Komplexität in Bezug auf Links ist die Data-URI gemäß RFC2397. Die Data-URI ermöglicht es, Bilder inline über dieses Format auszuliefern:

root@kitploit:~
<img src="data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=">

Wir haben einen Helfer bereitgestellt, um den Mimetyp gefolgt vom Base64-Inhalt von Data-URI-Links zu überprüfen:

root@kitploit:~
p.AllowDataURIImages()

Dieser Helfer aktiviert GIF-, JPEG-, PNG- und WEBP-Bilder.

Es sei darauf hingewiesen, dass mit der Verwendung von Data-URI-Links ein potenzielles Sicherheits-risiko verbunden ist. Du solltest Data-URI-Links nur aktivieren, wenn du den Inhalten bereits vertraust.

Wir haben auch einige Funktionen, die den Umgang mit nutzergenerierten Inhalten erleichtern:

root@kitploit:~
p.AddTargetBlankToFullyQualifiedLinks(true)

Dies stellt sicher, dass Anker-<a href="" />-Links, die voll qualifiziert sind (das href-Ziel enthält einen Hostnamen), mit target="_blank" ergänzt werden.

Zusätzlich erhält jeder Link, der nach Anwendung der Policy target="_blank" hat, auch das rel-Attribut um noopener ergänzt. Das bedeutet, dass ein Link wie <a href="//host/path"/> beginnen und als <a href="//host/path" rel="noopener" target="_blank"> enden kann. Es ist wichtig zu beachten, dass das Hinzufügen von noopener ein Sicherheitsmerkmal und kein Problem ist. Browser haben die unglückliche Eigenschaft, dass ein als Ergebnis von target="_blank" geöffnetes Browserfenster den Opener (deine Webseite) weiterhin steuern kann; dies schützt davor. Der Hintergrund dazu ist hier zu finden: https://dev.to/ben/the-targetblank-vulnerability-by-example

Hilfsfunktionen für die Policy-Erstellung

Wir bündeln auch einige Helfer, um die Policy-Erstellung zu vereinfachen:

root@kitploit:~

// Permits the "dir", "id", "lang", "title" attributes globally
p.AllowStandardAttributes()

// Permits the "img" element and its standard attributes
p.AllowImages()

// Permits ordered and unordered lists, and also definition lists
p.AllowLists()

// Permits HTML tables and all applicable elements and non-styling attributes
p.AllowTables()

Ungültige Anweisungen

Die folgenden Anweisungen sind ungültig:

root@kitploit:~
// This does not say where the attributes are allowed, you need to add
// .Globally() or .OnElements(...)
// This will be ignored without error.
p.AllowAttrs("value")

// This does not say where the attributes are allowed, you need to add
// .Globally() or .OnElements(...)
// This will be ignored without error.
p.AllowAttrs(
	"type",
).Matching(
	regexp.MustCompile("(?i)^(circle|disc|square|a|A|i|I|1)$"),
)

Beide Beispiele weisen dasselbe Problem auf: Sie deklarieren Attribute, geben aber nicht an, ob diese global oder nur auf bestimmten Elementen (und auf welchen) erlaubt sind. Attribute gehören zu einem oder mehreren Elementen, und die Policy muss dies deklarieren.

Einschränkungen

Wir haben noch keine Werkzeuge enthalten, die das Erlauben und Bereinigen von CSS unterstützen. Das bedeutet, dass du, sofern du die schwere Arbeit nicht in einem einzigen regulären Ausdruck erledigen möchtest (nicht empfehlenswert), das "style"-Attribut nirgendwo erlauben solltest.

Im gleichen Sinne gelten sowohl <script> als auch <style> als schädlich. Diese Elemente (und ihre Inhalte) werden standardmäßig nicht gerendert und erfordern, dass du explizit p.AllowUnsafe(true) setzt. Dir sollte bewusst sein, dass das Erlauben dieser Elemente den Zweck eines HTML-Sanitizers zunichtemacht, da du entweder JavaScript (und jedes klar geschriebene XSS) und CSS (das ein DOM modifizieren kann, um JS einzufügen) explizit erlauben würdest. Darüber hinaus hat diese Bibliothek die Einschränkung, dass sie nicht erkennt, ob HTML gültig strukturiert ist, und das kann dazu führen, dass diese Elemente einige der Sicherheitsmechanismen des WhatWG-HTML-Parser-Standards umgehen.

Es ist nicht die Aufgabe von bluemonday, dein schlechtes HTML zu reparieren; es ist lediglich die Aufgabe von bluemonday, zu verhindern, dass bösartiges HTML durchkommt. Wenn du nicht zusammengehörige HTML-Elemente oder nicht konforme Verschachtelungen von Elementen hast, bleiben diese erhalten. Wenn du jedoch wohlstrukturiertes HTML hast, wird bluemonday es nicht zerstören.

TODO

  • Untersuchen, ob Entwickler Elemente und Attribute auf eine Blacklist setzen möchten. Dies würde es Entwicklern ermöglichen, eine vorhandene Policy (wie bluemonday.UGCPolicy()) zu nehmen, die 90 % dessen abdeckt, was sie suchen, aber mehr tut, als sie brauchen, und die zusätzlichen Dinge zu entfernen, die sie nicht möchten, um sie zu 100 % ihren Vorstellungen anzupassen.
  • Untersuchen, ob Entwickler einen validierenden HTML-Modus möchten, in dem die HTML-Elemente nicht nur in einen ausbalancierten Baum umgewandelt werden (jedes Start-Tag hat ein schließendes Tag in der richtigen Tiefe), sondern auch, dass Elemente und Zeichendaten nur in ihrem erlaubten Kontext vorkommen (d. h., dass ein table-Element kein Nachkomme eines caption ist, dass colgroup, thead, tbody, tfoot und tr erlaubt sind und dass Zeichendaten nicht erlaubt sind).

Langfristige Ziele

  1. Den Code für eine feindselige Peer-Review öffnen, ähnlich den Attack Review Ground Rules
  2. Mittel einwerben und ein externes Sicherheits-Review bezahlen
Tool herunterladen