System and Method for Providing a Secure Access to a Webpage

The present invention relates generally to providing a secure access to a webpage, for example using a security object such as a token.

A phishing attack may refer to an attempt to steal sensitive information by an attacker masquerading as a trusted entity such as a bank or other organization that holds sensitive data. For example, the attacker may mislead a victim into opening an email, instant message, or text message and clicking a malicious link leading to a fake webpage appearing exactly like a real webpage of the trusted entity. The attacker, operating and monitoring the fake page, may request the user to enter his credentials, e.g., username and password. Once the user types this data into the fake webpage, the attacker may hijack the user credentials and use them to enter the user's account on the real trusted entity.

Phishing attacks can have devastating results. For individuals and organizations, this may include unauthorized purchases, the stealing of funds, identify theft or stealing sensitive information. Therefore, a method for preventing phishing attacks is required.

According to embodiments of the invention, a computerized system and method for providing a secure access to a webpage may include obtaining, at an authentication server from a user agent application, a request to open the webpage provided by a web server, together with a username; generating a token by the authentication server; providing, by the authentication server, the token to the user agent application and to the web server; sending, by the user agent application, a request to open the webpage together with the token to the web server; verifying, by the web server, the token obtained from the user agent application against the token obtained from the authentication server; and opening the webpage by the web server upon successful verification.

Embodiments of the invention may include signing the token by the user agent application using a private key owned by the user agent application prior to providing the token to the web server, where sending, by the user agent application, the token to the web server may include sending the signed token, where the web server may verify the signed token obtained from the user agent application against the token obtained from the authentication server using a public key corresponding to the private key.

Embodiments of the invention may include authenticating the user by the authentication server prior to generating the token.

According to embodiments of the invention, authenticating the user by the authentication server may include: sending, by the authentication server, a push notification to the user via a user device; and obtaining, at the authentication server, a user confirmation from the user device.

Embodiments of the invention may include operating a web browser by the user agent application.

Embodiments of the invention may include providing the webpage to the user through the web browser.

According to embodiments of the invention, providing the webpage may include: sending, by the authentication server to the web browser, a single sign-on (SSO) token; using the SSO token to authenticate the user; and opening the webpage via the web browser, upon successful verification of the SSO token.

According to embodiments of the invention, providing the webpage may include: sending, from the authentication server to the web browser, a single sign-on (SSO) token; sending, from the web browser to the authentication server, a request for executing the webpage; sending, from the web browser to the authentication server; the SSO token; authenticating the user, by the authentication server, using the SSO token; sending, from the authentication server to the web browser, a corresponding URL for the required webpage, upon successful verification of the user; sending from the web browser, a request to open the URL to the web server; forwarding the request to a verification service; verifying the SSO token by the verification service; and opening the webpage by the web server via the web browser, upon successful verification of the SSO token.

According to embodiments of the invention, the token may be valid for a limited period.

According to embodiments of the invention, a computerized system and method for providing a secure access to a webpage, the method may include: obtaining, in a user agent application, a request to open a webpage; sending, by the user agent application, the request to open the web portal to an authentication server, together with a username; generating a token by the authentication server; sending, by the authentication server, the token to the user agent application; sharing, by the authentication server, the token with a portal server; signing the token by the user agent application using a private key owned by the user agent application; sending, by the user agent application, the signed token together with an address of the webpage to the portal server; verifying, by the portal server, the signed token against the shared token using a public key corresponding to the private key; and opening the webpage by the portal server upon successful verification.

According to embodiments of the invention, sharing, by the authentication server, the token with a portal server may include: storing, by the authentication server, the token in a database common to the authentication server and to a portal server; and reading, by the portal server, the token from the common database.

It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

In the following description, various aspects of the present invention will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will also be apparent to one skilled in the art that the present invention may be practiced without the specific details presented herein. Furthermore, well known features may be omitted or simplified in order not to obscure the present invention.

Although some embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information transitory or non-transitory or processor-readable storage medium that may store instructions, which when executed by the processor, cause the processor to execute operations and/or processes. Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term “set” when used herein may include one or more items unless otherwise stated. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed in a different order from that described, simultaneously, at the same point in time, or concurrently.

Various methods known in the art are aimed at preventing phishing attacks. Multi-factor authentication (MFA) is a popular authentication method that requires the user to provide two or more verification factors on top of the username, for example one or more of a pin code, a biometric factor or a password and a one-time password (OTP). The user may typically receive the OTPs via email, SMS or a mobile application, and may be required to provide the OTP as part of a legitimate login process. However, MFA may not provide sufficient protection against some phishing attacks, for example dynamic phishing attacks. In a dynamic phishing attack, the fake webpage, after obtaining the username of the user, may use the username to login into the trusted entity, the trusted entity may send the OTP to the user in whichever way that is supported by the legitimate application, and the user, expecting the OTP, may provide the OTP to the fake webpage. Thus, the attacker may get the OTP from the user as well and use it to complete the login process.

In another example, the trusted entity may authenticate the user following a login request by sending a push notification message (e.g., a message initiated by a server) to a user device (such as a mobile phone of the user) and requesting the user to approve the request via an application on the user device. In a dynamic phishing attack, the fake webpage, after obtaining the username of the user, may use the username to login into the trusted entity, the trusted entity may send the push notification message to the user, and the user, expecting the push notification message, may approve the push notification message. Thus, the attacker may login into the trusted webpage without even having to obtain an OTP.

In another example, the attacker may use the username of the user to login into the trusted entity without the user trying to login to the fake web page. The trusted entity may send the push notification message to the user, and the user, accidently, may approve the push notification message. Thus, the attacker may login into the trusted webpage without even having to obtain an OTP or creating a fake webpage.

Typically, webpage or a website is stored and operated by a web server. When a client device, referred herein also as a local device) wants to access or open a webpage, a copy of the webpage may be downloaded from the server onto the client device and displayed in a web browser of the client device. Embodiments of the invention may provide a secure access to a webpage or a website, using a security object such as a token (e.g., an alphanumeric sequence or other data object) that is sent (e.g., via direct link, a network or provided through a common or shared database) from an authentication server to the web server or portal server and to a client device. According to embodiments of the invention, the requested webpage or website may open (e.g., downloaded and display on a client device) only after verification of the token sent to the client device against the token sent to the web server or portal server. Thus, a request for opening the webpage or website that is sent to the web server or portal server without the token may not be served. For example, a request obtained from an attacker after a successful phishing attempt, e.g., from an attacker that has succeeded in stilling the credentials and the MFA factors, e.g., an OTP, of the user, or if the user has approved an authentication message that was sent to the user device(depending on the verification method used by the legitimate webpage or a website, may not be served, since the attacker may not have access to the token and may not be able to provide the token to the webpage. Therefore, embodiments of the invention may improve the technology of protecting against phishing attempts and possible other illegitimate usage of stolen user credentials, by preventing access to the requested webpages from the attacker.

Reference is made to, which is a systemaccording to embodiments of the invention. According to some embodiments, local device, user device, authentication serverand web servermay include components of computing device. Systemmay include devices associated with a particular user such as local deviceand user device. Whilepresents devices associated with a single user and a single web server, this is done for simplicity only and systemmay include a plurality of devices associated with a plurality of users and a plurality of web servers.

Networkmay include any type of network or combination of networks available for supporting communication between local device, authentication serverand web server, and other devices connected to network. Networkmay include for example, a wired, wireless, fiber optic, or any other type of connection, a local area network (LAN), a virtual private network (VPN), a wide area network (WAN), the Internet and intranet networks, etc. According to some embodiments, authentication serverand web servermay have a direct link between them, or may be connected through a local or private network, e.g., a LAN or WAN networks.

Web or application servermay be a service or an application for delivering static content, such as webpages, images, videos, and files as well as dynamic content such as real-time updates, personalized information, and customer support.

Each of local deviceand user devicemay be a computing device associated with a user. Local devicemay execute a user agent software or application, e.g., agentand a browser application. Each of local deviceand user devicemay be connected to network. A user may initiate a request to open website or webpage, e.g., a request to download and display the website or webpageon local device) through local device, e.g., using agentand browser. As used herein webpagemay refer to a document on the Internet or web that is identified by a unique uniform resource locator (URL), e.g., a unique address on the web. Webpagemay be provided or operated by a server connected to network, e.g., web server. Webpagemay be access limited, e.g., protected by one or more factors such as a username, a password, MFA, e.g., fast identity online (FIDO), push notification, or other types of MFA, etc. Thus, a user may gain access to webpage(e.g., download and present webpage) by providing the required factors.

In a successful phishing attack or following other types of attacks, an attacker may have possession of the factors required for opening webpage, e.g., the username, password, OTP, or may deceive the user to confirm authentication request by approving authentication factors, e.g. confirming a push authentication message or confirming the request via a FIDO token, etc. In some cases, the attacker may have the possession of one of more factors and deceive the user to confirm another one or more factors. Thus, in prior art systems, the attacker may gain access to webpagedespite not being the actual user. In many scenarios, the attacker may not have possession of local deviceand/or user device, and may not try to access webpagethrough local deviceor agent, but through another computing system. According to embodiments of the invention, web servermay open webpageonly after obtaining a certain tokenor other security data object from local device. Token or security data objectmay be provided specially to local devicefrom authentication server, and may be sent directly from local deviceto web serverduring login with no involvement of the user. Thus, tokenin some embodiments is never provided to the user and the user may not be required to provide tokenduring a legitimate login process. Therefore, the user may not be able to provide the token to an attacker. Thus, it may be assumed that the attacker may not get tokenin the phishing attack, and thus may not be able to open webpage.

Databasemay be a storage device (e.g., storagedepicted in) used for storing tokens and any other data, as required by the application.

User devicemay be a device external to local device(e.g., physically separated from local device) or internal to local device, that may be used to authenticate or verify an identity of the user. User devicemay be or may include for example, a mobile smartphone operating an authentication application or an embedded biometric module with authentication capabilities (embedded for example in local device), e.g., an embedded fingerprint module. User devicemay verify the identity of the user using any applicable method, e.g., using a pin code, or by performing biometric authentication using at least one of a fingerprint, a facial pattern, an iris pattern, a retinal pattern, voice authentication, etc. User devicemay have a direct line of communication with local device, e.g., using Bluetooth Low Energy (BLE), universal serial bus (USB), Near Field Communication (NFC) etc.

According to embodiments of the invention, authentication servermay obtain or receive the request to open webpagefrom agent. In response to obtaining the request to open webpage, authentication servermay generate a token, and provide or send the generated tokento both agentand web server. Tokenmay be valid for a limited period, e.g., may be used for only a limited time from generation, after which tokenexpires, e.g., 1 minute, 2 minutes, etc. Tokenmay include data such as a random or non-random value, string, vector or other identifier associated with the request to open webpage. Authentication servermay send or provide token(and optionally the time limit of token) to web serverdirectly, e.g., via a direct link between authentication serverand web server, via network, or by storing tokenin a common or shared database, e.g., database, that may be connected to and accessible by both authentication serverweb server.

Agentmay send tokenobtained from authentication serverto web server. Thus, web servermay obtain two versions of token, one from authentication serverand one from agent. Web servermay verify tokenobtained from agentagainst tokenobtained from authentication server, e.g., verify that tokenobtained from agentmatches tokenobtained from authentication server. For example, web servermay check that tokenobtained from agentequals or is identical to tokenobtained from authentication server, or that a predetermined relation exists between tokenobtained from agentand tokenobtained from authentication server. If the two tokens are identical or have the predetermined relation between them, or if other verification methods of tokenobtained from agentagainst tokenobtained from authentication serverare successful, a successful or positive verification or simply “verification” may be established; the tokens are not identical, it may be considered that verification failed. Other verification methods may be used. Web servermay provide webpageto agent, or may provide access to webpageto agent, only if the verification of tokenis successful. If the verification of tokenis not successful or fails, e.g., if no token is obtained from agentor if a wrong token (e.g., unmatching token) is obtained from agent, then web servermay not provide webpageto agentor may prevent access to webpagefrom agent. Thus, access of an attacker that does not have possession of tokento webpagemay be denied and prevented.

According to some embodiments, agentmay sign tokenprior to sending tokento web serverusing a private keyowned by agent, and send the signed version of tokento web server. Web servermay verify the signed token obtained from agentagainst tokenobtained from authentication serverusing a public keycorresponding to private key(e.g., private keyand public keymay form a public-private key pair) to verify the signed token obtained from agent, or determine verification failed. This may provide a second level of protection against unauthorised access to webpagesince on top of not having access to token, the attacker may not have access to the private key as well.

According to some embodiments, authentication servermay authenticate the user prior to generating tokenor prior to sending tokento agent, e.g., using MFA, FIDO, etc. For example, authentication servermay send a push notification to the user via user device, that may or may not include a second factor, such as an OTP, PIN code, biometric factor, etc. the user may confirm the push notification via inputting a confirmation to user deviceand send the confirmation message to authentication server. The authentication servermay determine that the user is authenticated in response to obtaining the confirmation message from user device. Other methods and protocols may be used by authentication serverto authenticate the user.

In some implementations, local deviceor agentmay operate a web browserto provide webpage, as well as other portal applications to the user. Providing other portal applications may be performed in any applicable manner and using any relevant protocol, e.g., security assertion markup language single sign-on (SAML SSO). Thus, the user may be authenticated once and gain access to multiple applications. For example, providing other portal applications may include sending, from authentication serverto web browser, a single sign-on (SSO) token, using the SSO token to authenticate the user and opening the required portal application via web browser, upon successful verification of the SSO token.

In some applications, providing other portal applications may include sending an SSO token from authentication serverto web browser, sending a request for executing a required portal application from web browserto authentication server, sending the SSO token from web browserto authentication server, authenticating the user by authentication serverusing the SSO token, sending a corresponding URL for the required portal application, from authentication serverto web browserupon successful verification of the user, sending from web browsera request to open the URL to a server providing the required portal application, e.g., web server, forwarding the request to authentication service or identity provider (IdP), e.g., such as IdPdepicted in, verifying the SSO token by IdP, and opening the required portal application by web servervia web browser, upon successful verification of the SSO token.

Reference is now made towhich is a flowchart of a method for providing a secure access to a webpage, according to embodiments of the invention. An embodiment of a method for providing a secure access to a webpage may be performed, for example, by the systems shown in, or other systems.

In operationa user agent application, e.g., agentoperated by local device, may send a request to open a webpage to authentication servertogether with username or other ID, and password if required. The request to open the webpage may be obtained at local devicefrom a user and forwarded to authentication server. In operation, authentication servermay generate a token, e.g., a random or non-random value associated with the request to open webpage. The generated token may be valid for a limited period. In operation, authentication servermay share, provide or send the token (and optionally the time limit of token) to web server. In operationthe token may be shared between authentication serverand web servervia a shared or common database, e.g., databasethat may be accessible by both authentication serverand web server, depicted in, or sent via networkor a direct link. In operation, authentication servermay provide or send the token to user agent application on local device. In operation, local devicemay provide or send the token to web server, together with a request to open a webpage operated or provided by web server. In operation, web servermay verify the token obtained from local device(e.g., from a user agent application operated by local device), against the token obtained from authentication server. Verifying the token may include comparing the two tokens or performing other operations to verify that the two tokens match, and optionally verifying that the token has not expired. In operation, web servermay, upon successful or positive verification of the token, open the required webpage, e.g., the webpage requested by the user agent application in operation. For example, web servermay enable the user agent application to download and present the webpage requested by the user agent application in operation. That is, if the token is not verified successfully, e.g., if no token is obtained from local device, or if the token obtained from local deviceexpired or does not match the token obtained from authentication server, then web servermay not open the required webpage, e.g., the web servermay prevent the user agent application from accessing the web page and may not enable the user agent application to download and present the webpage requested by the user agent application in operation. In operation, web servermay, again only upon successful verification of the token, send webpage data to local device, e.g., to a browser application operated by local device. If the token is not verified successfully in operation, web servermay not send webpage data to local deviceor may not provide access to the webpage to local device.

Reference is made to, which is a flowchart of a method for providing secure access to a webpage with added levels of protection, according to embodiments of the invention. An embodiment of a method for providing secure access to a webpage with added levels of protection may be performed, for example, by the systems shown in, or other systems. Embodiments of the method for providing secure access to a webpage with added levels of protection may be similar to embodiments of performing providing secure access to a webpage, as presented in, with the added levels of security provided by authenticating the user and using a private-public key pair to protect the token. Similar operations will be given the same reference numerals.

In operation, authentication servermay authenticate the user prior to generating the token, e.g., using MFA such as FIDO, push notification, or other MFA types. Authenticating the user by authentication servermay include, in some embodiments, sending a push notification, that may or may not include a second factor, such as an OTP, PIN code, biometric factor, etc, an OTP, a FIDO token or another type of MFA, to the user via a user device, and obtaining a user confirmation by all required authentication factors, from the user device. Other methods for authenticating the user by authentication servermay be used. In case the authentication fails, the process may terminate at this point.

Additionally or alternatively, as presented in operation, local devicemay sign the token using, for example, a private key, before sending a signed version of the token to web serverin operation. Web servermay verify the token signature, as indicated in operation, using for example, a public key corresponding to the private key used by local deviceto sign the token. It is noted that some embodiments may only add certain levels of security, e.g., either authenticating the user (operation) or signing the token and verifying the signature of the token (operations-), while other embodiments may implement both.

Reference is made to, which is a systemaccording to embodiments of the invention. Components in systemthat are similar to components in systemare given the same reference numerals and will not be described in detail again. According to some embodiments, portal server, web serverand IdPmay include components of computing device.

Organizational portal server, also referred to herein simply as portal server, may be a gateway providing access through web browserto business information, organization data, organization applications and webpageslocated inside and outside of the organization, to members of the organization. According to embodiments of the invention, portal servermay provide secure access to webpageusing a token as disclosed herein.

According to embodiments of the invention, authentication servermay obtain or receive the request to open webpagefrom agent. In response to obtaining the request to open webpage, authentication servermay generate a token, and provide or send the generated tokento both agentand portal server. Tokenmay include a random or non-random value associated with the request to open webpage. Tokenmay be time limited, e.g., may expire after some time. Authentication servermay send token(and optionally the time limit of token) to portal serverdirectly, e.g., via a direct link between authentication serverand portal server, via network, or by storing tokenin database, that may be connected to portal serveras well.

Agentmay send tokenobtained from authentication serverto portal server. Thus, portal servermay obtain two versions of token, one from authentication serverand one from agent. Portal servermay verify tokenobtained from agentagainst tokenobtained from authentication servere.g., verify that tokenobtained from agentmatches tokenobtained from authentication server, and optionally verifying that the token has not expired. For example, portal servermay check that tokenobtained from agentequals or is identical to tokenobtained from authentication server, or that a predetermined relation exists between tokenobtained from agentand tokenobtained from authentication server.

Portal servermay provide webpageto agent, or may provide access to webpageto agent, only if the verification of tokenis successful. Portal servermay utilize any applicable protocol to provide webpageoperated by web serverto browser. If the verification of tokenis not successful, e.g., if no token is obtained from agentor if a wrong or expired token (e.g., unmatching token) is obtained, then portal servermay utilize any applicable protocol to prevent web serverfrom providing webpageto agentor may prevent access to webpagefrom agent. Thus, access of an attacker that does not have access to tokento webpagemay be prevented.

According to some embodiments, agentmay sign tokenprior to sending tokento portal serverusing a private keyowned by agent, and send the signed version of tokento portal server. Portal servermay verify the signed token obtained from agentagainst tokenobtained from authentication serverusing a public keycorresponding to private keyto verify the signature of the signed token obtained from agent. This may provide a second level of protection against unauthorised access to webpagesince on top of not having access to token, the attacker may not have access to the private key as well.

According to some embodiments, authentication servermay authenticate the user prior to generating tokenor prior to sending tokento agent, e.g., using MFA or FIDO. For example, authentication servermay send a push notification, e.g., including an OTP or a FIDO token, to the user via user device, the user may confirm the push notification via user deviceand send the confirmation message, e.g., including the OTP or the FIDO token, to authentication server. The authentication servermay determine that the user is authenticated in response to obtaining the confirmation message from user device. Other methods and protocols may be used by authentication serverto authenticate the user.

In some implementations, local deviceor agentmay operate a web browserto provide webpage, as well as other portal applications to the user. For example, providing other portal applications may include sending, from a portal server (e.g., portal serverpresented in) to web browser, a SSO token, using the SSO token to authenticate the user and opening the required portal application via web browser, upon successful verification of the SSO token.

In some applications, providing other portal applications may include sending an SSO token from the portal server to web browser, sending, with or without a request from the user, a request for executing a required portal application from web browserto the portal server, sending the SSO token from web browserto authentication server, authenticating the user by authentication serverusing the SSO token, sending a corresponding URL for the required portal application, from authentication serverto web browserupon successful verification of the user, sending from web browsera request to open the URL to a server providing the required portal application, e.g., web server, forwarding the request to a verification service, verifying the SSO token by the verification service, and opening the required portal application by the server providing the required portal application via web browser, upon successful verification of the SSO token.

Reference is now made towhich is a flowchart of a method for providing a secure access to a webpage through a portal server, according to embodiments of the invention. An embodiment of a method for providing a secure access to a webpage through a portal server may be performed, for example, by the systems shown in, or other systems. Some operations in embodiments of the for providing a secure access to a webpage through a portal server depicted inare similar to operations of embodiments of the method for performing providing a secure access to a webpage, as presented in; those operations will be given similar reference numerals.

In operationa user agent application, e.g., agentoperated by local devicemay send a request to open a webpage to authentication servertogether with a user identifier, e.g., username. The request to open the webpage may be obtained in local devicefrom a user and forwarded to authentication server. In operation, authentication servermay generate a token, e.g., a random or non-random value associated with the request to open webpage. The generated token may be valid for a limited period. In operations, authentication servermay share, provide or send the token to portal server(and optionally the time limit of token). In operationthe token may be shared between authentication serverand portal servervia a shared or common database, e.g., databasethat may be accessible by both authentication serverand portal server, depicted in, or sent via networkor a direct link. In operation, authentication servermay provide or send the token to user agent application on local device. In operation, local devicemay send the token to portal server, together with a request to open a webpage operated or provided by web server. In operation, portal servermay verify the token obtained from local device(e.g., from a user agent application operated by local device), against the token obtained from authentication server. Verifying the token may include comparing the two tokens or performing other operations to verify that the two tokens match, and optionally verifying that the token has not expired. In operation, portal servermay, upon successful verification of the token, send a list of URLs to local device, e.g., to a browser application (e.g., browser) operated by local device. That is, if the token is not verified successfully, e.g., if no token is obtain from local device, or if the token obtained from local devicedoes not match the token obtained from authentication server, or if the token has expired, then portal servermay not send the list of URLs required to open the required webpages. In some embodiments, local device, e.g., a browser application operated by local device, may send a request to authentication serverwith each URL, which may send in response the service URLs for web server. In operation, local device, e.g., a browser application operated by local device, may, again only upon successful verification of the token, send a request to each web serverthat appears in each service URL. If the token is not verified successfully in operation, local devicemay not send a request to any web server. In operation, web servermay open the webpage and in operation, web servermay provide webpage data to local device, e.g., to a browser application operated by local device. It is noted that more levels of protection may be provided, including authenticating the user and using a private-public key pair to protect the token.