Actually, this OWASP rule does not exclude access checking. But using temporary indirection keys has also effects on CSRF attacks.
2010/2/3 Thiago H. de Paula Figueiredo <thiag...@gmail.com> > On Tue, 02 Feb 2010 19:21:22 -0200, Howard Lewis Ship <hls...@gmail.com> > wrote: > > Intresting. So perhaps instead of encoding the primary key of a >> Hibernate entity directly, you'd instead maintain a lookup combining >> user id and object id, mapped to a random string. The random string >> would have to be in some kind of fast lookup table stored persistently >> (perhaps in the DB for sharing across the cluster, if any). >> > > Is the overhead worth it? As attackers car intercept the URLs, you still > need to check if the user can access that data. > > Anyway, that's the kind of idea that popped into my head ... what's >> your solution looking like? >> > > Not 100% related, but I created an ActivationContextEncoder<T> interface > and corresponding ActivationContextEncoderSource service. This way, I can > have the logic for generating the activation context value for a given type > separate from its ValudeEncoder logic. The above pseudo-id lookup logic > above could be implemented in a reusable way with ActivationContextEncoder. > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, software architect and developer, Ars Machina Tecnologia da > Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
