Hash: SHA1

Hanno Schlichting wrote:
> Tres Seaver wrote:
>> Hanno Schlichting wrote:
>>> Removed _filterPasswordFields hack, preventing keys with the exact
>>> key 'passw' to be filtered out in one place is just obscurity.
>> But you didn't de-obfuscate it, you ripped it out.  Now, the response
>> view shows credentials, which is a security hole.
> Unless I've misunderstood the code this particular "feature" only worked
> for input fields whose name contained "passw" in some form. It didn't
> check on input type being password.

The server side wouldn't know that:  the presence of such a field in the
request is completely independent of any form (e.g., cookies passed long
after logging in).

> As soon as the name is "auth" or anything else the check would fail. It
> also only did this filtering in the __str__ representation of the
> request, not the text method or any of the other methods to access the
> data. I call that security through obscurity.

We had a collector issue reported with a CVE because any view which
returned / included the request *showed the users credentials*,
including to people looking over his shoulder or at a conference beamer.

> Dealing with password input type fields is something for a form library
> but not a request object in my book.

The issue isn't about *form fields*:  it is about not exposing
credentials.  Many of the views which could provoke the hole don't use a
form library at all (nor should they be required to).

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Repoze-dev mailing list

Reply via email to