Ein interessanter (beängstigender) Trick eines *nahezu* unerkennbaren Exploits. Wolfgang Ettlinger
Was wäre, wenn eine Hintertür *buchstäblich* nicht *gesehen* werden könnte und somit selbst vor *gründlichen* Code-Reviews unentdeckt bliebe?
Ich poste den Screenshot des Exploits aus dem Beitrag mit dem tatsächlichen Exploit, der eingekreist ist
Wenn Sie wirklich sehr genau hingeschaut hätten, hätten Sie das wahrscheinlich gesehen, aber ich kann sehen, wie es leicht zu übersehen ist, da es alle Linting-Probleme vermeiden würde und die Syntaxhervorhebung überhaupt nicht beeinträchtigt. Dann werden die Befehle, so wie dieser Code geschrieben ist, ausgeführt
Jedes Element im Array, die fest kodierten Befehle sowie der vom Benutzer bereitgestellte Parameter, wird dann an die
exec-Funktion übergeben. Diese Funktion führt Betriebssystembefehle aus.
Sie halten es für änderungswürdig
Das Cambridge-Team schlägt die Einschränkung von Bidi-Unicode-Zeichen vor. Wie wir gezeigt haben, können Homoglyphen-Angriffe und unsichtbare Zeichen ebenfalls eine Bedrohung darstellen.
Gibt es also eine ESLint-Einstellung, um Bidi-Unicode-Zeichen zu beschränken oder sie in Entwicklungsworkflows zu implementieren?
Die ESLint-Regeln comma-spacing und comma-dangle fangen diesen Exploit ab. Ich habe es gerade in VS Code bestätigt. Sowohl die AirBnB- als auch die Google-Styleguides schreiben diese Regeln vor. Nur ein weiterer Grund, warum Linting wichtig ist.
Ich finde, dass Lint-Regeln ein Standardbestandteil jedes Projekts sein sollten...
Für diejenigen, die Zeichen immer noch manuell linten (so wie ich), identifiziert der folgende Regex zufällig den Exploit. Im Wesentlichen findet er Nicht-Leerzeichen, die außerhalb von ASCII liegen, sowie ein paar heimtückische Leerzeichen.
[\x0B\xA0]|[^\s\x20-\x7E]So lustig, dass VS Code 1.63.0 genau diesen Codeblock behoben hat
Ich war so aufgeregt, dass ich diesen Beitrag gar nicht in den Release Notes verlinkt sah. Ups.
Einfach zu verhindern
1) Kein nachgestelltes Komma in den Lint-Regeln setzen. 2) Jede Eingabe ablehnen, die nicht die erwartete Form hat
Damit Lint-Regeln diesen Exploit abfangen können, müssten Sie nachgestellte Kommas erfordern und nicht verbieten. Die Funktionsweise des Exploits besteht darin, dass er visuell so aussieht, als ob er nachgestellte Kommas hätte, obwohl dies tatsächlich nicht der Fall ist.
Mein eslint trimmt meinen nachgestellten Leerraum beim Speichern. Die Array-Zeile wäre also offensichtlich aufmerksamkeitsbedürftig. In einer Code-Überprüfung würde ich das erste nachgestellte Komma zurücksenden.
Einfache Korrektur bei der Code-Überprüfung (auch wenn Linter Leerzeichen schützen), in jedem Editor einfach Leerzeichen anzeigen. Mit Open Source kann man nicht einfach einen PR akzeptieren, indem man Code nur im Browser betrachtet.
Sie sollten nur 2 Leerzeichen zulassen: Leerzeichen & Zeilenumbruch. Es ist also einfach, sie visuell zu überprüfen.
Das ist ein sehr englischzentrierter Vorschlag. Während Programmierer, die andere Sprachen verwenden, normalerweise Variablen- und Funktionsnamen in ASCII verwenden, sollten IDEs und Code-Editoren niemals Nicht-ASCII-Zeichen blockieren. Es könnte Homoglyphen und unsichtbare Zeichen blockieren, aber das Verbieten von nicht-englischen Zeichen kann in nicht-englischen Sprachen viele Probleme verursachen