Re: [ml] Re: Controllo Accesso

On 2/18/06, Felix <felix.t@xxxxxxxxxx> wrote:
> > [...]
> >> Che voi sappiate, esistono metodi che garantiscano al server che ogni
> >> richiesta che arriva è "genuina" (cioè che il client non ha in qualche
> >> modo manomesso lo stub e la richiesta arrivi _effettivamente_ da quello
> >> stub)?
> >
> > Senza conoscere i dettagli implementativi, un modo può essere cifrare lo stub assegnato al client in modo da renderne
> > difficile la manomissione.
> > ...
> > In entrambi i casi l'utente dovrebbe conoscere una chiave di cifratura per poter "manomettere" lo stub.
>
> In pratica lo stub è l'interfaccia che contiene i metodi che il client
> può invocare sulle risorse.. è un proxy che non fa altro che nascondere
> al client i dettagli di rete: il client invoca un metodo sullo stub il
> quale ingloba tutta la logica per invocare le operazioni sulle risorse
> da remoto (in realtà non si invocano operazioni direttamente sulle
> risorse ma si manda una richiesta a un gestore). Allora l'idea è: se lo
> stub fosse configurato dinamicamente in modo da contenere SOLO i metodi
> che quel client è autorizzato ad usare sulle risorse, potrebbe essere
> questa una metodologia valida dal punto di vista del controllo
> d'accesso?
se il meccanismo che usi nello stub per identificare univocamente i
client è valido si

> Un'idea per non aggirare lo stub potrebbe essere quella della
> cifratura come mi dicevi, ma in questo caso la chiave dovrebbe risiedere
> per forza anche lato client (se ricevessi uno stub cifrato come farei ad
> usarlo?) e non è impossibile scovarla (dump della memoria ad esempio).

se non c'è la possibilità che chi ha accesso ai client con più
privilegi possa fare leaking di informazioni verso chi usa i client
con meno privilegi (si copia il certificato e glielo da) potresti
firmare il traffico dei client con un certificato e legare al
certificato (e quindi alla firma e al traffico) cosa può e non può
fare un determinato client.

> Inoltre si rende necessaria anche una protezione della comunicazione tra
> stub e gestore delle risorse per evitare attacchi tipo MITM, o più
> semplicemente per evitare di riuscire a mandare una richiesta al gestore
>   attraverso un pacchetto di rete generato ad Hoc bypassando così lo stub.

potresti creare una topologia di rete ad hoc per evitare MITM o farli
comunicare su VPN o su SSL sempre con certificato

> In entrambi i casi, la chiave dovrebbe sempre risiedere anche presso la
> macchina del client che ha disposizione diversi modi per scovarla.
>
> Ciao & grazie,
> Felix :-)
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List
>