Un altro programmatore ha usato le peggiori pratiche di programmazione

So che sembra strano dirlo, ma un collega programmatore al lavoro ha deliberatamente usato un paio di cattive pratiche di programmazione apposta! Spiegherò. Prima di tutto lasciami dire che è un ragazzo intelligente e per la maggior parte scrive codice intelligibile.

Gli è stato chiesto di implementare le licenze su un progetto di applicazione web scritto in Java. Dal momento che è Java, se uno lo volesse davvero, probabilmente si potrebbe hackerare i barattoli e leggere i nomi delle classi e dei metodi scritti all'interno. La sua soluzione a questo problema era letteralmente chiamare goffamente variabili e metodi nomi poco ovvi e inserirli in classi già congestionate piuttosto che generare nuove classi.

La sua giustificazione era che se un hacker volesse cambiare determinate classi al fine di aggirare i controlli delle licenze (e quindi ottenere una copia gratuita del prodotto), avrebbe avuto un momento molto più difficile se non fosse ovvio quali metodi svolgere questi compiti particolari. Solo dopo averlo fatto, l'ho affrontato, suggerendo che potremmo forse acquistare una sorta di biblioteca di offuscatori per farlo per noi, mantenendo al contempo buone pratiche di programmazione. Afferma di non aver avuto il tempo o le risorse per cercare quel tipo di soluzione.

..Che mi lascia ad un dilemma. Cerco una libreria di offuscatori in Java e riparo il suo vecchio codice (che potrebbe essere un po 'permaloso nel rimodellare il suo codice), o lo lascio così tanto, tanto che mi infastidisce senza fine?

La sicurezza attraverso l'offuscamento non è mai una buona sicurezza. Devono esserci modi migliori per proteggere la tua proprietà intellettuale. E questo è ciò che tu e il tuo collega dovreste sollevare come una preoccupazione comune con il vostro manager. Se il management decide quindi di non voler spendere tempo o denaro per migliorare la sicurezza, entrambi dovrete convivere con quella decisione (non è il vostro prodotto, è il prodotto dell'azienda) e meglio non spendere (spreco?) ancora tempo sull'argomento.

Originale: cosa dice il tuo capo? Scopri - fallo.

Mi è stato chiesto di elaborare quanto sopra:

Prima di tutto, penso che tu abbia più di un dilemma:

• Dovresti "correggere" il codice di un'altra persona?
• L'implementazione (di seguito A) delle altre persone è abbastanza grave da poter essere sostituita con qualcos'altro?
• Un offuscatore (di seguito B) sarà migliore per questo "incorporare le licenze nella nostra applicazione"?

Innanzitutto, visto un caso aziendale, il problema è risolto. A è in atto ed è - molto probabilmente - una soluzione "abbastanza buona" per il problema. La tua azienda potrebbe essere contenta di averlo appena protetto abbastanza da rendere necessario uno sforzo deliberato per romperlo.

Ciò significa che anche se non ti piace (e, fidati di me, vedrai molto peggio durante la tua carriera ) fa ciò che è necessario. Quindi, poiché il problema è risolto, non dovresti "semplicemente farlo", ma piuttosto convincere la persona incaricata di assegnare il tuo lavoro che a lungo termineil prezzo di questa implementazione sarà abbastanza alto da giustificare un rollback e la scelta di un offuscatore di azioni. Ciò richiederà un po 'di preparazione da parte tua, e nota anche che gli offuscatori hanno anche degli aspetti negativi che devi sapere (altre risposte lo coprono bene). Ad esempio, le tracce dello stack non sono immediatamente utilizzabili, ecc. Tutto dipende da quanto sia importante evitare la pirateria. Si noti che il più difficile da rompere è quelli che richiedono l'esecuzione di chiavi hardware ed è probabilmente più costoso di quanto piaceranno ai vostri clienti.

Pertanto, questa decisione non è tua da prendere, poiché la tua azienda ha bisogno di utilizzare risorse aggiuntive per andare a B. Quindi devi portare le tue preoccupazioni alla persona responsabile, spiegare questa e qualsiasi altra preoccupazione a lungo termine abbastanza bene da fargli capire perché lo consideri inferiore al tuo suggerimento. Quindi lascia che prenda la decisione e, indipendentemente da ciò che risulta, rispettarla e comportarsi di conseguenza in modo professionale. Si noti che molto probabilmente l'autore originale dovrà mantenerlo mentre lo ha scritto e se lascia o non vuole più, è possibile sollevare nuovamente la questione.

In altre parole: cosa dice il tuo capo? Scopri - fallo.

Nota anche che questo sarebbe stato diverso se avessi sollevato il problema in precedenza, in modo che il denaro sprecato per il tempo impiegato nell'implementazione di A fosse inferiore. In altre parole, quando doveva essere fatta la scelta tra A e B.

Infine, vorrei commentare la tua domanda sul "fissare semplicemente il codice di altre persone". Questa non è una piccola correzione al codice esistente (che trovo bene e incoraggiato, specialmente con i test in atto). È un rollback e una reimplementazione dirompenti, e anche nei team con proprietà di codice comune ciò non sarebbe una cosa accettabile da fare - almeno per me - senza previa approvazione.

Spero che questo chiarisca il mio punto di vista.

Cerco una libreria di offuscatori in Java e riparo il suo vecchio codice (che potrebbe essere un po 'permaloso nel rimodellare il suo codice), o lo lascio così tanto, tanto che mi infastidisce senza fine?

No , tornare indietro a qualcuno e modificare il codice di cui sono responsabili sarebbe un'offesa peggiore rispetto alla scrittura del codice discutibile per cominciare.

L'hai tirato fuori con il programmatore, il tuo prossimo passo è quello di tenere il naso fuori da esso o portarlo con la gestione e quindi tenere il naso fuori da esso.

C'è stata una revisione ufficiale del codice di qualsiasi tipo - o lo scontro ha avuto una "revisione del codice" non ufficiale? Direi che trattandosi di un argomento delicato e importante come la sicurezza e le licenze, è necessario sollevare la catena. Hai fatto la prima parte - confrontandoti con il programmatore. Tuttavia, ora che non sta ascoltando, puoi / dovresti accettarlo. In caso contrario, potresti essere parte del problema.

Gli direi che lo farai - questo PUO 'cambiare idea. In caso contrario, scrivi al tuo capo e al programmatore CC un'e-mail politicamente corretta, ma accurata e concisa sulla situazione. Nell'e-mail, chiedi un incontro tra voi tre e / o qualsiasi altra parte partecipante.

Incontra sempre queste cose a testa alta - eppure in modo politico e amichevole.

Se riesci a trovare un offuscatore che può offuscare la firma delle classi (nomi dei metodi, ecc.), Allora, proponi di acquistarlo e usarlo.

Fino ad allora, potresti dover convivere con esso. Ammetto di aver fatto qualcosa di simile in un recente progetto Grails: i controlli di licenza sono incorporati deliberatamente nel già ampio metodo di accesso, quindi sarebbe piuttosto difficile sostituire il metodo per bypassare il controllo.

Può dimostrare che un tale hack è fattibile o è solo uno scenario ipotetico di cui è un po 'preoccupato? Può fare una dimostrazione dal vivo di questo lavoro? Dovrebbe provare. Sul serio. Se funziona, dovrebbe essere presentato alla direzione e quindi suggerire di procurarsi un offuscatore.

Se un offuscatore non è abbastanza sicuro, hai cercato altri modi per proteggere il JAR, forse qualcosa come crittografarlo o compilarlo in codice nativo?

RE: rielaborare il suo codice: si tratta solo di rinominare? Molti IDE hanno strumenti di refactoring che possono farlo abbastanza facilmente.

Indipendentemente da quanto sia prezioso il tuo IP, la cosa intelligente non è quella di manipolare il tuo codice nella speranza di confondere gli hacker. A parte il fatto che sarà un incubo continuare ad andare avanti, in realtà non risolve alcun problema. Rende solo più difficile ma non impossibile. Quindi non è davvero una soluzione e gli effetti collaterali sono cattivi. È come prendere medicine che non funzionano e hanno effetti collaterali negativi.

Il tuo problema è come proteggere il tuo IP. Trova una soluzione per questo: offuscatori, server delle licenze, ecc.

Ho riscontrato un problema simile quando un altro sviluppatore ha chiamato le nostre routine di crittografia / decrittazione str__copye str__delete(nota il secondo trattino basso). Era scadente e avrebbe potuto essere fatto meglio, quindi abbiamo aspettato che ci fosse una storia in cui fosse necessario aggiornare le licenze. La gestione non ha avuto problemi con la manciata di ore in più perché l'abbiamo descritta come "ripulisci, quindi la prossima volta che andremo in licenza, ci vorrà meno tempo e sarà più sicuro". Problema risolto, nessun sentimento ferito.

Il mio primo pensiero è stato il mantenimento di quel codice. Se il codice è già offuscato e viene spostato, buona fortuna cercando di ottenere un controllo su quel codice. Sarai quindi l'hacker che cerca di decifrare il codice.

Invece, consiglierei di ripulire il codice e usare un offuscatore per fare tutto il duro lavoro. A lungo termine avrai molto codice gestibile e lascerai tutta la folle complessità a chiunque voglia hackerare la tua licenza.

Ricorda che nessun offuscatore è perfetto e un hacker molto determinato può decodificare qualsiasi cosa, ma almeno sarà solo lui. Inoltre gli offuscatori aggiungono molta più complessità di quella che un ragazzo probabilmente può.

Sono pienamente d'accordo con le risposte che dovresti chiedere al tuo capo in merito al problema e fare quello che dice.

Tuttavia un addendum molto importante a queste risposte è che dovresti documentare le tue preoccupazioni sia sulla sicurezza che sulla manutenibilità. Indipendentemente dal fatto che modifichi o meno il codice, è importante che le persone sappiano di cosa ti preoccupi e perché. Questo è importante sia in modo proattivo (il tuo capo non può prendere una decisione che non sa nemmeno che deve essere presa) sia in modo difensivo (se / quando un hacker fa buchi nel sistema di licenze scarsamente protetto, non possono biasimarti per il loro sbaglio.)

"Non essere il professionista più superiore a conoscere un problema".

In altre parole, dillo al tuo capo e vai da lì. Se stai zitto, e sei in cima al totum su quel segreto, quando la spinta arriva a spingere sarai responsabile. Di 'al tuo capo di passaggio e lascia che decida un modo per affrontarlo. In questo modo sei sollevato dall'onere della scelta.

Non limitarti a dirlo al tuo capo, perché molti manager forse non sono così tecnici, ma fanno quello che facciamo sempre: dare il problema e le possibili soluzioni con i vantaggi / gli svantaggi per ciascuna di quelle soluzioni. Quindi lascia che decidano e faccia passare quello. Ecco perché i manager / leader vengono pagati con un sacco di soldi!

La pura verità è che, dato il tempo e le risorse sufficienti, qualsiasi cosa può essere violata. È una semplice funzione di quanto è popolare la tua app. Più è popolare, più hacker qualificati attira e più tempo è dedicato alla sua rottura. L'offuscamento del codice fornisce proprio questo: un mezzo per aumentare il tempo necessario per romperlo, simile alla crittografia. Quindi, se il tuo codice viene offuscato, richiede che l'autore dell'attacco sia abile e gli dedichi del tempo, altrimenti si dispererà e si arrenderà. Devi chiederti se la tua app vale la pena su entrambi i fronti.

È davvero sorprendente quanto possa diventare difficile decifrare il codice offuscato. Puoi facilmente trasformare un semplice programma a 10 linee C in un assemblaggio di 100 linee uno attraverso l'offuscamento. Se provi a eseguire il debug, salterai in modo insignificante nel codice e potresti essere davvero frustrante passarci attraverso. Alla fine si romperà ma diventa davvero difficile e dato che nulla è davvero impossibile, questo è il punto. L'offuscamento del codice riduce il numero di persone che sono in grado di romperlo.

Certo ci sono modi migliori, come cercare di confondere il debugger non il cracker, ma questo è economico ed efficiente. Tuttavia nominare le cose goffamente non lo taglia del tutto. Devi cambiare le funzioni di chiamata del flusso di controllo che in realtà non fanno nulla per il tuo codice generale ma ne aumentano le dimensioni e la complessità: chiama funzioni fittizie il cui valore di ritorno non viene utilizzato da nessuna parte, da funzioni interne che fanno davvero qualcosa. Puoi già vedere come questo può diventare davvero confuso.

Hai qualcosa che l'attaccante non ha. Il codice sorgente originale. Trova un modo per organizzarlo meglio per te stesso.