Applicazioni Web: memorizzare l'ID nei campi nascosti in modo sicuro?

Ho appena avuto questo pensiero, non so se sono lento però.Applicazioni Web: memorizzare l'ID nei campi nascosti in modo sicuro?

Di solito, memorizzo l'id dell'articolo che sto modificando in un campo nascosto. Poi nel backend (sto usando PHP/Zend Framework btw), ho capito per determinare quale elemento viene modificato. Ma poi ho pensato, in qualcosa di più sicuro, ad es. modifica profilo, l'utente può in qualche modo modificare un campo nascosto giusto? Quindi può modificare il profilo di qualcun altro. So per il profilo di modifica, posso ottenere l'id dalla variabile di sessione, ma cosa succede se ho qualcosa che mi richiede di memorizzare l'id da qualche parte?

Ho ottenuto ACL (Zend_Acl). Faccio questo. Fondamentalmente prendi l'id dai parametri della richiesta

$id = $req->getParam('id');

quindi controlla se l'utente che ha effettuato l'accesso è autorizzato a modificare l'elemento. Ma la cosa è che mi chiedo se l'url è qualcosa come /users/edit/1 dove 1 è l'id. Ma in qualche modo, il campo nascosto viene cambiato in 2, quale sarà il parametro della richiesta?

Come gestiresti questo?

fonte

2010-08-05 Jiew Meng

È necessario memorizzare qualche tipo di ID sul client, altrimenti come sapresti quale elemento modificare?
Questo non ti libera dal obbligatorio verifica sul server che l'utente corrente ha i privilegi per modificare/vedere l'elemento modificato.
Altrimenti, perché ti interesserebbe sapere come ha potuto modificare l'oggetto (sia con l'uso legittimo dello strumento web, sia modificando il campo nascosto/qualunque).

fonte

2010-08-05 13:07:28

Mi chiedo quale valore otterrò se il parametro id viene emesso sia in GET che in POST? quale sarà usato? –

è definito nel php.ini –

Beh, sicuramente questo dipenderà dal quale stai effettivamente chiamando. $ _POST o $ _GET. È quindi possibile scegliere quale è utilizzato e, per quanto ne sapevo, l'utilizzo di vars globali in questo modo non è una buona idea. – webnoob

La memorizzazione dell'ID nel valore nascosto non è del tutto sicura. Generalmente, memorizziamo l'ID nella variabile di sessione.

fonte

2010-08-05 13:04:22 ppshein

Non è necessario utilizzare la variabile di sessione. È semanticamente più solido (e più semplice) verificare che i dati di pubblicazione degli utenti dispongano dell'autorizzazione per modificare il record per il quale pubblicano i dati. – meagar

ah. meagar, hai detto quello che pensavo molto bene! avere 2 variabili che presumibilmente memorizzano lo stesso valore, è disordinato e forse incline agli errori –

L'OP sta chiedendo come determinare quale sia il record che si sta modificando senza che venga modificato, cioè come memorizzano l'ID per poi postare di nuovo sul server per interrogare il record con, quindi l'affermazione di ppshein è corretta. Si memorizzerebbe l'ID in una sessione in modo che non possa essere modificato e POI controllare le autorizzazioni per quel record. Non è possibile controllare le autorizzazioni se non si conosce il documento che si sta modificando. – webnoob

Non deve essere basato su nulla inviato dall'utente. Controllare sempre le autorizzazioni utente sul lato server. Un utente malintenzionato può preparare qualsiasi richiesta al server.

fonte

2010-08-05 13:07:14

come dice ppshein, la memorizzazione di ID sensibili in una variabile nascosta NON è sicura. Vuoi memorizzare una password in una var nascosta? È davvero facile anche per un hacker principiante ottenere questi dati.

È necessario assicurarsi che tutti i controlli di accesso siano applicati dal server.

nel tuo caso, è necessario assicurarsi che l'utente che ha effettuato l'accesso (quello sulla sessione) sia il proprietario del profilo che si sta modificando. O che l'utente che sta apportando le modifiche ha le autorizzazioni per modificare quel profilo (ad esempio è un amministratore)

fonte

2010-08-05 13:08:51 hvgotcodes

D'accordo con tutti i punti precedenti ma se davvero hai bisogno di memorizzare qualcosa clientide per qualsiasi motivo, puoi sempre criptare il dati e decifrati quando hai bisogno di usarlo, ma di nuovo, usare le sessioni sarebbe il modo migliore per affrontarle dato che non sono accessibili dal lato client.

fonte

2010-08-05 13:54:24 webnoob

che non cambia il fatto che l'utente può modificare il valore tho. –

Ovviamente è qui che entra in gioco la convalida sul lato server. Se un hacker ha modificato un valore in un ID crittografato, non sarebbe più decodificato correttamente e quindi sapresti che qualcosa non andava. – webnoob

quindi penso che la crittografia potrebbe non essere troppo utile in questo caso in quanto l'ID non è un segreto. crittografare o meno, avrò ancora bisogno di controllare se l'utente ha accesso alla risorsa richiesta. –

Applicazioni Web: memorizzare l'ID nei campi nascosti in modo sicuro?

risposta

Problemi correlati