You make a great point about a zoo login, or allowing developers to do
SASL auth to LDAP from PHP. It's not obvious to the user that they may
be exposing this information on those systems.
I think it is possible to remove that information from view. We're
going to talk about this internally and figure out the best approach.
Thanks for pointing this out.
On 9/15/10 10:27 AM, Jacob Beauregard wrote:
> Benjamin Coddington wrote:
>> Hi Jacob,
>> You are absolutely correct that any user-submitted data used for logic
>> should always be sanitized; if not for security, than at least for
>> expected behavior.
> I honestly believe this would be less likely to happen than for
> someone's personal data to be compromised by leaving a shell open. I
> would still advocate it as a good practice though.
>> However, I do not think that LDAP filter injection presents a security
>> risk here at UVM since we do not expose password attributes, nor do we
>> store keys in LDAP.
> Particularly what I was thinking of is if a query is naively bound to an
> account, perhaps for a multi-user interface, then personal information
> related to that specific, bound account can be compromised using injection.
> SSN via PeopleSoft and SI data
> Personal contact info (home address, phone)
> Class schedule
> Also, for my entry, there's a hash in a field called userPassword.
>> Also, if the query is bound to a particular user's account, it may
>> only be so if that user has supplied their credential. Any information
>> available is already granted to that user, and an injection would not
>> gain additional information.
>> These security constraints exist in LDAP. We try to design UVM systems
>> to make sure that poor programming against LDAP or SQL..(etc) doesn't
>> jeopardize the information outside that programmer's domain.
>> I'd like very much to be shown where we are wrong about this. Feel
>> free to show us a functioning vulnerability. I'll be very pleased to
>> be shown to be wrong, and SAA will be pleased to improve the security
>> of our systems.
> I doubt many people would worry about their identity being stolen
> because they left a Zoo shell open because they're simply not aware of
> that possibility. The directory page gives you a big fat warning, though
> I don't know whether it's on every page that leads to accessing that
> information. Meanwhile, the Zoo shell doesn't give you any warning that
> people can grab a boatload of your personal information fast just by
> typing ldapsearch uid=`whoami`
>> My purpose here is not to discredit the seriousness of injection
>> attacks. Rather, I'd like to publicly state my own feeling about the
>> risk this presents to UVM's LDAP security -- that the risk is rather
>> small -- in order to combat the risk that FUD could creep into this
>> great IT community at UVM.
> Yes, very small for injection, but there are also other kinds of risk
> just by the nature of the data accessible to the user.