Sicherheit auf Typebene: Die Zukunft der sicheren KI-Codegenerierung?

Einführung

Code wird schneller denn je geschrieben und generiert – leider entstehen dadurch auch Sicherheitslücken immer schneller. Ein LLM darum zu bitten, keine Sicherheitslücken einzubauen, funktioniert nicht immer. Es wird immer deutlicher, dass die heutige Art der Softwareentwicklung – manuell oder mit Unterstützung – nicht ausreicht, um zuverlässig, konsistent und nachweislich sicheren Code zu schreiben.

Der zunehmende Erfolg von Rust hat gezeigt, dass sich ganze Klassen von Schwachstellen auf praktikable und ergonomische Weise vollständig beseitigen lassen. Rust hat praktisch alle (die meisten) speicherbezogenen Korruptionsschwachstellen zur Compile-Zeit beseitigt. Warum sollten wir uns also auf diese Klasse von Schwachstellen beschränken?

In diesem Beitrag zeige ich, wie sich Code so schreiben lässt, dass Sicherheitslücken in Webanwendungen nicht kompilierbar sind (oder die Typprüfung nicht bestehen). Außerdem erläutere ich, wie sicherheitsorientierte Bibliotheken oder gezielt eingesetzte Bibliotheks-Wrapper ganze Klassen von Schwachstellen verhindern können – unabhängig davon, ob der Code von Menschen oder einem LLM geschrieben wird. Anhand von Codebeispielen in Python und Rust zeige ich Muster, mit denen sich Schwachstellenklassen beseitigen lassen.

Warum Typen?

Richtig eingesetzt, können Typsysteme unglaublich leistungsstarke Werkzeuge sein. Sie ermöglichen es, die Invarianten eines Systems festzuschreiben – also alle Regeln, Eigenschaften und Beziehungen sämtlicher Daten in Ihrem Programm. Anstatt einen hilfreichen Kommentar zu hinterlassen oder Laufzeitprüfungen durchzuführen (die womöglich erst greifen, wenn Ihr erster Kunde etwas Wichtiges tun möchte), können Sie sicherstellen, dass jeder Aufruf Ihrer add-Funktion ausnahmslos zwei int-Typen über die gesamte Codebasis hinweg übergibt.

Meiner Erfahrung nach enthält Code, den ich mit sehr strengen Typen schreibe, deutlich weniger Laufzeitfehler als Code ohne diese Typen. Denn ich muss jeden Parameter, alle Daten und jede Eingabe durchdenken. Wenn ich die Anforderungen passend im Code festschreibe, mache ich deutlich weniger Fehler. Dann enthält mein Code nur noch Fehler in der Geschäftslogik und keine Fälle wie „Hoppla, ich habe einer Funktion für die Addition von Ganzzahlen einen String übergeben“.

Viele Sicherheitslücken sind einfach eine bestimmte Art von Fehler. Wenn meine obige Aussage zutrifft, sollten sich viele dieser Fehler mit einem hinreichend flexiblen Typsystem beheben lassen.

Trusted Types

Dieser Beitrag ist unter anderem von der Trusted Types Web API inspiriert. Diese API verhindert die meisten Formen von DOM-XSS, indem sie sicherstellt, dass XSS-Injection-Sinks nur bekannte sichere Werte akzeptieren, beispielsweise Werte, die von einem geeigneten XSS-Sanitizer bereinigt wurden. Mit CSP lässt sich die API zusätzlich einschränken, sodass die Verwendung der Trusted Types API vorgeschrieben ist. Andernfalls wird ein TypeError ausgelöst.

Ein ähnlicher Mechanismus kommt im Linux-Kernel mit dem Makro __user zum Einsatz, das sicherstellt, dass Zeiger aus dem Userspace korrekt verarbeitet werden.

In den folgenden Abschnitten betrachten wir, wie sich diese Technik verallgemeinern lässt und wie Sie sie auf beliebige Klassen von Sicherheitslücken anwenden können.

IDOR beheben

Insecure Direct Object Reference (IDOR) ist eine hartnäckige Sicherheitslücke, die auf fehlende Authentifizierungs- und/oder Autorisierungsprüfungen bei API-Aktionen zurückgeht. Ein klassisches Beispiel ist ein API-Endpunkt, der eine fortlaufende Benutzer-ID entgegennimmt und die zugehörigen Benutzerdaten zurückgibt. Ändert man jedoch den Wert der Benutzer-ID, liefert er ohne entsprechende Autorisierungsprüfungen die Daten eines anderen Benutzers zurück.

Statistisch gesehen verwenden Sie als Leser wahrscheinlich Python. Deshalb untersuchen wir diese Schwachstelle zunächst und zeigen, wie sie sich in Python allein mit Typannotationen beheben lässt.

In Python

Wir beginnen mit einem anfälligen Beispiel:

1import sqlite3
2
3from fastapi import FastAPI, Depends
4
5app = FastAPI()
6
7DATABASE = "app.db"
8
9def get_db():
10    conn = sqlite3.connect(DATABASE)
11    conn.row_factory = sqlite3.Row
12    try:
13        yield conn
14    finally:
15        conn.close()
16
17@app.get("/balance/{user_id}")
18def get_balance(user_id: int, db: sqlite3.Connection = Depends(get_db)):
19    cursor = db.execute(f"SELECT balance FROM accounts WHERE user_id = {user_id}")
20    row = cursor.fetchone()
21    return {"uid": user_id, "balance": row["balance"]}

Das sieht nach einem ganz normalen API-Aufruf aus: Sie übergeben eine ganzzahlige Benutzer-ID, fragen die Datenbank ab und geben das Ergebnis als Antwort zurück. Aber hoppla! Wir haben keinerlei Authentifizierungs- oder Autorisierungsprüfungen eingebaut. Jeder Benutzer kann den Kontostand eines beliebigen anderen Benutzers abrufen, sofern er dessen ID kennt – ein klassischer IDOR-Fall. Wir erhalten den Schwachstellenbericht, zahlen der forschenden Person die Prämie und aktualisieren die Funktion wie folgt:

1@app.get("/balance/{user_id}")
2def get_balance(user_id: int, db: sqlite3.Connection = Depends(get_db)):
3    if not (check_authentication() and check_authorization()): return 403
4    ...

Perfekt, die Benutzerdaten sind sicher. Doch ein solcher Fehler passiert erschreckend leicht. Eine einzige vergessene Authentifizierungsprüfung an einem API-Endpunkt kann erhebliche Folgen haben. Betrachten wir nun denselben Endpunkt, diesmal mit einem Typsystem, das sicherstellt, dass diese Schwachstelle nicht erneut auftritt:

1import sqlite3
2
3from fastapi import FastAPI, Depends
4from typing import Never, NewType, Final
5from collections.abc import Generator
6from contextlib import contextmanager
7
8app = FastAPI()
9
10DATABASE = "app.db"
11
12def get_db():
13...
14
15UserID = NewType("UserID", int)
16
17class AuthenticationProvider:
18    def do_authn(self) -> "AuthenticationGuard":
19        # do something to check the auth
20        return AuthenticationGuard(guard=AuthenticationGuard._INSTANTIATION_TOKEN)  # pyright: ignore[reportPrivateUsage, reportArgumentType]
21
22class AuthenticationGuard:
23    _INSTANTIATION_TOKEN: Final = object()
24
25    def __init__(self, *, guard: Never):
26        # could also do some runtime checks to ensure caller
27        assert guard is self._INSTANTIATION_TOKEN
28
29class UncheckedUserID:
30    __value: UserID
31
32    def __init__(self, user_id: UserID):
33        self.__value = user_id
34
35    @contextmanager
36    def ensure_authn(self, guard: AuthenticationGuard) -> Generator[UserID, None, None]:
37        assert guard
38        yield self.__value
39
40
41@app.get("/balance/{user_id}")
42def get_balance(unauth_user_id: UncheckedUserID = Depends(UncheckedUserID), db: sqlite3.Connection = Depends(get_db)):
43    authguard = AuthenticationProvider().do_authn()
44    with unauth_user_id.ensure_authn(authguard) as user_id:
45        cursor = db.execute(f"SELECT balance FROM accounts WHERE user_id = {user_id}")
46        row = cursor.fetchone()
47        return {"uid": user_id, "balance": row["balance"]}

Der Code ist hier deutlich umfangreicher. Im Gesamtbild geht er jedoch ohnehin in Ihrem Authentifizierungs- und Autorisierungscode auf.

Die wichtigste Änderung im neuen Code: Wir reichen keine einfachen Typen mehr herum (wie zuvor die Benutzer-ID als int). Eingabedaten werden in einer opaken Klasse gekapselt und sind nur zugänglich, wenn Sie nachweisen, dass Authentifizierung und Autorisierung bereits durchgeführt wurden. Da Ihre Klasse UncheckedUserID nichts Nützliches tun kann (etwa in einem SQL-Ausdruck verwendet werden), gibt die Typprüfung zuverlässig einen Fehler aus, wenn Sie vergessen haben, die Authentifizierungsprüfung durchzuführen und den eigentlichen Wert user_id auszulesen.

Da Python dynamisch ist, könnten Sie die Prüfung technisch umgehen und ohne gültiges AuthenticationGuard auf den internen Wert zugreifen. Man kann jedoch hoffen, dass solcher unerwünschter Code bei einer PR-Prüfung auffällt. Andere Sprachen wie Rust bieten deutlich stärkere Garantien: Selbst mit unsauberem Code lässt sich nicht direkt auf den internen Wert der Wrapper-Klasse zugreifen. Natürlich wird der Code weiterhin ausgeführt, sodass extreme Maßnahmen wie das Auslesen des Speichers einer Instanz möglich sind. Wenn Sie aber lediglich sicherstellen möchten, dass Ihre Authentifizierung konsistent ist – warum sollten Sie das tun?

In Rust

Sichtbarkeitsangaben in Rust bieten eine strenge Kontrolle darüber, welcher Code auf den gekapselten user_id-Wert zugreifen kann. Damit lassen sich Authentifizierungs- und Autorisierungsprüfungen noch zuverlässiger sicherstellen. Im folgenden Beispiel verwenden wir Axum mit einem Extractor, der sicherstellt, dass der Eingabewert korrekt in unsere sichere Wrapper-Klasse deserialisiert wird.

1use axum::{response::IntoResponse, routing::get, Json, Router};
2
3mod unchecked_input {
4    use axum::extract::{FromRequestParts, Path};
5    #[derive(serde::Deserialize, serde::Serialize, Debug)]
6    pub struct UserID(u32);
7
8    #[derive(FromRequestParts)]
9    pub struct UncheckedUserID {
10        #[from_request(via(Path))]
11        value: UserID,
12    }
13
14    impl UncheckedUserID {
15        pub const fn ensure_authn(self, _: super::authentication::AuthenticationGuard) -> UserID {
16            self.value
17        }
18    }
19}
20
21mod authentication {
22    use std::marker::PhantomData;
23
24    pub struct AuthenticationGuard {
25        _internal: PhantomData<()>,
26    }
27
28    pub struct AuthenticationProvider {}
29    impl AuthenticationProvider {
30        pub const fn do_auth() -> Option<AuthenticationGuard> {
31            // do something to check the auth
32            Some(AuthenticationGuard {
33                _internal: PhantomData,
34            })
35        }
36    }
37}
38
39async fn get_balance(user_id: unchecked_input::UncheckedUserID) -> impl IntoResponse {
40    match authentication::AuthenticationProvider::do_auth() {
41        Some(guard) => {
42            let user_id = user_id.ensure_authn(guard);
43            // go and do some SQL
44            Json(serde_json::json!({"uid": user_id, "balance": 0.0}))
45        }
46        None => Json(serde_json::json!({"error": "auth failure"})),
47    }
48}
49
50#[tokio::main]
51async fn main() {
52    let app = Router::new().route("/balance/{user_id}", get(get_balance));
53
54    let listener = tokio::net::TcpListener::bind("127.0.0.1:8000")
55        .await
56        .unwrap();
57    axum::serve(listener, app).await.unwrap();
58}

Praxistauglichkeit

Diese Methode zur Behebung von Sicherheitslücken setzt natürlich eine erhebliche Unterstützung voraus, insbesondere bei etablierten Softwareprojekten. Es braucht eine Entwicklungsinfrastruktur, die sicherstellt, dass diese Muster konsequent eingehalten werden. Dafür kommen vor allem zwei Ansätze infrage: Wrapper-Bibliotheken oder benutzerdefinierte Linter-Regeln.

Nehmen wir als Beispiel den Python-Fall. Als Unternehmen könnten Sie die Bibliothek MyOrgFastAPI vorschreiben, einen schlanken Wrapper für FastAPI. Damit stellen Sie sicher, dass alle API-Endpunkte benutzerdefinierte Typen verwenden, die diese Sicherheitsanforderungen erfüllen. Kein Endpunkt darf ein Argument vom Typ str entgegennehmen; stattdessen muss es eine Form von UncheckedString sein.

Alternativ können Sie diese Regeln auf Linter-Ebene umsetzen, wenn Sie keine eigene Wrapper-Bibliothek pflegen möchten. Entwickler erhalten dadurch zwar nicht so früh Feedback, doch ein Verbot einfacher Typen bietet weiterhin dasselbe Sicherheitsnetz.

Ganz gleich, welchen Ansatz Sie wählen: So stellen Sie sicher, dass jeder einzelne Fall korrekt behandelt wird. Dieses Codemuster lässt sich ganz natürlich auf den Schutz vor allen möglichen Schwachstellen ausweiten:

• Ein UncheckedString muss ordnungsgemäß bereinigt werden, bevor er als einfacher String an den Benutzer zurückgegeben wird. So wird XSS verhindert.

• Ein UncheckedString kann nicht an eine SQL-Abfrage angehängt werden. So werden klassische SQL-Schwachstellen verhindert.

• Ein UncheckedString kann nicht an eine Befehlszeichenfolge angehängt werden. So werden Command-Injection-Schwachstellen verhindert.

Die Liste ließe sich fortsetzen.

Solche Muster eignen sich gleichermaßen für menschliche Entwickler und KI-Agenten. Einen KI-Agenten überall zur Authentifizierung aufzufordern, ist möglicherweise nicht hundertprozentig zuverlässig. Authentifizierung hingegen während der Kompilierung oder beim Linting durchzusetzen, kann äußerst wirkungsvoll sein.

Fazit

Sicherheit auf diese Weise auf Typ-Ebene umzusetzen, kann sowohl für menschliche Entwickler als auch für KI-Agenten ein äußerst wirkungsvolles Mittel sein. Zwar ist insbesondere bei bestehenden Softwareprojekten zunächst ein gewisser Mehraufwand nötig, doch der Nutzen kann erheblich sein: Ganze Klassen von Schwachstellen lassen sich vollständig beseitigen.

Wie Sie mit Ihren Daten umgehen, hängt stark vom jeweiligen Projekt ab. Wenn Sie sich jedoch frühzeitig damit befassen, zahlt sich das für sicheren Code aus.