È più sicuro programmare un sistema client-server in una lingua diversa dall'inglese?

Tecnicamente leggermente, sì. Ma:

• Sarebbe sicurezza per oscurità , che è una cattiva idea
• Non aumenta la fiducia nel tuo prodotto
• Sarebbe molto facile capire cosa fa cosa, ci vorrebbe solo un po 'di tempo
• Google Translate, puoi semplicemente usare nomi senza senso, non sarebbe ancora di grande aiuto
• renderebbe la manutenzione più difficile
• renderebbe i controlli molto difficili, poiché i revisori potrebbero non capire la lingua

Tutto sommato, probabilmente non ne vale la pena.

Non sarebbe sensibilmente più sicuro. I tecnici inversi sono spesso costretti a lavorare con sistemi che non hanno qualsiasi nome originale intatto (il software di produzione spesso rimuove i nomi di simboli), quindi si abituano a gestire nomi generati da un computer. Un esempio , preso da Wikipedia, di uno snippet del tipo di codice C decompilato che viene spesso visto:

struct T1 *ebx;
struct T1 {
    int v0004;
    int v0008;
    int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;

Le persone che sono abituate a lavorare con questo tipo di rappresentazione non sono ingannate dall'uso di variabili e tali da dare nomi irrilevanti. Questo non è specifico per il codice compilato e l'uso di C è solo un esempio. Gli ingegneri inversi in generale sono abituati a comprendere codice non intuitivo. Non importa se stai usando JavaScript, o Java, o C. Non importa nemmeno se stiano analizzando nient'altro che la comunicazione con l'API stessa. Gli ingegneri inversi non saranno ingannati dall'uso di nomi di variabili o funzioni casuali o irrilevanti.

Non proprio: tutte le funzioni integrate saranno ancora in inglese, quindi non ci vorrà molto sforzo per capire cosa rappresenteranno le tue variabili. Potrebbe rallentare leggermente qualcuno, ma dato che le persone riescono ancora a decodificare il codice con variabili a singolo carattere dappertutto, o che è stato eseguito attraverso gli offuscatori, scambiare il linguaggio usato per variabili e funzioni significa semplicemente fare una ricerca-sostituzione una volta che hai capito a cosa serve una delle tue variabili, quindi ripetendo finché non hai una comprensione sufficiente.

Questa è sicurezza attraverso l'oscurità e ritarderà un attaccante dedicato per cinque minuti.

Se vuoi confondere un attaccante, nominare le cose come opposte o qualcosa di non correlato avrebbe lo stesso effetto. Quindi la tua funzione "crea utente" potrebbe essere chiamata "BakeCake". Ora puoi rispondere a te stesso della sicurezza che ti dà. In realtà, questo sarebbe più sicuro, in quanto non può essere sconfitto semplicemente usando un dizionario.

Sì, all'inizio potrebbe confondere, ma uno sguardo al sistema in funzione e tutto diventa immediatamente chiaro.

Il tuo sistema DEVE essere protetto da solo . Se si basa sul javascript sul lato utente che passa un parametro con il valore "open sesame", lo stai facendo male.

Dovresti sviluppare il programma nella lingua che è più conveniente per te (ad esempio in base alla competenza del tuo coder, alla coerenza con la tua base di codice, o anche con i termini che stai usando).

Altre risposte hanno già indicato come non fornisce realmente sicurezza. Se vuoi fare un programma sicuro, piuttosto che preoccuparti dei potenziali hacker che leggono facilmente il tuo codice e apprendono un buco segreto, probabilmente dovresti preoccuparti di renderlo leggibile alle persone che lo controllano .

Se esiste un parametro di funzione chiamato nonce, e un commento che dice come stiamo garantendo che sia univoco tra le richieste, eppure non è inviato sulla richiesta, puoi essere sicuro che si tratta di un errore. In realtà, avere quel codice facilmente leggibile diminuirà le possibilità che quel parametro venga rilasciato / svuotato (dopo tutto, tutto ha funzionato senza di esso ...), o se ciò accade davvero, rendi più semplice che un altro dei tuoi sviluppatori noti il problema.

(Anche terze parti potrebbero suggerirti qualcosa ... Probabilmente, ci saranno più persone che lo guarderanno casualmente rispetto a quelle che stanno cercando di romperlo. Un attaccante casuale molto probabilmente inizierà lanciando uno strumento automatico e sperando che trova qualsiasi cosa.)

TL; DR: produce codice leggibile. Per le persone che dovrebbero occuparsene. In caso di dubbi, dovresti preferire quello che la maggior parte delle persone conosce.

Potrebbe persino peggiorare le cose rendendo il sistema più difficile da mantenere.

Fai un esempio estremo ispirato alla storia e comunica tra front e back end in Navajo . Quando (non se) è necessario applicare una patch al codice necessario per:

• lavorare con quello che per te è una sciocchezza (con la possibilità in più di bug / errori di battitura e più tempo per lavorare su un codice non intuitivo), o
• assumere / mantenere i programmatori fluenti in Navajo (una combinazione di abilità rare e potenzialmente costosa, forse impossibile trovare un appaltatore)

Vorrei anche notare che nella maggior parte dei casi per javascript sul lato client, lo script come sviluppato (con nomi di variabili significativi ecc.) sarebbe "minimizzato" al fine di aumentare le prestazioni sul client (dimensione del file più piccola da scaricare).

Come parte di questo, la maggior parte dei nomi di variabili viene ridotta a singoli caratteri e viene eliminato il maggior spazio possibile. Questo diventa quasi illeggibile come qualsiasi altra cosa tu possa scrivere.

Vorrei anche notare che chrome (ad esempio) ha metodi che prendono un file 'less human readable' come questo e 'pretty print', rendendo molto più facile capire cosa sta succedendo.

In breve, il linguaggio umano che usi per scrivere il tuo codice client non fa una grande differenza.

Se si crede ai mass media, allora la maggior parte degli hacker sono russi, cinesi, nordcoreani, quindi sono già che operano sotto l'handicap di dover hackerare i sistemi occidentali in un lingua non nativa. Quindi, a meno che tu non scelga qualcosa di incredibilmente oscuro, come nel film Windtalkers non farà alcuna differenza per loro. Ma lo sforzo extra per te significa meno tempo per te per trovare e correggere bug, quindi semmai questa strategia renderebbe la tua sicurezza più debole .

Diverse risposte hanno (giustamente) sottolineato che si tratta di "sicurezza attraverso l'oscurità", che in realtà non è una forma di sicurezza. È più sicuro presumere che l'autore dell'attacco abbia un codice sorgente completamente annotato seduto di fronte a loro mentre sta attaccando attivamente.

Il software è "sicuro" quando la conoscenza di tutto ciò che può essere conosciuto prima di una richiesta / transazione / sessione è di dominio pubblico E questo non ha alcun impatto sulla sicurezza effettiva del prodotto.

Il codice sorgente deve essere considerato di dominio pubblico, se non altro perché i dipendenti insoddisfatti non vengono ritirati e sparati quando vengono interrotti. Oppure, come spesso si dice, "l'unico modo in cui due persone mantengono un segreto è se uno di loro è morto." Quindi qualsiasi "conoscenza speciale" che viene nascosta dall'offuscamento di qualsiasi tipo deve essere considerata come "conoscenza generale" "Non appena viene prodotto.

La sicurezza, nella sua essenza, non è altro che "dire quello che fai e fare ciò che dici". Analisi della sicurezza: l'audit del codice e schemi di valutazione formale, come quelli condotti secondo i Common Criteria, richiede che i meccanismi per eseguire un'azione è ben documentata e tutte le transizioni da uno stato sicuro ad un altro stato sicuro sono possibili solo quando tutti i requisiti sono soddisfatti. Un rischio con l'offuscamento di tutti i tipi è che questi requisiti sono oscurati da una codifica intelligente: vedere l'esempio di "create_user ()" non riuscendo perché è "segretamente" l'utente "cancella utente" o "rinomina utente" o qualcos'altro. Per un esempio del mondo reale di quanto sia difficile la rinomina nel cervello, ci sono test on-line in cui è necessario leggere il nome di un colore che viene stampato sullo schermo in un colore diverso. Ad esempio, la parola "ROSSO" scritta in un carattere blu provocherà un certo numero di persone che dicono "BLU" invece di "ROSSO".

Potrebbe essere irrilevante. Considera lo scenario in cui stai codificando (ad es.) In italiano invece che in inglese, ma la maggior parte dei tuoi clienti si trova in Italia, gli hacker che parlano naturalmente in Italia hanno una motivazione / un profitto superiore ad attaccarti.

In questo scenario, la codifica in un'altra lingua non ha alcun effetto o può anche rendere più facile l'hacking.