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
