-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Repoze-dev mailing list