Xterm.js: Support Hyperlink Ansi Escape

Gute Idee, PR willkommen!

Es könnte zum Standard werden und das Parsen erleichtern.
Zugehöriges Problem: https://github.com/xtermjs/xterm.js/issues/583

Der größte Vorteil ist, dass wir Text verknüpfen können, ohne das Terminal mit einer langen URL spammen zu müssen. Zum Beispiel könnte man in Fehlermeldungen auf die Dokumentation verlinken, ohne sie sehr ausführlich zu machen.

Dies sollte mit Vorsicht implementiert werden. Sie müssen in der Lage sein, den Link zu bewegen, um zu sehen, wohin er führt. Andernfalls können Sie Benutzer unwissentlich mit bösartigen Websites verknüpfen. Dies ist bereits ein großes Problem beim E-Mail-Phishing.

Sie könnten beispielsweise einen Link erstellen, der den Titel "login.facebook.com" trägt, ihn jedoch tatsächlich mit login.faceboook.com verknüpft. Die Seite sieht genauso aus, das Kennwort des Benutzers wird jedoch beim Anmelden gespeichert.

iTerm2 zeigt die URL folgendermaßen an:

Dies ähnelt auch der Anzeige der URL durch Chrome, wenn Sie mit der Maus über Links fahren.

Wenn dies implementiert ist, senden Sie bitte ein Problem oder eine PR an supports-hyperlinks , um die Unterstützung für diese Funktion zu ermitteln.

@jamestalmage Dies muss wahrscheinlich den Einbettern von xterm.js überlassen bleiben. Derzeit gehört die Umgebung den Terminalemulatoren, die xterm.js verwenden. Zum Beispiel setzen Hyper- und VS-Code jeweils einzeln TERM_PROGRAM .

@Tyriar - In diesem Fall supports-hyperlinks in das Commit ein, das dies auslöst , und in die Versionshinweise, wenn es weit geht. Ich bin mir nicht sicher, ob es supports-hyperlinks Äquivalente für andere Sprachen gibt, aber wenn ja, sind sie wahrscheinlich auch erwähnenswert.

Ich habe eine Proof-of-Concept-Implementierung:

links.txt

Es gibt ein grundlegendes Problem darin, dass diese Links nicht wirklich im Puffer gespeichert sind und daher verschwinden, wenn die Größe des Fensters geändert wird. Stattdessen werden die Linkinformationen in MouseZoneManager gespeichert, das durch _mouseZoneManager.clearAll gelöscht wird.

Ich glaube, ein echter Fix muss warten, bis die Neuimplementierung des Puffers abgeschlossen ist. Wir brauchen einen Mechanismus zum Annotieren von Zellen und / oder Zellbereichen, der bei Größenänderung stabil ist.

(Oder vielleicht fehlt mir einfach etwas, weil ich neu in dieser Codebasis bin.)

Ich glaube, ein echter Fix muss warten, bis die Neuimplementierung des Puffers abgeschlossen ist. Wir brauchen einen Mechanismus zum Annotieren von Zellen und / oder Zellbereichen, der bei Größenänderung stabil ist.

@PerBothner ja du hast wahrscheinlich recht. Eine andere Sache, über die wir nachdenken müssen, bevor dies ausgeliefert werden kann, ist, wie die zugrunde liegende URL von xterm.js verfügbar gemacht wird, damit Einbettungsprogramme sie in der Benutzeroberfläche anzeigen können. Wir möchten es wahrscheinlich auch aus Sicherheitsgründen standardmäßig deaktivieren (da die URL standardmäßig nicht angezeigt wird).

Ich habe meinen Patch aktualisiert und in einen Zweig verschoben :

Nicht bereit für eine Pull-Anfrage - verschiedene zuvor erwähnte Probleme wurden nicht behoben.

Vorschlag für die API, dies zu verwenden:

export class Terminal {
    /**
     * Adds a handler for the ANSI hyperlink escape `\x1b]8;;url\alabel\x1b]8;;`, you should use
     * this API to display the full URL to the user. Note that ANSI hyperlinks will only work if
     * there is a handler for security reasons.
     * <strong i="6">@param</strong> onHover The callback that fires when the mouse enters a link's zone.
     * <strong i="7">@param</strong> onLeave The callback that fires when the mouse leaves a link's zone.
     * <strong i="8">@return</strong> An IDisposable which can be used to disable the handler.
     */
    addAnsiHyperlinkHandler(onHover: (event: MouseEvent, url: string) => void, onLeave: () => void): IDisposable;
}

@mofux @jerch Feedback zur API-Form? Ich kann diesen Thread nicht finden, der über die Form dieser spricht, aber vielleicht sollte dies set anstelle von add da es nur Sinn macht, 1 zu haben.

Es könnte auch besser sein, so etwas wie ILinkHoverEvent :

interface ILinkHoverEvent {
  // Maybe the cell the mouse is under is also needed?
  x1: number;
  y1: number;
  x2: number;
  y2: number;
  url: string;
}

export class Terminal {
    addAnsiHyperlinkHandler(onHover: (event: ILinkHoverEvent) => void, onLeave: () => void): IDisposable;
}

Eine andere Alternative:

interface ILinkHoverEvent {
  linkStart: Cell;
  linkEnd: Cell;
  mousePosition: Cell;
  url: string
}

@ Tyriar IMO macht es wenig Sinn, dafür einen separaten Handler zu erstellen. Der wahrscheinliche Verbraucher dieser API wäre unser Renderer, der die URL in einem Tooltip rendert, wenn wir den Mauszeiger über den verknüpften Text bewegen, nicht wahr? Vielleicht wäre es sinnvoll, unseren Linkifier mit den oben genannten Hooks für onLinkHover und onLinkLeave und diese Ansi-Hyperlinks so zu behandeln, wie wir es derzeit mit Weblinks tun?

Der wahrscheinliche Verbraucher dieser API wäre unser Renderer, der die URL in einem Tooltip rendert

@mofux Ich dachte eher an das Such-Addon. Der Einbettungsmodus bietet die Benutzeroberfläche in jedem gewünschten Stil. Wir stellen nur die Rückrufe bereit, um dies zu tun. Guter Punkt, dass Sie damit noch nichts anfangen können. Ich vermute, mit der vorhandenen Link-API zu verschmelzen und eine Einstellung ITerminalOptions.enableAnsiHyperlinks für die Anmeldung zu haben und das Warum zu erläutern.

Ich vermute, mit der vorhandenen Link-API zu verschmelzen und eine Einstellung ITerminalOptions.enableAnsiHyperlinks für die Anmeldung zu haben und das Warum zu erläutern.

Wie wäre die Geschichte für Einbetter, um diese Funktion zu unterstützen? Das Öffnen des (unsichtbaren) Links beim Klicken auf den verknüpften Text ist möglicherweise gefährlich - insbesondere, wenn die verknüpfte URL nirgendwo angezeigt wird 🤔

Obwohl es in der Tat nett ist, das Ziel im Voraus zu zeigen, glaube ich nicht, dass es ein Problem gibt, "unbekannte" URLs zu öffnen. Die Sicherheitsaspekte wurden in den Kommentaren unter den Spezifikationen erörtert. Browser öffnen ständig "unbekannte" URLs, z. B. wenn ein JS-Code das Ziel kurz vor dem Öffnen ändert, um dem Benutzer häufig eine "nette" URL anzuzeigen, diese jedoch tatsächlich über einen Redirector zu öffnen.

Apropos ... etwas, das mir bisher noch nicht eingefallen ist ...

Wenn xterm.js in einem tatsächlichen Browser ausgeführt wird und der Link in einem neuen Tab dieses Browsers geöffnet wird: Ich denke, die URL von xterm.js über das Referer-Feld zu verlieren, ist ein Grund zur Sorge. Ich bin mir nicht sicher über die aktuelle Unterstützung für rel = "noreferrer", aber es scheint etwas zu sein, das verwendet werden sollte.

Siehe diese verwandte Diskussion des Schwebetextes . Bei diesem Problem geht es darum, Abschnitte der Ausgabe mit "Tool-Tops" und anderen Mouseover-Popups zu versehen. Dies ist nicht dasselbe wie das Anzeigen der URL, wenn Sie den Mauszeiger über einen Link bewegen. Beide möchten jedoch möglicherweise denselben Mechanismus verwenden, um den tatsächlichen Schwebetext anzuzeigen. Beide würden wahrscheinlich ein MouseZoneManager .

Haben wir XSS-Experten? Vielleicht brauchen wir ein Audit, lol.

Für mein begrenztes Wissen über die Browsersicherheit sind Daten, die die Grenze zwischen Terminal und Browser überschreiten, der Hauptangriffsvektor bei xterm.js:

• XSS vom Browser (JS) ins Terminal (Daten)
  Das ist bereits möglich und liegt in der Verantwortung des Integrators (xterm.js kann dies auf keinen Fall kontrollieren). Faustregel: Importieren Sie niemals Skripte von einer nicht vertrauenswürdigen Quelle auf der Terminalseite oder dem pty-Websocket. Dadurch geht das System verloren, auf dem sich die pty befindet. Lassen Sie nicht zu, dass ungefilterter Benutzerinhalt in die Seite und dergleichen eingefügt wird - im Grunde genommen sind alle typischen XSS-Dinge oder die Pty verloren.
• XSS vom Terminal (Daten) in den Browser (JS)
  Dies ist eine neue Qualität, die wir möglicherweise mit URLs eingeben, wenn wir nicht sicherstellen, dass die Terminaldaten niemals den JS-Kontext der Einbettungsseite (also das Terminalobjekt selbst) erreichen. Wenn dies möglich ist (nehmen wir an, dass dies für eine Sekunde der Fall ist), kann ein Angreifer Zugriff auf die Browserseite erhalten und somit einen Angriff auf Terminal (Daten) - Browser (JS) - Terminal (Daten) ausführen. Nehmen wir weiter an, dass xterm.js häufig in Cloud-Orchestrierungs-Serviceportalen ausgeführt wird und der Administrator Terminalsitzungen für verschiedene Computer verwendet. Outch. Sobald der Angreifer Zugriff auf die eingebettete Browserseite erhält, sind alle Cloud-Dienste, auf die der Administrator Zugriff hat, in Gefahr.

Die Frage ist: Gibt es Möglichkeiten, die Grenze zwischen Terminal (Daten) und Browser (JS) mit URLs zu überschreiten? Auch hier hilft mein begrenztes Wissen über die Browsersicherheit nicht viel. Das einzige Szenario, an das ich denken kann, sind Lesezeichen, die sich selbst in das JS der Seite einfügen. Ich habe keine Ahnung, ob wir dies vermeiden können, indem wir immer nur Inhalte in einem neuen Fenster / Tab öffnen (schätze, die Sitzung wird immer noch lecken, wenn nicht nur http? Was ist mit der Websocket-Verbindung?), Was mich denken lässt, dass wir die URL analysieren müssen und streife jeden "JS aussehenden Inhalt" ab, oh je ...

Bearbeiten: Beachten Sie, dass Websockets die meisten Sicherheitseinstellungen des Browsers verfehlen, sie haben nicht einmal eine zuverlässige Überprüfung des gleichen Ursprungs (gehen Sie mit Ajax Long Polling, wenn Sie diese lol benötigen). Hmm ...

Lesezeichen [...] entfernen alle "JS-aussehenden Inhalte"

Ich denke, es ist eine gute Idee, nur URLs auf die Whitelist zu setzen, die mit "http: //", "https: //", vielleicht "ftp: //" beginnen, und alles andere abzulehnen. Oder zumindest das fehlende Schema sowie "Javascript:" auf die schwarze Liste setzen.

In meinem Hyperlinks-Zweig habe ich einen Patch https://github.com/PerBothner/xterm.js/commit/b2647b90d301c52229d01720800865a0d39f436f für eine einstellbare Rückruffunktion auf einen Klick hinzugefügt. Dadurch können Sie ändern, wie der Link behandelt wird. Wenn DomTerm beispielsweise so konfiguriert ist, dass mein xterm.js-Zweig verwendet wird, nachdem ls --hyperlink=auto auf die meisten Dateinamen geklickt hat, wird die Datei in Emacs geöffnet, aber HTML-Dateien öffnen die Datei in Ihrem Standardbrowser, abhängig von Ihren Einstellungen .

(Seien Sie gewarnt, dass der Prototyp etwas schuppig ist. Ich weiß nicht, ob dies für den DomTerm-Prototyp spezifisch ist.)

Browser öffnen ständig "unbekannte" URLs, z. B. wenn ein JS-Code das Ziel kurz vor dem Öffnen ändert, um dem Benutzer häufig eine "nette" URL anzuzeigen, diese jedoch tatsächlich über einen Redirector zu öffnen.

@egmontkob In Browsern starten Sie im Allgemeinen an einem sicheren Ort wie einer Suchmaschine, die Ihnen sehr deutlich sagt, wann sich die Domain befindet. Für Terminals müssten Sie Programmen vertrauen (von denen einige möglicherweise Remote-Inhalte drucken), und selbst beim Cating einer Datei kann ein böswilliger Link angezeigt werden. Es scheint am besten zu sein, standardmäßig sicher zu sein und eine Einstellung zu haben, die nur die Risiken beschreibt und Abschwächungen bietet.

In meinem Hyperlinks-Zweig habe ich einen Patch PerBothner @ b2647b9 für eine einstellbare Rückruffunktion auf einen Klick hinzugefügt.

@PerBothner hier im webLinks-Addon gibt es bereits einen Handler: https://github.com/xtermjs/xterm.js/blob/509ce5fa3a698ee7847419117e9dd6b979b105bf/src/addons/webLinks/webLinkss.ts# Richten Sie 2 verschiedene Weblink-Handler ein.

(Entschuldigung für die verspätete Antwort - ich wurde von der Seite verfolgt.)

@ Tyriar schrieb "es gibt bereits einen Handler hier im webLinks Addon". Das Problem besteht darin, dass webLinksInit einen ILinkMatcher erstellt und den angegebenen Handler einem bestimmten ILinkMatcher zuordnet, der eine Reihe von regulären Ausdrücken enthält, mit denen er übereinstimmt. Aber wie spezifizieren wir den Link-Handler für Hyperlinks, die durch eine Escape-Sequenz erstellt wurden und daher nicht das Ergebnis einer Regex-Übereinstimmung sind? Dieser Handler muss "global" sein, da er keinem ILinkMatcher oder Regex zugeordnet ist. Das Festlegen dieses globalen / Standard-Handlers mithilfe von webLinksInit oder Terminal.registerLinkMatcher funktioniert nicht.

Mir scheint, wir brauchen ein linkHandler -Feld im Terminal - ein handler -Feld im ILinkMatcher ist nicht genug. Und wenn wir beispielsweise ein linkHandler -Feld in Terminal es sinnvoll, diesen Handler als Standard für registerLinkMatcher zu verwenden. Das macht mein Patch.

Wenn jemand dabei helfen möchte, muss Folgendes geschehen:

• Finden Sie heraus, wie Sie mit den Auswirkungen auf die Sicherheit umgehen können, wenn Links nicht als URLs angezeigt werden. Dies dient wahrscheinlich dazu, die Funktion zu aktivieren und einen Hook freizulegen, damit Verbraucher ein Popup anzeigen können
• Finden Sie eine nette API heraus, um einen Link zu öffnen. Wir haben bereits etwas sehr Ähnliches mit der Link Matcher-API. Kann dies verallgemeinert werden?
• Fügen Sie die Logik zum Parser hinzu und speichern Sie die Links irgendwo, vielleicht als IMarker s?

Mein Hyperlinks-Zweig https://github.com/PerBothner/xterm.js/tree/hyperlinks kann ein Ausgangspunkt sein. (Obwohl es ein bisschen alt ist, funktioniert es möglicherweise nicht mehr.)

Wie ist der Status der oben genannten Niederlassung? Arbeitet jemand daran?
@ Tyriar hat die erforderlichen Schritte gut aufgelistet. Sind einige dieser Schritte ausgeführt?

@ Jma353 Ich glaube nicht, dass irgendjemand aktiv daran arbeitet, also

@ Tyriar Ich habe die Spezifikation nicht in allen Details gelesen, aber es scheint, dass die Implementierung einige Parser-Handler-Jonglage beinhalten würde, insb. so etwas wie eine vorübergehende InputHandler.print Überlastung. Etwas seltsam, dass es so gemacht ist (es zieht den Terminalstatus etwas in den Parser, eine Tatsache, die bisher keine andere Escape-Sequenz tut), aber es sollte machbar sein, indem der Druckhandler dazwischen ausgetauscht wird.

@ Jerch Ja, es würde einige Parser-Änderungen benötigen. Das Ändern der Größe umschlossener Links ist ein Fall, bei dem wir sicherstellen müssen, dass auch funktioniert.

VS Code unterstützt jetzt das Anzeigen detaillierter Hovers für Links. Wenn Sie dies also anschließen, wird das Problem gelöst:

Es ist eine Schande, dass es ein bisschen komisch ist, da unsere Parser-Hooks es nicht abdecken. In diesem Fall könnte dies vollständig als Addon mithilfe von Parser-Hooks, Markern und den Link-Provider-APIs erfolgen.

@Tyriar Auch mit # 2751 kann der erweiterte attr-Speicher verwendet werden, um URL-Inhalte zu den Pufferzellen zu kommentieren.

Es ist eine Schande, dass es ein bisschen komisch ist, da unsere Parser-Hooks es nicht abdecken. In diesem Fall könnte dies vollständig als Addon mithilfe von Parser-Hooks, Markern und den Link-Provider-APIs erfolgen.

Ja, das ist ein Problem und imho kann auf Addon-Ebene nicht gelöst werden, selbst wenn wir einen Print-Handler-Hook freigeben würden. Ich denke, dies muss direkt in die Codebasis und einige außergewöhnliche Bedingungen gehen (wie jede nicht druckbare Aktion, bevor der Finalizer bestätigt wird, sollte die URL-Markierung von Zellen und dergleichen aufheben).