Executando verificação de segurança...
1

Framework de segurança para códigos, python e typescript. (MSF) Master Security Framework.

Master Security Framework: Análise Técnica Completa do meu Framework de Segurança Multi-Camada para Aplicações Modernas

MSF

Resumo

O Master Security Framework (MSF) é um framework de segurança abrangente, multi-linguagem e multi-camada projetado para proteger aplicações modernas em todos os níveis da pilha tecnológica. Implementado em Python e TypeScript, o MSF oferece mais de 350 funções distribuídas em 28 módulos, cobrindo desde autenticação e criptografia até detecção de ataques web, análise de rede, segurança cloud, proteção de inteligência artificial, honeypots adaptativos, defesa ativa e conformidade enterprise. Este artigo apresenta uma análise técnica detalhada de cada módulo, função, padrão de design e mecanismo de segurança implementado no framework.


1. Introdução

1.1. O Problema

Aplicações modernas enfrentam um espectro de ameaças cada vez mais sofisticado. Um único sistema pode ser alvo de ataques em múltiplas camadas simultaneamente: injeção de prompts em modelos de linguagem, exploração de vulnerabilidades web (XSS, SQLi, SSRF), escaneamento de portas, ataques DDoS, misconfigurações cloud, containers comprometidos, dependências vulneráveis na cadeia de suprimentos de software, e violações de conformidade regulatória.

A abordagem tradicional de segurança -- resolver cada problema com ferramentas isoladas -- cria silos de defesa que deixam lacunas entre as camadas. O MSF foi projetado para resolver esse problema oferecendo uma plataforma unificada de segurança que opera em todas as camadas da aplicação.

1.2. O que é o Master Security Framework

O MSF é um framework de segurança open-source implementado em duas linguagens: Python e TypeScript. Cada módulo existe em ambas as linguagens com a mesma semântica, permitindo que equipes poliglotas utilizem o mesmo conjunto de capacidades de segurança independentemente da stack tecnológica.

O framework é estruturado em torno de quatro pilares:

  1. Prevenção: Validação de entrada, sanitização, criptografia, hardening de configuração
  2. Detecção: Análise de padrões de ataque, anomalias estatísticas, assinaturas de malware, comportamento suspeito
  3. Resposta: Alertas autônomos, quarentena, contenção, self-healing
  4. Conformidade: Verificação automática de LGPD, GDPR, HIPAA, PCI-DSS

1.3. Métricas do Projeto

  • 243 testes automatizados passando (77 Python + 166 TypeScript)
  • 14 módulos Python com mais de 180 funções
  • 14 módulos TypeScript com mais de 170 funções
  • Telemetria OpenTelemetry integrada em todas as funções
  • Logging estruturado (pino no TypeScript, loguru no Python)
  • Cache in-memory com invalidação automática
  • Policy Engine para regras de segurança configuráveis
  • Event Bus para comunicação assíncrona entre módulos

2. Arquitetura do Framework

2.1. Camada de Infraestrutura (Core)

A base do MSF é composta por seis componentes de infraestrutura que são compartilhados por todos os demais módulos:

Configuração Global: Um objeto de configuração centralizado que armazena parâmetros de segurança, thresholds, listas de permitidos/bloqueados, e chaves criptográficas. A configuração pode ser recarregada em tempo real a partir de variáveis de ambiente sem reiniciar a aplicação.

Motor de Políticas (Policy Engine): Um sistema de avaliação de regras que permite definir políticas de segurança como declarações estruturadas. O engine suporta operadores lógicos, condições compostas, e ações de enforcement (allow, deny, warn, log).

Barramento de Eventos (Event Bus): Um sistema de pub/sub assíncrono que permite que módulos publiquem eventos de segurança e outros módulos se inscrevam para reagir. O event bus inclui um histórico de eventos e uma dead letter queue para eventos que falharam no processamento.

Registrador de Métricas (Metrics Registry): Um sistema de métricas que suporta counters (para contagens cumulativas), gauges (para valores instantâneos), e histograms (para distribuições). Todas as funções de detecção públicam métricas automaticamente.

Gerenciador de Cache (Cache Manager): Um cache LRU (Least Recently Used) com TTL (Time-To-Live) configurável, usado para armazenar resultados de válidações caras, listas de IPs bloqueados, fingerprints de sessões, e tokens revogados.

Telemetria OpenTelemetry: Integração completa com o padrão OpenTelemetry, gerando spans de tracing distribuido para cada operação de segurança. Isso permite correlacionar eventos de segurança com traces de requisições em arquiteturas de microsserviços.

Logger Estruturado: Logging estruturado em formato JSON com pino (TypeScript) e loguru (Python), incluindo contexto automatico como trace ID, severity, módulo, e metadados de segurança.

Tratamento de Exceções: Uma hierarquia de exceções de segurança (SecurityError, ValidationError, AuthenticationError, EncryptionError) que permite tratamento granular de erros de segurança.

2.2. Camada de Proteção

Sobre a infraestrutura, o MSF organiza seus módulos de segurança em três camadas funcionais:

Camada de Entrada: Web, API, Auth -- protegem os pontos de entrada da aplicação
Camada de Infraestrutura: Network, Cloud, File -- protegem a infraestrutura subjacente
Camada Inteligente: AI, Monitoring, Defensive, Honeypot -- protegem com inteligência e adaptação


3. Modulo de Autenticação (Auth)

O módulo de autenticação é o mais extenso do framework, com 30 funções em Python e 7 em TypeScript. Ele cobre todo o ciclo de vida da autenticação: geração e validação de tokens, gerenciamento de sessões, detecção de ataques, e métodos avançados de verificação de identidade.

3.1. JWT (JSON Web Tokens)

O MSF implementa um sistema completo de JWT que vai além da simples geração e validação:

  • generate_jwt cria tokens com subject, claims customizadas, expiração configurável, e issuer. Suporta algoritmos HS256, HS384, HS512, RS256, ES256.
  • validate_jwt verifica assinatura, expiração, claims obrigatorias, e retorna o payload decodificado. O parâmetro verify_exp permite desabilitar a verificação de expiração para casos específicos.
  • revoke_jwt adiciona o JTI (JWT ID) do token a uma blacklist de revogação. Isso é essencial para logout antes da expiração natural do token.
  • rotate_jwt valida o token antigo e emite um novo com a mesma identidade, permitindo rotação silenciosa de tokens sem interromper a sessão do usuário.
  • validate_refresh_token valida refresh tokens com verificação de pertencimento ao usuário específico, prevenindo que um refresh token roubado seja usado por outro usuário.

3.2. Gerenciamento de Sessões

O sistema de sessões do MSF inclui proteção contra sequestro de sessão:

  • secure_session cria uma sessão vinculando user_id, IP, user agent, e device fingerprint. Isso permite detectar mudanças suspeitas no contexto da sessão.
  • validate_session verifica se o session_id pertence ao usuário e se o IP atual corresponde ao IP registrado na criação da sessão.
  • detect_session_hijack compara o IP e user agent atuais com os dados históricos da sessão. Se o IP mudou para uma sub-rede diferente ou o user agent mudou significativamente, a função retorna verdadeiro indicando possível sequestro.
  • detect_token_replay mantém um registro de tokens ja utilizados. Sé um token é apresentado mais de uma vez, a função detecta o replay attack.

3.3. Detecção de Ataques de Autenticação

O MSF detecta três tipos principaís de ataques contra sistemas de autenticação:

  • detect_credential_stuffing monitora tentativas de login de um único IP contra múltiplas contas de usuário. Se um IP tenta muitos usernamês diferentes em uma janela de tempo, é sinalizado como credential stuffing.
  • detect_bruteforce monitora tentativas de login contra uma única conta. Se o número de tentativas excede o threshold na janela de tempo, é sinalizado como brute force.
  • detect_impossível_travel calcula a distância entre duas localizações de login consecutivas e compara com o tempo decorrido. Se a velocidade necessária para viajar entre os pontos excede limites físicos razoáveis (ex: 900 km/h), a função detecta viagem impossível.
  • geo_velocity_check estende a detecção de impossível travel para múltiplas localizações, calculando a velocidade geográfica entre todos os pontos de login consecutivos.

3.4. Autenticação Adaptativa e Baseada em Risco

  • adaptive_auth ajusta os requisitos de autenticação baseado no score de risco do contexto. Um login de um dispositivo conhecido em uma localização familiar pode requerer apenas senha, enquanto um login de um dispositivo novo em um país diferente pode requerer MFA adicional.
  • behavioral_auth utiliza biometria comportamental (padrão de digitação, movimento do mouse, ritmo de navegação) para verificar a identidade do usuário comparando com a baseline comportamental registrada.
  • risk_based_auth calcula um score de risco composto a partir de múltiplos fatores: localização, dispositivo, horario, comportamento, reputação do IP, e retorna uma decisão de autenticação com nível de confiança.

3.5. TOTP e Backup Codes

  • generate_totp gera códigos Time-based One-Time Password seguindo o RFC 6238, com dígitos e período configuráveis.
  • validate_totp valida tokens TOTP com tolerância de drift de relógio (parâmetro drift), compensando dessincronização entre o servidor e o dispositivo do usuário.
  • verify_backup_code verifica e consome códigos de backup/recovery, removendo-os da lista de válidos após o uso para prevenir reutilização.

3.6. WebAuthn e Passkeys

  • passkey_auth valida autenticações FIDO2/WebAuthn verificando a assinatura criptográfica do autenticador, os dados do autenticador, e o client data JSON.
  • webauthn_verify realiza uma verificação completa de asserção WebAuthn, incluindo validação do origin, RP ID (Relying Party ID), e assinatura criptográfica contra a chave pública registrada.
  • phishing_resistant_auth verifica se um método de autenticação é resistente a phishing, requerendo FIDO2 level 2 ou superior com atéstação verificada.

3.7. Segurança de Senhas

  • password_entropy calcula a entropia Shannon de uma senha, medindo sua complexidade informacional em bits. Senhas com entropia abaixo de 40 bits são consideradas fracas.
  • detect_weak_password combina análise de entropia com verificação contra listas de senhas comuns (rockyou, top 10000, etc.).
  • password_breach_check verifica se o hash de uma senha aparece em um banco de dados de breaches conhecidas (Have I Been Pwned e similares).
  • secure_password_hash cria hashes de senha com salt criptográfico e key stretching (iterações), suportando algoritmos como PBKDF2, bcrypt, scrypt, e Argon2.
  • verify_password_hash compara uma senha contra um hash armazenado usando comparação segura em tempo constante.

3.8. Fingerprinting de Dispositivo e Browser

  • device_fingerprint gera um identificador único do dispositivo a partir de atributos como user agent, resolução de tela, timezone, idiomas, e plataforma.
  • browser_fingerprint utiliza técnicas avançadas de fingerprinting baseadas em características de rendering: hash do canvas 2D, hash do WebGL, hash do contexto de audio, e lista de fontes instaladas.
  • biometric_validation compara dados biometricos (impressão digital, reconhecimento facial, iris) contra um templaté armazenado com threshold de similaridade configurável.

4. Modulo de Criptografia (Crypto)

O módulo de criptografia implementa algoritmos modernos de criptografia simétrica, assimétrica, e pós-quântica, com foco em autenticação e integridade.

4.1. Criptografia Autenticada

  • encrypt_data utiliza authenticated encryption com associated data (AEAD), suportando AES-256-GCM e ChaCha20-Poly1305. O associated data (AAD) permite vincular metadados não criptografados ao ciphertext de forma autenticada.
  • decrypt_data realiza a descriptografia autenticada, verificando a tag de autenticação antes de retornar o plaintext. Se a tag não corresponde, a descriptografia falha, prevenindo ataques de padding oracle e ciphertext manipulation.
  • encrypt_file e decrypt_file estendem a criptografia autenticada para arquivos em disco, gerenciando nonce, salt, e metadata de forma segura.

4.2. Criptografia Hibrida

  • hybrid_encrypt combina criptografia assimétrica (para troca de chaves) com criptografia simétrica (para o payload). A chave simétrica é gerada aleatoriamente, usada para criptografar o payload, e depois criptografada com a chave pública do destinatário.
  • hybrid_decrypt reverte o processo: descriptografa a chave simétrica com a chave privada e depois descriptografa o payload.

4.3. Criptografia Pos-Quantica

O MSF implementa os algoritmos pós-quânticos padronizados pelo NIST:

  • pqc_encrypt e pqc_decrypt utilizam ML-KEM (antigo Kyber) para criptografia resistente a computadores quânticos.
  • kyber_key_exchange implementa o protocolo de troca de chaves Kyber para estábelecimento de chave compartilhada pós-quântica.
  • dilithium_sign utiliza ML-DSA (antigo Dilithium) para assinaturas digitais pós-quântica.
  • sphincs_sign utiliza SPHINCS+, um esquema de assinatura baseado em funções hash, como alternativa pós-quântica stateless.
  • falcon_sign utiliza Falcon, um esquema de assinatura baseado em reticulados (lattices) com assinaturas compactas.

4.4. HMAC e Verificação de Assinatura

  • generate_hmac produz um Hash-based Message Authentication Code usando HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, ou HMAC-SHA3-256.
  • verify_hmac compara o HMAC calculado com o HMAC esperado usando comparação em tempo constante.
  • verify_signature verifica assinaturas digitais (Ed25519, ECDSA, RSA-PSS) contra uma mensagem e chave pública.

4.5. Utilitarios Criptográficos

  • secure_random gera bytes criptográficamente seguros usando os.urandom() (Python) ou crypto.getRandomValues() (TypeScript).
  • secure_memory_erase sobrescreve regiões de memória contendo dados sensíveis com zeros, prevenindo que dados permaneecam na memória após o uso.
  • anti_timing_compare compara duas sequências de bytes em tempo constante, iterándo sobre todos os bytes independentemente de onde ocorre a primeira diferença, prevenindo timing attacks.

5. Modulo Web

O módulo Web é o mais extenso em termos de detecção de ataques, com 30 funções em Python e 35 em TypeScript. Ele cobre todas as categorias de vulnerabilidades web listadas no OWASP Top 10 e além.

5.1. Cross-Site Scripting (XSS)

  • detect_xss analisa input em busca de padrões de XSS incluindo: tags <script>, event handlers (onload, onclick, onerror), URIs javascript:, DOM XSS (innerHTML, document.write), e XSS via SVG/MathML. A função utiliza um conjunto de padrões regex e calcula um score de confiança baseado no número de padrões correspondentes. O severity_threshold permite ajustar a sensibilidade da detecção.
  • sanitize_html remove tags e atributos não permitidos de HTML, utilizando uma allowlist de tags seguras (<p>, <br>, <strong>, <em>, etc.) e atributos seguros (href, src, alt, title, etc.). Tags não permitidas são removidas completamente, e atributos perigosos como on* são filtrados.
  • sanitize_svg sanitiza SVG removendo elementos perigosos como <script>, <foreignObject>, <animate>, e atributos de evento.
  • sanitize_markdown sanitiza markdown removendo HTML perigoso embutido enquanto preserva a formatação markdown nativa.
  • sanitize_css remove propriedades CSS perigosas como expression(), url(javascript:), behavior, e -moz-binding.
  • sanitize_js remove padrões perigosos de JavaScript incluindo eval(), Function(), setTimeout/setInterval com string, document.write, document.cookie, manipulação de DOM insegura, e métodos de execução de código.

5.2. Injeção SQL e NoSQL

  • detect_sqli detecta padrões de SQL injection incluindo: UNION-based (UNION SELECT), blind (AND 1=1, OR '1'='1'), time-based (SLEEP(), WAITFOR DELAY), error-based, e stacked queries. A função também detecta técnicas de evasion como encoding hex, comentários (--, /* */), e concaténação de strings.
  • detect_nósqli detecta injeção em bancos NoSQL (principalmente MongoDB) identificando operadores perigosos em input: $gt, $gte, $lt, $lte, $ne, $in, $nin, $regex, $where, $exists.

5.3. Server-Side Request Forgery (SSRF)

  • detect_ssrf verifica URLs contra uma lista de domínios permitidos e IPs bloqueados. A função detecta técnicas de bypass SSRF incluindo: redirecionamentos para localhost, uso de DNS rebinding, URLs com encoding (%00, %0d%0a), e acesso a metadata endpoints de cloud (169.254.169.254, metadata.google.internal).

5.4. Remote Code Execution (RCE) e Command Injection

  • detect_rce identifica padrões de execução remota de código incluindo chamadas a eval(), exec(), system(), passthru(), popen(), backticks, e pipe operators.
  • detect_command_injection detecta injeção de comandos OS usando operadores de shell: ;, |, ||, &&, backticks, $(), e redirecionamentos (>, >>).

5.5. File Inclusion e Path Traversal

  • detect_lfi detecta Local File Inclusion identificando sequências de path traversal (../, ..\), encoded traversal (%2e%2e%2f), e protocolos perigosos (php://filter, php://input, data://, expect://).
  • detect_rfi detecta Remote File Inclusion quando URLs externas são passadas como parâmetros de include/require.
  • detect_path_traversal verifica se um path resolve dentro de um base_path permitido, detectando traversal absoluto e relativo.

5.6. Templaté Injection

  • detect_template_injection detecta Server-Side Templaté Injection (SSTI) para engines Jinja2 ({{ 7*7 }}, {% for %}), EJS (<%= %>), Handlebars ({{#each}}), Pug, Twig, Mustache, e um modo genérico que detecta sintaxe de template comum.

5.7. Deserialization e Open Redirect

  • detect_deserialization_attack identifica insecure deserialization verificando classes permitidas e padrões de gadgets conhecidos (Java serialization, Python pickle, PHP unserialize, YAML deserialization).
  • detect_open_redirect verifica se uma URL de redirecionamento aponta para um host na lista de permitidos, prevenindo redirecionamentos para domínios maliciosos.

Leia mais...

Infelizmente o tabenews tem limite de caracteres, então deixo o artigo aqui para mais detalhes quem tiver interesse.
leia aqui

Carregando publicação patrocinada...
1

Se me permite lhe dar um conselho, siga a filosofia UNIX: "faça uma coisa, mas faça bem feito".

Eu não analisei muito, mas olhando por cima dá para ver que você basicamente tentou fazer uma ferramenta tudo-em-um. Só que não adianta fazer tudo, se tudo o que se faz for mal feito ou superficial. Daí não existe cenário onde é vantajoso usar sua ferramenta tudo-em-um, porque em todos os cenários ela perde para alguma ferramenta "concorrente" que faz muito melhor.

Na maioria dos casos onde projetos tentam ser tudo-em-um, eles fracassam justamente porque não dá para fazer tudo bem feito. O que você apresentou como um "problema":

A abordagem tradicional de segurança -- resolver cada problema com ferramentas isoladas -- cria silos de defesa que deixam lacunas entre as camadas.

Não é um problema de verdade. As coisas são feitas assim justamente porque existe uma ferramenta apropriada para cada situação. E o que você apresentou como "solução":

O MSF foi projetado para resolver esse problema oferecendo uma plataforma unificada de segurança que opera em todas as camadas da aplicação.

Isso sim é um problema de verdade. Porque você tá criando um ponto único de falha, que é justamente o que práticas modernas de segurança tentam evitar o máximo possível.