Segurança no nível de tipos: o futuro da geração segura de código com IA?

Introdução

Como o código é escrito (e gerado) cada vez mais rápido, um efeito colateral lamentável é que as vulnerabilidades de segurança também surgem mais rápido do que nunca. Pedir ao seu LLM que não inclua vulnerabilidades de segurança no código nem sempre funciona. Está cada vez mais claro que a forma como o software é criado hoje, manualmente ou com assistência, não é suficiente para escrever código seguro de maneira confiável, consistente e comprovável.

O crescimento da popularidade do Rust mostrou que é possível eliminar completamente classes inteiras de vulnerabilidades de forma prática e simples. Na prática, o Rust eliminou todas (ou quase todas) as vulnerabilidades de corrupção de memória em tempo de compilação. Então, por que deveríamos nos limitar a essa classe de vulnerabilidades?

Neste artigo, vou explicar como é possível escrever código de modo que vulnerabilidades de segurança em aplicações web sejam impossíveis de compilar (ou de passar pela verificação de tipos), e como bibliotecas seguras desde a concepção ou wrappers de biblioteca bem posicionados podem impedir completamente que classes inteiras de vulnerabilidades sejam introduzidas, manualmente ou por um LLM. Vou mostrar padrões de código em Python e Rust que podem ser usados para eliminar classes de vulnerabilidades.

Por que usar tipos?

Quando usados corretamente, os sistemas de tipos podem ser ferramentas incrivelmente poderosas. Eles permitem codificar as invariantes de um sistema, ou seja, todas as regras, propriedades e relações de cada dado do seu programa. Em vez de deixar um comentário útil ou fazer verificações em tempo de execução (que talvez só sejam acionadas quando seu primeiro cliente tentar fazer algo importante), você pode garantir que cada chamada da função add passe apenas dois valores do tipo int, em todos os casos e em toda a base de código.

Pela minha experiência, o código que escrevo com tipos extremamente rigorosos tem bem menos bugs em tempo de execução do que o código que escrevo sem eles, pois sou obrigado a raciocinar sobre cada parâmetro, cada dado e cada entrada. Quando codifico tudo isso adequadamente, cometo bem menos erros, e meu código passa a ter apenas bugs de lógica de negócio, em vez de problemas como “ops, passei uma string para uma função que soma inteiros”.

Muitas vulnerabilidades de segurança são apenas um tipo específico de bug. Se você considerar verdadeira a afirmação que fiz acima, então muitos desses bugs podem ser resolvidos com um sistema de tipos suficientemente flexível.

Tipos confiáveis

Este artigo foi inspirado, em parte, pela API web Trusted Types. Essa API mitiga, na prática, a maioria das formas de XSS no DOM, garantindo que os pontos de entrada de injeção de XSS aceitem apenas valores conhecidos como seguros, como aqueles sanitizados por um sanitizador de XSS apropriado. Também é possível restringir ainda mais essa API com CSP para exigir o uso da API Trusted Types, gerando um TypeError caso ela não seja usada.

Um mecanismo semelhante é usado pelo kernel do Linux com a macro __user, que garante que ponteiros provenientes do espaço do usuário sejam tratados adequadamente.

Nas próximas seções, vamos explorar como generalizar essa técnica e aplicá-la a classes arbitrárias de vulnerabilidades de segurança.

Como resolver IDOR

A Referência Direta Insegura a Objetos (IDOR) é uma vulnerabilidade grave que decorre da falta de verificações de autenticação e/ou autorização ao executar ações de API. Um exemplo clássico é um endpoint de API que recebe como parâmetro um ID de usuário incremental e retorna dados desse usuário. Porém, ao alterar o valor do ID, ele retorna dados de outro usuário, sem as verificações de autorização adequadas.

Estatisticamente, é provável que você, leitor, use Python. Por isso, vamos começar explorando essa vulnerabilidade e como resolvê-la em Python usando apenas dicas de tipo.

Em Python

Vamos começar com um exemplo vulnerável:

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"]}

Esta é uma chamada de API bem comum: você informa um ID de usuário inteiro, consulta o banco de dados e retorna o resultado na resposta. Mas, opa! Esquecemos de adicionar verificações de autenticação ou autorização; qualquer usuário pode consultar o saldo de qualquer outra pessoa (desde que tenha o ID), um caso clássico de IDOR. Recebemos o relatório da vulnerabilidade, pagamos a recompensa ao pesquisador e atualizamos a função da seguinte forma:

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    ...

Perfeito, os dados do usuário estão seguros. Mas é muito fácil cometer esse erro. Esquecer uma verificação de autenticação em um único endpoint de API pode ter impactos significativos. Agora, vamos analisar o mesmo endpoint, mas usando o sistema de tipos para garantir que essa vulnerabilidade não volte a acontecer:

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"]}

Há bem mais código aqui, mas, no contexto geral, ele acabaria sendo incorporado ao seu código de autenticação e autorização de qualquer forma.

A principal mudança neste novo código é que nunca usamos tipos básicos (como o ID de usuário do tipo int nos exemplos anteriores). Os dados de entrada são abstraídos em uma classe opaca, acessível apenas quando você comprova que já realizou as etapas de autenticação e autorização. Ao garantir que sua classe UncheckedUserID não possa fazer nada útil (como ser usada em uma expressão SQL), o verificador de tipos emitirá um erro de forma confiável se você esquecer de fazer a verificação de autenticação para extrair o valor “real” de user_id.

Como Python é uma linguagem tão dinâmica, tecnicamente seria possível contornar a verificação e acessar o valor interno sem fornecer um AuthenticationGuard válido. Mas esperamos que uma revisão de pull request identifique esse código indesejável. Outras linguagens, como Rust, oferecem garantias muito mais fortes: mesmo com código malfeito, não é possível acessar diretamente o valor interno da classe wrapper. É claro que o código continua em execução, então você pode tomar medidas extremas, como despejar a memória da instância. Mas, se o objetivo é apenas garantir que a autenticação seja consistente, por que faria isso?

Em Rust

Os especificadores de visibilidade do Rust oferecem um controle rigoroso sobre quais partes do código podem acessar o valor user_id encapsulado, tornando esse método ainda mais confiável para garantir as verificações de autenticação e autorização. No exemplo a seguir, usamos o Axum com um extrator para garantir que o valor de entrada seja desserializado corretamente na nossa classe wrapper de segurança.

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}

Viabilidade

É claro que mitigar vulnerabilidades de segurança dessa forma exige um comprometimento significativo, especialmente em projetos de software mais consolidados. Seria necessário criar uma infraestrutura de desenvolvimento para garantir que esses padrões sejam seguidos de forma consistente. As duas principais maneiras de fazer isso seriam com bibliotecas wrapper ou regras personalizadas de lint.

Considere, por exemplo, o caso do Python. Como organização, você poderia exigir o uso da biblioteca MyOrgFastAPI, um wrapper leve do FastAPI, e garantir que todos os endpoints de API usem tipos personalizados que implementem esses requisitos de segurança. Nenhum endpoint poderia receber um argumento str; teria que ser algum tipo de UncheckedString.

Outra opção, se você não quiser manter uma biblioteca wrapper personalizada, é implementar essas regras no linter. Embora isso não dê feedback ao desenvolvedor tão cedo, ainda pode oferecer a mesma proteção ao proibir tipos básicos.

Seja qual for o método escolhido, ele garantirá que cada caso seja tratado corretamente. Esse padrão de código pode ser estendido naturalmente para proteger contra vários tipos de vulnerabilidade:

• Um UncheckedString precisa ser sanitizado corretamente para gerar uma string simples que possa ser retornada ao usuário, mitigando XSS

• Um UncheckedString não pode ser concatenado a uma consulta SQL, mitigando vulnerabilidades clássicas de SQL

• Um UncheckedString não pode ser concatenado a uma string de comando, mitigando vulnerabilidades de injeção de comandos.

E a lista continua.

Esses padrões também se aplicam tanto a desenvolvedores quanto a agentes de IA. Pedir a um agente de IA que garanta a autenticação em todos os casos talvez não seja 100% confiável, mas exigir autenticação na etapa de compilação ou lint pode ser extremamente eficaz.

Conclusão

Implementar a segurança dessa forma, no nível de tipos, pode ser uma ferramenta incrivelmente poderosa tanto para desenvolvedores quanto para agentes de IA. Embora possa haver algum esforço inicial, especialmente em projetos de software existentes, os benefícios podem ser significativos: classes inteiras de vulnerabilidades podem ser eliminadas.

A forma de tratar os dados pode variar bastante de um projeto para outro, mas pensar nisso desde o início pode trazer grandes benefícios para a segurança do código.