Method and apparatus to secure user confidential data from untrusted browser extensions

[0001] 1. Field of the Invention

[0002] The present invention relates to computer systems. More particularly, the present invention relates to computer security.

[0003] 2. Description of Related Art

[0004] Collection of user confidential data has been an ever increasing focus of computer malware. Spyware, rootkits, and malicious browser extensions, such as browser helper objects (BHOs), all attempt to gather user confidential data. For example, malicious drive-by downloads can install a silent browser helper object (BHO) that a user may not be aware of. Once installed, the silent BHO has full access to form posts and/or data object model (DOM) events in order to gather data entered in form fields by a user. With identity theft becoming a larger problem, these types of attacks are rising as other security vulnerabilities are increasingly secured.

[0005] In some systems, such as Windows Vista operating systems, in which the user is prompted for BHO installation, a user may permit a malicious BHO installation as the disclosed purpose may be completely different from that expected by a user or the disclosed purpose may be misunderstood by a user. Once installed, either explicitly by the user or silently by exploiting a vulnerability in the browser, the malicious BHO has full access to user confidential data.

[0006] In accordance with one embodiment of the invention, a method for securing user confidential data from untrusted browser extensions includes: installing a primary security browser extension first in a browser event notification order list utilized by a web browser; installing a secondary security browser extension last in the browser event notification order list; receiving a user data event at the primary security browser extension, the user data event including user confidential data; obfuscating the user confidential data in the user data event, the obfuscating replacing the user confidential data with obfuscated data in the user data event; releasing the user data event including the obfuscated data for processing by a subsequent browser extension next in the browser event notification order list; receiving the user data event including the obfuscated data at the secondary security browser extension; de-obfuscating the obfuscated data in the user data event, the de-obfuscating replacing the obfuscated data with the user confidential data in the user data event; and releasing the user data event including the user confidential data for further processing.

[0007] In some embodiments, prior to obfuscation of the user confidential data in the user data event, enumerated browser extensions and associated browser extension threads are disabled from receiving selected browser events, such as data object model (DOM) state events; and then re-enabled after de-obfuscation of the obfuscated data.

[0008] Embodiments described herein are best understood by reference to the following detailed description when read in conjunction with the accompanying drawings.

[0017] Common reference numerals are used through the drawings and detailed description to indicate like elements.

[0018] Typically, most web browsers include one or more browser support extension mechanisms. For example, Windows Internet Explorer (IE) utilizes browser helper object (BHOs), and Firefox utilizes extensions or plug-ins. These browser extensions may or may not have a user interface (UI). Many browser extensions do not utilize a UI and are meant to offer added services to the content being rendered in the browser, like annotating the content or links.

[0019] Conventionally, a browser extension is installed on a computer system and registers with the operating system for loading onto a web browser and to receive browser events, also termed browser event notifications. For example, both Windows Explorer and Internet Explorer (IE) use the same registry for registering browser extensions and load the browser extensions from the registry. A parameter in the registry entry of a browser extension can designate the particular web browser. For example, a parameter in the registry entry of a browser extension can designate not for use by Explorer, e.g., Explorer=1, then that browser extension would not be loaded inside Windows Explorer, but the browser extension would be loaded in Internet Explorer. As another example, Firefox utilizes a configuration file for registering browser extensions, and Firefox loads the browser extensions from the configuration file.

[0020] As a user interacts with a web page, such as by entering data in form fields, browser events associated with the web page are generated, such as a begin navigate event, a post data event, complete navigate event, a key stroke event, a data submission in a form field event, as well as many other well documented browser events. Also, typically, when a user navigates to a web page, the web browser maintains the entire content of the page as a data object model (DOM) object. As a user enters data into the web page, the DOM object is updated with the user data resulting in DOM state events.

[0021] The web browser permits each registered browser extension see each event, and the event is sent down to each browser extension in the event notification order. Typically, a browser event associated with user confidential data includes the actual user data as well as a DOM object pointer that points to the memory location of the DOM object maintaining the content of the web page.

[0022] The web browser passes an event to registered browser extensions in accordance with an event notification order. In Internet Explorer, the registered browser extensions receive browser events in the order in which the browser extensions are loaded; and the order in which the browser extensions are loaded is in ascending order of the browser extensions globally unique identifiers (GUIDs). In Firefox, the order in which the browser extensions receive browser events is the order in which the browser extensions appear in the configuration file, which is the order in which the browser extensions were loaded into the browser.

[0023] As the web browser is becoming the most frequently used application on a personal computer, and as more user confidential data is being entered through the web browser, such as banking and shopping transactions, malicious attacks are being increasingly focused on the web browser. There are an increasing number of malicious exploits that can install malicious code so that a malicious browser extension persists on a target computer system. For a malicious browser extension to persist on a computer system, typically a malicious file is created so that the malicious extension persists on disk, and a registry entry associated with the malicious browser extension is created to notify the web browser that a browser extension has been registered with the operating system.

[0024] Thus, for example, if a user enters user confidential data into a form field of a web page, and a malicious browser extension is present on the web browser, when the malicious browser extension receives an event, the malicious browser extension potentially has the ability to access and modify the content of the event. For example, the malicious browser can copy or modify the user confidential data, such as a bank account routing number in the post data parameter of the event, resulting in compromise of the user confidential data.

[0025] Embodiments in accordance with the invention secure user confidential data in user data events from compromise by untrusted web browser extensions, such as malicious web browser extensions. Referring now generally to FIG. 2, in one embodiment, a security application is installed on a host computer system which installs two security browser extensions: a primary security browser extension that is registered to receive browser events first in the browser event notification order (operation 204); and a secondary security browser extension that is registered to receive browser events last in the browser event notification order (operation 206).

[0026] When a browser event is received at the primary security browser extension (operation 208), a determination is made whether the event is a user data event, e.g., includes user confidential data (check operation 210). In one embodiment, if the event is not determined to be a user data event (“NO”), the event is released for further processing (operation 226), such as to the next browser extension in the event notification order.

[0027] Alternatively, if the event is determined to be a user data event (“YES”), the user confidential data in the event is obfuscated by the primary security browser extension (operation 216) and released to the next browser extension in accordance with the event notification order. The event is then passed in accordance with the event notification order, until it is received by the secondary security browser extension (operation 220). The secondary security browser extension de-obfuscates the obfuscated data to restore the user confidential data in the event (operation 222) and releases the event for further processing (operation 226), for example, for sending by the web browser to a web site.

[0028] In some embodiments, optionally, upon receipt and determination of a user data event by the primary security browser extension, enumerated browser extensions in the browser event notification order and associated browser extension threads are disabled from receiving selected event notifications, such as data object model (DOM) state events (operation 214). In these embodiments, after receipt of the user data event at the secondary security browser extension, the disabled enumerated browser extensions and associated browser threads are re-enabled (operation 224).

[0029] Referring now to FIG. 1, more particularly, FIG. 1 is a diagram of a computer system 100 including a security application 106 for securing user confidential data from untrusted browser extensions installed on and executing on a host computer system 102, e.g., a first computer system, in accordance with one embodiment of the present invention. Host computer system 102, sometimes called a user device, typically includes a central processing unit (CPU) 108, hereinafter processor 108, an input output (I/O) interface 110, and a memory 112, including an operating system 104 and a web browser 114. In one embodiment, operating system 104 and/or web browser 114 maintains an event notification order list 144, such as a browser extension registry or browser extension configuration file, that provides the order in which registered browser extensions receive events from web browser 114.

[0030] In one embodiment, memory 112 includes security application 106. In one embodiment, security application 106 installs and registers two security browser extensions in the event notification order of web browser 114: a primary security browser extension 140 that is registered to receive browser events first in the browser event notification order; and a secondary security browser extension 142 that is registered to receive browser events last in the browser event notification order. In one embodiment, primary security browser extension 140 and secondary security browser extension 142 are browser helper objects (BHOs).

[0031] In one embodiment, memory 112 can further include a security service 116 which provides cryptographic keys for use in obfuscating user confidential data by primary security browser extension 140 and for de-obfuscating obfuscated user confidential data by secondary security browser extension 142. In some embodiments, security service 116 securely stores user confidential data. In one embodiment, security service 116 communicates with primary security browser extension 140 and secondary security extension 142 over a secure communication channel (not shown).

[0032] In one embodiment, web browser 114 renders web page content and receives user data, such as user confidential data, input into rendered form fields for sending to web page servers, such as a computer system 138. In one embodiment, web browser 114 also maintains DOM objects associated with rendered web pages.

[0033] In the present embodiment, web browser 114 is any one of a number of conventional web browser applications, such as Windows Internet Explorer, or Firefox. Web browser 114 utilizes browser extensions installed on and registered on host computer system 102. Herein a browser extension is an application installed on and registered on host computer system 102, such as a browser helper object (BHO), browser plug-in, or other browser extension that interacts with web browser 114.

[0034] As earlier described, web browser 114 sends browser events, i.e., herein also simply termed events, to registered browser extensions in accordance with an event notification order list, such as in accordance with a browser extension registry, browser extension load list, browser extension configuration file, or other listing utilized by web browser 114 for determining the event notification order of registered browser extensions.

[0035] For example, in the web browser Internet Explorer, the list of loaded browser extensions, i.e., the browser registry, is managed inside IEFRAME.dll. This registry is enumerated via a function at 0x7e28c265 for ieframe.dll version 7.0.5730.11. Internet Explorer loads browsers extensions, such as browser helper objects (BHOs), in alphabetic ascending order of the GUIDs of the browser extensions and passes events to the browser extensions in the order of load.

[0036] Typically when web browser 114 receives a user input, such as submission of user confidential data, web browser 114 generates a browser event that is passed to each of the browser extensions in the order of the browser event notification order, e.g., browser event notification order list 144. In this way, each browser extension can perform its associated processes, if any, on the event. As earlier noted, should a malicious browser extension be installed and registered on web browser 114, user confidential data present in an event, if any, is subject to compromise by the malicious browser extension when it receives the event.

[0037] Host computer system 102 may further include standard devices like a keyboard 118, a mouse 120, a printer 122, and a display device 124, as well as, one or more standard input/output (I/O) devices 126, such as a compact disk (CD) or DVD drive, floppy disk drive, or other digital or waveform port for inputting data to and outputting data from host computer system 102. In one embodiment, security application 106 is loaded into host computer system 102 via I/O device 126, such as from a CD, DVD or floppy disk containing security application 106.

[0038] In one embodiment, host computer system 102 is coupled to external systems by a network 128, such as the Internet. For example, host computer system 102 is coupled to a server computer system 130 and computer system 138 via network 128. Server computer system 130 typically includes a processor 132, a memory 134, and an I/O interface 136.

[0039] In one embodiment, computer system 138 can be a web content server hosting a web page. In one embodiment, computer system 138 is similar to host computer system 102 and/or server computer system 130, for example, includes a central processing unit, an input output (I/O) interface, and a memory. Computer system 138 may further include standard devices like a keyboard, a mouse, a printer, a display device and an I/O device(s). The various hardware components of computer system 138 are not illustrated to avoid detracting from the principles of the invention.

[0040] Network 128 can be any network or network system that is of interest to a user. In various embodiments, I/O interface 110 and I/O interface 136 include analog modems, digital modems, or a network interface card. The particular type of and configuration of host computer system 102, computer system 138, and server computer system 130 are not essential to this embodiment of the present invention.

[0041] Herein, in one embodiment, malicious code is defined as any computer program, module, set of modules, or code that enters a computer system environment without an authorized user's knowledge and/or without an authorized user's consent. A malicious browser extension, such as a malicious BHO, that can access user private data in a browser event is one example of malicious code. Further herein, malicious activity is any activity resulting from the execution of malicious code.

[0042] FIGS. 2A and 2B illustrate a flow diagram of a method 200 for securing user confidential data from untrusted browser extensions in accordance with one embodiment of the invention. In the present description, web browser 114 is described with reference to Internet Explorer. The examples provided herein are for clarity of description and are not intended to limit the present invention to Internet Explorer, and the invention is applicable to other web browsers.

[0043] Referring now to FIGS. 1 and 2A together, in one embodiment, execution of security application 106 by processor 108 results in the operations of method 200 as described below. Initially, security application 106 is installed on host computer system 102 and method 200 is entered at an ENTER operation 202 with processing transitioning to an INSTALL PRIMARY SECURITY BROWSER EXTENSION operation 204.

[0044] In INSTALL PRIMARY SECURITY BROWSER EXTENSION operation 204, security application 106 installs and registers a primary security browser extension, herein also termed primary security extension 140, on host computer system 102. As earlier described, Internet Explorer loads browser helper objects in alphabetic ascending order of the globally unique identifiers (GUIDs) and passes events in the order of load.

[0045] In one embodiment, security application 106 utilizes a GUID, i.e., a primary GUID, for primary security extension 140 so that primary security extension 140 is placed first in the event notification order to receive a browser event from web browser 114. In alternate embodiments, other techniques, such as patching the event notification order list, e.g., the load order sequence, can be used to place primary security extension 140 first in the event notification order sequence.

[0046] Registering as the first browser helper object (BHO) in the event notification order list ensures that the primary security extension 140 initially receives a user data event prior to other registered browser extensions. From INSTALL PRIMARY SECURITY BROWSER EXTENSION operation 204, processing transitions to an INSTALL SECONDARY SECURITY BROWSER EXTENSION operation 206.

[0047] In INSTALL SECONDARY SECURITY BROWSER EXTENSION operation 206, security application 106 installs and registers a secondary security browser extension, herein also termed secondary security extension 142, on host computer system 102. As earlier described, Internet Explorer loads browser helper objects in alphabetic ascending order of the globally unique identifiers (GUIDs) and passes events in the order of load.

[0048] In one embodiment, security application 106 utilizes a GUID, i.e., a secondary GUID, for secondary security extension 142 so that secondary security extension 142 is placed last in the event notification order to receive a browser event from web browser 114. As earlier described, in alternate embodiments, other techniques, such as patching the event notification order list, e.g., the load order sequence, can be used to place secondary security extension 142 last in the event notification order sequence.

[0049] Registering as both the first browser extension (operation 204) and as the last browser extension in event notification order list 144 ensures that security application 106 itself is not bypassed in event notifications, for example by a malicious browser extension, e.g., a malicious BHO.

[0050] In some embodiments, security application 106 evaluates the registered browser extensions for exempted browser extensions that are allowed to access the user confidential data in an event, such as other security browser extensions. The exempted browser extensions are then reordered in the event notification order so that they are subsequent to secondary security browser extension 142.

[0051] In one embodiment, security application 106 compares each registered browser extension against a white list of exempted browser extension entries each identifying an associated exempted browser extension. When a registered browser extension matches an entry in the white list, the associated browser extension is exempted; otherwise, the registered browser extension is not exempted. Examples of registering the primary security extension 140 and secondary security extension 142 are later further described herein with reference to FIGS. 3A, 3B, and 3C. From INSTALL SECONDARY SECURITY BROWSER EXTENSION operation 206, processing waits until receipt of a browser event from web browser 114, with processing transitioning to a RECEIVE EVENT AT PRIMARY SECURITY BROWSER EXTENSION operation 208.

[0052] In RECEIVE EVENT AT PRIMARY SECURITY BROWSER EXTENSION operation 208, a browser event is received at primary security extension 140 from web browser 114. From RECEIVE EVENT AT PRIMARY SECURITY BROWSER EXTENSION operation 208, processing transitions to a USER DATA EVENT check operation 210.

[0053] In USER DATA EVENT check operation 210, primary security extension 140 determines whether the event is a user data event. In one embodiment, a user data event is any event that includes user confidential data. In one embodiment, user confidential data is any data, data type, or data pattern that is determined for encryption, replacement, or obfuscation in accordance with an embodiment of the invention.

[0054] In one embodiment, the transaction type of the event is evaluated to determine if it matches a listing of transactions types associated with user confidential data. If the transaction type matches a listed transaction type, the event is determined to be a user data event.

[0055] In one embodiment, data in a post data parameter of the event is evaluated to determine whether or not the event is a user data event. For example, in one embodiment, data in a post data parameter of the event is evaluated for a data pattern indicative of user confidential data, such as a credit card number, a bank account number, a social security number, a user name, a user password, or other user confidential data indicator. When the data pattern matches a user confidential data pattern, the event is determined to be a user data event.

[0056] In one embodiment, the event is identified as a user data event because the primary security browser extension 140 has the user confidential data to provide a form filling functionality in the event. Upon a determination that the event is not a user data event (“NO”), from USER DATA EVENT check operation 210, processing transitions to a RELEASE EVENT TO FURTHER PROCESSING operation 226 (FIG. 2B), where the event is released to further processing, such as release to a next browser extension in the browser event notification order list 144, or to exempted browser extensions. From RELEASE EVENT TO FURTHER PROCESSING operation 226 (FIG. 2B), processing transitions to an EXIT operation 228, with processing exiting method 200, or optionally returning to operation 208 (FIG. 2A) on receipt of a next event at primary security extension 140.

[0057] Referring back again to USER DATA EVENT check operation 210, alternatively, upon a determination that the event is a user data event (“YES”), processing transitions from USER DATA EVENT check operation 210 to an optional DISABLE ENUMERATED BROWSER EXTENSIONS AND EXTENSION THREADS operation 214, or proceeds directly to an OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 216.

[0058] In optional DISABLE ENUMERATED BROWSER EXTENSIONS AND EXTENSION THREADS operation 214, in one embodiment, primary security extension 140 disables loaded browser extensions and associated extension threads from receiving selected browser notifications. In particular in one embodiment, loaded browser extensions and associated extension threads are disabled from receiving DOM state change event notifications as data is being entered in form fields.

[0059] In one embodiment, security application 106 enumerates and identifies the loaded browser extensions. For example, as earlier described, the list of loaded browser extensions is managed inside IEFRAME.dll for Internet Explorer. This list is enumerated via a function at 0x7e28c265 for ieframe.dll version 7.0.5730.11. In one embodiment, security application 106 patches the enumeration routine, for example using hooking/interception techniques, to prevent DOM related events from being sent to the enumerated browser extensions, i.e., those browser extensions other than primary security extension 140 and secondary security extension 142.

[0060] Although a loaded browser extension may not be receiving DOM state change event notifications, this does not prevent the loaded browser extension, such as a malicious browser extension, from having a process thread that polls for browser or DOM state events and performs the same state extraction task, e.g., extraction of user confidential data, if the thread identifies form fields.

[0061] Thus, in one embodiment, security application 106 enumerates process threads whose ThreadStartAddress, i.e., the address of the thread function, belongs to a disabled browser extension address space. Once such threads are identified, these threads are suspended for the duration of the event transaction. From optional DISABLE ENUMERATED BROWSER EXTENSIONS AND EXTENSION THREADS operation 214, processing transitions to an OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 216.

[0062] In OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 216, user confidential data present in the event is obfuscated. In one embodiment, user confidential data present in the post data parameter of the event is obfuscated. In some embodiments, alternatively or additionally, a DOM pointer in the event is obfuscated, for example, by replacing the actual DOM pointer with a dummy DOM pointer, i.e., a false DOM pointer. In one embodiment, the actual DOM pointer is stored in a local secure memory location.

[0063] Thus, for example, in one embodiment, primary security extension 140 requests and obtains a security key from security service 116, for example over a secure communication channel, and utilizes the security key to encrypt the user confidential data, thereby replacing user confidential data with encrypted data. In some embodiments, primary security extension 140 identifies itself to security service 116 when requesting the security key. In some embodiments, security service 116 generates a unique new security key when primary security extension 140 requests the security key.

[0064] As another example, primary security extension 140 uses a resident obfuscation algorithm, such as an XOR algorithm, to obfuscate the user confidential data in the event, thereby replacing the user confidential data with obfuscated data. In still another embodiment, primary security extension 140 stores the user confidential data with security service 116, or in a local secure memory location, and replaces the user confidential data with dummy data.

[0065] Examples of obfuscation of user confidential data and DOM pointers is later further described herein with reference to FIGS. 4A, 4B, and 4C. From OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 216, processing transitions to a RELEASE EVENT TO SUBSEQUENT BROWSER EXTENSION operation 218.

[0066] In RELEASE EVENT TO SUBSEQUENT BROWSER EXTENSION operation 218, the event including the obfuscated user confidential data, herein also termed obfuscated data, is released to the next browser extension in event notification order list 144. Thus, at this point the subsequent browser extension, unless disabled in operation 214, will receive the event but will not have access to the user confidential data as the user confidential data was obfuscated in operation 216. From RELEASE EVENT TO SUBSEQUENT BROWSER EXTENSION operation 218, processing transitions to a RECEIVE EVENT AT SECONDARY SECURITY BROWSER EXTENSION operation 220.

[0067] Referring now to FIG. 2B, in RECEIVE EVENT AT SECONDARY SECURITY BROWSER EXTENSION operation 220, the event including the obfuscated data is received at secondary security extension 142. From RECEIVE EVENT AT SECONDARY SECURITY EXTENSION operation 220, processing transitions to a DE-OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 222.

[0068] In DE-OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 222, the user confidential data obfuscated in operation 216 is restored. For example, if the actual user confidential data in the post data parameter of the event was obfuscated, the original user confidential data is restored in the post data parameter in accordance with the obfuscation method.

[0069] Further, if the DOM object was replaced with a dummy DOM object in operation 216, the original DOM object is restored. For example, in one embodiment, the actual DOM pointer is obtained by secondary security extension 142 from the local secure memory location storing the actual DOM pointer, and the dummy DOM pointer in the event is replaced with the retrieved DOM pointer.

[0070] As another example, in one embodiment, if the user confidential data was encrypted by primary security extension 140 in accordance with a security key obtained from security service 116, secondary security extension 142 obtains the key from security service 116 and utilizes the key to decrypt the encrypted data and obtain the user confidential data. The encrypted data is then replaced with the user confidential data. In some embodiments, secondary security extension 142 identifies itself to security service 116 when requesting the security key.

[0071] As another example, if primary security extension 140 used a resident obfuscation algorithm, such as an XOR algorithm, to obfuscate the user confidential data in the event, secondary security extension 142, utilizes the XOR algorithm to de-obfuscate the obfuscated data and restore the user confidential data. In still another embodiment, if primary security extension 140, in operation 216, stored the user confidential data with security service 116, or in a local secure memory location, and replaced the user confidential data with dummy data, secondary security extension 142 would obtain the stored user confidential data from security service 116, or from the local secure memory location, and replace the dummy data with the user confidential data. From DE-OBFUSCATE USER CONFIDENTIAL DATA IN EVENT operation 222, processing transitions to an optional RE-ENABLE DISABLED ENUMERATED EXTENSIONS AND EXTENSION THREADS operation 224, where optional operation 214 was earlier performed, or transitions directly to RELEASE EVENT FOR FURTHER PROCESSING operation 226.

[0072] In optional RE-ENABLE DISABLED ENUMERATED EXTENSIONS AND EXTENSION THREADS operation 224, extensions and extension threads disabled in operation 214, if any, are re-enabled. Thus, in embodiments in which operation 214 was performed, the actions taken to disable enumerated extensions and extension threads are remediated such that the disabled extensions and extension threads are re-enabled. In embodiments in which optional operation 214 was not performed, this operation is not performed. From optional RE-ENABLE DISABLED ENUMERATED EXTENSIONS AND EXTENSION THREADS operation 224, processing transitions to RELEASE EVENT FOR FURTHER PROCESSING operation 226.

[0073] In RELEASE EVENT FOR FURTHER PROCESSING OPERATION 226, the event is released for further processing. For example, from operation 224, or directly from operation 222, the event now including the user confidential data is released for further processing, for example, by the web browser or as another example, by any remaining exempted browser extensions following secondary security extension 142. From RELEASE EVENT FOR FURTHER PROCESSING operation 226, processing transitions to EXIT operation 228, with processing exiting method 200, or optionally returning to operation 208 on receipt of a next event.

[0074] Referring now to FIGS. 3A, 3B, and 3C, FIG. 3A illustrates a block diagram representation of a browser event notification order list 144A of web browser 114 prior to installation of primary security extension 140 and secondary security extension 142. Typically a browser event, shown as event 302 is passed to each registered BHO in the order of browser event notification order list 144A.

[0075] Thus, in FIG. 3A, event 302 would be initially received by BHO A, which is first, i.e., “1”, in the event notification order, then to BHO B, and then subsequently through to BHO G which is last, i.e., “7”, in the event notification order. Assuming for example, that BHO D is a malicious web browser extension, BHO D would receive the event and have access to user confidential data present in the event.

[0076] Referring now to FIG. 3B, FIG. 3B illustrates a block diagram representation of the browser event notification order list 144E after installation of primary security extension 140 and secondary security extension 142 in accordance with one embodiment of the invention. In the present embodiment, event 302 is now initially received by primary security extension 140, shown as PSBHO 304A, which is now first, i.e., “1”, in the event notification order, then to BHO A, which is now second in the event notification order, and then subsequently through to secondary security extension 142, shown as SSBHO 306A, which is now last, i.e., “9”, in the event notification order.

[0077] As PSBHO 304A obfuscates the user confidential data in event 302 (operation 216 (FIG. 2A)), malicious BHO D receives the event, but can access only obfuscated data. Thus, the user confidential data has been secured from compromise by malicious BHO D. SSBHO 306A de-obfuscates the obfuscated data in the event (operation 222 (FIG. 2B)), thus restoring the user confidential data in the event prior to further processing.

[0078] Referring now to FIG. 3C, FIG. 3C illustrates a block diagram representation of the browser event notification order list 144C after installation of primary security extension 140 and secondary security extension 142 in which exempted browser extensions are present in accordance with embodiment of the invention. In the present embodiment, assume browser extensions BHO B and BHO G are exempted browser extensions, herein collectively illustrated as exempted browser extensions 308.

[0079] When secondary security extension 142, i.e., SSBHO 306B is installed, BHO B and BHO G, i.e., exempted browser extensions 308, are placed after secondary security BHO 142 in the event notification order list 144C. Thus, SSBHO 306B is still “last” in the event notification order relative to un-exempted browser extensions, e.g., BHO A, BHO C, BHO D, BHO E, and BHO F. However, exempted browser extensions 308 are present subsequent to SSBHO 306B in browser event notification order list 144C. Thus, FIG. 3C illustrates that “last” can be further defined as last in the event notification order relative to non-exempt browser extensions where exempted browser extensions, e.g., exempted browser extensions 308, are present.

[0080] Accordingly, in FIG. 3C, event 302 is initially received by primary security extension 140, shown as PSBHO 304A, which is first in the event notification order, then passed to BHO A, which is now second, and then subsequently through to secondary security extension 142, shown as SSBHO 306B, which is now last relative to the non-exempt browser extensions 308. Thus, as shown in FIG. 3C, the user confidential data is secured against compromise by malicious BHO D, as the user confidential data is obfuscated by PSBHO 304A, but the user confidential data is made available to exempted browser extensions 308 by placing exempted browser extensions 308 subsequent to SSBHO 306B in browser event notification order list 144C.

[0081] Referring now to FIGS. 4A, 4B, and 4C, FIG. 4A illustrates a block diagram representation of an event 402A including user confidential data 406 and a data object model (DOM) pointer 410 prior to obfuscation of the user confidential data and/or replacement of the data object model (DOM) pointer. As illustrated, user confidential data 406 is present in a post data parameter 404A of event 402A, as well as a DOM pointer 410. Thus, should event 402A be received by a malicious browser extension, user confidential data 406 and DOM pointer 410 would be accessible by the malicious browser extension and subject to compromise.

[0082] FIG. 4B illustrates a block diagram representation of an event 402B in which the user confidential data and the DOM pointer of FIG. 4A are obfuscated/replaced in accordance with one embodiment of the invention. As illustrated, following obfuscation of user confidential data 406 (FIG. 4A) by primary security extension 140 in operation 216 (FIG. 2A), post data parameter 404B now includes obfuscated data 408. Further, in some embodiments, in operation 216, DOM pointer 410 (FIG. 4A) is replaced with dummy DOM pointer 412. Thus, following obfuscation in operation 216 (FIG. 2A), the user confidential data originally present in event 402A (FIG. 4A) is secured against compromise by browser extensions subsequent to primary security extension 140, unless exempted as earlier described.

[0083] FIG. 4C illustrates a block diagram representation of an event 402C in which user confidential data 406 and DOM pointer 410 of FIG. 4A are restored in accordance with one embodiment of the invention. As illustrated, following de-obfuscation by secondary security extension 142 in operation 222 (FIG. 2B), post data parameter 404C now includes restored user confidential data 406 and dummy DOM pointer 412 (FIG. 4B) is replaced with restored DOM pointer 410. Thus, following de-obfuscation in operation 222 (FIG. 2B), the user confidential data and the DOM object originally present in event 402A (FIG. 4A) is restored to the event for further processing, such as by subsequent exempted browser extensions in the event notification order list, and/or the web browser, such as for sending to a web server.

[0084] Referring again to FIG. 1, security application 106 is in memory 112. As used herein, a computer memory refers to a volatile memory, a non-volatile memory, or a combination of the two. Although security application 106 is referred to as an application, this is illustrative only. Security application 106 should be capable of being called from an application or the operating system. In one embodiment, an application is generally defined to be any executable code. Moreover, those of skill in the art will understand that when it is said that an application or an operation takes some action, the action is the result of executing one or more instructions by a processor.

[0085] While embodiments in accordance with the present invention have been described for a host computer system configuration, an embodiment of the present invention may be carried out using any suitable means and/or hardware configuration involving a personal computer, a workstation, a portable device, or a network of computer devices. Other network configurations other than host computer system configurations, e.g., client-server, peer-to-peer, web-based, intranet, internet network configurations, are used in other embodiments.

[0086] Herein, a computer program product comprises a medium configured to store or transport computer readable code in accordance with an embodiment of the present invention. Some examples of computer program products are CD-ROM discs, DVDs, ROM cards, floppy discs, magnetic tapes, computer hard drives, servers on a network and signals transmitted over a network representing computer readable code. In another embodiment, a computer program product comprises a tangible storage medium configured to store computer readable code including CD-ROM discs, DVDs, ROM cards, floppy discs, magnetic tapes, computer hard drives and servers on a network.

[0087] As illustrated in FIG. 1, this medium may belong to the computer system itself. However, the medium also may be removed from the computer system. For example, security application 106 may be stored in memory 134 that is physically located in a location different from processor 108. Processor 108 should be coupled to the memory 134. This could be accomplished in a client-server system, or alternatively via a connection to another computer via modems and analog lines, or digital interfaces and a digital carrier line.

[0088] More specifically, in one embodiment, host computer system 102 and/or server computer system 130 are a portable computer, a workstation, a two-way pager, a cellular telephone, a digital wireless telephone, a personal digital assistant, a server computer, an Internet appliance, or any other device that includes components that can execute the functionality in accordance with at least one of the embodiments as described herein. Similarly, in another embodiment, host computer system 102 and/or server computer system 130 are comprised of multiple different computers, wireless devices, cellular telephones, digital telephones, two-way pagers, or personal digital assistants, server computers, or any desired combination of these devices that are interconnected to perform, the methods as described herein.

[0089] In view of this disclosure, the functionalities of security application 106 in accordance with the embodiments of the present invention can be implemented in a wide variety of computer system configurations. In addition, the functionalities of security application 106 could be stored as different modules in memories of different devices. For example, security application 106 could initially be stored in computer system 130, and then as necessary, a portion of security application 106 could be transferred to host computer system 102 and executed on host computer system 102. Consequently, part of the functionality of security application 106 would be executed on processor 132 of server computer system 130, and another part would be executed on processor 108 of host computer system 102.

[0090] In view of this disclosure, those of skill in the art can implement various embodiments of the present invention in a wide-variety of physical hardware configurations using an operating system and computer programming language of interest to the user. In yet another embodiment, security application 106 is stored in memory 134 of server computer system 130. Security application 106 is transferred over network 128 to memory 112 in host computer system 102. In this embodiment, I/O interface 110 and I/O interface 136 would include analog modems, digital modems, or a network interface card. If modems are used, network 128 includes a communications network, and security application 106 is downloaded via the communications network.

[0091] This disclosure provides exemplary embodiments of the present invention. The scope of the present invention is not limited by these exemplary embodiments. Numerous variations, whether explicitly provided for by the specification or implied by the specification or not, may be implemented by one of skill in the art in view of this disclosure.