Pagina 5 di 8 primaprima ... 3 4 5 6 7 ... ultimoultimo
Visualizzazione dei risultati da 41 a 50 su 76

Discussione: Purga stringhe PHP

  1. #41
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da k.b Visualizza il messaggio
    Ometto i parametri username e password per semplicita':...
    mysql -e "DELETE FROM clienti WHERE cliente='franco'"
    E' proprio il delete (l'ho scritto prima) che mi fa paura: se dovesse capitare qualche "guaio" durante il restore andrei a "colpire" tutti i clienti, non solo il cliente "franco"
    A che pro? Il tuo applicativo avra' comunque tutte le password, e non penso tu dia gli accessi diretti al db ai clienti,
    Il che senso "avrà tutte le password"? L'utente mysql diciamo pluto con cui funziona il programma ha una sua password "mysql".
    "Sopra" ci sono le "password" degli utenti dell'applicazione, ma che poi alla fine vengono tutti eseguiti con i diritti dell'utente pluto di mysql.
    E l'utente "pluto" di mysql ha GRANT specifici per insert, select e update delle singole viste, singole tabelle e singoli campi.
    Nella tabella test, ad esempio, l'utente mysql pluto può solo fare UPDATE del campo X.
    Se il sito viene compromesso PHP\javascript\css avrà i diritti (al massimo) dell'utente pluto mysql, quindi non riuscirà, ad esempio, a cancellare o modificare i campi della tabella test che non siano X.
    L'utente pluto tra l'altro è legato a @localhost, non può accedere da altre macchine della rete locale

    In sostanza è una rete di sicurezza ("o difesa in profondità"+"minimi diritti") nell'ipotesi peggiore (=quella da considerare) di compromissione totale per iniezione di codice (non di query, proprio di codice).

    Poi che non sia da solo sufficiente lo sto imparando...

  2. #42
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da k.b Visualizza il messaggio
    I dati nel database non rappresentano nessun rischio, perche' da soli non fanno nulla, essendo - appunto - solo dati
    Prima o poi, però, verranno mostrati all'utente.
    E lì un rischio lo diventano, siamo d'accordo?

    Con un template engine, come dice il link che tu stesso citi
    non so cosa sia

  3. #43
    Quote Originariamente inviata da brancomat Visualizza il messaggio
    E' proprio il delete (l'ho scritto prima) che mi fa paura: se dovesse capitare qualche "guaio" durante il restore andrei a "colpire" tutti i clienti, non solo il cliente "franco"
    Se succede "qualche guaio" imprecisato, puo' succedere anche se usi tabelle separate no? Magari per sbaglio restori i dati di cliente_franco nella tabella cliente_mario.

    Quote Originariamente inviata da brancomat Visualizza il messaggio
    Il che senso "avrà tutte le password"? L'utente mysql diciamo pluto con cui funziona il programma ha una sua password "mysql".
    "Sopra" ci sono le "password" degli utenti dell'applicazione, ma che poi alla fine vengono tutti eseguiti con i diritti dell'utente pluto di mysql.
    E l'utente "pluto" di mysql ha GRANT specifici per insert, select e update delle singole viste, singole tabelle e singoli campi.
    Nella tabella test, ad esempio, l'utente mysql pluto può solo fare UPDATE del campo X.
    Se il sito viene compromesso PHP\javascript\css avrà i diritti (al massimo) dell'utente pluto mysql, quindi non riuscirà, ad esempio, a cancellare o modificare i campi della tabella test che non siano X.
    L'utente pluto tra l'altro è legato a @localhost, non può accedere da altre macchine della rete locale

    In sostanza è una rete di sicurezza ("o difesa in profondità"+"minimi diritti") nell'ipotesi peggiore (=quella da considerare) di compromissione totale per iniezione di codice (non di query, proprio di codice).

    Poi che non sia da solo sufficiente lo sto imparando...
    Non sono sicuro di aver capito bene quello che dici, pero' se il tuo applicativo - come immagino - e' in grado di gestire tutti i clienti, o usa una password con privilegi su tutti db e le tabelle, o da qualche parte in qualche file di configurazione ha i dati dei singoli utenti. Quindi se il sito viene compromesso, che differenza fa avere un file di config con una password o lo stesso file di config con un elenco di password per utenti distinti?

  4. #44
    Quote Originariamente inviata da brancomat Visualizza il messaggio
    Prima o poi, però, verranno mostrati all'utente.
    E lì un rischio lo diventano, siamo d'accordo?

    non so cosa sia
    Scusa, ma posti dei link come riferimento e non sai nemmeno di cosa parlano?

  5. #45
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da k.b Visualizza il messaggio
    Se succede "qualche guaio" imprecisato, puo' succedere anche se usi tabelle separate no? Magari per sbaglio restori i dati di cliente_franco nella tabella cliente_mario.
    Concordo pienamente (infatti me la faccio sotto quando devo fare i restore...)
    Non sono sicuro di aver capito bene quello che dici, pero' se il tuo applicativo - come immagino - e' in grado di gestire tutti i clienti, o usa una password con privilegi su tutti db e le tabelle, o da qualche parte in qualche file di configurazione ha i dati dei singoli utenti. Quindi se il sito viene compromesso, che differenza fa avere un file di config con una password o lo stesso file di config con un elenco di password per utenti distinti?
    Nel classico file db.php c'è il nome utente (pluto) e la password dell'utente mysql
    Nel database nella tabella degli utenti ci sono i vari utenti "applicativi" e le rispettive password.
    Durante la fase di login controllo ovviamente la tabella degli utenti applicativi (e lì, visto il problema drupal di cui ho capito il 20% volevo tagliar via update, select e solcavolo tanto per andar sul sicuro. anzi aggiungerò ; e -- esplicitamente)
    a quel punto, dopo essere loggato nell'applicazione, so il cliente (e quindi la tabella) e l'utente applicativo (e quindi la vista).
    L'utente pluto ha GRANT "mirati" per ogni vista (può fare insert sui campi x,y,z della tabella k, può fare solo select dei campi a,b della tabella u e così via).
    Se "buco" il login applicativo mi trovo ad operare con l'utente pluto di mysql (dò per scontato addirittura che uno si legga la password tranquillamente da db.php).
    Ma ora cosa posso fare? Quello che i GRANT mi permettono (il che è male, ma almeno non ci sono DELETE e gli UPDATE sono limitatissimi).
    Posso fare delle INSERT.
    Nel caso di "buco" posso ripristinare abbastanza facilmente cancellando le INSERT effettuate (o almeno questo è quello che vorrei fare)

    In pratica faccio le prove con un phpmyadmin, così da bypassare l'applicazione del tutto, dandola per compromessa, e cercando di capire cosa posso e non posso fare per limitare i danni.

    sì lo so sarà un approccio da principiante... ma cos'altro posso fare?

    Forse più chiaramente: ho una lista di un 200 righe di GRANT diverse per l'utente pluto, da usare come "ultima linea di difesa" per ridurre i danni al database.
    L'utente pluto NON è in grado di fare select,update e delete "come vuole" sulle tabelle.

    ANZI ove possibile ho usato viste NON modificabili per definizione (sono quelle con i join), in modo che anche se uno riuscisse a fare non so cosa (cioè operare davvero con phpmyadmin) non potrebbe cambiare i dati, perchè mysql non è in grado di farlo in ogni caso.
    Se tutto va male, ridurre i danni.
    Ultima modifica di brancomat; 14-09-2015 a 15:09

  6. #46
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da k.b Visualizza il messaggio
    Scusa, ma posti dei link come riferimento e non sai nemmeno di cosa parlano?
    Certo che non so tutto, se lo sapessi mica sarei un principiate che chiede aiuto in un forum, non trovi?

  7. #47
    Intanto ti faccio un paio di esempi dei risultati della tua funzione di purga, prendiamo queste stringhe:

    - il cliente presenta saltuarie alterazioni dell'umore
    - gli utenti per procedere devono premere il pulsante "like" nella pagina facebook
    - e' possibile alternare i colori per una migliore resa
    - dopo aver modificato i dati e' necessario cliccare su "UPDATE"

    diventano

    - il cliente presenta saltuarie zioni dell'umore
    - gli utenti per procedere devono premere il pulsante "" nella pagina facebook
    - e' possibile nare i colori per una migliore resa
    - dopo aver modificato i dati e' necessario cliccare su ""

    sicuro che sia il comportamento atteso?

  8. #48
    Quote Originariamente inviata da brancomat Visualizza il messaggio
    Certo che non so tutto, se lo sapessi mica sarei un principiate che chiede aiuto in un forum, non trovi?
    Ma ci mancherebbe, pero' se posti tu un link a supporto di quello che dici, dovresti almeno sapere di cosa parla, no?

    Inoltre se chiedi aiuto in un forum dovresti considerare la possibilita' che ci sia chi ne sa piu' di te, e che i consigli che ti da' sono validi. Invece tu sembri avere gia' deciso la tua strada e scarti ogni suggerimento.
    Ultima modifica di k.b; 14-09-2015 a 15:14

  9. #49
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da k.b Visualizza il messaggio
    Ma ci mancherebbe, pero' se posti tu un link a supporto di quello che dici, dovresti almeno sapere di cosa parla, no?
    Posto i link quando me li si chiede, vorrei precisarlo.

  10. #50
    Quote Originariamente inviata da brancomat Visualizza il messaggio
    Posto i link quando me li si chiede, vorrei precisarlo.
    Non mi e' chiara la precisazione, se uno ti chiede un link tu ne posti uno a caso senza leggerlo?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.