Buona ingegneria del software rispetto alla sicurezza

Question

Le linee guida Security and Design descrivono in modo approfondito vari metodi per rendere più difficile per un utente malintenzionato compromettere l'implementazione della fatturazione in-app.

Particolarmente indicato è la facilità con cui si può decodificare un file .apk, anche se occultato tramite Proguard. Quindi raccomandano persino di modificare tutto il codice di applicazione di esempio, in particolare "punti di ingresso noti e punti di uscita".

Quello che trovo manca è alcun riferimento al confezionamento certi metodi di verifica in un unico metodo, come la statica Security.verify() che restituisce boolean: Una buona pratica di progettazione (codice ridurre la duplicazione, riutilizzabile, più facile da eseguire il debug, auto-documentazione, ecc .) ma tutto ciò che un utente malintenzionato deve fare ora è identificare quel metodo e farlo sempre restituire true ... Quindi indipendentemente da quante volte l'ho usato, ritardato o non ritardato, a caso o no, semplicemente non importa.

D'altra parte, Java non ha macro come in C/C++, che consente di ridurre la duplicazione del codice sorgente, ma non ha un singolo punto di uscita per una funzione verify().

Così le mie domande:

Esiste un conflitto intrinseco tra i ben noti di ingegneria del software/codifica pratiche e di design per la cosiddetta sicurezza? (nel contesto di Java/Android/transazioni sicure almeno)

Cosa si può fare per mitigare gli effetti collaterali del "design per la sicurezza" che sembra "spararsi nel piede" in termini di complicazioni eccessive software che avrebbe potuto essere più semplice, più gestibile e più facile da eseguire il debug?

Potete raccomandare buone fonti per approfondire questo argomento?

Answer 1

Come al solito, è un compromesso. Rendere il tuo codice più difficile da decodificare/crack significa renderlo meno leggibile e difficile da mantenere. Sei tu a decidere fino a dove andare, in base alla base di utenti prevista, alle tue abilità nell'area, al tempo/ai costi, ecc. Questo non è specifico per Android. Guarda this Google I/O presentation per varie fasi di offuscamento e rendere il tuo codice antimanomissione. Quindi decidi quanto sei disposto ad andare per le tue app.

D'altra parte, non c'è bisogno di offuscare/indurire, ecc tutta del codice, solo la parte che si occupa di licenze, ecc Questo è di solito una parte molto piccola di tutto il codice di base e non ha davvero bisogno di cambiarlo spesso, quindi potresti probabilmente vivere con esso è difficile da seguire/mantenere, ecc. Basta tenere alcune note su come funziona, quindi ti ricorderai di te 2 anni dopo :).

Answer 2

La produttività del contatore che stai descrivendo è la punta dell'iceberg ... Nessun software è privo di bug al 100% al momento del rilascio, quindi cosa fai quando gli utenti iniziano a segnalare problemi?

Come si risolvono o si risolvono i problemi di campo dopo aver disabilitato la registrazione, la traccia di stack e tutti i tipi di altre informazioni che aiutano i tecnici di inversione ma aiutano anche il team di sviluppo legittimo?

Answer 3

Per quanto difficili siano i metodi di offuscamento, c'è sempre un modo per decodificarli. Voglio dire, se il tuo software diventa più popolare tra la comunità di hakers, alla fine qualcuno proverà a decodificarlo.

L'offuscamento è solo un metodo per rendere più difficile il processo di reverse engineering.

Quindi è l'imballaggio.Penso che siano disponibili molti metodi di imballaggio, ma lo è anche il processo di decodifica.

È possibile controllare lo www.tuts4you.com per vedere quante tonnellate di guide sono disponibili.

Non sono un esperto come molti altri, ma questa è la mia esperienza nel processo di apprendimento del reverse-engineering. Inoltre recentemente ho visto molte guide per il reverse engineering delle applicazioni Android. Ho visto anche in nullc0n (non sicuro) CTF, c'era un'app in Reversing Android. Se vuoi, posso menzionare il sito dopo aver cercato.