Re: [WEB SECURITY] Autocomplete attribute

[Andrew van der Stock <vanderaj@xxxxxxxxxx>]

--Apple-Mail-37-566281558
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

The controls you are talking about deal with state at rest, not state  
in transit. Key loggers deal with data that is in transit, not at  
rest. In the banking world, we would like more control over the data  
at rest, more particularly *enforced* controls not just hints. Data  
in transit, and particularly hacks like Jeremiah Grossman's zombie  
and other JS keyloggers are a real problem. They should not be able  
to run without explicit permission.

In your article, I have a huge problem with the idea that  
autocomplete is detrimental. It saves the millions of customers who  
use kiosks and shared PCs a great deal of embarrassment. Warts and  
all, autocomplete is better than NO autocomplete.

My major concern is complexity. For example, autocomplete="off" is  
simple and easy to understand. Setting four lines of XSL and then  
some more code after that which does *EXACTLY* the same thing as the  
three word version ... but may not be supported in any of the four  
browsers for some time will simply get no traction. Don't over- 
engineer the thing. That happened to SAML, and look where it is  
today. I do not vote for solution 3.

Data at rest controls, not just AUTOCOMPLETE. Let's think of the  
total solution, and not just about one corner case.

a) Form Data

We need some method of controlling cached state for form data, and  
for that to be enforced. All of the usual suspects are suggestions  
only. We rely upon hints like autocomplete to ensure that caching of  
private user data is off. We can't guarantee it on any browser today,  
but at least it's ignored. Realistically, we'll continue to use  
autocomplete=off as long as it's supported.

b) JS vars and cache

Often, you'll see code like this in "dynamic" pages:

var acctID = "1234567890";
var username = "user";

Although I actively work to ensure such code is gone, until the day  
it is, we would like a way to indicate to the browser pages such as  
these are mandatorily not cacheable, and to protect the DOM from  
outside inspection, particularly from IFRAMEs and from cross-domain  
access.

c) DOM control

There should be a model for DOM security access, and this should be  
extended to all Javascript. Such as,

// Before the next line, act as per current JS security model (ie  
none) for compatibility
document.perm.openassert();		// start permissions assertion
// By default, all permissions are now denied
document.perm.assert('xhr', true); 	// allow XML HTTP Request to run
document.perm.assert('eval', true); 	// allow eval (necessary evil  
for most XHR / JSON)
document.perm.assert('xd', true); 	// allow resources from other than  
the source domain, but need to specify them by using addsourcedomain();
document.perm.addsourcedomain('foo.com'); // allow another domain to  
be accessible by code
document.perm.endassert();		// no more permission entries will be  
obeyed after this line

This means that we can now allow "Server B" XHR by adding the  
"approved" second XHR to the list. This is better than ALL of the  
hacks I've seen (like Dojo.io's IFRAME hack, or the 1x1 Flash nasty).  
It also prevents keyloggers etc from communicating with their bad  
sites as they are not in the list. As long as we know that we have to  
be the first script to do the above steps, we can control that. So  
even if our code is faulty (and most scripts are in some way), then  
the damage is lessened. We might still be defaceable, but we will not  
suffer major leaks or create zombies for customers.

The four major areas I think JS needs a security model:

a) local storage without Flash hacks. It must be protected from other  
apps asking for the state

b) network access (by default, it shouldn't be able to, and only by  
explicit request to first party sites, and second / third party sites  
by absolute agreement from the first party site)

c) output to the rendered DOM needs to be safer. We need a safer way  
of doing this:

Old:
element.innerHTML = unsafeStr; // bad

New:
element.innerHTML.raw = rawHTML; // good - shows that the author  
knows that they are about to output raw HTML
element.innerHTML = unsafeStr; // will be HTML entitized by default

d) Access to local browser features which contain state, such as  
Bookmarks, etc

D) is special. Most browsers implement a range of prohibitions, such  
as not being able to create popups or  spam the bookmarks menu. These  
should be formalized, and a default set chosen (or at least a way for  
a JS to interrogate what is prohibited so they don't try to do X  
banned behavior). But a second part of this is about history and  
cache traces. The reason? URLs in many apps have embedded state.  
Again, not a great look for a "secure" application and less and less  
relevant as attackers learn how easy it is to use XHR to perform  
posts, but it does help on shared PCs and kiosks. We REALLY REALLY  
want to stop those vulnerable apps from caching anything.

I'd like to see something like:

document.hints.history = false; // turn off the history cache for  
this page
document.hints.history.basename = true; // allow the browser to cache  
the basename

document.hints.cache = false; // prevent any form of caching for this  
page
document.hints.cache.basename = true; // allow the browser to cache  
the page, but overwrite any page with the same basename and do not  
cache the URL

document.hints.js.cache = false; // prevent this page from caching  
any pre-initialized JS values

document.hints.bookmark = false; // prohibit the bookmarking of this  
page
document.hints.bookmark.basename = true; // when the user presses  
"bookmark", add only the basename

document.hints.referer = false; // prohibit the sending of a referrer  
header
document.hints.referer.basename = true; // allow the sending of just  
the basename (ie foo.php, no args)

Although it would be nice to be able to say something like:

document.hints.bookmark = "url"; // potentially only bookmark login  
pages, etc

It would be abused for sure. Goatse anyone?

thanks,
Andrew

On 07/08/2006, at 7:40 AM, Benjamin Hawkes-Lewis wrote:

> Many mainstream web user agents (Internet Explorer, Gecko-based  
> browsers, Konqueror, and WebKit-based browsers like Safari) support  
> a non-standard HTML "autocomplete" attribute on "form" and "input"  
> elements that can inhibit the storage and autofilling of sensitive  
> data in HTML forms. I'm drafting a proposal to create a namespace  
> to allow an attribute corresponding to the existing HTML  
> "autocomplete" attribute to be employed in web documents using XHTML.
>
> The basic reason is that, despite its known weaknesses, banks and  
> "experts" continue to demand it, and, despite the existence of  
> alternative techniques, it is commonly employed in JavaScript-based  
> web applications such as Google Suggest. I don't wish to see web  
> authors' inability to use their cherished "autocomplete" attribute  
> become yet another barrier to the adoption of newer W3C standards.
>
> However, I'm also interested in collecting considered security  
> opinion for and against "autocomplete", and compiling alternatives  
> (e.g. user education, nonces, one-shot passwords) for those  
> determined to make their websites more secure and keep users'  
> sensitive data safer.
>
> However, I am not by any means a security buff and I wanted to  
> consult people who are. It was suggested to me that I should post a  
> link to my draft to this list for discussion:
>
> http://wiki.mozilla.org/ 
> The_autocomplete_attribute_and_web_documents_using_XHTML
>
> I hope it's food for thought if nothing else.


--Apple-Mail-37-566281558
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF7TCCAqYw
ggIPoAMCAQICEHDpbeyPC2HmVmzK8H4pbTYwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDEyMTEyNTgzMFoXDTA3MDEyMTEyNTgz
MFowbDEWMBQGA1UEBBMNdmFuIGRlciBTdG9jazEPMA0GA1UEKhMGQW5kcmV3MR0wGwYDVQQDExRB
bmRyZXcgdmFuIGRlciBTdG9jazEiMCAGCSqGSIb3DQEJARYTdmFuZGVyYWpAZ3JlZWJvLm5ldDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1BjiSYD8iJZtifLladCqzbUh8tWD0iOHVLtjEG/9
ZRZvKE7htblQLGPTGvip4jqqtTRnaH/pPD4offdhKMYk0KNU7c3zRXXTbeHHeT+41uAcSkrwQtep
tTtZyr1C9jv0g+qCT0yZKjnTB6Q7bJ9mXXQwzC+2Ow5+w5TcbMyh5WkCAwEAAaNTMFEwDgYDVR0P
AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFIDAeBgNVHREEFzAVgRN2YW5kZXJhakBncmVlYm8u
bmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAhN6eYx2tYnW/LrbI+fS5oKlm69M9
cCTxl2gTZnaYc2G737mU7X7UTuDx8ALB2AkYjk/C3nbKJ/FbPbVEocZZahgWJcBzwL6lrtw4GwZ4
on/t+SFjDzsZN6ZqNr27GX/MrtxjCeBiNsi78yytkNIMXnwgqexN+0NMaDRfgUYJqnEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYICjzCCAosCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHDpbeyPC2HmVmzK8H4pbTYwCQYFKw4DAhoF
AKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODA3MTYx
MjIxWjAjBgkqhkiG9w0BCQQxFgQURVjZz63+cpbL4gw37roPLLPp5l8wgYUGCSsGAQQBgjcQBDF4
MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBw6W3sjwth5lZs
yvB+KW02MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAhBw6W3sjwth5lZsyvB+KW02MA0GCSqGSIb3DQEBAQUABIGAt+FDiL3b4YUb
/qhExWKtYqafWQy1kCuZ/35IR28YtbN8HqSRqCcuojFC2TNylsG2o4F18LoMer7LI9Gh6hVllf7d
XKnErMd5cyRyvF6bXC47l/vfCbW71sd5PGVQgMuEyuSlt5GNoQHSFAzADJQ6tFVsbZKJSamjBuzM
g8vGnQAAAAAAAAA=

--Apple-Mail-37-566281558--