You are correct that the site could exfiltrate after each keypress, but
malicious sites rarely ask for a single string of personal data;
typically a phishing or other malicious site will ask for multiple
somewhat related fields. In this case the user would receive a warning
before handing over their entire profile to a phishing site.
On 12-03-22 2:05 PM, Adam Barth 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
