Impedire accesso non autorizzato ai dati delle tabelle

di il
28 risposte

28 Risposte - Pagina 2

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Un breve commento, che in sostanza replica quanto già evidenziato da MAX ed OREGON, ovviamente parliamo di applicazioni DESK.

    Access come BE non è da prendere in considerazione, e purtroppo il fatto sia composto da Client e Server o FE e BE, spesso confonde soprattutto i meno esperti che non ne comprendono la commistione, è vero però che questi utenti hanno esigenze decisamente poco o meno impegnative anche in termini di Sicurezza.

    I più esperti quanto meno i concetti chiari però li hanno e comprendono sicuramente cosa sia imputabile al mezzo piuttosto che allo sviluppo.

    Come FE credo possa ancora dire al sua in termini di Tempo/Risultati, pur riconoscendo che non è al passo con i tempi ed ha grossi limiti di operatività sulla rappresentazione dei dati e la grafica, se vogliamo entrare nel tecnico anche sulla Sicurezza ci sono più pregiudizi che consapevolezza.

    Un Client, fatto con qualsiasi SW se lo lasci aperto e te ne vai chiunque fa danni… 

    Ricordo agli esperti e non, che attualmente il compilato PCode è probabilmente più sicuro di un Compilato in NET che sia VB o C#, per i quali esistono i Decompilatori gratutiti… 
    Non credo ci sia un Decompilatore Gratuito per i file in PCode(Accde o Mde), ma posso confermare che ci sono società che sono in grado di farlo, ho partecipato io stesso ad un Test di una società Russa che ha fatto reverse engineering di un mio File ACCDE, qualche anno fa, ma nulla di Free nel WEB, per quanto ne so.

    La gesione utenti da quando si gestiscono i dati è delegata al Server, e questo con qualsiasi SW si possa sviluppare un Client, non si salvano PWD nel Client, se si sono creati Users e Permission ServerSide, la procedura di LINK delle Tabelle passerà la Connection String costruita con i dati dello USER se sono giusti si procede se sono sbagliati si gestirà l'errore, ed ovviamente si devono DISTRUGGERE alla chiusura, ricordo che ora la connection String non è più in chiaro nelle Tabelle di Sistema, ma in ogni caso le Linked vanno rimosse alla chiusura, ed anche il giochino dell'inibizione dello SHIFT è Bypassabile come qualsiasi protezione, pur se legata alla PWD del Client, cosa diversa dalla PWD di Login per una gestione utenti.

    Il problema è che il concetto non può vedere delgato allo Shift la proteggere il client, ma la logica con cui questo viene sviluppato.

    Molti “sviluppatori” non implementano la gestione USER nel server mettono le PWD nel Client, lasciano le LINKED collegate e poi si lamentano che Access non è sicuro…?

    Senza PWD salvate e distruggendo le Linked alla chiusura vorrei qualcuno mi spiegasse tecnicamente in modo chiaro senza tanto fumo, dove è possibile bypassare sicurezze che altri Client sviluppati con linguaggi più evoluti invece non consentono…  

    Ovviamente si possono trovare mille difetti ancora alle cose, ma partendo da un utilizzo “tecnicamente logico” magari….

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Finalmente posso dirmi soddisfatto di quanto da me cercato.
    Non sono riuscito a bloccare la possibilità di non usare il tasto SHIFT.
    Sono però riuscito ad ottenere un file .accde che non permetta l'accesso diretto alle varie tabelle a nessun utente.
    Più sotto, nelle mie varie risposte che finalmente sono riuscito a scrivere, spiegherò come.

    24/10/2023 - fratac ha scritto:


    Non esiste.

    Qualsiasi cosa tu ti possa inventare, una volta entrati in access, qualsiasi utente ha eccesso completo.

    Ha sì accesso completo alle macro e potrà eliminare i vari elementi (machere, macro, collegamenti alle tabelle, ecc.) ma non potrà modificare i record dalle tabelle collegate in quanto non essendoci la password del collegamento memorizzata, non potrà accedere a nessun dato. Anche le query non funzionerannbo in quanto non avranno accesso alle tabelle su cui fare le elaborazioni. L'importante è non avere tabelle importate o collegate senza password, allora sì avranno accesso completo.

    24/10/2023 - By65Franco ha scritto:


    Se trovi lo smanettone di turno, le protezioni al database vengono bypassate … ed in ogni caso, soprattutto con access, una volta che ti sei autenticato è festa grande.

    Mi definisco smanettone di turno, ma con la mia soluzione non vedo (e spero non ci sia) soluzioni per aggirare l'accesso.

    24/10/2023 - oregon ha scritto:


    Addirittura, per potere scrivere e leggere normalmente si ha anche accesso al file con i dati che puoi anche eliminare senza problemi. 

    Se la tua necessità è questa, usa un RDBMS. 

    Infatti ho sempre ipotizzato di non usare direttamente Access per i dati ma solamente per le query, le maschere ed i report. Lì sì lo trovo velamente veloce e pratico (sia pe rlo sviluppatore che per l'utente utilizzatore). Di usaro solo come Front-end e non come Back-end.

    25/10/2023 - By65Franco ha scritto:


    infatti è quello che accennavo… una volta loggato è festa grande ;-)

    Penso di essere riuscito ad evitare la festa grande :-)

    25/10/2023 - max.riservo ha scritto:


    Io, con db accde, gestisco queste proprietà al primo avvio del front-end :

    Grazie della lista delle proprietà, vedrò di applicarle anche ai miei prossimi database.

    25/10/2023 - max.riservo ha scritto:


    Non so quanto sia facile accedere al sorgente di Access (accde) e/o quanto sia ancora facile riuscire a riabilitare il tasto shitf … in tutti i casi accetto che sia fattibile

    Per l'accesso ai sorgenti non ho idea, presumo se compilati con .accde, l'unico sistema sia la decompilazione, ma penso che questo lo si ha con tutti i linguaggi di programmazione.
    Per il tasto SHIFT, purtroppo confermo che è rimovibile.

    25/10/2023 - max.riservo ha scritto:


    Io ho un form di login dove impostare utente/pwd, dopo creo la connessione alle tabelle tramite l'oggetto Tabledefs (non ho memorizzato la stringa di connessione completa di UID e PWD nel sorgente di Access). Utilizzando Access2013, io non ho trovato il modo di vedere la stringa di connessione completa (ovvero la stringa di connessione è presente ma senza UID e PWD) : non dubito che qualcuno riesca a trovare dove eventualmente UID e PWD siano salvati.

    Per la stringa di connessione non metterei la mano sul fuoco che attraverso un editor esadecimale non riuscirei a vedere la stringa in chiaro…

    Meglio usare qualche funzione o concatenazioni di testo per ‘mimetizzare’ la vera stringa.

    25/10/2023 - max.riservo ha scritto:


    Io non sarei così sicuro di quanto scrivi : esistono i trigger sulla modifica dei dati. Io gestisco nelle tabelle, a livello di record, sfruttando i trigger, user e data inserimento, user e data modifica.

    Grazie per l'informazioni dei trigger. Usando un MySql gestito da una ditta esterna, questi erano nascosti e non accessibili e mi ero dimenticato della loro esistenza… Terrò in mente la possibilità di usarli su un nuovo server MySql.

    26/10/2023 - @Alex ha scritto:


    Come FE credo possa ancora dire al sua in termini di Tempo/Risultati, pur riconoscendo che non è al passo con i tempi ed ha grossi limiti di operatività sulla rappresentazione dei dati e la grafica, se vogliamo entrare nel tecnico anche sulla Sicurezza ci sono più pregiudizi che consapevolezza.

    Sono completamente d'accordo su questa affermazione.

    26/10/2023 - @Alex ha scritto:


    Senza PWD salvate e distruggendo le Linked alla chiusura vorrei qualcuno mi spiegasse tecnicamente in modo chiaro senza tanto fumo, dove è possibile bypassare sicurezze che altri Client sviluppati con linguaggi più evoluti invece non consentono…  

    Su Microsoft Access semplicemente avviando il database con il tasto SHIFT premuto, si avvia la maschera di autenticazione che avrà il compito di far connettere le tabelle collegate. Poi basta accedere alle varie tabelle dal riquadro di spostamento. Anche se la maschera di autenticazione nascondesse il riquadro di spostamento, basterebbe farlo riapparire premendo F11.

    La mia soluzione è quella di verificare la presenza della variabile ‘AllowBypassKey’ e che questa valga ‘False’ prima di inserire le credenziali delle tabelle.

    Function GetAllowBypassKey() As Boolean
       On Error GoTo GestioneErrore
       Dim bAllowBypassKey As Boolean
       bAllowBypassKey = CurrentDb.Properties("AllowBypassKey")
       GetAllowBypassKey = bAllowBypassKey
       Exit Function
       
    GestioneErrore:
       GetAllowBypassKey = True
    End Function
    

    Al momento dell'inserimento delle credenziali, farò:

       Dim bAllowBypassKey As Boolean
       bAllowBypassKey = GetAllowBypassKey()
       If bAllowBypassKey = False Then
           Dim db As Database
           Set db = CurrentDb
           db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"
           db.TableDefs("cliente").RefreshLink
       Else
           MsgBox "Spiacente, l'uso del tasto SHIFT non è bloccato!"
       End If
    

    Questo su un database .accde e tabelle collegate tramite password non memorizzata in fase di collegamento.

    Spero, confido, che questo codice non sia attaccabile,
    fatemi sapere cosa ne pensate.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"

    Se questa è la tua stringa di connessione (completa di UID e PWD) allora fai bene a pensare che con qualche editor esadecimale si possa leggere …

    Io concatendo alla parte fissa di stringa di connessione UID e PWD digitati dall'utente tramite il form di login …

    Aggiungo che volendo, è anche possibile rinunciare alle tabelle collegate : basta lavorare molto di SQL, dipende da quanto sia pressante l'esigenza di sicurezza.

    Volendo (con MySQL ma credo anche con altrei RDBMS) è possibile collegare delle viste (non modificabili per definizione e/o rese non modificabili) per l'estrazione dei dati e poi si lavora di SQL per gli aggiornamenti : è più impegnativo sicuramente, dipende dalle esigenze.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    Mi definisco smanettone di turno, ma con la mia soluzione non vedo (e spero non ci sia) soluzioni per aggirare l'accesso.

    Ciao,

    Ok…. beh si , in fondo siamo un pò tutti smanettoni di tanto in tanto… ;-)

    facciamo così, quando hai terminato il progetto me lo passi e ti faccio vedere come si accede.  ;-)

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - max.riservo ha scritto:


    31/10/2023 - zio3d ha scritto:


    db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"

    Se questa è la tua stringa di connessione (completa di UID e PWD) allora fai bene a pensare che con qualche editor esadecimale si possa leggere …

    Io concatendo alla parte fissa di stringa di connessione UID e PWD digitati dall'utente tramite il form di login …

    Aggiungo che volendo, è anche possibile rinunciare alle tabelle collegate : basta lavorare molto di SQL, dipende da quanto sia pressante l'esigenza di sicurezza.

    Volendo (con MySQL ma credo anche con altrei RDBMS) è possibile collegare delle viste (non modificabili per definizione e/o rese non modificabili) per l'estrazione dei dati e poi si lavora di SQL per gli aggiornamenti : è più impegnativo sicuramente, dipende dalle esigenze.

    La mia è una stringa di esempio fatta per i test.
    Nel mio caso avrei concatenato alcune stringhe prelevandole da un array di stringhe precedentemente riempito in modo sparso.

    Ottimo il tuo suggerimento di concatenare parte della login/password per l'autenticazione. Terrò sicuramente in considerazione.

    Avevo provato tempo fa a non utilizzare le tabelle collegate ma direttamente istruzioni che si connettevano direttamente alle tabelle e query tramite SQL ma, nel mio caso, non serviva una sicurezza così estrema. Era troppo laborioso apportare modifiche rispetto alla comodità e velocità di usare le tabelle e le query che Access mi mette a disposizione. Per via della sicurezza, a mio avviso qui si passa di livello, non più smanettoni ma hacker.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    Avevo provato tempo fa a non utilizzare le tabelle collegate ma direttamente istruzioni che si connettevano direttamente alle tabelle e query tramite SQL ma, nel mio caso, non serviva una sicurezza così estrema. Era troppo laborioso apportare modifiche rispetto alla comodità e velocità di usare le tabelle e le query che Access mi mette a disposizione.

    Ecco … appunto … la facilità d'uso ha un prezzo.

    31/10/2023 - zio3d ha scritto:


    Per via della sicurezza, a mio avviso qui si passa di livello, non più smanettoni ma hacker.

    Non sono d'accordo : qui si passa da smanettoni/hobbisti (persone che si acculturano leggendo qualche post in rete e/o guardando qualche video e/o usando autocomposizioni - magari riescono anche a produrre dei prodotti sw interesanti ma spesso carenti da un punto di vista tecnico) a professionisti (persone che studiano e approfondiscono i vari argomenti perchè in fondo, grazie alla conoscenza dei vari prodotti, portano a casa il giusto compenso - almeno si spera).

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - max.riservo ha scritto:


    Non sono d'accordo : qui si passa da smanettoni/hobbisti (persone che si acculturano leggendo qualche post in rete e/o guardando qualche video e/o usando autocomposizioni - magari riescono anche a produrre dei prodotti sw interesanti ma spesso carenti da un punto di vista tecnico) a professionisti (persone che studiano e approfondiscono i vari argomenti perchè in fondo, grazie alla conoscenza dei vari prodotti, portano a casa il giusto compenso - almeno si spera).

    Per hacker intendevo il senso buono della parola: “una persona che utilizza le proprie competenze informatiche per esplorare i dettagli dei sistemi programmabili” (cit wiki).
    Probabilmente era preferibile scrivere “Professionista”.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - By65Franco ha scritto:


    31/10/2023 - zio3d ha scritto:


    Mi definisco smanettone di turno, ma con la mia soluzione non vedo (e spero non ci sia) soluzioni per aggirare l'accesso.

    Ciao,

    Ok…. beh si , in fondo siamo un pò tutti smanettoni di tanto in tanto… ;-)

    facciamo così, quando hai terminato il progetto me lo passi e ti faccio vedere come si accede.  ;-)

    Qui mi preoccupi…

    Non so se fare finta di niente e tenermi la mia “sicurezza” o se capire come sia aggirabile la protezione che ho attuato.
    Resto col dubbio…

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    la mia “sicurezza”

    Guarda che non esiste “sicurezza” che tenga, se qualcuno vuole superare i tuoi blocchi, li supera.

    Tutto sta nel trovare le credenziali per loggarti al DBMS e quelle si trovano abbastanza facilmente.

    Ovviamente non da “tutti”, ma “tutti” possono chiedere di farlo a chi lo sa fare se interessati.

    Fossi in te, mi fermerei a quello che ho ottenuto senza andare oltre perché non serve proprio.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    Qui mi preoccupi…

    Non so se fare finta di niente e tenermi la mia “sicurezza” o se capire come sia aggirabile la protezione che ho attuato.
    Resto col dubbio…

    Poi non venirmi a dire che non te lo avevo detto ..  ;-)

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - oregon ha scritto:


    31/10/2023 - zio3d ha scritto:


    la mia “sicurezza”

    Guarda che non esiste “sicurezza” che tenga, se qualcuno vuole superare i tuoi blocchi, li supera.

    Tutto sta nel trovare le credenziali per loggarti al DBMS e quelle si trovano abbastanza facilmente.

    Ovviamente non da “tutti”, ma “tutti” possono chiedere di farlo a chi lo sa fare se interessati.

    Fossi in te, mi fermerei a quello che ho ottenuto senza andare oltre perché non serve proprio.

    Non ho capito il senso di questo intervento.
    Non mi sembra di aver insistito su nessun argomento, appena ho trovato quanto da me richiesto mi sono subito fermato, nessun "andare oltre".

    È palese che la sicurezza completa non esiste e dipende tutto da quale grado si vuole raggiungere.
    Infatti avevo scritto "la mia “sicurezza”" per indicare il mio grado di sicurezza desiderato e “Resto col dubbio…” per indicare che a me bastava quanto trovato e di non voler indagare ulteriormente...
    Avevo anche iniziato il post con “Finalmente posso dirmi soddisfatto di quanto da me cercato.” per affermare che il grado così raggiunto mi bastava.

    Ok, avevo scritto "Spero, confido, che questo codice non sia attaccabile", davo per scontato “dalla maggior parte delle persone senza esperienza o che abbia con un minimo di esperienza”.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - zio3d ha scritto:


    Non so se fare finta di niente e tenermi la mia “sicurezza” o se capire come sia aggirabile la protezione che ho attuato.

    Ho dedotto da questa frase che avresti una mezza intenzione di capire come si superano i tuoi accorgimenti per porre rimedio.

    31/10/2023 - zio3d ha scritto:


    Non ho capito il senso di questo intervento.

    Il senso era solo quello di evitarti perdite di tempo, tutto qui,

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    È palese che la sicurezza completa non esiste e dipende tutto da quale grado si vuole raggiungere.

    La sicurezza completa ESISTE. 

    Diciamo che NON ESISTE SE uno suppone di avere TUTTO il tempo dell'universo per far saltare una protezione. 
    MA SE ragionamo in termini di: per far saltare la protezione, TUTTI i computer esistenti sul PIANETA TERRA (dove per computer ci mettiamo anche cellulari, tablet, i computer a bordo delle lavastoviglie, ecc) fatti lavorare a 10GHz 24 ore al giorno, 7 giorni su 7, impiegnerebbero DIVERSI ANNI, va da se che PRATICAMENTE PARLANDO hai un buon grado di sicurezza.

    Per far “saltare” una chiave a 128 bit, servono 3.4*10^34 tentativi.
    Diciamo 10*10^9 computer (dieci MILIARDI di computer), tutti che lavorano a 10GHz (10*10^9 Hz), fanno 100*10^18=1*10^20 op/secondo.
    Servono 3.4*10^14 secondi e cioe': 10 MILIONI di anni. Anche se lo trova dopo la META" dei tentativi possibili, servono 5 MILIONI di anni.

    Personalmente, fra 5 MILIONI di anni staro' facendo qualcos'altro di piu' interessante ;-)

    Il problema “la sicurezza non esiste” SE non esiste perche' il ragazzetto smanettone delle superiori, con il pc di papa' di 10 anni fa, e qualche oretta di “relax” (o anche qualche DECINA di minuti, giusto perche' non ha voglia di darsi da fare), fa saltare la tua “protezione”, va da se che la tua protezione non serve a un gran che.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    31/10/2023 - migliorabile ha scritto:


    Personalmente, fra 5 MILIONI di anni staro' facendo qualcos'altro di piu' interessante ;-)

    Super !!! 

    pure io fra 5 milioni di anni ;-))

Devi accedere o registrarti per scrivere nel forum
28 risposte