Data Module,componenti relativi ed eventuali falle di siurezza

[Lorenzo]

Avevo un dubbio.
Per quanto riguarda le applicazioni in fase di sviluppo,uso un data module come piattaforma di input-output.
La classe che gestisce il data module inoltre la uso per racchiudere i metodi e le proprietà pubbliche che servono per operare sugli oggetti visibili(che sono di  tipo Published) e che permettono un interscambio di dati.

Questo modus operandi mi dà modo di avere sotto gli occhi una lista di oggetti da utilizzare.
In produzione sostituisco con classi i cui membri che nel data module sono published,diventano privati.

La domanda è quanto un data module con oggetti published possa rappresentare una eventuale falla di sicurezza.
Trattandosi di oggetti accessibili per chiunque possa accedere al data module,supponendo di avere oggetti che gestiscono connessioni ad un database o al server,qualche esperto hacker potrebbe arrivare a leggerne il contenuto?

[DragoRosso]

Non confondere sicurezza dell'eseguibile con sicurezza (relativa) del codice.
Quello che viene definito come pubblico / privato / pubblicato / protetto è esclusivamente una definizione di visibilità (OOP).
Non ha nulla a che fare con la sicurezza dell'eseguibile (codice eseguibile).

Quelle definizioni impongono una condizione di visibilità del codice nelle classi derivate (o istanziate) che il compilatore deve garantire: una proprietà privata (o magari strict private) non può essere usata a livello di codice sorgente da una classe derivata o da una qualsiasi altra parte di codice che non appartenga alla classe stessa.

Ma stiamo parlando solo a livello di codice sorgente.

Per farti capire meglio, un qualsiasi debugger può accedere ad una qualsiasi proprietà di una classe istanziata che sia privata o no, quindi ciò già ti dà alcune informazioni sulla "sicurezza" del codice eseguibile.

Per evitare che le informazioni presenti nell'eseguibile possano aiutare hacker a danneggiarti il codice compila senza inofrmazioni di debug (-O0), senza RTTI ed esegui lo "strip" a livello di linker.

Se poi invece parliamo di componenti, cioè di parti di codice che fornisci per implementare nuove funzionalità allora è diverso. In Lazarus / FPC è più complesso vista la vastità di composizioni che si possono avere ... a differenza di Delphi dove puoi distribuire una DCU definita per ogni versione rilasciata (e normalmente basta la MAJOR quindi una per la 12, una per la 13, etc ... in Lazarus / FPC dovresti rilasciarne (si chiamano PPU) una per ogni possibile combinazione di versione.

E' per questo che in Lazarus / FPC i componenti si rilasciano solo sotto forma di sorgenti e devono essere sempre compilati con la versione corrente di sviluppo (cioè la versione in uso).

Fornendo solo le DCU (per Delphi), chi le userà potrà usare solo ed esclusivamente ciò che tu vuoi mettere a disposizione, cioè la "parte" pubblica" e "protected" (nel caso tu derivi il componente).

Se fornisci il sorgente, ovviamente uno può smanettarci e fare ciò che vuole: anche se non conosce i dettagli di connessione, potrebbe inserire ad esempio un metodo "intercettore" che riporta tutti dati di scambio a livello di istanza.

[Lorenzo]

Intendevo non a livello OOP.
Non ho una idea precisa su come lavori FPC.


Grazie molte per la spiegazione.

Per il resto,a meno che non si tratti di un progetto comune,non distribuirei mai il mio software assieme al suo codice sorgente poichè sappiamo tutti benissimo che lo sviluppo software comporta un notevole impiego di tempo,sforzi che portano a sacrificare una buona parte del proprio tempo.

[DragoRosso]

Non ho una idea precisa su come lavori FPC.

Bhè, FPC come Delphi e qualsiasi altro compilatore traduce il codice sorgente in eseguibile.

E' l'eseguibile che deve essere in "sicurezza", ma ovviamente è quasi impossibile (anzie direi senza timore di essere smentito ... impossibile, senza il quasi) renderlo sicuro al 100%.

Io sinceramente firmo il codice (con una mia firma EV) e qualsiasi cosa che carico (dll mie o di terze parti, eseguibile proprio compreso) verifico le firme (e un altro paio di "aggeggi" che inserisco nell'eseguibile).

Ma rimane comunque aperta l'opzione che ci sia un malware che attacca direttamente (tipo debugger per intenderci) l'eseguibile.

Ci sono tecniche che consentono di proteggere sufficientemente il lavoro di un eseguibile: crittografia, connessioni TLS, streaming binari, etc ...
Ma nulla si può fare in realtà se qualcuno decidesse di investire risorse "infinite" (ossia tempo, uomini e soldi) per craccare o danneggiare un software.

E attualmente è relativamente banale e stupido farlo, lo dimostra la "bucata" del famoso e costoso software antipirateria usato in molti giochi (sino a qualche mese fà ci volevano mesi ... oggi è stato bucato in minuti o poco più).

Quindi, non dedico più molto tempo al perfezionamento del sistema anticopia o antimanomissione (inusuale nel mio settore di attività) ma piuttosto dedico tempo al servizio al cliente, che rende molto di più e fidelizza sia i vecchi che i futuri clienti.

P.S.: il codice prodotto da FPC (o da Delphi) è sicuro, tenendo conto che lo sviluppatore ha seguito le corrette prassi ? Certo, ma entro "ogni ragionevole dubbio".

[DragoRosso]

Per il resto,a meno che non si tratti di un progetto comune,non distribuirei mai il mio software assieme al suo codice sorgente poichè sappiamo tutti benissimo che lo sviluppo software comporta un notevole impiego di tempo, sforzi che portano a sacrificare una buona parte del proprio tempo.

Ragionamento da imprenditore. Diciamo che la produzione di software ai fini commerciali è ciò che mantiene un sacco (se non tutti) gli sviluppatori.
Però è anche una fortuna che molti si dedichino allo sviluppo open source che sicuramente fà evolvere conoscenza, progresso e cultura.

Ed è anche una fortuna che l'open source non è "blindato" molto spesso dall'obbligo di fornitura dei sorgenti (GPL docet) ...

Vedremo come cambierà il mondo dello sviluppo software e della produzione quando entreranno in vigore le nuove regole nella comunità Europea (e in America pure).
Buon .... SBOM .... a tutti 

[DragoRosso]

Questo è un OT, ma si aggancia all'ultimo periodo del post precedente ... le nuove regole UE ...

mi fà "morire" l'imposizione di rendere uno sviluppatore commerciale responsabile (legalmente ... da cui derivano sia casi penali che civili) anche della parte "open source" non sviluppata da lui (ma da lui usata) ....

E nonostante ci sia verso questo "settore" una vasta spinta per renderne "spintanea" (se non obbligatoria) l'adozione ... ma con queste regole chi userà l'open source ?

Io piuttosto me lo copierei, lo modificherei a mio piacimento per renderlo "mio source" (per disconoscerne la paternità) e tanti saluti all'intero sistema ...

Almeno se esce qualche gabola con quel "open source" non si potrà abbinarlo al mio prodotto .... (e qui ci si aggancia all'SBOM).

[Lorenzo]

Cosa importante che noto è che FPC produce davvero un codice pulito.
E non è una cosa molto comune tra i compilatori.
Di sicuro racchiude ancora buona parte dell'eredità Borland.

Io solitamente consegno il codice spesso proprietà aziendale,loro si occupano delle licenze.

Di media quanto può costare mensilmente il servizio di EV?


Riguardo la nuova direttiva UE mi fido solo dei miei pregiudizi: per me sembra studiata per inibire la libera iniziativa nel campo dello sviluppo software.
Magari non entrerà in vigore perchè  potrebbe non convenire alla stessa Microsoft che chissà quanti milioni di dollari dovrà sborsare per risarcire quelle aziende danneggiate da attacchi dovuti a varie falle di sicurezza di Windows.
Che poi ad esser sarcastici,c'hanno pure i media a favore: ogni volta che nei tg viene data notizia di un attacco hacker,spesso come immagini di repertorio che trasmettono mostrano uno schermo con la schermata di Ubuntu.
(Mi fa ridere questa cosa)

[DragoRosso]

Di media quanto può costare mensilmente il servizio di EV?

Io ho fatto l'EV con Certum,  unico certificatore Europeo (Polacco x la precisione). Non che un certificatore americano fosse diverso, ma volevo investire in Europa i miei soldi.

Ho pagto sugli 800 Euro per tre anni compresa la chiavetta (c'è anche la versione cloud in alternativa volendo).
Processo di accreditamento lungo e certosino con mille domande (anche per l'indirizzo che su alcuni miei documenti era abbreviato rispetto ad altri).

I prezzi mi pare che anche ora sono più o meno li, dipende dai momenti: i vari certificatori molto spesso fanno offerte e sconti.

[DragoRosso]

Cosa importante che noto è che FPC produce davvero un codice pulito.
E non è una cosa molto comune tra i compilatori.
Di sicuro racchiude ancora buona parte dell'eredità Borland.

Bhè, diciamo che i compilatori Pascal (non solo FPC) hanno vita facile visto che lavorano sul ... linguaggio Pascal. 
Il inguaggio sicuramente aiuta.
A me non piace l'innumerevole quantità di switch e l'insicurezza di compilazione a livello 3 o 4 di ottimizzazione (da usare a proprio rischio, se non sbaglio) che ha FPC.
Ritengo che un compilatore debba garantire in tutte le condizioni di compilazione la correttezza e l'aderenza del codice sorgente. L'unico switch che posso concepire è l'eventuale ottimizzazione o meno dei cicli for ad esempio.
Ma forse sono limitato io.

P.S.: in Delphi ci sono solo due scelte, o si ottimizza o no. Preferisco questo modo.

[Lorenzo]

Bhè, diciamo che i compilatori Pascal (non solo FPC) hanno vita facile visto che lavorano sul ... linguaggio Pascal. 
Il inguaggio sicuramente aiuta.
A me non piace l'innumerevole quantità di switch e l'insicurezza di compilazione a livello 3 o 4 di ottimizzazione (da usare a proprio rischio, se non sbaglio) che ha FPC.
Ritengo che un compilatore debba garantire in tutte le condizioni di compilazione la correttezza e l'aderenza del codice sorgente. L'unico switch che posso concepire è l'eventuale ottimizzazione o meno dei cicli for ad esempio.
Ma forse sono limitato io.

P.S.: in Delphi ci sono solo due scelte, o si ottimizza o no. Preferisco questo modo.

Mi sembra che sia il fattore principale che lo rallenta molto: ricorda i compilatori vecchio stile.
Cosa che Delphi sembra non abbia e che lo rende due volte più veloce nella compilazione.

[Lorenzo]

Ed è anche una fortuna che l'open source non è "blindato" molto spesso dall'obbligo di fornitura dei sorgenti (GPL docet) ...

Questo è interessante ed è questa licenza che conosco meno.