Abstract:
Unauthorized uses of embedded objects in websites are detected, in order to protect users from phishing sites using cloned copies of such objects. Authorized parties register objects for use at legitimate locations (e.g., specific IP address ranges or domains). When a client computing device accesses a website, the objects in the website are checked against the registered objects, to determine whether the objects are registered for use by the site being accessed. Depending upon trust status information concerning the objects, the access of the website can be permitted or blocked, or the user can be warned about questionable or un-trusted embedded objects. Additionally, the party that registered an object can be notified, in the case of an indication of unauthorized use of the object by a website.

Description:
TECHNICAL FIELD 
     This invention pertains generally to computer security, and more specifically to protecting users from phishing websites that include unauthorized copies of design elements intended to identify legitimate websites. 
     BACKGROUND 
     Computer users are often victimized by phishing attacks, in which they unknowingly provide personal and confidential information to malicious websites. Phishing is an attempt to criminally and fraudulently acquire sensitive information, such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. Phishing attacks are commonly made by sending fraudulent emails or instant messages, and enticing users to click on a link and submit personal information to what appears to be a legitimate website. 
     Phishing websites are often crafted so as to appear to be well known, trusted websites (e.g., the website of a legitimated e-merchant or financial institution with which targeted users conduct business). DNS, attacks, browser flaws, and/or careless user behavior are then exploited to direct users to these “cloned” sites. Since a phishing site is constructed as a visual copy of the original, legitimate site, the user believes it is “real,” and interacts with it, often disclosing personal information. 
     Many legitimate websites use distinctive and non-trivial design elements, such as javascript and flash objects, to create a more unique appearance and thereby attempt to make their sites harder to clone. Unfortunately, phishers have become very adept at capturing these graphic elements, and imbedding them in their phishing websites, thereby making them appear to be the legitimate originals. It would be desirable to be able to protect users from these phishing attack strategies. 
     SUMMARY 
     Unauthorized uses of embedded objects in websites are detected, in order to protect users from phishing sites using cloned copies of such objects. Authorized parties register objects for use at legitimate locations (e.g., specific IP address ranges or domains). When a client computing device accesses a website, the objects in the website are checked against the registered objects, to determine whether the objects are registered for use by the site being accessed. Depending upon trust status information concerning the objects, the access of the website can be permitted or blocked, or the user can be warned about questionable or un-trusted embedded objects. Additionally, the party that registered an object can be notified, in the case of an indication of unauthorized use of the object by a website. 
     The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating registration of embedded objects for authorized use at specific locations, according to some embodiments of the present invention. 
         FIG. 2  is a block diagram illustrating determining trust status information for objects embedded in web pages, according to some embodiments of the present invention. 
     
    
    
     The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a system  100  for protecting users against the embedding of cloned objects  101  in phishing web pages  102 , according to some embodiments of the present invention. It is to be understood that although various components are illustrated in  FIG. 1  as separate entities, each illustrated component represents a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a component is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries. 
     As illustrated in  FIG. 1 , objects  101  that can be embedded in websites  102  (e.g., flash-based ‘badges’, logos, javascript objects) can be registered with an object registration component  103 , running, for example, on a central server  104 . A party  105  who wishes to register an object  101  (e.g., a system administrator or web master or the like) submits a hash  107  (or other suitable identifier) of the object  101  to the object registration component  103 . In addition to the hash  107 , the party  105  submits a location binding  109  for the object  101  (e.g., a domain, IP addresses range, geo-region, etc.). The location binding  109  specifies the location(s) at which the object  101  is to be registered for authorized use. For example, if the location binding  109  specifies an IP address range, the party  105  is indicating that the object  101  is to be registered for use only by websites  102  within that IP address range. The object registration component  103  receives registration information  107 ,  109  from a number of parties  105 , and stores the registration information  107 ,  109  in a database  111  (or other storage mechanism). 
     The object registration component  103  can utilize any of a number of authentication and verification mechanisms to manage which parties  105  are allowed to register objects  101  for binding with which locations. A number of authentication and verification mechanisms are known to those of ordinary skill in the relevant art, and the use thereof within the context of the present invention will be readily apparent to those of such a skill level in light of this specification. 
     Turning now to  FIG. 2 , an object authentication component  201  runs on a user&#39;s computer  203 . Whenever the computer  203  accesses a webpage  102 , the object authentication component  201  notes all of the objects  101  embedded therein, and takes a hash  107  of each one. The object authentication component  201  transmits these hashes  107  and location information  205  concerning the website  102  being accessed to the central object registration component  103 . The object registration component  103  searches for each submitted hash  107  in the database  111 , determines whether the submitted hashes  107  correspond to registered objects  101 , and if so, whether the objects  101  are registered for use by the website  102  that the user&#39;s computer  203  is accessing. In other words, if a given object  101  embedded in the website  102  being accessed is registered, the object registration component  103  determines with the location  205  of that website  102  is specified by the stored location binding  109  for the object  101 . If so, the use of that object  101  by the website  102  being accessed is trusted. Otherwise, it is not trusted. If a given object  101  is not registered at all, this provides no definitive trust status information one way or the other. In any case, the object registration component  103  returns an indication  207  of the trust status (e.g., trusted, not trusted, unknown) for the objects  101  corresponding to the submitted hashes  107 . 
     In one embodiment, the object authentication component  201  is implemented as a web browser plug-in, but it can also be implemented in other ways, such as a HTTP/HTTPS proxy (local or remote, configured or transparent).  FIG. 2  illustrates the object authentication component  201  submitting a single transmission comprising hashes  107  of all embedded objects  101  in a given webpage  102 , and the object registration component  103  returning a single indication  207  regarding the trust status of each object  101 . In other embodiments, the object authentication component  201  can send each hash  107  individually, and the object registration component  103  in turn can generate and transmit a plurality of individual trust status indications  207 . In another embodiment, rather than returning trust status indication(s)  207  comprising explicitly determined trust status(es), the object registration component  103  simply sends back location bindings  109  corresponding to submitted hashes  107 . In this embodiment, the object authentication component  201  determines the trust status of given objects  101  itself based on the location binding  109  and the location of the site  102  being accessed. 
     As the object authentication component  201  receives (or generates) trust status indications  207  for the objects  101 , it stores the indications  207  in a database  111  (or other storage mechanism) along with the corresponding hashes  107 . This allows the object authentication component  201  to detect changes in an object&#39;s trust status over time. Additionally, upon receiving a trust status indication  207  for an object  101  embedded in a webpage  102  being accessed, the object authentication component  201  determines whether an entry for this object  101  (by hash  107 ) exists in the local database  111 . If so, the object authentication component  201  examines the previous entry, and determines whether the object  101  was previously trusted and is now not trusted. This indicates that the user is likely accessing an illegitimate clone of a site  102  previously visited. If no previous entry exists but the current indication  207  is that the object  101  is not trusted, this indicates that the website  102  being accessed is not legitimate, but not as strongly as the case in which the trust status of the object  101  has been demoted. Additionally, the trust status for the object  101  can be “unknown” or “trusted.” 
     Based on the trust status(es) of the object(s)  101  embedded in a given webpage  102 , the object authentication component  201  takes appropriate action as desired. The specific actions to take are a variable design parameter. For example, where all the embedded objects  101  are trusted, the object authentication component  201  typically lets the user access the webpage  102  without taking any additional steps. Where the status of at least one object  101  is unknown, the object authentication component  201  can allow the access to proceed without warning, block the access, or provide the user with a notification  209  concerning the unregistered object(s)  101 . Where at least one object  101  is not trusted and/or has been demoted in trust status, the object authentication component  201  typically blocks the access and/or alerts the user by providing a notification  209  as to which objects  101  are and/or are not trusted, etc. The exact method used for providing such a notification  209  is a variable design parameter. However, it typically is in the form of a visual indicator outside the content window, so as to prevent spoofing. Additionally, where un-trusted and/or demoted objects  101  are detected, the object authentication component  201  can report these objects  101  to the object registration component  103  (or some other type of central computer security service). In some embodiments, the object registration component  103  makes such determinations itself, based on the hash  107  submissions. The object registration component  103  can take any of a number of actions responsive to un-trusted and/or demoted objects  101 , such as contacting the party  105  who registered the object initially, and/or taking steps to have the website  102  in which the un-trusted objects  101  are embedded taken down (not illustrated). 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as magnetic or optical storage media, as well as solid state/flash media. Additionally, software portions of the present invention can be instantiated (for example as object code or executable images) within the memory of any computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.