In any major server-side web framework, there is usually a mechanism to read HTML form input, e.g. in ASP, for an HTML element,
<input type="text" name="the_field" />, it is
Request.Form is a dictionary-type object where the values are parsed from the POST data into key/value pairs.
There are also various recommendations for only keeping passwords in memory for minimal time, up to and including using a mutable character array instead of an immutable string, pinning it so it cannot be paged or copied, and zeroing each array element when done (or using something like .NET's
SecureString, which does the same).
Given these, what mechanisms might exist for telling the web server that it needs to treat the posted form data as secure, and to do the pinning/clearing for, say, an HTML
<input type="password" /> field?
One might reasonably expect the browser to go the extra mile for password fields (although I expect they don't), because they can infer from the markup that such protections are necessary.
The transport layer is covered by HTTPS, and is not in question.
But nothing I have seen provides the web server with the semantics of post data, so it can choose to apply in-memory protections.
I've had a couple of ideas how such a thing might be handled in a web server if designed by scratch (note that I am not designing a web server from scratch!):
Apply in-memory protections to all requests: This seems like it might be the most straight-forward, but may negatively impact performance for pages that are not strictly sensitive but are served under SSL (e.g. all-SSL sites or 'My Account' pages that don't have 'New Password' fields). Might be configurable at an 'all requests' / 'HTTPS only'
Standardise an HTTP header that defines the fields to be protected: Mitigates the all-SSL issue, but would provide an obvious starting point for inspection (although I'm sure
txtUser=foo&txtPassword=baris already a good-enough indicator). Would take x years for the W3C to agree on a standard, and another y years for browsers to implement it.
Register secure post fields in server config (or through language integration): The server's request stream parser would be responsible for reading each post key, checking against the internal list and apply in-memory protections to the subsequent post value. Maybe even excluding it from the normal
Request.Formin lieu of a
Request.Passwordsobject with a fit-for-purpose data structure, or substituing the
Request.Formvalue with an object reference to the
So are there any web servers that already do this (or something like it), or allow you low-enough level access to implement these protections manually? I thought maybe IIS7's integrated pipeline, but I can't see an event that runs early enough.
Are such protections even necessary, or is this just a solution looking for a problem? If so, what makes this unnecessary where a desktop app's in-memory password handling is not?