spamscanner/url-regex-safeAbgleich von URLs mit regulären Ausdrücken. Gepflegte, sichere und browserfreundliche Version von url-regex. Behebt CVE-2020-7661 für Node.js-Server.
Regulärer Ausdruck zum Abgleich von URLs. Gepflegte, sichere und browserfreundliche Version von url-regex. Löst CVE-2020-7661 für Node.js-Server. Funktioniert in Node v14+ und Browsern. Gepflegt für Spam Scanner und Forward Email.
Nach der Entdeckung von CVE-2020-7661 und der öffentlichen Offenlegung (durch meine Arbeit an Spam Scanner und Forward Email) – habe ich eine Implementierung von url-regex mit etwas zusätzlichem Kleber verwendet, um ungültige URL-Übereinstimmungen herauszufiltern.
Nachdem ich es jedoch in der Produktion bei Forward Email (das Hunderttausende E-Mails pro Woche verarbeitet) eingesetzt habe, fand und dokumentierte ich mehrere weitere Kernprobleme mit url-regex.
Da url-regex nicht mehr aktiv gepflegt wird, zum Zeitpunkt dieses Schreibens 9 offene Pull Requests hat und auch keine Browser-Unterstützung bot, entschied ich mich, dieses Paket für alle zu schreiben und alle offenen Pull Requests zusammenzuführen.
Dieses Paket sollte hoffentlich eher der realen beabsichtigten Verwendung eines URL-Regulärausdrucks entsprechen und dem Benutzer ermöglichen, es nach Wunsch zu konfigurieren. Bitte schauen Sie sich Forward Email an, wenn Ihnen dieses Paket geholfen hat, und erkunden Sie unseren Quellcode auf GitHub, der zeigt, wie wir dieses Paket verwenden.
HINWEIS: Das Standardverhalten dieses Pakets versucht, re2 zu laden (es ist eine optionale Peer-Abhängigkeit, die verwendet wird, um Denial-of-Service-Angriffe durch reguläre Ausdrücke und mehr zu verhindern). Wenn Sie dieses Verhalten nutzen möchten, müssen Sie re2 über npm install re2 installiert haben – andernfalls wird auf normale RegExp-Instanzen zurückgegriffen. Ab Version 4.0.0 haben wir eine Option hinzugefügt, falls Sie dieses Paket zwingen möchten, nicht einmal zu versuchen, re2 zu laden (z. B. wenn es in Ihrem node_modules ist, Sie es aber nicht verwenden möchten) – übergeben Sie einfach re2: false als Option.
npm:
npm install url-regex-safe
Wir haben CVE-2020-7661 behoben, indem wir RE2 für die Node.js-Nutzung eingebunden haben. Sie müssen Ihre URL-Regulärausdrücke nicht mehr manuell mit new RE2(urlRegex()) umschließen, wenn Sie url-regex-safe verwenden (das erledigen wir automatisch für Sie).
const urlRegexSafe = require('url-regex-safe');
const str = 'some long string with url.com in it';
const matches = str.match(urlRegexSafe());
for (const match of matches) {
console.log('match', match);
}
console.log(urlRegexSafe({ exact: true }).test('github.com'));
Da RE2 nicht für den Browser entwickelt wurde, wird es nicht verwendet, und daher ist CVE-2020-7661 auf der Client-Seite weiterhin ein Problem. Es ist jedoch nicht schwerwiegend, da es im schlimmsten Fall nur den Browser-Tab zum Absturz bringt (während es auf der Node.js-Seite den gesamten Prozess zum Absturz gebracht und eine Out-of-Memory-Ausnahme ausgelöst hätte).
Dies ist die Lösung für Sie, wenn Sie einfach überall <script>-Tags verwenden!
<script src="https://unpkg.com/url-regex-safe"></script>
<script type="text/javascript">
(function() {
var str = 'some long string with url.com in it';
var matches = str.match(urlRegexSafe());
for (var i=0; i<matches.length; i++) {
console.log('match', matches[i]);
}
console.log(urlRegexSafe({ exact: true }).test('github.com'));
})();
</script>
Angenommen, Sie verwenden browserify, webpack, rollup oder einen anderen Bundler, können Sie einfach der Node-Nutzung oben folgen.
Um dieses Paket mit TypeScript zu verwenden, können Sie das Paket @types/url-regex-safe für Typdefinitionen installieren.
npm install --save-dev @types/url-regex-safe
| Eigenschaft | Typ | Standardwert | Beschreibung | |
|---|---|---|---|---|
re2 | Boolean | true | Versucht, re2 anstelle von RegExp zum Erstellen neuer regulärer Ausdrucksinstanzen zu laden. Wenn Sie re2: false übergeben, wird re2 nicht einmal versucht zu laden. | |
exact | Boolean | false | Nur einen exakten String abgleichen. Nützlich mit regex.test(str), um zu prüfen, ob ein String eine URL ist. Wir setzen dies standardmäßig auf false, um String-Werte wie github.com abzugleichen (im Gegensatz zu der Anforderung eines Protokolls oder einer www-Subdomain). Wir glauben, dass dies eher der realen beabsichtigten Verwendung dieses Pakets entspricht. | |
strict | Boolean | false | URLs müssen mit einem gültigen Protokoll oder www beginnen, wenn auf true gesetzt. Wenn true, wird jede TLD erlaubt, solange sie mindestens 2 gültige Zeichen lang ist. Ist es false, wird die TLD mit der Liste der gültigen TLDs unter Verwendung von tlds abgeglichen. | |
auth | Boolean | false | Abgleich mit Basic-Authentication-Headern. Wir setzen dies standardmäßig auf false, da es in Chromium veraltet ist und andernfalls unerwünschte URL-Übereinstimmungen erzeugt (entspricht eher der realen beabsichtigten Verwendung dieses Pakets, indem es standardmäßig auch auf false gesetzt ist). | |
localhost | Boolean | true | Erlaubt localhost im Hostname-Teil der URL. Siehe test/test.js für weitere Einblicke in den localhost-Test und wie dieser einen möglicherweise unerwünschten Wert zurückgibt. Ein Pull-Request zur Lösung des Problems "pic.jp" vs. "pic.jpg" wäre willkommen. |
Sie müssen den Standardwert überschreiben und strict: true setzen, wenn Sie nicht github.com allein abgleichen möchten (allerdings wird www.github.com funktionieren, wenn strict: false ist).
Im Gegensatz zum veralteten und nicht mehr gepflegten Paket url-regex machen wir einige Dinge anders:
strict standardmäßig auf false (url-regex hatte dies auf true gesetzt)auth-Option hinzugefügt, die standardmäßig auf false gesetzt ist (url-regex gleicht Basic Authentication ab; hatte dies auf true gesetzt – dies ist jedoch ein veraltetes Verhalten in Chromium).parens- und ipv6-Optionen hinzugefügt, die standardmäßig auf false bzw. true gesetzt sind (url-regex hatte parens auf true gesetzt und ipv6 war nicht vorhanden oder auf false gesetzt).apostrophe-Option hinzugefügt, die standardmäßig auf false gesetzt ist (url-regex hatte dies auf true gesetzt).trailingPeriod-Option hinzugefügt, die standardmäßig auf false gesetzt ist (was bedeutet, dass Treffer keine nachgestellten Punkte enthalten, während url-regex dies auf true gesetzt hatte).Diese Einschränkung gilt nur, wenn Sie re2 verwenden: Da wir die Funktionalität "Negativer Lookbehind" von regulären Ausdrücken nicht nutzen können (aufgrund von RE2-Einschränkungen), konnten wir die Logik aus diesem Pull Request nicht zusammenführen. Dies hätte es uns ermöglicht, example.jpeg nur dann abzugleichen, wenn es example.jp wäre. Wenn Sie jedoch derzeit example.jpeg übergeben, wird example.jp daraus extrahiert (da .jp eine TLD ist). Möglicherweise existiert eine alternative Lösung, und wir begrüßen Beiträge aus der Community zu diesem Problem.
| Name | Website |
|---|---|
| Forward Email LLC | https://forwardemail.net |
| Kevin Mårtensson | |
| Diego Perini |
parens | Boolean | false | Abgleich mit Markdown-artigen nachgestellten Klammern. Wir setzen dies auf false, da es dem Benutzer überlassen bleiben sollte, nach Markdown-URLs zu parsen. |
apostrophes | Boolean | false | Abgleich mit Apostrophen. Wir setzen dies auf false, da wir nicht möchten, dass der String background: url('http://example.com/pic.jpg'); zu http://example.com/pic.jpg' führt. Siehe dieses Issue für weitere Informationen. |
trailingPeriod | Boolean | false | Abgleich mit nachgestellten Punkten. Wir setzen dies standardmäßig auf false, da das reale Verhalten example.com anstelle von example.com. als Treffer erwarten würde (dies unterscheidet sich von url-regex, das in diesem Paket den nachgestellten Punkt abgleicht). |
ipv4 | Boolean | true | Abgleich mit IPv4-URLs. |
ipv6 | Boolean | true | Abgleich mit IPv6-URLs. |
tlds | Array | tlds | Abgleich mit einer bestimmten Liste von TLDs oder der Standardliste von tlds. |
returnString | Boolean | false | Gibt den RegExp als String statt als RegExp zurück (nützlich für benutzerdefinierte Logik, wie wir es bei Spam Scanner gemacht haben). |