IL308932A - Methods for alerting a network user about entering an unauthenticated website - Google Patents

Description

006095IL METHODS FOR ALERTING A NETWORK USER UPON ACCESS OF AN UNAUTHENTICATED WEBSITE FIELD OF THE DISCLOSED TECHNIQUE The disclosed technique relates to the prevention of cyberattacks, in general, and to methods and systems for alerting a network user and/or a web domain owner upon access of an unauthenticated website, in particular.

BACKGROUND OF THE DISCLOSED TECHNIQUE As the Internet has developed and matured and become almost as essential as electricity to life in the modern world, so have the digital threats and attacks that occur over the Internet. Cyberattacks, as they are referred to, can include a plethora of threats that can happen to any user accessing a network such as the Internet. These attacks can include the intrusion of a virus to a computing system, the theft of sensitive information (such as banking passwords) and the impersonation of authentic websites for selling fake wares and apparel.

Site impersonation is a type of cyberattack wherein a counterfeit website is launched on the Internet that looks and functions like the genuine authentic website it is trying to copy. Such websites are also referred to as phishing websites, fake websites and/or unauthenticated websites. In such an attack, an unassuming user may access the counterfeit website and during interaction with the website, disclose sensitive information to an attacker or hacker who launched the website. The sensitive information may include usernames, passwords, credit card numbers and/or account numbers which the attacker may use to either impersonate the genuine user and/or to extort the user. The attacker may also falsely transact with the user, including the deployment of malicious software on the user’s computing platform.

For example, the fake website may be a fake social media website, with the intent of the attacker gaining access to the unassuming user’s account. If the 006095IL attacker succeeds in getting the username and password, the attacker may enter the account of the user under the real social media website, change the user’s password and then wreak havoc on the user’s profile. The attacker may also extort money from the user in order to return access to the user’s account to the user. If the fake website is a fake banking website, the intent of the attacker may be to gain access to the user’s banking website and steal money from the user’s bank account. If the fake website is a fake apparel website, the intent of the attacker may be to gain credit card information from a user and/or to sell counterfeit or fake apparel to the user. As JavaScript has become the predominant programming language through which the Internet is structured and is ubiquitous in website design and website construction, attackers can easily gain access to the code behind an authentic website. As JavaScript is an interpreted language, large parts of the code behind pretty much any website is readily available and accessible when a user or hacker accesses the genuine website. Many techniques are known to attackers and hackers for copying genuine websites and then building from the copied website a fake website. These techniques include website spoofing, website cloning and using iFrame HTML (aka clickjacking), however this list is not exhaustive. At first glance, a simple solution to the problem presented above would be to simply teach users that they should inspect the web address of a website they are accessing to ensure that it is the genuine website as web addresses are unique and are monitored and registered internationally. When a hacker launches a fake website, its web address will not be the web address of the genuine website. Sophisticated hackers will register a domain name that is very similar to the domain name of the genuine website, with maybe a single letter or digit being different in the domain name. However, even though the actual web address of a fake website will not match the web address of the genuine website, attackers rely on the general complacency of users and the fact that the web address as presented on a web browser is usually quite small compared to the actual website presented to the user. If a fake website looks like the genuine website, then a user will readily begin interacting with the website even if the web address is incorrect or even slightly 006095IL different than the web address of the genuine website. Thus, the above presented solution does not work in reality and most people who fall prey to a fake website do not pay attention to the web address of the website they have accessed.

Other solutions which have been proposed include the addition of software routines into the website domain which can do at least one of the four following actions: (i) alert website users to the fact that they’ve accessed a fake website, (ii) alert the website domain owner that a website user has accessed a counterfeit website, (iii) show a watermark or another verified notice/seal to assure the website user that he/she has reached the legitimate website, or (iv) utilize other security techniques to secure the website. The limitation of such solutions is that whenever a security mechanism is designed to operate by means of executable code which is embedded in the software logic of the website (herein referred to as a security software routine ), there is an inherent risk that a hacker who is utilizing all or some of the code from the legitimate website to build a fake website or initiate other fraudulent activity will be able to identify, remove and/or disable any operative security software routine added to the software logic of the website to prevent such an occurrence from happening.

There is thus a need for cybersecurity solutions which are dependent on software security routines embedded in the software logic of the website which employ a layer of protection making it difficult for hackers to identify the nature, location and/or functionality of the operative software security routine(s) and/or to disable and/or weaken the functionality of such software security routine(s).

SUMMARY OF THE PRESENT DISCLOSED TECHNIQUE It is an object of the disclosed technique to provide a novel method and system for alerting a network user and/or a web domain owner upon access of an unauthenticated website. In accordance with the disclosed technique, there is thus provided a method for alerting a network user upon the network user’s access to an unauthenticated website including the procedures of inserting at least one authenticity check into the lines of code of an authentic website and obfuscating at least one line of code representing the authenticity check inserted into the lines of 006095IL code of the authentic website. The method also includes the procedure of executing the authenticity check when the network user accesses a website, the website being at least one of the authentic website and the unauthenticated website.

In accordance with another aspect of the disclosed technique, there is thus provided a method for protecting credentials of a network user upon the network user’s access to an unauthenticated website and divulging the credentials to the unauthenticated website. The method includes the procedures of inserting at least one line of code into the lines of code of an authentic website for altering at least one data value entered into at least one credential field in the authentic website and obfuscating the line of code for altering the data value entered into the credential field in the authentic website. The method also includes the procedures of when the network user accesses a website, determining if the website is the authentic website or the unauthenticated website, and if the website is determined as the unauthenticated website, then determining if the network user is an innocent user or a malicious user. The method further includes the procedure of if the network user is determined as the innocent user, then applying the line of code for altering the data value entered into the credential field in the unauthenticated website. The method also includes the procedure of if the network user is determined as the malicious user, then not applying the line of code for altering the data value entered into the credential field in the unauthenticated website.

In accordance with a further aspect of the disclosed technique, there is thus provided a method for alerting a network user upon the network user’s access to an unauthenticated website including the procedures of injecting at least one authenticity check to an authentic website through at least one external platform providing at least one service to the authentic website and obfuscating at least one line of code representing the authenticity check. The method also includes the procedure of executing the authenticity check when the network user accesses a website, the website being at least one of the authentic website and the unauthenticated website. 30 006095IL In accordance with another aspect of the disclosed technique, there is thus provided a method for protecting credentials of a network user upon the network user’s access to an unauthenticated website and divulging the credentials to the unauthenticated website. The method includes the procedures of injecting at least one line of code into the lines of code of an authentic website through at least one external platform providing at least one service to the authentic website for altering at least one data value entered into at least one credential field in the authentic website and obfuscating the line of code for altering the data value entered into the credential field in the authentic website. The method also includes the procedures of when the network user accesses a website, determining if the website is the authentic website or the unauthenticated website, and if the website is determined as the unauthenticated website, then determining if the network user is an innocent user or a malicious user. The method further includes the procedures of if the network user is determined as the innocent user, then applying the line of code for altering the data value entered into the credential field in the unauthenticated website, and if the network user is determined as the malicious user, then not applying the line of code for altering the data value entered into the credential field in the unauthenticated website. 006095IL BRIEF DESCRIPTION OF THE DRAWINGS The disclosed technique will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which: Figure 1 is a schematic illustration of the implementation of the disclosed technique in an authentic website and a fake website, constructed and operative in accordance with an embodiment of the disclosed technique; Figure 2 is a schematic illustration of a method for alerting a network user upon access of an unauthenticated website, operative in accordance with another embodiment of the disclosed technique; Figure 3 is a schematic illustration of another implementation of the disclosed technique in a fake website, constructed and operative in accordance with a further embodiment of the disclosed technique; and Figure 4 is a schematic illustration of a method for altering sensitive information of a network user entered on an unauthenticated website, operative in accordance with another embodiment of the disclosed technique. 006095IL DETAILED DESCRIPTION OF THE EMBODIMENTS The disclosed technique overcomes the disadvantages of the prior art by providing methods for alerting a user that they’ve accessed an unauthenticated website. The method of the disclosed technique is elegant and compact and does not disrupt website optimization while also providing a large and visible notice to a network user that an unauthenticated website has been accessed. In addition, the method of the disclosed technique is discretely hidden within the lines of code of an authentic website, thus making it difficult for hackers and attackers to defeat.

As mentioned above, since JavaScript is the predominant programming language through which websites are built, attackers can easily gain access to the code behind an authentic website. There is thus an inherent vulnerability to any lines of code inserted into a website for the purposes of securing the website from outside attacks and from manipulation by criminal hackers. The disclosed technique involves the insertion of at least one line of code (herein referred to as the inserted code ) to the lines of code of the authentic website. The inserted code is obfuscated, thus making it more difficult for a hacker to determine the function of the inserted code and whether it is essential for the running of the website or not.

According to the disclosed technique, the inserted code is an executable script which performs at least one authenticity check of the website. The authenticity check substantially verifies that the website that has been accessed is indeed the authentic and intended website which the user wanted to access. If the authenticity check turns out positive, then nothing is shown to the user and the assumption is that the website the user has accessed is authentic. If the authenticity check turns out negative, then a large warning screen can be presented to the user, informing the user that they’ve accessed a potentially fake or unauthenticated website and should not continue interacting with the website. Even though a hacker will see such warning screens when building the fake website, according to the invention, authenticity checks are hidden in a unique method which prevents easy detection of the lines of code generating the authenticity checks and the warning screen if the at least one authenticity check turns out negative. Furthermore, the disclosed technique can distinguish between an innocent user accessing the authentic 006095IL website from an attacker attempting to clone the authentic website, such as when the attacker is debugging his own cloned unauthentic website and can thus bypass the warning screen if it is not an innocent user accessing the authentic website.

According to the disclosed technique, the warning screen, or even a warning message, can be forwarded not only to an innocent user but also to the owner of the authentic website that an unauthentic version of their website is on the Internet and that an innocent user accessed (or tried to access) the unauthentic version of their website.

It is noted that the disclosed technique is not limited to the actual insertion of code snippets into the source code of the authentic website. In one embodiment of the disclosed technique, the code snippet can be injected into the authentic website through a website application firewall (herein abbreviated WAF ) or content delivery network (herein abbreviated CDN ) workers (such as Akamai’s EdgeWorkers, F5’s iRules or Cloudflare’s Workers®) used by the authentic website. In such an embodiment, no modifications need to be made to the source code of the authentic website and when the source code of the authentic website is interpreted the WAF or CDN workers can insert the code snippet of the disclosed technique into the website on-the-fly without changing the source code of the website. In another embodiment of the disclosed technique, the code snippet can be injected into other platforms which service the authentic website, using any known injection techniques, thus not requiring any change to the lines of code of the authentic website while nonetheless enabling the authenticity checks to be performed on the authentic website as well as websites which are cloned from the authentic website.

According to the disclosed technique, the authenticity checks do not involve any pixels which are visible to a user and also do not require any sounds which are to be played. Thus, the authenticity checks according to the disclosed technique should not disrupt or alter any optimization already achieved for an authentic website as the authenticity checks do not involve the website as viewed by a network user. 30 006095IL According to the disclosed technique, even if a hacker manages to disable all the authenticity checks in the fake website such that an unsuspecting user interacts with the fake website and provides sensitive information to the backend of the fake website, the disclosed technique provides for a mechanism for poisoning the sensitive information provided to the backend of the fake website.

Thus, even if an unsuspecting user divulges sensitive information such as credit card information, banking card information and/or user names and passwords, the disclosed technique provides for a mechanism within the lines of code of the authentic website for poisoning such information if a fake website is cloned from the authentic website. As mentioned above, the disclosed technique can distinguish between an innocent user accessing the website and a hacker debugging a fake version of the website such that the poisoning of the user’s information is only performed if an innocent user is accessing the fake website and not if the user is accessing the genuine website or if the hacker is attempting to debug the fake website.

In a first embodiment of the disclosed technique, an executable script is inserted into the lines of code of the authentic website which verifies if all the scripts of the authentic website come from the document object model (herein abbreviated DOM ) of the authentic website. As mentioned above, the executable script is obfuscated and in some embodiments of the disclosed technique, the executable script may be nested within another script, thus making it difficult to debug the executable script itself.

In a second embodiment of the disclosed technique, instead of inserting the executable script which verifies if all the scripts of the authentic website come from the DOM of the authentic website into the lines of code of the authentic website, the executable script is embedded in a scalable vector graphics (herein abbreviated SVG ) image. In a variant of this embodiment, unscripted code (such as written in Red Alert code (i.e., OpenRA)) for performing the authenticity check is inserted into the cascading style sheets (herein abbreviated CSS ) of the authentic website. Since JavaScript cannot be inserted directly into CSS, as per the disclosed technique, a warning screen or alert message can be embedded into 006095IL CSS by the server side backend of the genuine website. For example, an "@import URL" statement can be added into the CSS of the server side backend, where the imported URL is another URL having server style statements for turning the issuance of a warning screen and/or alert message either "on" or "off". If the authenticity check returns a positive result, then the warning screen and/or alert message from the imported URL is turned off whereas if the authenticity check returns a negative result, then the warning screen and/or alert message from the imported URL is turned on. Standard debuggers do not debug CSS, thus inserting the warning screen or alert message into the CSS of the authentic website makes it more difficult for a hacker to determine the source of the warning screen which will be presented when the CSS-code gets loaded by the fake website.

In a third embodiment of the disclosed technique, an invisible watermark is added as inserted code to the authentic website. The invisible watermark may be a single pixel which is not viewable to the user, for example a pixel outside the viewable area of the screen upon which the website is presented or as another example, as a pixel which is positioned behind a viewable pixel and thus not viewable by the user. At least one line of code is added to the lines of code of the authentic website in which a request is sent to the authentic website to load the invisible watermark only if the request comes from the domain of the authentic website. The lines of code can thus also include an executable script for generating the warning screen if the invisible watermark was not loaded.

In a fourth embodiment of the disclosed technique, an invisible watermark is added as inserted code to the authentic website, except unlike the previous embodiment, the invisible watermark may be a single pixel positioned within the CSS of the authentic website. As described above, according to the disclosed technique, if the request does not come from the domain of the authentic website then a warning screen will be displayed to the user that the website they have accessed is not authentic. Thus, in each of the embodiments as listed above, the authenticity check includes inserted code for generating a warning to the user if the authenticity check returns a negative result. 30 006095IL According to one embodiment of the disclosed technique, the authenticity checks as described above are placed in multiple places within the lines of code of the authentic website. As an example, the inserted code of the disclosed technique as embodied by the first embodiment above can be placed a plurality of times within the lines of code of the authentic website. Thus, the authentic website will contain many lines of obfuscated code, scattered across the lines of code of the authentic website, which each check if all the scripts on the website come from the DOM of the website. As another example, the lines of code of the disclosed technique as inserted into the lines of code of the authentic website may include the different embodiments as mentioned above. Thus, the authentic website contains many lines of obfuscated code according to each one of the embodiments above, scattered not only across the lines of code of the authentic website but also within the CSS of the authentic website, for checking if all the scripts on the website come from the DOM of the website and also if the invisible watermark has been loaded or not. As a further example of the disclosed technique, the two examples can be combined, thus having a plurality of lines of inserted obfuscated code for each of the embodiments described above scattered across the lines of code of the authentic website as well as the CSS of the authentic website.

As mentioned above, hackers and attackers have known methods of cloning and copying websites for cyberattacks. According to the disclosed technique, in most cases, the inserted code for the authenticity check can distinguish between an attacker and an innocent user. Thus, in the case where the authenticity check recognizes attacker activity, the authenticity check will be performed, however the issuance of a warning message or alert screen will be bypassed, thereby duping the attacker into thinking they have bypassed the authenticity check of the genuine website when in fact they have not. However, even if during the process of building a fake website based on the lines of code of the authentic website, the warning screen of the disclosed technique gets triggered, thus warning the hackers and attackers that an unsuspecting user accessing their fake website will be warned that a fake website was accessed, since the lines of inserted code of the disclosed technique are obfuscated, are relatively short in 006095IL length (for example between 1-5 lines of code) and are scattered across the lines of code of the authentic website, the disclosed technique makes it difficult for hackers and attackers to defeat the authenticity checks of the disclosed technique.

According to the disclosed technique, part of the inserted code of the authenticity check can include a configurable warning message bypass (for example, configurable by an administrator). The bypass for the warning message may occur if the inserted code detects at least one of the following: a) at least one debugger tool is open in the web browser accessing the fake website; b) the fake website is being run on a local network (for example without access to a wide area network); c) the device accessing the fake website is identified as either new and/or untrusted; d) the IP address of the device accessing the fake website is located in a suspected/suspicious region; e) the device accessing the fake website is disconnected from the network; f) the web browser accessing the fake website is running in incognito mode; and g) the device accessing the fake website has been identified as having been involved in previous policy violations.

According to a fifth embodiment of the disclosed technique, obfuscated lines of code can be added to the lines of inserted code of the authentic website to send a message to the backend of the authentic website if the authenticity checks as described above in the first to fourth embodiments have been removed. Thus, according to the disclosed technique, even if the authenticity checks of the disclosed technique are successfully removed by a hacker in a fake website, the fake website will nonetheless send a message to the backend of the authentic website that a fake website of the authentic website has been generated and placed on the Internet. Whereas according to this embodiment of the disclosed technique an unsuspecting user will not be warned in real-time that they have 006095IL accessed a fake website, the backend of the authentic website will be warned that a website impersonating the authentic website is up on the Internet and being accessed by users. The message to the backend can be used by the owners of the authentic website to locate the IP address of the fake website and to take measures to have the fake website taken down, including the listing of the fake website on various known black lists maintained by Internet service providers (herein abbreviated ISPs ) as well as involving law enforcement authorities.

According to a sixth embodiment of the disclosed technique, obfuscated inserted code is added to the lines of code of the authentic website as authenticity checks as described above in the first to fourth embodiments, however all of the aforementioned authenticity checks do not issue a warning screen to an unsuspecting user that has accessed a fake website. In this embodiment, similar to the fifth embodiment, if any of the authenticity checks turn out negative (which will be the case when a fake website is accessed), instead of actively warning the user with a warning screen, the inserted code of the disclosed technique provide a message to the backend of the authentic website that at least one of the authenticity checks turned out negative. The message may also be forwarded to the owner of the authentic website and/or to the user via other communication means (such as through a message to a mobile phone or an e-mail address of either the user, the authentic website owner or both). The message may include information on the IP address of the fake website. As mentioned in the fifth embodiment above, the owners of the authentic website can then take measures to take down the fake website, have the fake website added to a black list of unauthenticated websites maintained by major ISPs and/or get the law enforcement authorities involved.

According to a seventh embodiment of the disclosed technique, if a user enters sensitive information in the unauthentic website and clicks an ‘OKAY’, ‘SEND’, ‘ENTER’ or other button on the unauthentic website for transmitting the sensitive information to the backend of the unauthentic website, the sensitive information is poisoned and altered before being transferred to the backend of the unauthentic website. Thus, a hacker will receive information from the innocent user 006095IL who accessed their fake website. However, the received information will not be the information which the user actually entered into the information fields of the unauthentic website. As mentioned above, the inserted code in the authentic website for altering (i.e., poisoning) the user’s sensitive information is obfuscated and can also distinguish between an innocent user accessing the fake website and a hacker attempting to debug the fake website. Thus, if the hacker is attempting to debug the fake website, any sensitive information they enter in as a test case will be unaltered and their backend will receive the same information. However, if an innocent user accesses the fake website and enters in sensitive information, the sensitive information will be altered and poisoned before being transferred to the backend of the fake website.

This embodiment of the disclosed technique can be implemented whether the obfuscated inserted code relating to the authenticity checks as described above is removed and detected by other obfuscated lines of inserted code in the genuine website or whether a user ignores or is unaware of the warning message presented to them that they’ve accessed an unauthentic website. Thus, in one embodiment of the disclosed technique, the inserted code for altering the sensitive information only alters the sensitive information if at least one of the authenticity checks as described above returns a negative result (meaning at least one authenticity check did not return a positive result). In another embodiment of the disclosed technique, the inserted code for altering the sensitive information alters the sensitive information regardless of whether the authenticity check(s) as described above return a negative result and thus alters the sensitive information entered provided a determination is made that an innocent user has accessed an unauthentic website.

In this embodiment, the inserted code may include an array of obfuscated domain names that are considered authorized domain names. If the current domain name of the accessed website does not match one of the authorized domain names then the accessed website is considered an unauthentic website and the sensitive information entered by the user is altered.

According to this embodiment of the disclosed technique, assuming sensitive information to be entered into an authentic website includes at least a 006095IL username and a password, the inserted code slightly alters the username, for example by altering at least a single character of the username. A numeric hash of a predetermined length is then calculated for the altered username and is used as an altered password for the user. The altered username and altered password are thus passed on to the backend of the fake website and as mentioned above, this only occurs when it is determined that an innocent user has accessed an unauthentic website. According to the disclosed technique, the user’s actual username and password are not forwarded to the backend of the fake website and the altered username and altered password are also not forwarded to the backend of the authentic website. Thus, a hacker will not be able to sniff the code relating to the fields where sensitive information is entered into the fake website to determine if the sensitive information is tampered with and/or is modified before being sent to the backend of the authentic website.

Also, according to the disclosed technique, the inserted code for altering the sensitive information can perform an authenticity check of the username and password entered on the authentic website using the same mechanism for altering the username and password if an innocent user enters sensitive information on a fake website. Thus, for example, the username entered on the authentic website may be used to determine a numeric hash of the same predetermined length as mentioned above. If the numeric hash determined from the username matches the password entered on the authentic website, the authentic website then knows that a hacker is attempting to access the authentic website based on sensitive information received from an innocent user who accessed the hacker’s fake website. As mentioned above, this is achievable according to the disclosed technique without having to store the altered sensitive information of the user either on the backend of the authentic website or on a third party server. Information from the hacker’s terminal (such as the web address which was used to access the authentic website and enter the altered sensitive information in) can then be forwarded to the backend of the authentic website which can be used by the owner of the authentic website for determining the location of the hacker, for involving law enforcement authorities and the like. 006095IL Reference is now made to Figure 1, which is a schematic illustration of the implementation of the disclosed technique in an authentic website and a fake website, generally referenced 100, constructed and operative in accordance with an embodiment of the disclosed technique. Shown in Figure 1 is an authentic website 102 which includes a plurality of webpages 104 and a plurality of CSSs 106.

Authentic website 102 schematically represents the lines of code included in plurality of webpages 104 and plurality of CSSs 106, which when interpreted and/or executed via a web browser (not shown), are displayed on a user device (such as a computer screen, a tablet, a smart phone, a smart watch and the like) as a website 112. As shown, the domain name of website 112 is shown in an address bar 114 in the web browser as www.mybank.com. An arrow 110 schematically shows the translation of the lines of code of authentic website 102 to displayed website 112.

Authentic website 102 represents the lines of code of the website as displayed to a user and thus represents the user’s interface with the website. However, authentic website 102 also includes an authentic website backend 108 (herein referred to simply as backend 108 ), which may be a server housing additional webpages, files and other data (all not shown) which are used by authentic website 102 when the user interacts with displayed website 112.

Authentic website 102 represents a website which may be the victim of cyberattacks. For example, authentic website 102 may be a banking website, an online shopping website, a postal service website, a medical service website, an insurance service website and the like. Usually, such websites provide access to personal information about a user and/or access to financial resources of the user, both of which can be used to the advantage of a hacker and/or attacker online.

However, authentic website 102 can represent any website developed by an individual and/or company for legitimate purposes.

In the example shown in Figure 1, authentic website 102 is a banking website and for purposes of simplicity, the landing page of displayed website 112 is shown as having two fields in which a user can enter information to gain access to further webpages on displayed website 112. As shown, a name field and an account field (not labeled) are displayed to a user accessing www.mybank.com. It 006095IL can be assumed that after the name field and account field are entered correctly, provided the user has an account at the bank, a further webpage may be displayed (not shown) asking the user to enter further information, such as an ID number and a password, for gaining access to the user’s online bank account. In the case of the authentic website, once the ID number and password are correctly entered, those values may be passed to backend 108 for retrieving the account information of the user and allowing the user to access their online bank account and perform various banking actions. As per the disclosed technique, and described below, the concern is when the user accesses an unauthenticated website and begins entering in sensitive information. The unauthenticated website may be programmed to transfer that information to the server of a hacker or attacker instead of transferring it to backend 108. The hacker or attacker can then use that information to gain access to the user’s bank account without the knowledge of the user.

Plurality of webpages 104 and plurality of CSSs 106 are shown with some basic example lines of code however, it is clear to the worker skilled in the art that authentic website 102 may include hundreds if not thousands of lines of code.

According to the disclosed technique, in order to warn and hopefully prevent a network user from divulging information over an unauthenticated website, inserted code is added to authentic website 102 as an authenticity check. As shown in one embodiment, the authenticity check can be included in one of plurality of webpages 104, such as an authenticity check 116A or an authenticity check 116B. As shown in another embodiment, the authenticity check can be included in one of plurality of CSSs 106, such as an authenticity check 118. In addition, a single authenticity check may be added to authentic website 102 (such as just authenticity check 116A) or a plurality of authenticity checks may be added to authentic website 1 (such as authenticity checks 116A, 116B and 118) in the webpages of the website, in the CSSs of the website or in both. Furthermore, any of the authenticity checks can be added through a WAF or CDN worker that services authentic website 102.

Any of the authenticity checks can also be added to an external platform that services authentic website 102 using an injection technique. In these two 006095IL embodiments, the authenticity checks are not added to the source code of authentic website 102 but rather injected through the WAF/CDN worker and/or through the external platform.

Authenticity checks 116A, 116B and 118, as described below, substantially check the authenticity of authentic website 102 to ensure that a network user has accessed the website they intended to access and not an unauthenticated website. Provided authenticity checks 116A, 116B and 118 return a positive result, then authentic website 102 functions as normal, meaning from the perspective of the user, no specific message is presented to them as they browse the website. As described below, the authenticity checks of the disclosed technique also includes lines of code for providing a warning to a network user (and/or to backend 108) that they’ve access an unauthenticated website if the authenticity checks return a negative result.

As mentioned above, authenticity checks 116A, 116B and 118 are not lengthy pieces of code which could compromise the optimization of authentic website 102. Authenticity checks 116A, 116B and 118 are embodied as at least line of inserted code and execute a computationally light check of the authenticity of authentic website 102, thus ensuring that the addition of authenticity checks 116A, 116B and 118 to the lines of code of authentic website 102 does not compromise the optimization of authentic website 102. In addition, authenticity checks 116A, 116B and 118 are not added as plain lines of code which might make it easy for a hacker or attacker to identify and then remove from a fake website which is cloned from the authentic website. According to the disclosed technique, authenticity checks 116A, 116B and 118 are added as obfuscated lines of inserted code, thus making it more difficult for a hacker to identify their presence in the lines of code of the website and to determine their functionality. Obfuscation of the lines of inserted code of authenticity checks 116A, 116B and 118 can be executed using known obfuscation techniques, such as Jscrambler or the open source tool JavaScript Obfuscator.

According to a first embodiment of the disclosed technique, the authenticity check is at least one line of inserted code wherein all the scripts in 006095IL plurality of webpages 114 are checked and verified that they come from the DOM of the authentic website. Such an authenticity check can be embodied as an executable script written in JavaScript which performs the following executable actions, for example checking the src attribute of the script whose authenticity is to be verified and ascertaining that it comes from the authentic website, checking a digital signature of the innerText property of the script whose authenticity is to be verified, and the like. According to the disclosed technique, such a script is obfuscated and when executed by the web browser, will verify that all scripts in the website indeed come from the DOM of the authentic website, which may be stored in backend 108. The executable script forming authenticity check 116A or 116B may be a script nested within a script, thus making it more difficult for a hacker or attacker to debug the executable script. In this first embodiment, the authenticity check is specifically added to the lines of code of plurality of webpages 104.

According to a second embodiment of the disclosed technique, the authenticity check is also at least one line of inserted code wherein all the scripts in plurality of webpages 114 are checked and verified that they come from the DOM of the authentic website. However, in this embodiment, instead of placing the authenticity check in plurality of webpages 114, the authenticity check is placed in plurality of CSSs 106, such as authenticity check 118. Since authenticity check 1 is an executable script, such as a script written in JavaScript, authenticity check 118 cannot be placed as is inside plurality of CSSs 106 as JavaScript cannot be inserted in CSS. According to the disclosed technique, authenticity check 118 is written as an executable script embedded into a text-based image format which can be placed inside plurality of CSSs 106. An example of a text-based image format is SVG, thus authenticity check 118 can be written as an executable script embedded in an SVG image (which is defined via text). As an example, authenticity check 1 can be written as: 006095IL . As mentioned above, authenticity check 118 can also be written in an unscripted form as executable code, for example such as: wherein the server style located at "backend-server.com" contains executable scripts for implementing the flow of software logic for determining authenticity of the website. The executable scripts determine if a red alert should be shown to the network user or not and return a code to the CSS that triggers the red alert accordingly through at least one style code statement. It is noted that in addition, authenticity check 118 can also be obfuscated.

When the website is loaded and aspects of the formatting of displayed website 1 are loaded from plurality of CSSs 106, authenticity check 118 will be executed and will verify that all the scripts in plurality of webpages 104 come from the DOM of authentic website 102. In this second embodiment, the authenticity check is specifically added to the lines of code of plurality of CSSs 106. Standard debuggers do not debug CSS, thus according to the disclosed technique, inserting authenticity check 118 within the CSS of authentic website 102 makes it more difficult for a hacker to determine that an authenticity check has been added to the lines of code of the authentic website when cloning the website.

According to a third embodiment of the disclosed technique, authenticity check 116A or 116B is embodied as an executable script for adding and verifying that an invisible watermark has been added to and is present in authentic website 102. The invisible watermark may be a single pixel which is not viewable to the network user on displayed website 112, for example as a pixel outside the viewable area of displayed website 112 or as a pixel which is positioned behind a viewable pixel and thus not viewable by the user. Authenticity check 116A or 116B may be embodied as a script which requests that the invisible watermark be drawn only if the request comes from the domain of authentic website 102, for example www.mybank.com. As an example of this embodiment, an authenticity check may be written as: 006095IL Similar to the first embodiment described above, the executable script forming authenticity check 116A or 116B may be a script nested within a script, thus making it more difficult for a hacker or attacker to debug the executable script. In this third embodiment, the authenticity check is specifically added to the lines of code of plurality of webpages 104.

According to a fourth embodiment of the disclosed technique, authenticity check 116A or 116B is also embodied as an executable script for adding and verifying that an invisible watermark has been added to and is present in authentic website 102. However, in this embodiment, instead of placing the authenticity check in plurality of webpages 114, the authenticity check is placed in plurality of CSSs 106, such as authenticity check 118. Authenticity check 118 is thus written as an executable script in a text-based image format such as SVG such that it can be inserted into plurality of CSSs 106. Thus, as plurality of CSSs 106 are executed and displayed website 112 is loaded, authenticity check 118 requests that an invisible watermark be added to displayed website 112 only if the request originated from authentic website 102, meaning from www.mybank.com. In this fourth embodiment, the authenticity check is specifically added to the lines of code of plurality of CSSs 106, thus providing the same benefits as the second embodiment in that standard debuggers do not debug CSS and thereby making it more difficult for a hacker to determine that an authenticity check has been added to the lines of code of the authentic website when cloning the website.

The description of Figure 1 until now merely shows how authenticity checks are added to the lines of code of an authentic website and what actions such authenticity checks perform. Figure 1 however, also shows how the authenticity checks of the disclosed technique are used to alert a network user when they’ve accessed an unauthenticated website. As mentioned above, an attacker or hacker may copy or clone an authentic website in order to gain sensitive information from a user and then use that information to gain access to the user’s account. As an underlying assumption, when a hacker or attacker copies or clones a website, their desire is that the unauthentic or fake website will look and behave exactly like the authentic website, at least until the webpages and fields where the 006095IL user is to enter sensitive information. Thus, as shown in Figure 1 is a fake website 102’ which includes a plurality of webpages 104’ and a plurality of CSSs 106’. As shown, fake website 102’ is substantially a copy of authentic website 102, as the lines of code of authentic website 102, including the lines of code of the webpages and CSSs, can be easily copied and cloned. It is to be assumed that parts of fake website 102’ will be altered such that the information entered by the user in various fields will end up on a server which the hacker can access instead of backend 108.

However, a hacker will not want to alter the lines of code of fake website 102’ too much, since any significant changes in look, feel and response times might raise suspicion with the user that the website they’ve accessed isn’t authentic website 102 but rather a fake website. As mentioned above, the desire of a hacker is that fake website 102’ looks, feels and behaves like authentic website 102 such that a network user will use fake website 102’ and divulge sensitive information without questioning the authenticity of fake website 102’.

As shown by an arrow 122, when fake website 102’ is loaded, it is displayed as a website 124. Displayed website 124 will have a different IP address than the authentic website, for example as shown in Figure 1 as www.fake.mybank.com in an address bar 126, however the look of displayed website 124 will be practically speaking identical to displayed website 112, as that is certainly what a hacker or attacker desires. Since address bar 126 is quite small, most network users don’t usually look at the IP address as displayed in address bar 126, certainly if in a user’s peripheral vision it appears to be the IP address of the authentic website. In Figure 1, the IP address of fake website 102’ is shown as www.fake.mybank.com, however the IP address could be www.mybank1.com, www.2mybank.com or something which is deceptively similar to www.mybank.com such that only a very discerning network user will notice a difference.

As shown in Figure 1, when the hacker copies or clones authentic website 102 all the lines of code, including any lines of code containing at least one authenticity check, will be copied as well. A hacker will then begin to run fake website 102’ locally to make sure that whatever changes they’ve made to the lines of code of fake website 102’, such as sending information entered into the name 006095IL and account number fields to a server which the hacker has access to and not to backend 108, do not alter the look and feel of website 102’ too much. A hacker might also be aware that security features may have been added to authentic website 102 which might warn a user that fake website 102’ is not authentic, thus a hacker may attempt to debug fake website 102’ and remove any lines of code that appear to contain safety features. For example, the hacker may determine that the lines of code relating to authenticity check 116A appear to be related to some security feature and thus may have erased those lines of code in fake website 102’.

However, as shown, a plurality of authenticity checks may be placed in the lines of code of authentic website 102 such that when those lines of code are copied and cloned, a hacker may not be able to determine all of their locations and thus some of the authenticity checks of authentic website 102 may remain even when the hacker launches their fake website. As shown, fake website 102’ may include authenticity check 116B’ and authenticity check 118’.

As mentioned above, authenticity checks 116B’ and 118’ may be obfuscated as lines of code and may also be nested within scripts or within plurality of CSSs 106’, thus making it difficult for a hacker to debug such lines of code as scripts nested within scripts are not usually debuggable in standard debuggers and CSSs are not usually part of what standard debuggers debug. If a user loads fake website 102’, then when authenticity check 116B’ and/or authenticity check 118’ are executed, a warning window 128 may be loaded on displayed website 124, ostensibly warning the network user that an unauthenticated website has been accessed. Authenticity checks 116A, 116B and 118 may include as part of their lines of code a call to load warning window 128 if the authenticity checks return negative. As mentioned above, the authenticity checks of the disclosed technique may either include a verification that all scripts on the website come from the DOM of the authentic website and/or a request to load an invisible watermark from authentic website 102 only if the request comes from the IP address of the authentic website. In the case of fake website 102’, of necessity there will be executable scripts that are not from the DOM of the authentic website which the hacker will have added to have data entered by the user into displayed website 124 006095IL forwarded to a server which the hacker has access to. In addition, in the case of an invisible watermark, the invisible watermark will not be loaded as the IP address making the request to load the invisible watermark (such as www.fake.mybank.com) will not match the IP address of the authentic website. In either of these cases, the authenticity check will return a negative result and will thus trigger the loading of warning window 128. Even though the hacker may try to remove any connection between fake website 102’ and backend 108, at minimum, authenticity checks 116B’ and 118’ may also contain in their lines of a code a request from backend 108, which will return a negative response (as the request will not have originated from www.mybank.com) and thus trigger the loading of warning window 128. In Figure 1, warning window 128 is shown schematically as an octagon (usually associated with a stop sign) with the words ‘WARNING’ however, warning window 128 can be embodied as any kind of visual warning that can be displayed to the user, including text telling that user that they’ve accessed an unauthenticated website. Warning window 128 can also be embodied as a sound clip which is played and audibly tells and warns the user that a fake website has been accessed.

If the hacker launches fake website 102’ as shown, then when a user accesses displayed website 124, before the network user can even enter values into the name and account number fields, warning window 128 will be displayed to the user as at least one of authenticity checks 116B’ and 118’ will return a negative response.

According to another embodiment of the disclosed technique, in the case of a sophisticated hacker, fake website 102’ may be run multiple times with the goal of the hacker figuring out which lines of code in fake website 102’ copied from authentic website 102 are triggering warning window 128. In the examples described above, an average hacker attempting to debug fake website 102’ might forego launching fake website 102’ as plain and regular debugging of fake website 102’ will not reveal which lines of code are triggering the loading of warning window 128. However, a sophisticated hacker might try a brute force method of removing different lines of code in fake website 102’ to see which lines are triggering warning 006095IL window 128 and/or might build their own debugger to examine parts of the code of fake website 102’ which aren’t normally examined in a standard debugger and thus might discover which lines in the code are the authenticity checks which are triggering warning window 128. In this embodiment of the disclosed technique, in a fifth embodiment of authenticity checks 116A, 116B and/or 118, which can be embodied as any of the authenticity checks mentioned above (either a verification of the source of the scripts in the website as coming from the DOM of the authentic website and/or a verification of an invisible watermark, and either placed in the lines of code of the webpages of the website or in the CSSs of the website), if a negative result is returned, then instead of presenting warning window 128 on displayed website 124, a message is provided to backend 108. The message might include the IP address of fake website 102’ and other information related to fake website 102’. For example, the message could include the following details: "Red alert displayed to end-user for potentially harmful website running under iFrame: from URL="fake-bank.com, deviceIP=192.168.1.1, deviceID=BANK-123456789, victimUser=john.doe@bank.com". The message can thus be provided to the owners of authentic website 102 who can then take action against fake website 102’. For example, the information in the message can be used to take measures to have fake website 102’ taken down, including the listing of fake website 102’ on various known black lists maintained by ISPs as well as involving law enforcement authorities. This embodiment provides a fallback safety position for authentic website 102 in case a hacker manages to erase the authenticity checks that trigger warning window 128. Thus, in such a scenario, even though a user accessing displayed website 124 will not be warned with warning window 128 that they’ve accessed an unauthenticated website and may divulge sensitive information, backend 108 will be provided with a message that a fake website has been launched and users are accessing that site and not authentic website 102. The message can also be used by backend 108 to contact the user who accessed fake website 102’ to warn them that they’ve accessed a fake website as well as contacting the owner of the authentic website. This communication may be via an e-mail to the user, a SMS message to a smartphone or smart watch of the user or 006095IL an automated phone call to the user based on information about the user stored in backend 108 and likewise to the owner of the authentic website. Thus, the user can be warned in near real-time that they’ve accessed a fake website and should be careful about divulging sensitive information and the owner can be warned that a fake website mimicking their real and authentic website is on the Internet and users are accessing the fake website instead of the authentic website.

According to yet another embodiment of the disclosed technique, as described above, the authenticity checks of the first to fourth embodiments may be written as lines of code which do not trigger warning window 128 but automatically send a message to backend 108. Thus in this embodiment, even though the network user is not provided with an immediate warning that they’ve accessed a fake website, a hacker may launch fake website 102’ thinking they can easily dupe network users into divulging sensitive information when in fact, once fake website 102’ is launched, any access to fake website 102’ will trigger a message being sent to backend 108 wherein the owners of authentic website 102 can take immediate action against fake website 102’. As mentioned above, the authenticity checks of the first to fourth embodiments may be written with a configurable bypass message for determining if the code of fake website 102’ is being run by an innocent user who has accessed fake website 102’ or whether it is being run by a hacker attempting to debug fake website 102’ and remove any safety features from it. If the configurable bypass message, which may also be obfuscated, determines that fake website 102’ has been accessed by an innocent user, then warning window 128 may be triggered when the user begins to interact with fake website 102’, such as when the user attempts to enter data in the name field. If the configurable bypass message determines that fake website 102’ is being debugged by a hacker or attacker, as per the conditions listed above (for example, at least one debugger tool is open in the web browser, the device accessing fake website 102’ is not connected to a network, and the like, as described above), then warning window 128 may be bypassed and not presented to the hacker. Instead of warning window 128 being presented to the hacker, then as described above in the fifth and sixth 006095IL embodiments of the disclosed technique, a message may be sent to backend 1without the hacker’s knowledge, thus enabling the website owner to take action about fake website 102’. Therefore, according to the disclosed technique, all six embodiments presented above can be combined in the authenticity check of the disclosed technique depending on the kind of user, determined by the configurable bypass message of the disclosed technique, accessing fake website 102’.

Reference is now made to Figure 2, which is a schematic illustration of a method for alerting a network user upon access of an unauthenticated website, operative in accordance with another embodiment of the disclosed technique. In a procedure 160, at least one authenticity check is inserted into the lines of code of an authentic website. Thus code to perform the authenticity check is inserted into the lines of code of the authentic website. The authenticity check can be as short as a single line of inserted code or can be a plurality of lines of inserted code. As described above in Figure 1, the authenticity check can be inserted into the lines of code of a webpage of the website, into the lines of code of a CSS of the website or into both. In the case of insertion into the lines of code of the CSSs of the website, the authenticity check is embedded in a text-based image format such as SVG. In addition, a single authenticity check may be inserted into the lines of code in procedure 160 or a plurality of authenticity checks can be inserted into the lines of code of the authentic website. As mentioned above, the authenticity check can also be added through a WAF that services the authentic website, or through any external platform (using an injection technique such as a CDN worker) that services the authentic website. In these embodiments, the authenticity checks are not added to the source code of the authentic website but rather injected through the WAF and/or the external platform. As described above in Figure 1, the authenticity check can be a nested executable script which checks that all the scripts on the website come from the DOM of the authentic website. The authenticity check can also be an executable script which inserts an invisible watermark on the displayed website (i.e., an instance of the website) only if the request for inserting the invisible watermark originated from the domain name of the authentic website. The authenticity check of the disclosed technique in procedure 160 substantially verifies 006095IL that the website accessed by a network user is indeed the authentic website which the user intended to access. As described below in procedures 166 and 168, the authenticity check also includes actions that can be executed if the authenticity check returns a negative response. As mentioned above, the authenticity check may also include lines of code for distinguishing between an attacker trying to clone an authentic website and an innocent user having accessed a fake website.

In a procedure 162, the inserted code representing the authenticity check which was inserted into the lines of code of the authentic website is obfuscated.

Any known obfuscation technique can be used, such as Jscrambler or the open source tool JavaScript Obfuscator (available at https://obfuscator.io/), for obfuscating the code representing the authenticity check. The authenticity check is obfuscated thus making it more difficult for a hacker or attacker cloning or copying the authentic website to find and erase the line(s) of code representing the authenticity check that was added to the lines of code of the authentic website.

In a procedure 164, when a user accesses a website, either the authentic website or a fake website cloned from the authentic website, as the website loads, the at least one authenticity check of procedure 160 which was inserted into the lines of code of the authentic website is executed. As mentioned above, the at least one authenticity check verifies that the website accessed by a network user is indeed the authentic website which the user intended to access as per the various embodiments of the authenticity check as described above in Figure 1. The authenticity check of procedure 160 is always executed when the user accesses the authentic website. The authenticity check of procedure 160 will be executed when the user accesses a fake website which was cloned and/or copied from the authentic website provided that the hacker or attacker was not able to remove the authenticity check from the lines of code of the fake website. As mentioned above, the authenticity check may also be able to determine if a hacker is trying to clone the authentic website and debug a fake website they have created or whether an innocent network user has accessed the fake website.

In the case of a positive response to the authenticity check, which will be the case if the network user accessed the authentic website, nothing will 006095IL necessarily happen to the displayed website accessed by the user. Thus, the network user will continue to access and interact with the displayed website as if the authenticity check were not present in the lines of code of the authentic website.

The owner of the authentic website however, will be satisfied that the network user has accessed the authentic website and not a fake website. However, in the case of a negative response to the authenticity check, the authenticity check includes further executable lines of code for performing an action to alert the network user that an unauthenticated website has been accessed. As described above, the further action performed may be dependent on whether the authenticity check has determined that a hacker is debugging a fake website or whether the network user has unknowingly accessed the fake website. The action can either be an active action for alerting the network user that they’ve accessed a fake website trying to impersonate the authentic website or a passive action, for example if it is determined that a hacker is trying to debug a fake website they have cloned from the authentic website, wherein the backend of the authentic website is notified that a user accessed a clone of the authentic website, i.e., a fake website and/or that a hacker is debugging the fake website. These actions are shown below in procedures 166 and 168. As shown, the procedures can occur simultaneously.

In a procedure 166, if at least one of the authenticity checks returns a negative response (i.e., not all the scripts on the website could be verified as coming from the DOM of the authentic website and/or the invisible watermark was not loaded when the displayed website was loaded), then a warning message is presented to the user, alerting them that they’ve accessed an unauthenticated website. The warning message may be a window with an icon and a written message. The warning message may also be an audio file playing a message or sound for alerting the network user that they’ve accessed an unauthenticated website and should be careful about not divulging sensitive information. In another embodiment of the disclosed technique, procedure 166 is only carried out if the authenticity check determines that the negative response was returned from an innocent network user having accessed a fake website and not from a hacker attempting to debug the fake website in an attempt to remove security features from 006095IL the fake website. In the latter case, procedure 168 may be executed instead of procedure 166, thus no warning message would be presented to a network user who is actually a hacker.

In a procedure 168, if at least one of the authenticity checks returns a negative response (i.e., not all the scripts on the website could be verified as coming from the DOM of the authentic website and/or the invisible watermark was not loaded when the displayed website was loaded), then a warning message is sent to the backend of the authentic website. In this procedure, no message is provided to the network user however, a message is provided to the backend of the authentic website. This procedure may be carried out in the event that the authenticity check(s) can determine that the network user is a hacker trying to debug a fake website and remove any security features from it. The owner of the authentic website, having access to its backend, can use the message to determine the domain address of the fake website and then take steps to have the fake website taken down, added to various known black lists of fake websites maintained by ISPs as well as to involve law enforcement authorities. The owner of the authentic website can also use the message to alert the network user (in the case of an innocent network user, as determined by the authenticity check) through other communication channels that they’ve accessed an unauthenticated website, such as via a text message, e-mail or telephone call to the network user. In this procedure, even if a hacker or attacker manages to remove the authenticity checks in the fake website which load a warning message to the user, the assumption is that the message provided to the backend will not be easily discoverable by the hacker and thus even though the fake website will look and behave like the authentic website, when a user accesses the unauthenticated website, a message will nonetheless be sent to the backend of the authentic website which can be used by the authentic website owner to take down the fake website and/or alert the network user through other communication channels.

Reference is now made to Figure 3, which is a schematic illustration of another implementation of the disclosed technique in a fake website, generally referenced 180, constructed and operative in accordance with a further 006095IL embodiment of the disclosed technique. As described above, even with all the authenticity checks described above in reference to Figure 1, the possibility still exists that an innocent user may access an unauthenticated (i.e., fake) website and unknowingly divulge sensitive information such as credit card information, banking card information, user identification names/numbers and/or passwords for accessing accounts on social media and at financial institutions (for example). The implementation of the disclosed technique in Figure 3 shows how the disclosed technique can be used to protect sensitive information of an innocent user even if they inadvertently disclose and enter such information on a fake and unauthenticated website. Shown is a webpage 182 of an unauthenticated website, having a web address 184 of www.fake.mybank.com. It is assumed that webpage 182 was cloned and copied from the authentic website it is trying to copy, shown below as a webpage 218 of an authentic banking website, having a web address 220 of www.mybank.com. As shown, both webpage 182 and webpage 218 have respective ID fields 186 and 222, respective password fields 188 and 224 and respective "OK" buttons 190 and 226 for sending information entered into the ID field and password field to a website backend. Similar to the authenticity checks as described above in Figure 1, the lines of code of the authentic website include obfuscated lines of code for protecting sensitive information entered into specific fields on the webpages of the website, such as ID field 222 and password field 224.

The lines of code, as described below, substantially alter the ID and password entered into the ID and password fields in the case of a fake website cloned from the authenticated website which is accessed by an innocent user. The disclosed technique as described herein assumes that a hacker or malicious user having cloned the authentic website has not altered the obfuscated lines of code described herein for altering the ID and password entered by an innocent user on a fake website. As mentioned above, the obfuscated lines of code may be added through a WAF and/or an external platform which provides services to webpage 182.

Assuming an innocent user accesses webpage 182 and enters their actual ID and password for accessing the website of www.mybank.com, not realizing that they’ve access webpage 182 which is on a fake website. As shown, 006095IL the user enters in ID field 186 their ID name as "user1@example.com" and in password field 188 their password as "ajFUh749!D" and then pushes OK button 190. Normally, the data values entered into an ID field and password field are passed as parameters to a website backend for processing and gaining access to the personal information of the user, such as the user’s bank account. As shown by an arrow 210, according to the disclosed technique, a number of actions are performed before the values entered in ID field 186 and password field 188 are passed to the website backend of webpage 182, shown as a fake website backend 208, according to the obfuscated lines of code added to the authentic website. Not explicitly shown in Figure 3, first an authenticity check is performed on the lines of code of webpage 182, using any of the authenticity checks described above, to determine if webpage 182 is indeed an unauthenticated and fake website or whether the website is the genuine website. Once the authenticity check is performed, and assuming it returns a negative value, meaning webpage 182 is a fake webpage and is not authenticated, the lines of code make a determination if the user who entered the values in the ID field and the password field is an innocent user or a suspected malicious user (for example a hacker). As mentioned above, this determination can be made using any of the techniques mentioned above for bypassing a warning message to an innocent user, such as if a debugger tool is open in the web browser accessing the fake website or if the web browser accessing the fake website is running in incognito mode. If the determination determines that the user is a malicious user then no alterations are made to the sensitive information entered and the values in the ID and password fields are passed directly to fake website backend 208. This is done to dupe and confuse a malicious user into thinking that an innocent user accessing their fake website and entering in their sensitive information will actually give the malicious user access to the innocent user’s account based on the sensitive information entered.

If the determination determines that the user is an innocent user, then the following actions, schematically shown as lines of code 192, are performed on the values entered into ID and password fields 186 and 188 before the values are passed to fake website backend 208. As shown, the value entered in ID field 186 is 006095IL retrieved, shown as a retrieved ID value 194. A slight change or alteration is then made to the ID value, such as changing a single letter and/or number in the ID value. As shown, ID value 194, which is "user1@example.com" was changed to an altered ID value 196, shown as "usur1@example.com" wherein the "e" of "user" was changed to a "u". As another example, a predefined number (such as ‘5’) may be added to the first number determined in the ID value entered in ID field 186.

Thus, if an innocent user entered "1761user@example.com", the altered ID value might be "1766user@example.com". Any known method can be used in this action provided it leaves the ID value resembling an ID value that appears likely that a human selected it and/or agreed to it (for example, in the case of authentic websites which provide a user with a selection of ID values to choose from for use with their account). In one embodiment of the disclosed technique, as described below, certain restrictions may be placed on such a method for increasing the chances that the altered ID value resembles an ID value that a human selected or agreed to. It is noted as well that ID field 186 is representative of any identifying credential field and thus may be instead a username field, an account number field, an account name field and the like. Once altered ID value 196 is generated, altered ID value 196 is entered into a hash function 198 for producing a hash value 200.

As shown, "usur1@example.com" has been turned into hash value "!a38712f4$".

As hash values may be significantly longer than the original value entered into the hash function, hash function 198 may include other procedures for selecting only a portion of the actual hash value produced and then appending symbols to the portion of the actual hash value. Hash values may be significantly longer than the original value entered into the hash function depending on the hash function used (of which there are many known in the art). A hash value of 60 characters (for example) might appear suspicious to a malicious user looking at the ID value and password entered into the fields of their fake website as most users do not tend to enter passwords that are 60 characters long and most websites also set an upper limit of how long a password may be entered. The hash value of "usur1@example.com" using the hash algorithm md2 returns a value which is significantly longer than "usur1@example.com". Thus, in this example of the 006095IL disclosed technique as shown in Figure 3, only the first eight characters from the hash value of "usur1@example.com" using the hash algorithm md2 are used, generating "a38712f4". As this might also appear suspicious to a malicious user looking at the supposed ID value and password entered into their fake website, hash function 198 may also append symbols to the generated hash value, for example "!" to the beginning of the hash value and "$" to the end of the hash value.

Thus, as shown, hash function 198 generates hash value 200 as "!a38712f4$". As shown by an arrow 212, altered ID value 196 and hash value 200 are passed as the ID value and password entered by the innocent user in webpage 182 to fake website backend 208. Thus, as shown, altered ID value 196 is passed as ID value 206 and hash value 200 is passed as password value 204 to fake website backend 208, as shown by an arrow 214. Thus, even though the innocent user entered specific values to ID field 186 and password field 188 in webpage 182 of the fake website, the values received by fake website backend 208 which the malicious user has access to have been altered. It is noted as well, depending on the function used for hash function 198, that the domain address of the fake website may be used as at least a portion of the input to hash function 198. Thus, the altered password may encode the domain address of the fake website. If the malicious user then accesses the authentic website with an altered ID and an altered password, the inverse function of hash function 198 may be used on the entered altered password by the authentic website backend to determine the identity (i.e., the domain address) of the fake website. This information can be passed on to the innocent user, the owner of the authentic website and/or to law enforcement authorities.

According to the disclosed technique, hash function 198 can be replaced by any function (or a set of functions) for altering an entered password to something else which resembles what a password either entered or selected by a human user would look like. Other examples of hash function 198 are offered below. As should be clear from the description above, an altered ID and an altered password according to the disclosed technique are not stored or provided to a third party server, thereby preventing a hacker from sniffing the network and determining if the 006095IL lines of code of the authentic website alter or modify (for example, on purpose) ID values and/or passwords for security reasons. Thus, according to the disclosed technique, if a determination is made that an innocent user entered sensitive information on an unauthenticated website, the ID value and password entered are altered locally such that the backend of the fake website receives an altered ID value and password and not the ID value and password which the user originally entered.

As further shown in Figure 3, according to the disclosed technique, the inserted code added to the authentic website for protecting information entered into sensitive information fields on the authentic website can also determine if an ID value and password entered on the authentic website were altered values derived from an innocent user accessing a fake website cloned from the authentic website.

Thus, the disclosed technique also enables the detection of a malicious user attempting to use a stolen ID name and password entered on a fake website cloned from the authentic website when accessing the authentic website with the stolen ID name and password. As shown, fake website backend 208 receives an altered ID value and password from the innocent user who access webpage 182. The malicious user who created webpage 182 thinks that altered ID value 206 and altered password 204 are the ID value and password of the innocent user and may then attempt to access the authentic website with the credentials entered in by the innocent user in webpage 182. As shown by an arrow 216, a malicious user enters altered ID value 206 in ID field 222 and altered password 204 in password field 2 and then pushes OK button 226. Similar to what was described above, the inserted code for protecting information entered into sensitive information fields in the authentic website makes a determination if webpage 218 is part of an authentic website using any of the authenticity checks described above in Figure 1. Since "www.mybank.com" is an authentic website, the authenticity checks of the disclosed technique will return a positive result. Also, since www.mybank.com is an authentic website, there is no simple indication of whether values entered into ID field 222 and password field 224 from are an innocent user trying to access their account or a malicious user trying to gain access to the innocent user’s account. 006095IL According to the disclosed technique, the values entered in ID field 222 and password field 224 can have similar actions performed on them as in the case of a fake website (which was schematically shown as lines of code 192) in order to determine if the values entered into ID field 222 and password field 224 are altered ID and password values (and thus indicating a malicious user attempting to gain access to the account of an innocent user) or the actual ID and password values of an innocent user genuinely attempting to gain access to their account. These actions are shown schematically as lines of code 228 and occur after a user enters values in ID field 222 and password field 224 but before those values are passed to the website backend of the authentic website (shown as an authentic website backend 242), shown by an arrow 238.

As shown, the value entered in ID field 222 is retrieved, shown as a retrieved ID value 230. Since the authenticity check turned out positive, retrieved ID value 230 is not altered. Instead, retrieved ID value 230 is entered into a hash function 232 for producing a hash value 234. Hash function 232 is substantially similar to hash function 198 and applies the same additional procedures (if relevant) as mentioned above regarding hash function 198. Thus, if only a portion of the actual hash value produced is used and symbols are appended to the portion of the actual hash value in hash function 198, then similar procedures are performed in hash function 232. As shown, since hash function 232 and hash function 198 are substantially equivalent, therefore an ID value of "usur1@example.com" will return a hash value 234 of "!a38712f4$" using hash function 232. An if then clause 236 is applied to verify if there is an equivalence between the value entered by the user in password field 224 and hash value 2 determined from the value entered by the user in ID field 222. If hash value 234 is equivalent to the password value entered in password field 224, then the probability is very high that the ID value entered in ID field 222 is an altered ID value which was altered by the same lines of code in a fake website cloned from the authentic website. In such a case, instead of passing the values entered into ID field 222 and password field 224 to authentic website backend 242 in order to access a user’s account, the values entered into ID field 222 and password field 224 are passed to 006095IL authentic website backend 242, shown via an arrow 240, with an additional indication that the values being passed were altered values. As shown by an arrow 246, authentic website backend 242 can then issue a warning message 244 to, for example, the authentic website owner, that an altered ID and password were entered in the authentic website in an ostensible attempt by a malicious user to gain access to the account of an innocent user. Authentic website backend 2 can also issue warning message 244 to the innocent user via other communication channels stored for the innocent user (such as via e-mail, SMS and the like), indicating that an attempt to access their account has occurred and that a malicious user has almost succeeded in stealing their ID and password. According to the disclosed technique, even though an altered ID was entered in the authentic website, a fuzzy matching algorithm can be used by the authentic website backend to identify the actual innocent user from whom the malicious user attempted to steal their credentials. According to such a fuzzy matching algorithm, the authentic website backend knows all the valid IDs which have logged into the authentic website and also knows that the altered ID was altered by at most one or two characters. A list can then be compiled of all valid IDs which almost match the altered ID by a change in one or two characters at most. If only a single valid ID is determined in such a list, then the valid ID is the ID of the innocent user to be contacted with a warning message. If more than a single valid ID is determined in such a list, then the valid IDs can be checked to determine if any of those users have visited the fake website. As mentioned above and also described below, hash function 198 may encode the domain address of the fake website in the altered password, therefore the authentic website backend can determine which fake website the innocent user visited that led to the malicious user attempting to steal their credentials. Thus, a reduced list of valid IDs can be determined that visited the fake website encoded in the altered password. Again, if only a single valid ID from the reduced list is determined, then that single valid ID is the ID of the innocent user to be contacted with a warning message. If more than a single valid ID is determined in the reduced list, then all those valid IDs can be contacted with a warning message, as at least one of them is the actual innocent user whom the 006095IL malicious user lured to the fake website and almost stole their credentials. Such a warning message might also include a request from the innocent user that they change their ID and password for the authentic website immediately. The warning message may further indicate to the innocent user that they have accessed a fake version of the authentic website and should thus be more careful when attempting to access the authentic website that they have indeed accessed the authentic website.

As can be seen from Figure 3, the disclosed technique can protect an unsuspecting end user (i.e., an innocent user) that is about to disclose credentials (i.e., sensitive information) such as usernames and passwords, a one-time password, banking card information or credit card information to an imposter website (i.e., an unauthenticated website). As described above, the implementation of the disclosed technique as shown in Figure 3 is an obfuscated code snippet that is embedded into the lines of code of the authentic website as at least one script that changes the credentials entered by an innocent end user on an imposter website such that fake website backend 208 is not able to collect the true credentials of the innocent end user. As also mentioned above, the obfuscated code snippet includes measures to distinguish between an unsuspecting user accessing the imposter website and the malicious user (i.e., an attacker or hacker) debugging their imposter website. Also as described above, according to the disclosed technique, the credentials of the user entered on the imposter website are only changed and altered when a determination is made that the credentials entered where entered by the unsuspecting user. In the case of a malicious user, the credentials are left unchanged when they access their own imposter website, for example for the purposes of debugging their imposter website.

Figure 3 has presented an example of how the credentials of an innocent user can be modified when it is determined that an innocent user has accessed an imposter website and has provided credentials to the imposter website. However, other implementations are possible and according to the disclosed technique, any implementation thereof should include the following characteristics: 30 006095IL  Complete network silence, meaning an inability for an attacker to detect the sensitive information alteration mechanism by sniffing the network. Altered credentials are therefore not sent to any legitimate backend server and/or saved as marked altered credentials.

 The altered credentials must look like a human being has selected them and not like a randomly selected sequence. This imposes strict restrictions of the content and length of the altered credentials, such as an altered password.

 If at any later stage, a hacker or attacker decides to use the altered credentials collected by the imposter website, the genuine website must be able to detect them. And this is without the genuine website having access to a record of altered credentials.

 Since this implementation of the disclosed technique is substantially a third party offering to genuine website owners, the detection of marked and/or altered credentials cannot be done by the backend server of the third party. This is a reasonable characteristic since the genuine website owner (i.e., the client) is not likely to allow the third party backend server to keep and store the sensitive information and credentials of their users.

Figure 3 described a relatively simple process for slightly altering the credentials of an innocent user that involved changing a single character in the user’s ID value, using the altered ID value as input to a hash function and then appending further characters to the hash value outputted by the hash function to generate an altered password. This was merely an example and further examples are provided herein below which are more complex and can also provide information regarding the imposter website within the altered credentials. In a first example, at least one or two characters are modified in the user’s ID value as entered into ID field 186. The modified ID value is then used as an input to a hash function, similar to what was shown in Figure 3 as hash function 198. However, in this example the output of the hash function is then encoded into a sequence of 006095IL consonant-vowel pairs of Latin letters creating a word of a predetermined length, for example, a six character word. The website address (for example, the domain name) of the imposter website can then also be inputted to a second hash function (not shown), such as using a Base64 hash function, and then added to the word of predetermined length generated by the first hash function (i.e., hash function 198), thus creating an expanded altered password. Two or three additional characters can also be added to the expanded altered password as generated by a random number generator function thus forming the final outcome of an altered password to be forwarded to fake website backend 208. As a slightly different example from what was shown in Figure 3, assuming the user ID entered into ID field 186 was "user1@example.com", a character or two may get changed such that the altered user ID value is "usar1@example.com", and assuming that instead of "www.fake.mybank.com", the imposter website has a domain name of "www.fakesite.com". As an example of the disclosed technique, in order to increase the chances that the altered user ID appears to a malicious user like a user ID which a human (i.e., an innocent user) chose and is not a computer-generated ID which might appear to be random, the following conditions may be used when the user ID entered into ID field 186 is altered by a character or two. First, only the characters to the left of the "@" sign are altered, thus in the example above, no characters in the domain suffix "@example.com" are altered, only characters in "user1" are altered. Second, when a character in the user ID is changed, the category of character is changed for another character in the same category, thus vowels are altered only to other vowels, consonants are altered only to other consonants and non-alphabetic characters (i.e., numbers and/or symbols) are altered only to other non-alphabetic characters. Assuming further that the final outcome altered password is to have twelve characters, the first hash function is used on "usar1@example.com" to generate the first six characters of the altered password as "caTeli". The domain name of the imposter website is then used as input to a Base64 hash function for generating the next three characters in the altered password and the last three characters are generated from a random number generator. Thus, the altered password passed to fake website backend 006095IL 208 might be "caTelif7jkk4" where "f7j" is the Base64 hash function value of "www.fakesite.com" and "kk4" are randomly generated characters.

According to the above example, if the malicious user attempts to enter "usar1@example.com" and "caTelif7jkk4" in the ID and password fields of the genuine website which www.fakesite.com is trying to pass off as, the lines of code embedded in the genuine website will begin computing a hash value for "usar1@example.com" as per the hash functions listed above. If, for example, the first six characters of the computed hash function miraculously match the first six characters of the entered password, it can be known with high probability that the entered credentials were altered credentials by lines of code in www.fakesite.com copied from the genuine website which www.fakesite.com is trying to copy.

Depending on the first hash function used to generate the first six characters of the altered password based on the altered ID value, the probability of a false positive can be one in a billion if not even higher, thus making the chances of a false positive completely irrelevant for all practical purposes. The next three characters of the entered password can then be entered into a reverse Base64 hash function to generate the domain name of where the innocent user entered their credentials which generated the altered credentials which the malicious user entered into the genuine website. The domain name can then be passed as warning message 2 to the owner of the genuine website in order to take action against www.fakesite.com (for example by informing ISPs to put this domain name on various blacklists and/or by informing law enforcement authorities). The domain name can also be passed to the innocent user as warning message 244 via other communication channels as mentioned above (e-mail, SMS and the like), thus letting the innocent user know where (i.e., on which website (albeit fake)) a phishing attempt was made to steal their ID value and password. As mentioned above, this is merely another example of an implementation of the disclosed technique.

As another example of how an altered password is generated, the user ID value may be changed by a single character, however instead of using hash function 198 to generate the first six characters of the altered password, hash function 198 can be used to select two four-letter words from the English language. 006095IL A dictionary of 200 such words can be added as part of the lines of code added to the genuine website, thus hash function 198 is used to select two of those words, giving 200 possibilities for an eight character word. An uppercase-lowercase binary encoding can then be used to change the case of the eight characters forming the altered password, thus giving 2 further possibilities and in total 200x2 possibilities (~40 million password combinations). This eight character word can then be encoded according to the hash value of hash function 198. As mentioned above, a further hash function can be used to encode the domain name of the imposter website and added to the altered password and then further characters can be added to the altered password using a random number generator function, as described above. Similar to the previous example, similar encoding is performed on ID and password values entered into the ID and password fields of the genuine website, and if there is a miraculous match between the encoding of the entered ID value with the entered password, it can be ascertained with very high certainly that the entered ID and password values were actually altered ID and password values generated by an imposter website that an innocent user accessed and provided therein their credentials.

According to further examples of the disclosed technique, the combinations and positions of the characters selected for the altered password can be shuffled, the words stored in the aforementioned dictionary can be changed (for example, more words, longer words, shorter words and the like) and different encoding functions (i.e., not just hash functions) can be used to encode the altered ID value and generate the altered password. Reference is now made to Figure 4, which is a schematic illustration of a method for altering sensitive information of a network user entered on an unauthenticated website, operative in accordance with another embodiment of the disclosed technique. In a procedure 270, at least one line of code (i.e., a code snippet) is inserted into the lines of code of an authentic website, for altering sensitive information fields in the authentic website. As mentioned above, the inserted code can also be inserted through a WAF and/or an external platform which provides service to the authentic website. As described below, the inserted 006095IL code can determine if credentials entered into specific information fields of a cloned website should be altered and also if credentials entered into specific information fields of the authentic website are indicative of altered credentials derived from the cloned website. The sensitive information fields can include ID values, usernames, selected passwords, generated passwords, one-time passwords, account numbers, account names and the like. In a procedure 272, the inserted code for altering sensitive information fields in the lines of code of the authentic website is obfuscated. The lines of code can be obfuscated using any known obfuscation technique. As mentioned above, due to the obfuscation of these lines of code, it is assumed that if the authentic website is cloned then the fake website which is generated will nonetheless also contain these lines of code. With reference to Figure 3, the lines of code of the authentic website include obfuscated lines of code for protecting sensitive information entered into specific fields on the webpages of the website, such as ID field 222 (Figure 3) and password field 224 (Figure 3). The lines of code alter the ID and password entered into the ID and password fields in the case of a fake website cloned from the authenticated website which is accessed by an innocent user.

In a procedure 274, when a user accesses a website, the lines of code include a determination of whether the website accessed is an authentic website or a fake (i.e., unauthenticated) website. As mentioned above in Figure 2, the disclosed technique provides for authenticity checks for determining if an accessed website is a genuine, authentic website or rather a clone of the genuine website.

The authenticity checks can include determining whether scripts in the accessed website come from the DOM of the authentic website or not. In this procedure, as it is unclear what kind of user (i.e., innocent versus malicious) is accessing the website (i.e., authentic versus unauthenticated), a determination is first made as to whether the accessed website is genuine or fake. In the case of a fake website, the method proceeds to procedure 276. In the case of an authentic website, the method proceeds to procedure 282. With reference to Figure 3, first an authenticity check is performed on the lines of code of webpage 182 (Figure 3) to determine if webpage 182 is indeed an unauthenticated and fake website or whether the 006095IL website is the genuine website. This determination can be made using any of the authenticity checks mentioned above in reference to Figure 1.

In a procedure 276, when the determination of procedure 274 determines that the accessed website is an unauthenticated website, then a determination is made if the user accessing the website is an innocent user or a malicious user.

This determination can be made based on network data of the web browser accessing the unauthenticated website as described above, such as if a debugger tool is open in the web browser, if the web browser is operating on a local network and/or if the web browser is operating in incognito mode. With reference to Figure 3, once the authenticity check is performed, and assuming it returns a negative value, meaning webpage 182 (Figure 3) is a fake webpage and is not authenticated, the inserted code makes a determination if the user who entered the values in the ID field and the password field is an innocent user or a suspected malicious user (for example a hacker). This determination can be made using any of the techniques mentioned above for bypassing a warning message to an innocent user, such as if a debugger tool is open in the web browser accessing the fake website or if the web browser accessing the fake website is running in incognito mode.

In a procedure 278, if the determination of procedure 276 is that the user is an innocent user, then the inserted code from procedure 270 is applied for altering credentials entered into sensitive information fields in the fake website.

Thus, if the innocent user enters credentials in the fake website, the inserted code alters the credentials before they are passed to the backend of the fake website. As mentioned above, the credentials can be altered by slightly changing at least one character of an identifying credential (such as a username, ID value and the like) and using the altered identifying credential as input to a function for generating a password, where the function may be a hash function. With reference to Figure 3, if the determination determines that the user is an innocent user, then the following actions, schematically shown as lines of code 192 (Figure 3), are performed on the values entered into ID and password fields 186 (Figure 3) and 30 006095IL 188 (Figure 3) before the values are passed to fake website backend 208 (Figure 3).

In a procedure 280, if the determination of procedure 276 is that the user is a malicious user (i.e., a hacker), then the inserted code from procedure 270 is not applied for altering credentials entered into sensitive information fields in the fake website. Thus, if a hacker is attempting to debug their fake website (and such a determination is made in procedure 276), in this procedure any credentials entered into sensitive information fields in the fake website are left as is and unaltered. A malicious user is thus tricked into thinking that credentials entered into their fake website by an unassuming user will be accurately passed to their website backend.

With reference to Figure 3, if the determination determines that the user is a malicious user then no alterations are made to the sensitive information entered and the values in the ID and password fields are passed directly to fake website backend 208 (Figure 3). This is done to dupe and confuse a malicious user into thinking that an innocent user accessing their fake website and entering in their sensitive information will actually give the malicious user access to the innocent user’s account based on the sensitive information entered.

In a procedure 282, when the determination of procedure 274 as mentioned above determines that the accessed website is the authentic and genuine website, then the inserted code for altering sensitive information fields is applied. Thus, when the user (i.e., either innocent or malicious) accesses the authentic website and enters credentials in sensitive information fields (such as an ID field and a password field), the lines of inserted code mentioned above in procedure 270 are applied. In the case of an authentic website, the inserted code does not alter the entered identifying credential but rather uses the entered identifying credential as input to a function for generating a password (i.e., an encoded value of a sensitive information field) based on the entered identifying credential. The function mentioned here is the same function used in procedure 278 and can be a hash function. With reference to Figure 3, the value entered in ID field 222 (Figure 3) is retrieved, shown as a retrieved ID value 230 (Figure 3). Since the authenticity check turned out positive, retrieved ID value 230 is not 006095IL altered. Instead, retrieved ID value 230 is entered into a hash function 232 (Figure 3) for producing a hash value 234 (Figure 3). Hash function 232 is substantially similar to hash function 198 (Figure 3) and applies the same additional procedures (if relevant) as mentioned above regarding hash function 198. The values entered in ID field 222 (Figure 3) and password field 224 (Figure 3) can have similar actions performed on them as in the case of a fake website (which was schematically shown as lines of code 192 (Figure 3)) in order to determine if the values entered into ID field 222 and password field 224 are altered ID and password values (and thus indicating a malicious user attempting to gain access to the account of an innocent user) or the actual ID and password values of an innocent user genuinely attempting to gain access to their account.

In a procedure 284, an encoded value of a first sensitive information field is compared to the value of a second sensitive information field. If the two values are equivalent, then a warning message is flagged. As mentioned in procedure 282, the value of an identifying credential is used as input to a function for generating the value of another credential, such as a password. Thus, the value of the identifying credential is encoded to generate the value of a second credential, such as a password. In this procedure, the encoded value of a first sensitive information field (such as the value entered into the identifying credential which is then used as input to a function for generating a password, for example) is compared to the value entered into a second sensitive information field (such as the value actually entered by the user in the password field on the authentic website).

If the two values are equivalent (i.e., indicating with high probability that the credentials entered were credentials entered by an unassuming user on a fake website which altered the credentials passed to the backend server of the fake website), then a warning message is flagged. As mentioned above, the warning message can be sent to the authentic website owner, the innocent user or both, indicating that a phishing attempt has occurred and that the innocent user divulged credentials and sensitive information on an unauthenticated website. With reference to Figure 3, an if then clause 236 (Figure 3) is applied to verify if there is an equivalence between the value entered by the user in password field 224 006095IL (Figure 3) and hash value 234 (Figure 3) determined from the value entered by the user in ID field 222 (Figure 3). If hash value 234 is equivalent to the password value entered in password field 224 then the probability is very high that the ID value entered in ID field 222 is an altered ID value which was altered by the same lines of code in a fake website cloned from the authentic website. In such a case, the values entered into ID field 222 and password field 224 are passed to authentic website backend 242 (Figure 3) with an additional indication that the values being passed were altered values. Authentic website backend 242 can then issue a warning message 244 (Figure 3) to, for example, the authentic website owner, that an altered ID and password were entered in the authentic website in an ostensible attempt by a malicious user to gain access to the account of an innocent user.

Authentic website backend 242 can also issue warning message 244 to the innocent user via other communication channels stored for the innocent user (such as via e-mail, SMS and the like), indicating that an attempt to access their account has occurred and that a malicious user has almost succeeded in stealing their ID and password. It will be appreciated by persons skilled in the art that the disclosed technique is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the disclosed technique is defined only by the claims, which follow. 20

Claims (37)

006095IL -48- CLAIMS

1. A method for alerting a network user upon said network user’s access to an unauthenticated website comprising the procedures of: inserting at least one authenticity check into the lines of code of an authentic website; obfuscating at least one line of code representing said at least one authenticity check inserted into said lines of code of said authentic website; and executing said at least one authenticity check when said network user accesses a website, said website being at least one of said authentic website and said unauthenticated website.

2. The method according to claim 1, wherein said unauthenticated website is a fake website cloned from said authentic website.

3. The method according to claim 1, wherein said at least one authenticity check comprises a single line of code.

4. The method according to claim 1, wherein said at least one authenticity check comprises a plurality of lines of code.

5. The method according to claim 1, wherein said at least one authenticity check is inserted into the lines of code of at least one webpage of said authentic website.

6. The method according to claim 1, wherein said at least one authenticity check is inserted into the lines of code of at least one cascading style sheet (CSS) of said authentic website.

7. The method according to claim 1, wherein said at least one authenticity check is inserted into the lines of code of at least one webpage of said authentic 006095IL -49- website and at least one cascading style sheet (CSS) of said authentic website.

8. The method according to claim 6, wherein said at least one authenticity check is embedded in said at least one CSS in a text-based image format.

9. The method according to claim 8, wherein said text-based image format is scalable vector graphics (SVG) format.

10. The method according to claim 6, wherein said at least one authenticity check is embedded in said at least one CSS in an unscripted form as executable code.

11. The method according to claim 1, wherein said at least one authenticity check is a nested executable script.

12. The method according to claim 1, wherein said at least one authenticity check verifies that all the scripts on said website come from a document object model (DOM) of said authentic website.

13. The method according to claim 1, wherein said at least one authenticity check is an executable script which inserts an invisible watermark on a displayed instance of said website only if a request for inserting said invisible watermark originated from a domain name of said authentic website.

14. The method according to claim 1, further comprising the procedure of executing at least one action if said at least one authenticity check returns a negative response.

15. The method according to claim 1, wherein said at least one authenticity check comprises at least one line of code for distinguishing between an attacker 006095IL -50- attempting to clone said authentic website and said network user accessing said unauthenticated website.

16. The method according to claim 15, wherein said at least one line of code for distinguishing between said attacker attempting to clone said authentic website and said network user accessing said unauthenticated website comprises a detection of at least one of the following: at least one debugger tool is open in a web browser accessing said unauthenticated website; said unauthenticated website is running on a local network; a device accessing said unauthenticated website is identified as at least one of a new device and an untrusted device; an IP address of said device accessing said unauthenticated website is located in a suspicious region; said device accessing said unauthenticated website is disconnected from a network; said web browser accessing said unauthenticated website is running in incognito mode; and said device accessing said unauthenticated website is identified as having been involved in previous policy violations.

17. The method according to claim 15, further comprising the procedure of performing at least one action if said at least one authenticity check distinguishes said network user as said network user accessing said unauthenticated website.

18. The method according to claim 17, wherein said at least one action is an active action for alerting said network user and is selected from the list consisting of: presenting a visual warning message to said network user; presenting an audible warning message to said network user; 006095IL -51- presenting a warning icon to said network user; and playing a sound to said network user.

19. The method according to claim 17, wherein said at least one action is a passive action and is selected from the list consisting of: sending a warning message to a backend of said authentic website that said network user has accessed said unauthenticated website; and sending a warning message to said backend of said authentic website to contact said network user through at least one communication channel that said network user has accessed said unauthenticated website.

20. The method according to claim 15, further comprising the procedure of bypassing a presentation of a warning message to said network user if said at least one authenticity check distinguishes said network user as said attacker attempting to clone said authentic website.

21. The method according to claim 15, further comprising the procedure of sending a warning message to a backend of said authentic website if said at least one authenticity check distinguishes said network user as said attacker attempting to clone said authentic website.

22. The method according to claim 17, wherein said at least one action comprises sending a message to an owner of said authentic website that said network user has accessed said unauthenticated website.

23. The method according to claim 1, wherein said procedure of obfuscating said at least one line of code is executed using an obfuscation technique selected from the list consisting of: Jscrambler; JavaScript Obfuscator. 006095IL -52-

24. A method for protecting credentials of a network user upon said network user’s access to an unauthenticated website and divulging said credentials to said unauthenticated website comprising the procedures of: inserting at least one line of code into the lines of code of an authentic website for altering at least one data value entered into at least one credential field in said authentic website; obfuscating said at least one line of code for altering at least one data value entered into said at least one credential field in said authentic website; when said network user accesses a website, determining if said website is said authentic website or said unauthenticated website; if said website is determined as said unauthenticated website, then determining if said network user is an innocent user or a malicious user; if said network user is determined as said innocent user, then applying said at least one line of code for altering at least one data value entered into at least one credential field in said unauthenticated website; and if said network user is determined as said malicious user, then not applying said at least one line of code for altering at least one data value entered into at least one credential field in said unauthenticated website.

25. The method according to claim 24, wherein said at least one credential field is selected from the list consisting of: a username field an ID field; an account name field; an account number field; a credit card number field; a banking card number field; and a password field.

26. The method according to claim 24, wherein said procedure of determining if said website is said authentic website or said unauthenticated website 006095IL -53- comprises the sub-procedure of applying at least one authenticity check to the lines of code of said website.

27. The method according to claim 26, wherein said at least one authenticity check is selected from the list consisting of: verifying that all the scripts on said website come from a document object model (DOM) of said authentic website; an executable script which inserts an invisible watermark on a displayed instance of said website only if a request for inserting said invisible watermark originated from a domain name of said authentic website; and comparing a domain name of said website to an array of authorized domain names.

28. The method according to claim 24, wherein said procedure of determining if said network user is an innocent user or a malicious user comprises the sub-procedure of detecting at least one of the following: at least one debugger tool is open in a web browser accessing said unauthenticated website; said unauthenticated website is running on a local network; a device accessing said unauthenticated website is identified as at least one of a new device and an untrusted device; an IP address of said device accessing said unauthenticated website is located in a suspicious region; said device accessing said unauthenticated website is disconnected from a network; said web browser accessing said unauthenticated website is running in incognito mode; and said device accessing said unauthenticated website is identified as having been involved in previous policy violations. 30 006095IL -54-

29. The method according to claim 24, wherein said procedure of applying said at least one line of code for altering at least one data value entered into at least one credential field in said unauthenticated website comprises the sub-procedures of: altering at least one character in a first data value entered into a first one of said at least one credential field thereby generating an altered first data value; using said altered first data value as an input into a function for generating a second data value; and passing said altered first data value and said second data value to a backend server of said unauthenticated website.

30. The method according to claim 29, wherein said function is selected from the list consisting of: a hash function; and an encoding function.

31. The method according to claim 24, further comprising the procedures of: if said website is determined as said authenticated website, then applying said at least one line of code for altering at least one data value entered into at least one credential field in said authenticated website; comparing an altered data value of a first data value entered into a first one of said at least one credential field in said authenticated website with a second data value entered into a second one of said at least one credential field in said authenticated website; and flagging a warning message if said altered data value is equivalent to said second data value entered into said second one of said at least one credential field in said authenticated website.

32. The method according to claim 31, further comprising the procedure of sending said warning message to an owner of said authentic website. 006095IL -55-

33. The method according to claim 31, further comprising the procedure of sending said warning message to said network user determined as said innocent user through at least one communication channel associated with said network user.

34. A method for alerting a network user upon said network user’s access to an unauthenticated website comprising the procedures of: injecting at least one authenticity check to an authentic website through at least one external platform providing at least one service to said authentic website; obfuscating at least one line of code representing said at least one authenticity check; and executing said at least one authenticity check when said network user accesses a website, said website being at least one of said authentic website and said unauthenticated website.

35. The method according to claim 34, wherein said at least one external platform is selected from the list consisting of: a website application firewall; and a content delivery network worker.

36. A method for protecting credentials of a network user upon said network user’s access to an unauthenticated website and divulging said credentials to said unauthenticated website comprising the procedures of: injecting at least one line of code into the lines of code of an authentic website through at least one external platform providing at least one service to said authentic website for altering at least one data value entered into at least one credential field in said authentic website; obfuscating said at least one line of code for altering at least one data value entered into said at least one credential field in said authentic website; 006095IL -56- when said network user accesses a website, determining if said website is said authentic website or said unauthenticated website; if said website is determined as said unauthenticated website, then determining if said network user is an innocent user or a malicious user; if said network user is determined as said innocent user, then applying said at least one line of code for altering at least one data value entered into at least one credential field in said unauthenticated website; and if said network user is determined as said malicious user, then not applying said at least one line of code for altering at least one data value entered into at least one credential field in said unauthenticated website.

37. The method according to claim 36, wherein said at least one external platform is selected from the list consisting of: a website application firewall; and a content delivery network worker.