linguaggio di programmazione e minacce alla sicurezza

2

Lavoro principalmente su applicazioni aziendali basate su C / C ++. Ora pochi moduli stanno migrando a Java. Inoltre, in parallelo, è stato sottolineato come garantire che l'applicazione abbia il più alto punto di riferimento in materia di sicurezza.

Ora, la mia domanda è -

Supponiamo che la stessa applicazione sia sviluppata in tutte e 3 le lingue (C / C ++ / Java), quali sono le possibili aree delle minacce alla sicurezza specifiche della lingua? (Ad esempio const string verrà rivelato nel nome mangaling, che può essere una possibile minaccia per la sicurezza).

Qualsiasi link mi sarebbe di grande aiuto.

    
posta kumar_m_kiran 08.03.2013 - 09:57
fonte

3 risposte

8

Il maggior rischio in qualsiasi lingua è avere sviluppatori che non padroneggiano la suddetta lingua . Lo sviluppo sicuro richiede di pensare a tutti i "casi d'angolo" e non funziona a meno che lo sviluppatore non sappia cosa fa in tutti i punti. Un programmatore C competente che non conosce Java eseguirà un codice più sicuro in C che in Java (e viceversa).

Si può affermare che nelle lingue con "forti garanzie", le conseguenze di alcuni errori di programmazione sono meno terribili se osservate da un punto di vista della sicurezza. Ad esempio, un overflow del buffer in Java porta a un'eccezione e (di solito) alla chiusura del thread offendente, mentre in C può portare a un exploit hole fino a una shell remota per l'attacker. Questo mi rende un po 'meno preoccupato quando devo fidarmi degli sviluppatori con codice Java piuttosto che con codice C. Tuttavia, altri potenziali bug relativi alla sicurezza sono immutati tra codice Java e C (se il codice crea istruzioni SQL in un modo suscettibile all'iniezione SQL, quindi nulla in Java proteggerà contro questo - in una certa misura, la gestione semplice delle stringhe di caratteri in Java promuove bug di SQL injection).

L'offuscamento riguarda più il mantenimento della proprietà intellettuale che della sicurezza. Non impedirà agli hacker di decodificare il codice, ma aiuta ad ottenere la qualifica legale (quando si utilizza l'offuscamento, si rende chiaro, o almeno più chiaro, che non si desidera che il codice sia decodificato, rendendo così " sconfinare "più ovvio agli occhi di un giudice - ma i dettagli variano molto a seconda della giurisdizione). Il bytecode Java è più semplice da decodificare rispetto al C o C ++ compilato, ma sarebbe sbagliato affermare che compilare C o C ++ sia immune da reverse-engineering.

    
risposta data 08.03.2013 - 13:49
fonte
3

Ciò che ho fatto in passato quando faccio il porting di qualcosa tra le lingue o lavorando su qualcosa che dovrà lavorare a stretto contatto con una lingua diversa è di cercare problemi linguistici specifici sul sito web OWASP.

Speriamo che questo sia un po 'un punto di partenza.

Modifica

Dovrei aggiungere, ed è stato coperto in altre risposte, che parlare con un esperto nella lingua potrebbe essere la tua scommessa più sicura, ovviamente questa non è sempre un'opzione (almeno nel breve periodo)

    
risposta data 08.03.2013 - 10:24
fonte
0

Hai chiesto il link, e avrei messo la mia scommessa sulla guida OWASP per le pratiche di codifica sicura .

La cosa buona di questa guida è che ti forniscono AREE DI RISCHIO ad es. controllo degli accessi, gestione della memoria, gestione dei file e, a seconda dell'uso di una lingua e della sua sintassi, puoi farla quasi scrivere e orribilmente sbagliato se non si tiene a mente le istruzioni contenute in questo materiale di riferimento.

Devi programmare con sicurezza in mente principalmente la sua funzionalità.

Se sei interessato a fare l'analisi del codice sorgente ci sono molti strumenti gratuiti forniti da OWASP. Ecco la lista

    
risposta data 08.03.2013 - 11:18
fonte

Leggi altre domande sui tag