System and method for website legitimacy verification

Abstract

The present invention provides a method and a system for verifying the legitimacy of websites in a simple and uniform manner. A central Verification Server, associated with a preselected well-known and trusted domain name, receives a verification request from a Client Website. The request includes a returnURL parameter, which comprises a URL pointing to the Webpage to be verified. The Verification Server checks whether the returnURL's domain name is legitimate, for example, by matching it against a whitelist of pre-approved domain names. If the check fails, the User is notified, and the process is aborted. The server displays a Verification Page under its own trusted domain name, indicating whether the check succeeded or not, and enabling the User to verify the server's identity (for instance, by inspecting the domain name in the address bar). Upon user confirmation, the server redirects the browser to the address indicated in the returnURL parameter, thereby assuring the User that the reopened Webpage is legitimate.

Description

[0001] SYSTEM AND METHOD FOR WEBSITE LEGITIMACY VERIFICATION

[0002] FELD OF THE INVENTION

[0003] The present invention relates to website authentication and security. More specifically, it concerns a method and a system for enabling end-users to easily and reliably verify the legitimacy of websites they are visiting, in order to protect them against phishing, fraud, and other malicious online impersonations.

[0004] BACKGROUND

[0005] Phishing remains a widespread and persistent threat despite the many efforts invested in combating it. Fraudulent actors continuously create fake replicas of well-known websites such as banking platforms, government portals, charity donation sites, and e-commerce checkouts, all aiming to deceive users into disclosing personal information, credit card numbers, passwords, or other sensitive data.

[0006] Conventional defense mechanisms typically rely on blacklists of malicious websites, protective software, and user training. These approaches, however, suffer from inherent shortcomings. Blacklists are reactive by nature: malicious websites are often reported and added only after they have been in circulation for days, during which countless users may have already been misled. Protective software packages are costly, require installation, updates, and technical knowledge, and are therefore unsuitable for the average User. Training users to identify suspicious websites depends heavily on their ability to notice subtle details such as misspelled domain names, swapped look alike characters (for example, "0" instead of "0", or "1" instead of "I"), or to interpret rather technical digital certificates and padlock icons— skills that are far from ordinary, especially among elderly or novice users.

[0007] Another existing approach is to instruct users to memorize and inspect domain names and validate PKI certificates of the websites they access. In practice, this expectation proves unrealistic. Most users lack the expertise to reliably distinguish between authentic and deceptive domain names or to analyze certificate details. Moreover, phishing sites often employ sophisticated techniques, such as domain typo-squatting, visual similarity, or the use of SSL certificates that appear genuine, further confusing the public.

[0008] As a result, none of the available solutions provides a simple, universal, and user- friendly mechanism that ensures users— regardless of theirtechnical skills— that the Website they are currently visiting is legitimate and not a scam.

[0009] There is, therefore, a strong and growing need for a mechanism that ensures website legitimacy verification in a manner that is consistent, simple, and accessible to all users, without requiring any specialized knowledge or technical abilities.

[0010] Various attempts have been made in the art to provide mechanisms for website verification and phishing prevention. A few notable examples are summarized below.

[0011] US 10,504,166 B2 -Method and system for website verification describes a method for verifying a website by storing legitimate website records in a registry, receiving a verification request for a website, and returning a code to be displayed on the Website. The User enters this code into a verification module to confirm that the Website matches the registry record. While this system enables verification against a registry, it requires the end-user to manually enter verification codes in order to complete the process. Such reliance on user input is impractical for the general public and particularly for users with no technical background. There is still a need in the art for a verification method that does not rely on code entry by the end-user and that allows for a universal and straightforward confirmation without requiring any technical skill.

[0012] US 11,575,666 -A website verification service discloses a system and method for verifying websites by registering websites with a verification service, associating verification credentials (such as codes or images), and presenting these credentials to users through the browser or a verification module, enabling the User to confirm that the Website is legitimate.

[0013] This solution also relies on the User's ability to correctly interpret and validate special codes or images. In practice, many users cannot be expected to reliably remember or recognize verification images or strings, and mistakes may compromise the verification process. There is still a need in the art for a method that provides website legitimacy verification without requiring end-users to recall or identify special credentials, and that delivers a clear and immediate indication of trust.

[0014] US 7,877,784 B2 -Verifying authenticity of webpages discloses a method and system for verifying the authenticity of webpages by analyzing certificates, DNS information, and other technical attributes of a requested webpage in order to confirm that the Webpage is authentic and not a fraudulent copy.

[0015] This approach depends on the User's or system's ability to analyze technical certificate data and DNS records. While effective in theory, most end-users are unable to interpret such information or to distinguish between valid and invalid certificates. There is still a need in the art for a solution that provides an immediate and user-friendly verification of website authenticity without requiring the User to perform any technical inspection.

[0016] US 9,276,956 B2 - Method for detecting phishing website without depending on samples, describes a method for detecting a phishing website that includes extracting a domain name from a target URL, querying PageRank and / or Alexa ranking of the domain, extracting keywords from the page title, and comparing domain information and server IP addresses to determine whether the Website is a phishing website. The disclosed method overcomes the difficulty in collecting phishing samples and is adapted to detect phishing aimed at new targets.

[0017] This method relies heavily on heuristics, rankings, and keyword analysis. Such techniques can be helpful but are prone to false positives and negatives, and cannot guarantee certainty for the end-user. Moreover, they depend on external services and reputation scores that may not always be up-to-date or available. There is still a need in the art for a website verification mechanism that does not depend on statistical or heuristic analysis, but instead provides a definitive, trusted indication of legitimacy directly to the end-user

[0018] SUMMARY OF THE INVENTION

[0019] The present invention provides a method and a system for verifying the legitimacy of websites in a simple and uniform manner. A central Verification Server, associated with a preselected well-known and trusted domain name, receives a verification request from a Client Website. The request includes a returnllRL parameter, which comprises a URL pointing to the Webpage to be verified.

[0020] The Verification Server checks whether the returnURL's domain name is legitimate, for example, by matching it against a whitelist of pre-approved domain names. If the check fails, the User is notified, and the process is aborted. The server displays a Verification Page under its own trusted domain name, indicating whether the check succeeded or not, and enabling the User to verify the server's identity (for instance, by inspecting the domain name in the address bar). Upon user confirmation, the server redirects the browser to the address indicated in the returnURL parameter, thereby assuring the User that the reopened Webpage is legitimate.

[0021] The invention repurposes the conventional returnURL mechanism. Instead of merely redirecting users after an action, the returnURL is first verified by a trusted server against a whitelist of legitimate domains, and only after user verification of the server's identity, the User is then redirected. This guarantees that the destination webpage is authentic.

[0022] This mechanism reduces user effort to a single consistent action — verifying that the Verification Page's domain name is the server's trusted one — and avoids reliance on technical skills, blacklist scanning, or complex manual inspection. Furthermore, there is no need for software installation, memorizing various domain names and their spelling, or end-user pre-registration. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Fig. 1 illustrates the overall verification workflow, in which a central Verification Server associated with an assumed trusted domain name (e.g., SeclIRL.xyz) interacts with Client Websites. The figure shows the Verify button on the Client page, the issuance of a Verification Request including a returnllRL parameter, the verification against a whitelist of legitimate domains, the display of the Verification Page with a Confirm button, and the Final Redirection back to the Client page once legitimacy is assured.

[0024] Fig. 2 illustrates the Client-side operation. The figure shows a Client Webpage (e.g., an e-commerce checkout page) defining a Verify button. When clicked, the button triggers the creation of a Verification Request, including the returnllRL parameter set to the current page's URL, and sends it to the Verification Server.

[0025] Fig. 3 illustrates the Server-side operation. The figure shows the extraction of the domain name from the returnURL parameter, verification against the Whitelist of legitimate domains, the display of the Verification Page hosted under the trusted domain, the User's confirmation step after having verified that the Verification Page's domain name is SecURL.xyz, and the Server's Final Redirection to the original Client webpage.

[0026] DEFINITIONS

[0027] In the description and claims of the present application, the following terms shall have the meanings ascribed to them herein. Such definitions are provided solely for clarity and convenience of understanding, and are not intended to limit, narrow, or otherwise restrict the scope of the invention beyond what is explicitly recited in the claims. Client Website: a website or online service that wishes to enable its users to verify its legitimacy by registering with the verification system described herein. The Client Website defines a 'Verify' button on selected webpages, preferably on those where users are required to provide sensitive information, such as credentials or payment details.

[0028] Verify button: a user interface element located on a selected webpage of the Client Website. Activation of the Verify button (typically by clicking it) initiates the verification process by issuing a Verification Request directed to the Verification Server. returnURL: a URL address included as a parameter in the Verification Request. It typically points to the current Webpage containing the Verify button, although it may point to any webpage (including webpages under different domain names). The returnURL represents the Webpage whose legitimacy is to be verified and to which the User will be redirected upon successful completion of the verification process.

[0029] Verification Server ("Server"): a central server or distributed system associated with a trusted entity, and having a preselected, well-known publicly published domain name. The server receives Verification Requests including a returnURL parameter, verifies the legitimacy of returnURL addresses, displays a Verification Page for user confirmation, and upon positive confirmation, performs the Final Redirection.

[0030] Legitimate Domain Names Whitelist: a registry or database stored and maintained by the Verification Server or by an affiliated or third-party entity, comprising pre-approved domain names that the server's operator has verified as legitimate. The Whitelist entries may include any combination of domain names, sub-domains, paths, and specific webpages (which, for the sake of readability, are all referred to herein as domains or domain names), and may be populated by the trusted operator of the Verification Server or by authorized entities. Examples for entries include: mydomain.com, blog.mydomain.com, and jacksmith.wixsite.com / elegant_bags.

[0031] End-User: a person operating a browser or other client application who interacts with the Client Website and wishes to verify that the displayed Webpage is legitimate. The End-User activates the Verify button, inspects the Verification Page to confirm the server's identity, and upon satisfaction, presses the Confirm button to proceed.

[0032] Verification process: the sequence performed by the Verification Server upon receiving a Verification Request. The process includes verifying that the return URL's domain name appears in the Legitimate Domain Names Whitelist and / or is not in a blacklist, enabling the User to validate the server's identity through a Verification Page, and performing the Final Redirection upon confirmation. The Verification process may further include additional steps or variations, as described in exemplary embodiments.

[0033] Verification Page: a webpage generated by the Verification Server and displayed under its preselected domain name. The page contains information that enables the User to verify that the page is genuinely served by the server, and includes features such as a Confirm button for positive user confirmation.

[0034] Verify Action: the action triggered when the User clicks the Verify button, whereby the returnURL is passed to the Verification Server as a parameter, and the server is requested to perform the Verification process. Confirm button: a user interface element located on the Verification Page. Pressing the Confirm button indicates that the User has successfully verified the server's identity, thereby authorizing the Final Redirection to the returnURL.

[0035] Final Redirection: the redirection carried out by the Verification Server, upon user confirmation, to the returnURL address. If the server determines that the returnURL is not legitimate, or if the User does not confirm the server's identity, no redirection is performed to the returnURL, and optionally, redirection may be performed to a safe webpage, e.g., www.google.com.

[0036] DETAILED DESCRIPTION OF THE INVENTION

[0037] The invention will now be described by way of non-limiting embodiments with reference to the accompanying drawings. Unless stated otherwise, identical reference numerals denote functionally similar elements. Terms defined in the "Definitions" section shall apply throughout this document.

[0038] Overall Architecture

[0039] Referring to Fig. 1, the invention comprises a Verification Server 100, operated by a trusted entity and associated with a preselected, well-known domain name (e.g., SecURL.xyz).

[0040] Fig. 1 illustrates the overall verification workflow, in which a central Verification Server associated with an assumed trusted domain name (e.g., SecURL.xyz) interacts with Client Websites. The figure shows the Verify button on the Client page 110, the issuance of a Verification Request [1.1] including a returnURL parameter (typically comprising Webpage 110's URL) to Verification Server 100, the verification [1.2] against a whitelist 104 of legitimate domains, the display [1.4] of the Verification Page 130 with a Confirm button, and the Final Redirection [1.5] back to the webpage 120 pointed by the verified returnllRL parameter (typically to the original Webpage) once legitimacy is assured.

[0041] In some embodiments, the Verification Server communicates with a Legitimate Domain Names Whitelist 104, which stores pre-approved domain names that have been verified as legitimate. In other embodiments, the Verification Server may additionally or alternatively query one or more external databases maintained by affiliated or third-party entities, e.g., a Certificate Authority (CA) or Dun and Bradstreet, which maintains a considerable amount of verified organization-related information, to determine legitimacy.

[0042] In some embodiments, Client Websites that wish to obtain verification services from the Verification server 100 first need to register their domain names with Whitelist 104, and then integrate a Verify button on selected webpages, such as Client Webpage 110. In other embodiments, the Verify Action is initiated not by a button placed on the Client Webpage, but by a browser-integrated control such as a toolbar button, extension, or add-on, thereby allowing verification of any webpage currently displayed in the browser.

[0043] In some embodiments, the Verification Server further communicates with additional data sources, including but not limited to: (i) details of enrolled Client Websites (name, description, logo, contact, business-related information, seniority, etc.), and (ii) user-related information such as email addresses, phone numbers, or personal phrases. Enrolment and InstsaHzation

[0044] In some embodiments, Client Websites may enroll with the Verification Server by submitting identifying details for verification. The Server operator may review and approve the submitted domains prior to storing them in the Whitelist.

[0045] In yet other embodiments, the server may automatically check candidate domain names against one or more blacklists before approval, thereby preventing inclusion of known malicious domains.

[0046] In some embodiments, additional verified information associated with a Client Website (e.g., information from OV / EV SSL Certificates, logo, seniority, and other Website or business-related information) may be stored with the server. In further embodiments, the Verification Page displayed to users may further comprise such information, thereby augmenting user trust once the server's identity has been confirmed.

[0047] Verif atson Request Formation

[0048] Reference is made to Fig. 2. In some embodiments, a Verify button 204 is defined [2.1] on a sensitive webpage of a Client Website, such as a login or checkout page 200.

[0049] When the End-User clicks the Verify button [2.2], client-side code sets the returnURL parameter 224 to the URL of the current page [2.3] and constructs [2.4] a VerifyURL 234 pointing to the Verification Server's domain (securl.xyz). The VerifyURL includes the returnURL parameter. In conventional web applications, a returnllRL parameter designates the Webpage to which a user is redirected after completing an action, such as login or form submission. In the present system, this mechanism is utilized for a novel purpose: the returnllRL identifies the Webpage to be verified. The Verification Server verifies that the returnllRL domain is included in a whitelist of legitimate domains, displays a trusted Verification Page for user confirmation, and only thereafter redirects the User to the returnURL. Accordingly, the User may be assured that the reached Webpage is legitimate. The returnURL may represent the current Webpage or any other webpage, including pages under different domains.

[0050] In some embodiments, the Verification Request is issued by redirecting the browser to the VerifyURL [2.5], for example, using JavaScript code (window, location. href=VerifyURL).

[0051] In yet other embodiments, where the returnURL is fixed and known in advance, the Client Website may define the Verify button as a static hyperlink pointing directly to the Verification Server with the returnURL parameter preset (e.g., https: / / securl.xyz / verify?returnURL=https: / / BestShoesEver.com / cart).

[0052] Server-Side Processing

[0053] Reference is now made to Fig. 3. In some embodiments, upon receiving a Verification Request, the Verification Server extracts [3.1] the domain name from the returnURL parameter 310.

[0054] In some embodiments, the Server checks [3.2] whether the domain is present in the Whitelist 104. In another embodiment, the server may additionally or alternatively verify that the domain name is not included in a blacklist or perform any check known in the art.

[0055] If the domain name is not in the Whitelist 104, the server displays [3.3] a verification failure message and aborts [3.4]. In some embodiments, the failure message may further comprise instructions to the End-User to abort any interaction with the suspicious Website, and may optionally redirect the User to a safe website such as www.google.com (not shown).

[0056] If the domain is found in the Whitelist, hence legitimate, the server displays [3.5] a Verification Page 130 hosted under its preselected domain name (securl.xyz). Preferably, the Verification Page 130 and any error message replace the Client webpage 110 so that if the verification fails, the End-User should not continue with the potentially malicious Client webpage 110.

[0057] In some embodiments, the Verification Page contains a Confirm button and instructs the End-User to verify that the domain name in the address bar matches the preselected domain name. In other embodiments, the Verification Page may further comprise additional items of verification, such as:

[0058] • the domain name and other information in the TLS / SSL PKI certificate of the page,

[0059] • a browser-provided visual indication that the displayed domain name matches the trusted domain,

[0060] • a user-specific personal phrase, or

[0061] In some embodiments, the Verification page may display additional pre-stored verified information relating to the Client Website.

[0062] If the End-User has verified the preselected domain name and the Confirm button [3.7] is pressed, the Verification Server performs the Final Redirection [3.9] to the returnURL. Preferably, the Final Redirection is performed by the server itself, thereby preventing manipulation by client-side code. In some embodiments, the Final Redirection may be performed by a server-side JavaScript code (e.g., window. location. href=returnllRL).

[0063] If the User declines to confirm, the Verification process aborts [3.8], for example, by redirecting the User to a safe website such as www.google.com (not shown) or closing the current window altogether.

[0064] End-User Perspective

[0065] From the End-User standpoint, the procedure is simple and uniform across all enrolled websites. In some embodiments, the User activates the Verify button embedded in the Client Website. In other embodiments, the User activates a browser-integrated control to initiate the verification.

[0066] In either case, the User is redirected to the Verification Page hosted under the server's trusted domain. The only action required is to ensure that the Verification Page's domain is the preselected trusted domain name (e.g., SecURL. xyz) and then to click Confirm, which reopens the client webpage (120), now verified.

[0067] This uniformity removes any users' need to register, memorize domain spellings, detect homoglyphs, install protection software, or interpret certificate details. Accordingly, in some embodiments, the invention is particularly suitable for novice users and the elderly. Alternative and Additional Embodiments

[0068] In some embodiments, in addition to the Whitelist 104, the server may maintain a secure database (not shown) to store additional verification and Client website-related information.

[0069] In some embodiments, End-Users may sign up with the Verification Server, which may store a user code in the browser's local memory. The User may select a personal phrase which the server may store in its secure database along with the user code. When the Verification Page is displayed, the server retrieves the user code from the browser's local memory and displays the personal phrase associated with the matching user code in the secure database, enabling the End-User to verify authenticity at a glance, since only the Server and the User know the personal phrase.

[0070] In other embodiments, the personal phrase is transmitted to signed-up End Users out-of-band (e.g., via SMS, email, or voice call). In yet another embodiment, the browser may provide a special visual indication (e.g., colored or blinking address bar) when the Verification Page is displayed under the preselected domain.

[0071] In some embodiments, the Verification Request may include additional parameters, such as the Client website's EV / OV PKI certificate with verified information, etc., or session identifiers or cryptographic tokens, to further protect against tampering.

[0072] In yet another embodiment, the Verify Action may be initiated by a browser- integrated add-on or extension, enabling End-Users to verify pages that have not integrated the Verify button. Advantages

[0073] The invention provides a standardized, simple, and effective mechanism for verifying website legitimacy. Unlike prior art solutions that rely on blacklists, complex certificate inspection, software installation, user registration, or complex user training, and frequently require technical understanding, the present invention reduces the verification task to a single domain name checking involving a trusted Verification Server.

[0074] In some embodiments, the invention provides immediate confirmation to End- Users. In other embodiments, the invention provides extended security through additional verification items such as personal phrases, out-of-band communication, or browser indicators.

[0075] Overall, the invention offers a scalable solution for protecting users from phishing and fraudulent websites, requiring no technical expertise and minimal effort from the End-User.

Claims

CLAIMS1. A system for verifying the legitimacy of a Website, comprising: a Verification Server, a verification module, a display module, an input module, and a redirection module, wherein said Verification Server has a preselected domain name associated with a trusted entity, and wherein said verification module receives a Verification Request comprising a returnllRL identifying a webpage to be verified and performs a verification process on said returnllRL, and wherein said display module generates and serves, under said preselected domain name, a Verification Page comprising at least one item for verification and a Confirm button, and wherein said input module receives a confirmation from an End-User that the Verification Page has been verified, and wherein said redirection module performs a Final Redirection of a browser to said returnURL in response to said confirmation.

2. The system of claim 1, wherein said Verification Request is initiated by activation of a button embedded in said Website.

3. The system of claim 1, wherein said Verification Request is initiated by activation of a button embedded in a browser extension, toolbar, or add-on.

4. The system of claim 1, wherein said Verification Server comprises maintaining and accessing a whitelist of pre-approved domain names.

5. The system of claim 1, wherein said verification process comprises any combination of querying a whitelist of pre-approved domain namesfor the returnllRL's domain name, and verifying that the returnllRL's domain name is not listed in a blacklist.

6. The system of claim 1, wherein said display module generates a Verification Page further comprising a user-specific personal phrase displayed to the End-User.

7. The system of claim 1, wherein said Verification Server further comprises maintaining and accessing Website-related information.

8. The system of claim 1, wherein said display module generates a Verification Page further comprising a browser-generated visual indication that the displayed address bar domain name matches said server's preselected domain name.

9. The system of claim 1, wherein said Verification module sends the End-User a user-specific personal phrase via an out-of-band communication channel selected from the group consisting of SMS, email, or voice call.

10. The system of claim 1, wherein said Final Redirection's destination is different from the returnURL.

11. The system of claim 1, wherein said display module generates a Verification Page further comprising details of the Website selected from the group consisting of: name, logo, contact details, business details, seniority, and information relating to the Website's SSL Certificate.

12. The system of claim 1, wherein said verification process further comprises accessing a whitelist stored and maintained by an affiliated or third-party entity.

13. A method for verifying the legitimacy of a Website, comprising receiving, by a Verification Server associated with a trusted entity and having a preselected domain name, a Verification Request comprising a returnllRL identifying a webpage to be verified, performing a verification process on said returnllRL, generating and serving, under said preselected domain name, a Verification Page comprising at least one item for verification and a Confirm button, receiving a confirmation from an End-User that the Verification Page has been verified, and performing a Final Redirection of a browser to said returnURL in response to said confirmation.

14. The method of claim 13, wherein said Verification Request is initiated by activation of a button embedded in said Website.

15. The method of claim 13, wherein said Verification Request is initiated by activation of a button embedded in a browser extension, toolbar, or add-on.

16. The method of claim 13, wherein said verification process comprises accessing a whitelist of pre-approved domain names.

17. The method of claim 13, wherein said verification process comprises any combination of querying a whitelist of pre-approved domain names for the returnURL's domain name, and verifying that the returnURL's domain name is not listed in a blacklist.

18. The method of claim 13, wherein said Verification Page further comprises a user-specific personal phrase displayed to the End-User.

19. The method of claim 13, further comprising maintaining and accessing website-related information.

20. The method of claim 13, wherein said Verification Page further comprises a browser-generated visual indication that the displayed address bar domain name matches said preselected domain name.

21. The method of claim 13, further comprising sending the End-User a user-specific personal phrase via an out-of-band communication channel selected from the group consisting of SMS, email, or voice call.

22. The method of claim 13, wherein said Final Redirection's destination is different from the returnURL.

23. The method of claim 13, wherein said Verification Page further comprises details of the Website selected from the group consisting of name, logo, contact details, and business details, seniority, and information relating to the Website's SSL Certificate.

24. The method of claim 13, further comprising accessing a whitelist stored and maintained by an affiliated or third-party entity.

25. A non-transitory computer-readable medium having stored thereon instructions which, when executed by one or more processors of a Verification Server associated with a trusted entity and having a preselected domain name, cause the Verification Server to perform a method for verifying the legitimacy of a website, the method comprising receiving a Verification Request comprising a returnURL identifying a webpage to be verified, performing a verification process on said returnURL, the verification process including at least one of querying a whitelist of pre-approved domain names, and verifying that the returnURL is not listed in a blacklist, generating and serving, under said preselected domain name, a Verification Page comprisingat least one item for verification and a Confirm button, receiving a confirmation from an End-User that the Verification Page has been verified, and performing a Final Redirection of a browser to said returnURL in response to said confirmation.

26. The computer-readable medium of claim 25, wherein the Verification Page further comprises a user-specific personal phrase displayed to the End-User.

27. The computer-readable medium of claim 25, wherein the Verification Page further comprises details of the Website selected from the group consisting of name, logo, contact details, and business details, seniority, and information relating to the Website's SSL Certificate.

28. The computer-readable medium of claim 25, wherein the Final Redirection destination is different from the returnURL.

29. A computer program product comprising program code means for causing a computer to carry out the method of claim 13 when the program is run on a computer.

30. The computer program product of claim 29, wherein the program code further causes the computer to execute the method according to any one of claims 14 to 24.

Images