Beim Lesen des Forge-Vertragss Quellcodes liefert eine direkte Suche nach `pub fn` eine scheinbar vollständige Liste der Einstiegspunkte. Ich habe diese Liste nicht einfach übernommen, sondern auch Trait-Implementierungen berücksichtigt und die gezielten Exporttests des Repositorys ausgeführt. Das Release-Ergebnis: 3 bestandene Tests, die eine einzelne Trait-Methode, mehrere Methoden und eine nicht im Manifest aufgeführte Methode abdecken.
Die Tests machen die Generierungsregeln deutlich. `pub fn` in einem gewöhnlichen impl wird als Exportkandidat behandelt, private Funktionen bleiben intern. Bei Trait-Implementierungen gibt es eine zusätzliche explizite Schranke: Eine Methode muss in `#[contract(expose=[...])]` aufgeführt sein. Eine im Trait definierte, aber nicht in expose aufgenommene Methode erscheint nicht automatisch nach außen. Und wenn das Manifest eine nicht vorhandene Methode aufführt, lässt die Generierungsphase das ebenfalls nicht stillschweigend durchgehen.
Das verändert den Ausgangspunkt der Schnittstellenprüfung: Dass eine Funktion im Quellcode „vorhanden“ ist, sagt noch nichts aus – entscheidend ist, was das Makro tatsächlich generiert. Wer nur nach pub sucht, übersieht Trait-Einstiegspunkte, die über expose freigegeben wurden; wer nur Traits durchsieht, zählt nicht exponierte Methoden fälschlich zur Angriffsfläche. Das Schema oder das Ergebnis der Makroexpansion kann beide Ansätze zusammenführen.
Ein erfolgreicher Export erledigt jedoch nicht die Autorisierung im Anwendungscode. Dass ein Aufruf von außen möglich ist, bedeutet nur, dass der Zugang besteht. Ob der Aufrufer den Zustand ändern, Vermögenswerte übertragen oder Verwaltungsaktionen auslösen darf, bestimmt weiterhin die Zugriffskontrolle des Vertrags selbst. Bei der Prüfung des Vertrags $DUSK kontrolliere ich die Exportoberfläche und die Autorisierung getrennt, damit Rust-Sichtbarkeit nicht an die Stelle einer Berechtigungsprüfung tritt.
Diese 3 Tests überprüfen nur die Generierungsregeln bei einem festgelegten Forge-Commit. Sie haben keine ABI eines Produktivvertrags eingelesen und auch nicht nachgewiesen, dass einem bestimmten öffentlichen Einstiegspunkt Schutz fehlt. Das Framework @Dusk bietet eine Methode, Einstiegspunkte zu beurteilen, aber kein Sicherheitsurteil über bereitgestellten Code.
Die tatsächliche Liste sollte man also nicht einfach aus dem Suchfeld des Quellcodes ableiten. Zuerst sollte das Makro zeigen, was nach außen gelangt ist; danach muss man im Vertrag prüfen, wer den Schlüssel erhalten hat. Werden diese beiden Schritte vermischt, werden sowohl interne Funktionen als auch externe Berechtigungen falsch eingeschätzt. #dusk
Die Tests machen die Generierungsregeln deutlich. `pub fn` in einem gewöhnlichen impl wird als Exportkandidat behandelt, private Funktionen bleiben intern. Bei Trait-Implementierungen gibt es eine zusätzliche explizite Schranke: Eine Methode muss in `#[contract(expose=[...])]` aufgeführt sein. Eine im Trait definierte, aber nicht in expose aufgenommene Methode erscheint nicht automatisch nach außen. Und wenn das Manifest eine nicht vorhandene Methode aufführt, lässt die Generierungsphase das ebenfalls nicht stillschweigend durchgehen.
Das verändert den Ausgangspunkt der Schnittstellenprüfung: Dass eine Funktion im Quellcode „vorhanden“ ist, sagt noch nichts aus – entscheidend ist, was das Makro tatsächlich generiert. Wer nur nach pub sucht, übersieht Trait-Einstiegspunkte, die über expose freigegeben wurden; wer nur Traits durchsieht, zählt nicht exponierte Methoden fälschlich zur Angriffsfläche. Das Schema oder das Ergebnis der Makroexpansion kann beide Ansätze zusammenführen.
Ein erfolgreicher Export erledigt jedoch nicht die Autorisierung im Anwendungscode. Dass ein Aufruf von außen möglich ist, bedeutet nur, dass der Zugang besteht. Ob der Aufrufer den Zustand ändern, Vermögenswerte übertragen oder Verwaltungsaktionen auslösen darf, bestimmt weiterhin die Zugriffskontrolle des Vertrags selbst. Bei der Prüfung des Vertrags $DUSK kontrolliere ich die Exportoberfläche und die Autorisierung getrennt, damit Rust-Sichtbarkeit nicht an die Stelle einer Berechtigungsprüfung tritt.
Diese 3 Tests überprüfen nur die Generierungsregeln bei einem festgelegten Forge-Commit. Sie haben keine ABI eines Produktivvertrags eingelesen und auch nicht nachgewiesen, dass einem bestimmten öffentlichen Einstiegspunkt Schutz fehlt. Das Framework @Dusk bietet eine Methode, Einstiegspunkte zu beurteilen, aber kein Sicherheitsurteil über bereitgestellten Code.
Die tatsächliche Liste sollte man also nicht einfach aus dem Suchfeld des Quellcodes ableiten. Zuerst sollte das Makro zeigen, was nach außen gelangt ist; danach muss man im Vertrag prüfen, wer den Schlüssel erhalten hat. Werden diese beiden Schritte vermischt, werden sowohl interne Funktionen als auch externe Berechtigungen falsch eingeschätzt. #dusk