If you mean malware as in something running on the computer, then the
entire issue is a moot point. If you mean a malicious site, then the
code is running with the limitations of browser content. In the second
case, the neither the database of 'sensitive fields' watched by the
browser, nor the filter used to detect sensitive data would be
accessible to content.
On 12-03-22 2:52 PM, Devdatta Akhawe wrote:
You would essentially make it easier to
malware to exfiltrate sensitive data: instead of writing the code to
detect when user is typing sensitive data, the malware could just look
at the db you use.
On 22 March 2012 14:05, Adam Barth <[email protected]> wrote:
The attacker will just watch for keydown events and exfiltrate the
data as the user types. Once you can detect a problem, the harm is
already done.
Adam
On Thu, Mar 22, 2012 at 1:51 PM, Yvan Boily <[email protected]> wrote:
I think I didn't explain it clearly.
We would use the field names in our analysis to nominate a set of fields
that are considered to contain sensitive data. The browser would acquire a
list of these fields through an update process, or ship with it. Through
normal usage the form history list will get filled out. When a form history
field is added that matches the list, the value of that field is added to
the filter to flag the data as sensitive. When a user enters data on a
site that matches the "sensitive" filter the user would be notified that
there is an untrustworthy site asking for potentially sensitive data.
Make more sense?
On 12-03-22 1:46 PM, Adam Barth wrote:
It seems like this wouldn't help in the case when your connection has
actually been compromised by an attacker because the attacker would just
avoid these sensitive names.
Adam
On Mar 22, 2012 1:27 PM, "Yvan Boily" <[email protected]> wrote:
Done.
I agree that the "sensitive" field list could be challenging to
produce. As for the "popular" site database, I would defer to other
existing lists of top sites (Alexa top site list comes to mind).
As for building the survey list we could probably use an add-on to
collect sanitized & anonymized data. Grabbing a list of the field names
that have matching values, and tracking a hit count for them would allow
us to see which fields are likely to be related; if we can gather just
the variable names and match count for a large set of users we should be
able to build a reasonable profile of what might constitute a
"sensitive" field.
On 12-03-22 1:14 PM, Sid Stamm wrote:
Hey Yvan,
Can I suggest bringing this up in dev.security? I think you'll get more
feedback there...
My take is that we could leverage this kind of info, but the set of
"sensitive" fields will change over time and I'm not too fond of
maintaining a database of (1) popular sites and (2) parameters that are
"sensitive" fields on those sites.
-Sid
On 03/22/2012 01:12 PM, Yvan Boily wrote:
Shane and I were having a quick chat about privacy and security UX and
we ended up chatting about an interesting concept to improve the user
experience when a 'bad' certificate is in use (expired, self-issued,
etc)
Firefox already maintains a database of auto-complete fields, and over
time a user will have a set of data that could potentially be used to
warn the user when they are sending 'sensitive' fields over insecure
channels.
By performing a survey of large usage payment sites we could identify
common parameter names that are saved on major sites, then flag fields
such as name, address, credit card number,etc, related fields as being
"personal" data.
If we did this, would it be feasible to analyze user input into DOM
elements and raise warnings if personal data is entered into documents
loaded from "bad" sites?
I haven't spent too much time thinking about it, but fields identified
as personal data from the survey could be fed into a bloom filter, and
then user input on "bad" sites could be checked against this filter to
determine if there is sensitive data in it. This could help users to
better understand the context of our somewhat unfriendly bad
certificate
error messages.
Thoughts?
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
