application identifier

Abstract

A method for verifying an application configured to execute on a client device. A challenge request is sent to the application. A candidate challenge response is received from the application in response to the challenge request and then provided as input to a verification computation along with a challenge input. Based on an output of the verification computation, it is determined that the candidate challenge response was generated by providing the challenge input to a challenge computation. Based on the determination that the candidate challenge response was generated by providing the challenge input to the challenge computation, the application is verified.

Description

Technical Field

[0001] This disclosure relates to identifying applications that run on client devices, particularly web browsers. Background Technology

[0002] Local applications running on client devices need to identify themselves to remote applications or servers in order to perform certain functions. For example, a web browser sends an HTTP request to a server to access its resources. An application associated with a resource can make a similar request when attempting to access a user profile or other characteristics provided by a server. In another example, an application sends a bid request to display advertisements within the application, indicating the type of application and its users.

[0003] During the identification or authentication process, an application provides data related to its identity. However, an application can spoof this data, allowing a malicious application to impersonate an authorized application and enable unauthorized functions. This can be called application spoofing. In the specific example of a web browser, this is called browser spoofing.

[0004] One known reason for using authentication is to ensure the enforcement of predefined security policies. The ability to define and enforce policies is fundamental to modern enterprise security. A policy is a set of rules that manage access to data, systems, or services within a given context. For example, a policy can restrict or block access to certain websites or domains, or restrict certain operations (such as file downloading or uploading, file modification or deletion, file sharing, access to or use of peripherals such as cameras or printers, clipboard copying, etc.). In this paper, a policy is said to be “enforced” when policy rules are evaluated on a given set of contextual inputs. Policies can be defined or customized by an organization, for example, and applied or enforced regarding infrastructure, services, etc., within the organization's domain.

[0005] Policies can be deployed and enforced in a variety of situations. For example, in the case of network traffic routed through a proxy service, policies can be enforced at the proxy service to determine whether to block or allow requests received at the proxy service. As another example, in a cloud computing context, policies can be enforced on backend cloud computing systems to determine whether to block or allow attempts to access cloud services, or to determine whether to allow or permit more granular actions related to cloud services (such as accessing, modifying, downloading, or uploading documents or other data, for example, whether to allow copying certain data to the clipboard). As yet another example, so-called "enterprise" browsers are equipped with policy engines to implement local policy enforcement and enforcement at the client device for web applications accessed via the enterprise browser. In this final example, ensuring the browser's identity is crucial. Summary of the Invention

[0006] This paper provides a mechanism for verifying an application. The validator sends a challenge to the application. In response, the application computes a challenge response based on known challenge computations. The challenge response is then sent from the application to the validator for verification.

[0007] If the application can correctly compute the challenge response, the validator can ensure that the application is of the required type. This helps prevent application spoofing, where an application attempts to impersonate another application, thereby gaining access to functionality or data that it would not otherwise be authorized to access.

[0008] Therefore, the method presented in this paper can be considered an application of anti-spoofing methods.

[0009] In one specific implementation, the application is a web browser. Ensure the browser is the required type, and in this case, an enterprise browser, so that the policy can be enforced.

[0010] The present invention is provided to present, in a simplified form, the selection of concepts further described below in the detailed description. The present invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. The claimed subject matter is also not limited to implementations that address any or all of the shortcomings mentioned herein. Attached Figure Description

[0011] To aid in understanding this disclosure and to illustrate how embodiments may be implemented, reference is made to the accompanying drawings by way of example, in which: Figure 1 The known federal certification process is shown; Figure 2 Example methods for performing browser validation are provided; Figure 3 Another example method for performing browser validation is provided; Figure 4 An example challenge request is illustrated schematically; Figure 5 An example of a query response is shown schematically; Figure 6A and Figure 6B The diagram illustrates the challenge computation and corresponding verification computation, including the hash function. Figure 7A and Figure 7B The diagram illustrates the challenge computation and corresponding verification computation, which respectively include encryption and decryption functions; Figure 8A and Figure 8B The diagram schematically illustrates the second challenge computation and the corresponding verification computation, which respectively include encryption and decryption functions; Figure 9 This demonstrates how malicious users can use automated tools to obtain sensitive information; Figure 10 An example method for rejecting browsers powered by automation tools is shown; Figure 11 Example methods for disabling developer tools are shown; and Figure 12 A schematic block diagram of an example computer system is shown. Detailed Implementation

[0012] When an application requests access to resources executed on or provided by the server, the application running on the client device identifies itself to the server. The application needs to provide data related to its identity, such as an application identifier and version.

[0013] An example of application authentication is federated authentication. Federated authentication is used to enable users to authenticate themselves and thereby access applications. During this process, the browser through which the user accesses the application is also authenticated.

[0014] This article provides federated authentication by way of example only, and it should be understood that the principles of the methods described herein can be extended to other implementations where an application needs to be executed on the client device to authenticate its identity to a server or other remote service.

[0015] Figure 1 A schematic block diagram of an example networked system performing known federal authentication is shown, including a client device 104, a local application authenticator 106, an identity provider (IDP) 110, a policy enforcement application programming interface (API) 112, and one or more remote applications 108.

[0016] At client device 104, a remote application 108 (located away from client device 104), such as a web application or cloud service, is accessed via a local application 102 (e.g., a web browser). In other embodiments, multiple local applications may be installed on client device 104 to access different remote applications.

[0017] A local application 102, such as a web browser, is shown to be executing on client device 104. Although in Figure 1Not shown, but client device 104 includes at least one processor programmed or otherwise configured to perform the functions described herein, and at least one network interface via which client device 104 can communicate with IDP 110, policy enforcement API 112, and remote web application 108. Local application 102, as illustrated herein, is an enterprise browser that enables users to participate in remote web application 108 and apply policies.

[0018] Client device 102 communicates with remote application 108, IDP 110 and policy enforcement API 112 via a network such as the public Internet.

[0019] IDP 110 integrates with remote application 108 to authenticate users. IDP 110 can authenticate users, for example, by receiving a user identifier and password associated with a user account registered to the user at remote application 108, and verifying that the user identifier and password match the user identifier and password associated with the account. Other user authentication methods are known, such as browser-to-web single sign-on (SSO).

[0020] Local application authenticator 106 authenticates local application 102. It also integrates with IDP 110 to enforce access policies of the access policy service. The authenticator 106 also equips local application 102 with policies.

[0021] Policy Enforcement API 112 is a backend service that includes a Representational State Transfer (REST) ​​API for supporting policy enforcement at the local application 102.

[0022] During known authentication, perform the following steps: 1. A user accesses a remote application 108 via a local application (web browser) 102 using a client device 104. The remote application 108 determines that a session cookie does not exist and therefore redirects the browser 104 to an IDP 110 for authentication.

[0023] 2. IDP 110 authenticates the user and redirects browser 106 to browser authenticator 106.

[0024] 3. Browser authenticator 106 verifies that browser 102 is the required type or version and prepares a list of tokens and policies that browser 102 should implement for remote application 108 and the user.

[0025] 4. Browser authenticator 106 redirects browser 102 to remote application 108 and provides browser 102 with: a. A token that can be used when calling the callback policy server; and b. The policy implemented by browser 102 on remote application 108.

[0026] In step 3, when browser 102 is verified, browser 102 automatically sends a user agent header to browser authenticator 106. The user agent header allows identification of the browser type.

[0027] As mentioned above, the policy is enforced because the browser is a predefined type (in this case, an enterprise browser). Therefore, it is important to identify browser 102 as an enterprise browser with strong guarantees.

[0028] However, in the browser verification steps mentioned above ( Figure 1 In step 3), a malicious user might incorrectly identify the browser type because the user agent header used to verify browser type is easily modified or replaced. This is known as browser spoofing. Therefore, the method of verifying browser type 102 is unreliable for security.

[0029] This article presents a modified authentication method that more reliably identifies browser type. In this method, step 3 above is modified.

[0030] Figure 2 A modified browser verification method is provided.

[0031] In step 1, browser 102 sends the user agent header to verifier 106 for verification, as described above and implemented in the known authentication flow.

[0032] Verifier 106 verifies that the user agent header corresponds to the required browser type (step 2), and in response, sends a challenge request to the browser (step 3). The challenge request is described in more detail below. In summary, the challenge request causes browser 102 to perform the corresponding challenge calculation to generate a challenge response, which can be used to verify that browser 102 is of the required type.

[0033] In step 4, the browser performs challenge computation in response to receiving a challenge request to generate candidate challenge responses. Candidate challenge responses are generated by providing the challenge input to the challenge computation.

[0034] In step 5, browser 102 sends a challenge response, including candidate challenge responses, to verifier 106.

[0035] Once received, validator 106 provides the candidate challenge response and challenge input to the validation computation, step 6, to determine whether the candidate challenge response has been correctly generated. If the candidate challenge response has been correctly generated, validator 106 validates browser 102 as belonging to the required type, step 7. Once the browser is validated, validator 106 sends a token and policy to browser 102, step 8, enabling browser 102 to provide remote application 108 to the user while implementing the policy.

[0036] Various methods for calculating candidate challenge responses and corresponding verification methods can be used. Refer to Figures 6 to 7 below. Figure 9 Describe some examples. Essentially, a challenge response is generated in such a way that it can only be generated by a browser of the desired type. For example, the challenge computation can be encoded in a browser of the desired type. Alternatively or additionally, the challenge input can include information that can only be known or derived by a browser of the desired type. The challenge response can also be derived from time-related data, preventing a malicious entity from using an intercepted challenge response to falsely validate itself as belonging to the desired browser type.

[0037] Figure 3 A modified method for verifying browser 102 is provided. Steps 1 and 2 are as follows: Figure 2 As described in [the text].

[0038] In step 3a, validator 106 generates a challenge seed and a challenge time, which are sent to browser 102 in a challenge request, step 3b. The challenge request may also include a challenge computation indicator. Validator 106 stores the challenge seed and challenge time in its accessible storage for later retrieval. Validator 106 also stores the challenge computation indicator.

[0039] In step 4a, browser 102 selects a challenge computation to perform. For example, browser 102 may have encoded multiple challenge computations. The challenge computation selection may be based on a challenge computation indicator (if included) in the challenge request, where each encoded challenge computation is associated with a challenge computation identifier. This selection may be based on the validator 106 from which the request is received; that is, multiple validators may exist, each associated with a corresponding challenge computation. Alternatively, only a single encoded challenge computation may exist, where the challenge computation is selected in response to receiving a challenge request.

[0040] Browser 102 obtains assertion data in step 4b. Assertion data is data that browser 102 claims to be true and can be proven true by verifying the challenge response. In this document, assertion data refers to data that defines the context of browser 102. See below for reference. Figure 5 The description can include assertion data.

[0041] In step 4c, browser 102 calculates candidate challenge responses. Challenge inputs include assertions, challenge seeds, and challenge times.

[0042] Each challenge input helps ensure browser validation. By including a challenge time, if a challenge response is provided to validator 106 after a delay exceeding a threshold, the challenge response becomes invalid. Therefore, intercepted challenge responses cannot be used by malicious users for browser spoofing, thus preventing replay attacks.

[0043] Challenge seeds can provide similar protection against replay attacks. For example, validator 106 can generate a new challenge seed for each challenge request. Therefore, any browser 102 that returns a candidate challenge response generated using a challenge seed provided in a different challenge request is not validated.

[0044] Assertion data defining the context of browser 102 can be used to determine whether defined browser standards are met. These standards may be needed to implement one or more strategies.

[0045] It should be understood that the challenge input data may include one or more of these elements. It will be apparent to those skilled in the art that other inputs may be used.

[0046] In step 5, browser 102 sends a challenge response to validator 106. The challenge response includes candidate challenge responses and assertion data.

[0047] In step 6a, the verifier retrieves the challenge seed and challenge time from storage in response to receiving a challenge response. Then, in step 6b, these, along with candidate challenge responses, are provided as input to the verification computation.

[0048] Based on the output of the verification calculation indicating that the target challenge response has been correctly calculated, the verifier 106 verifies the browser 102 in step 7 and sends the token and policy to the browser 102 in step 8.

[0049] Figure 4 A sample challenge request 400 is provided, which is sent from validator 106 to browser 102. Challenge request 400 includes navigation header 402, challenge seed section 404, challenge time section 406, and challenge identifier section 408.

[0050] Navigation header 402 is HTML content that causes the challenge response to automatically navigate back to validator 106.

[0051] The challenge seed section of a 404 error is an HTTP header that includes the challenge seed value provided as part of the challenge input. The seed value is a long, random string.

[0052] The Challenge Time section of a 406 HTTP Response Number (406) includes the Challenge Time header. The Challenge Time specifies the duration of the challenge. The challenge response must remain valid for the interval configured from the Challenge Time.

[0053] Challenge identifier section 408 is an HTTP header that includes a challenge computation indicator. Browser 102 uses the challenge computation indicator to select among possible challenge computations encoded at the browser.

[0054] Figure 5 A sample challenge response 500 generated by browser 102 is provided. Challenge response 500 includes three HTTP headers: a candidate response header 502 containing candidate responses, an assertion header 504 containing assertion data, and a browser verification code header containing the version of the browser verification code used.

[0055] Candidate challenge responses can be referred to as cryptographic responses.

[0056] The assertion data includes a challenge time 510, a browser version string 512, an operating system version string 514, a privacy indicator 516, a profile indicator 518, and an implementation code version 520. If the browser 102 is in private mode, the privacy indicator 516 is set to 1; otherwise, it is 0. If the user profile running on the browser is a working profile, the profile indicator is set to 1; otherwise, it is 0. The implementation code version 520 is the version string of the implementation code of the browser 102. In some embodiments, the challenge time 510 forms part of the challenge response 500 but is not part of the assertion data.

[0057] The challenge time is measured in milliseconds since the epoch, or as a time string in challenge request 400. The challenge time 510 included in challenge response 500 can be the challenge time received in challenge request 400. Alternatively, challenge time 510 can be the time since the challenge time of challenge request 400, or the absolute time when challenge response 500 was generated or assertion data was obtained.

[0058] The validator 106 uses assertion data to determine whether the browser 102 meets the requirements for implementing the security policy. It is provided as input to the validation calculation to check that the browser 102 has derived candidate challenge responses from the assertion data, and therefore the assertion data corresponds to the browser 102.

[0059] In the example above, the user profile is required as a working profile; that is, the profile indicator is set to 1 only for the working profile. It should be understood that, within the context of the implementation of the methods provided in this paper, other profile types can be defined as relevant or irrelevant (and therefore set to 1 or 0 respectively).

[0060] In the examples provided in this article, the browser needs to be run in public mode. This is due to privacy requirements. Specifically, in the implementation of the method provided in this article, the validator 106 collects audit data from the browser 102, and therefore the browser 102 cannot be executed in private mode.

[0061] Validator 106 examines the assertion data received from browser 102 to check if applied standards are met. These include, for example, requiring the user profile to be a working profile and the browser to be in public mode. Validator 106 can only validate the browser if the applied standards are met.

[0062] Verifier 106 can also check the challenge time 510 received in challenge response 500. If the challenge time 510 is required to be the same as the challenge time of challenge request 400, the verifier checks that this is true for the received challenge time 510. Verifier 106 can also check that the current time of receiving challenge response 500 is within a predefined time of the challenge time, thereby determining that challenge response 500 was generated in response to challenge input 400, and thus verifying that challenge response 500 is not part of a replay attack.

[0063] If the challenge time 510 of the challenge response 500 is required to represent the time of the assertion data or the challenge response 500, the validator checks that the elapsed time between the challenge request 400 and the challenge response 500 is less than a threshold time. This ensures that the challenge response 500 is generated in response to the challenge request 400, i.e., the challenge response 500 is not part of a replay attack or an attack using an intercepted challenge response 500.

[0064] As described above, the challenge request 400 includes a challenge computation instruction or challenge indicator, which is used by the browser 102 to select the challenge computation to be performed. The browser 102 includes logic for selecting the challenge computation, called a challenge selector, and logic for performing the challenge computation, called a challenge processor. Based on the challenge computation indicator, the browser 102's challenge processor knows how to answer different challenges by performing different challenge computations. The input required for the challenge computation is also known.

[0065] Figure 6A , Figure 7A and Figure 8A Example challenge calculations are provided, and Figure 6B , Figure 7B and Figure 8B Corresponding verification calculations are provided.

[0066] Figure 6AChallenge computation is provided, including a hash function 602 (e.g., SHA512 hash function). Assertion data, challenge seed, and challenge time are provided to hash function 602 as challenge input 604. A shared secret shared between browser 102 and validator 106 can also be provided to hash function 602 as input.

[0067] The candidate hash function 606 is calculated from the challenge input 604 and is provided as a candidate challenge response.

[0068] Corresponding to Figure 6A The processor that performs the challenge computation in the algorithm can be called a hash processor. If the hash function is SHA512, the processor can be called a SHA512 processor.

[0069] To verify candidate hash function 606, a verification computation 610 is performed, which includes hash function 610 and comparison function 608.

[0070] The challenge input 604 is provided to the hash function 602 to compute the target hash value 612. The target hash value 612, along with the candidate hash value 606 computed by the browser 102, is provided as input to the comparison function. The comparison function 608 compares the candidate hash function 606 and the target hash function 612 to determine if they are identical, i.e., whether the same input and hash function have been used to generate the hash value. The output of the comparison function 608 is called the challenge computation validity 614, and indicates whether the challenge response was validly generated.

[0071] Figure 7A The challenge computation 704, including the encryption function 708, is illustrated. The challenge computation 704 also includes a key generation function 706. A challenge input 702, including a challenge seed, assertion data, and challenge time, is provided as input to the challenge computation 704 to generate candidate challenge responses, in this case, encrypted data 714.

[0072] The challenge seed is provided as input to the key generation function 706, which then generates the encryption key 712. The key generation function can be, for example, the PBKDF2 function. Both the browser 102 and the verifier 106 know the number of iterations of PBKDF2.

[0073] The encryption function 708 uses the generated encryption key 712 to encrypt the assertion data and the challenge time, thereby generating encrypted data 714.

[0074] Corresponding to Figure 7A The processor for the challenge computation provided can be referred to as a cryptographic processor. In an embodiment where the key generation function is a PBKDF2 function, an example of a cryptographic processor is a PBKDF2 processor.

[0075] Figure 7B A corresponding verification function 710 is provided, which includes a key generation function 706, a decryption function 720, and a comparison function 722. The verification function 710 takes a challenge input 702 and encrypted data 714 as input.

[0076] The challenge seed is provided as input to the key generation function 706 of the verification function 710 to generate the decryption key 716. Since the key generation function 706 and its input are identical for both the challenge computation 704 and the verification computation 710, the encryption key 712 and the decryption key 716 are equal. These keys 712 and 716 are referred to as symmetric.

[0077] The decryption key 716 is then used by the decryption function 720 to decrypt the encrypted data 714. As a result, candidate decryption data 718, including candidate assertion data and candidate challenge times, is calculated.

[0078] The comparison function 722 compares the candidate encrypted data 718 with the assertion data and challenge time used to generate the encrypted data 714. The assertion data used is the assertion data received from the challenge response 500 of the browser 102, that is, the data that the browser 102 declares as true and declares to be used to generate the candidate challenge response.

[0079] The comparison function 722 outputs an indication of the validity of the challenge computation 724. That is, if the candidate decryption data 718 matches the data that was claimed to have been used to generate the encrypted data 714, the verifier 106 ensures that the browser 102 correctly generated the encrypted data and thus met the browser type requirements.

[0080] Figure 8A An alternative challenge computation including hash function 806 is illustrated. In this example, the processor can also be referred to as a cryptographic processor. However, in this example, the cryptographic key is not generated as part of the challenge computation. Instead, cryptographic function 806 uses a separately provided shared key to encrypt the assertion data and the challenge time. Therefore, the processor can be more specifically referred to as a shared-key processor.

[0081] In this example, the challenge input 802 includes an encryption key (shared key), assertion data, and a challenge time. The encryption function 806 uses the encryption key to encrypt the assertion data and challenge time to generate candidate challenge responses, in this case, encrypted data 808.

[0082] The encryption key is provided to browser 102 by verifier 106 sometime before the challenge request and is stored at browser 102. Alternatively, the encryption key is encoded in browser 102 and is known to verifier 106, so that there is no need to exchange encryption keys.

[0083] Figure 8B A corresponding verification calculation 810 is provided, including a decryption function 812 and a comparison function 814. The verification function receives challenge input 802, including the decryption key, assertion data, challenge time, and encrypted data 808. Note that the encryption key and decryption key are shared keys and are therefore equal.

[0084] The decryption key is stored by the verifier 106 and retrieved as input to the decryption function 812, which uses it to decrypt the encrypted data 808 to compute candidate decryption data 816, including candidate assertion data and candidate challenge times.

[0085] The comparison function 814 compares the candidate decryption data 816 with the assertion data and the challenge time (i.e., the data that browser 102 claims to have encrypted) and generates an indication of the validity of the challenge computation 818. As previously stated, if the candidate decryption data 816 matches the data that browser 102 claims to have encrypted, then the challenge computation is valid.

[0086] It should be understood that the challenge and verification computations provided above are provided as examples only. As can be seen from the examples above, the candidate challenge responses are cryptographic responses.

[0087] In the example challenge and validation calculations described above, the challenge time is provided as input. The challenge time can be the time received from the validator in the challenge response 400, or it can be a challenge time generated by browser 102 that defines the time of the challenge response. In some embodiments, the challenge time is not provided as input. In this case, the challenge time can be checked by validator 106 as described above to determine if the challenge response 500 is provided within a predefined allowed time window from when the challenge request 400 was sent.

[0088] The above method increases the difficulty of malicious entity attacks because the identity of browser 102 is ensured with a higher degree of confidence. In the example above, verifier 106 can ensure the browser environment or context, and therefore has the confidence to execute the desired policy. Specifically, the above method can verify: Browser version.

[0089] The version of the policy enforcement code that runs in the browser.

[0090] The operating system that hosts the browser.

[0091] The context in which a user runs in a browser, such as a non-private execution context.

[0092] This method provides a balance between security and availability, allowing verifier 102 to verify the identity of browser 102 and accept it and its associated execution context, or reject it. Verifier 102 may be part of a security service that also includes a policy service, and may further include IDP 110 and a policy enforcement API 112. The security service is performed by a security server located remotely from client device 104 and accessible via a network such as the Internet.

[0093] If validator 106 determines that a candidate challenge response has not been correctly computed, it rejects browser 102. For example, the assertion data used to derive the challenge response may not match the assertion data provided in the challenge response. In another example, the challenge time used to derive the challenge response may not match the challenge time in the challenge request. In yet another example, the challenge computation used to generate the challenge response may not be the challenge computation defined in the challenge request. It will be apparent to those skilled in the art that other methods are possible to invalidally generate challenge responses.

[0094] In summary, this method integrates with the federated authentication protocol and adds a browser verification phase: 1. During the user's authentication process, browser 102 is challenged by the authentication server.

[0095] 2. Browser 102 receives the challenge and responds with the response that server 106 expects to receive (based on the challenge parameters).

[0096] 3. Server 106 will verify the challenge response and either accept or reject it.

[0097] While browser validation methods are provided within the context of federal certification, it should be understood that the exposed browser validation can be used in any context where browser parameters are expected to be validated. Furthermore, other types of native applications can be validated in this way.

[0098] Even if the browser is 102 verified, malicious entities can still bypass security policies and controls. Two known ways this can be achieved are automation and embedding.

[0099] Browser 102 can be used as an automation tool, which can bypass the security controls defined by Browser 102 for providing remote application 108 by leveraging the automation API. This allows users to attempt to extract information using brute force and other options that cannot be implemented manually.

[0100] Browser 102 can be embedded into applications that can programmatically interact with it, bypassing defined session controls. For example, the application might perform a download activity, while browser 102 is only used to obtain the user's cookies for authentication. The application will retrieve the cookies from the embedded browser 102.

[0101] In traditional automated processes, such as those mentioned above... Figure 1 The following steps occur as described: 1. The client device launches the browser using custom command-line parameters, including but not limited to: a. Exposing the Developer Tools protocol via a public port; b. Configure the proxy for network communication; c. Configure a custom user profile for the launched browser.

[0102] 2. Once browser 102 is started, automation can control its behavior using the DevTools protocol API: a. Can control navigation; b. Custom JavaScript code can be injected; c. Files can be uploaded via the DevTools protocol, bypassing traditional upload controls; d. Files can be downloaded via the DevTools protocol, bypassing traditional upload controls.

[0103] By using the automated processes described above, malicious users can bypass most data loss prevention (DLP) measures and sometimes even security controls.

[0104] Figure 9 It provides example methods that can be implemented by malicious users to obtain sensitive information using automation tool 902.

[0105] In step 1.1, the user initiates automation via automation tool 902, which launches browser 102 with additional command-line parameters, step 1.2, and navigates to remote application 108 via browser 102, step 1.3, where the user account logs into remote application 108, step 1.4.

[0106] When automation tool 902 bypasses security controls, automation tool 902 allows the user to navigate to the sensitive data screen of remote application 108 via browser 102, step 2.1.

[0107] Automation tool 902 injects JavaScript into remote application 108, step 3.1, to extract sensitive information displayed on the sensitive data screen, step 3.2. The user can then save the sensitive data, step 3.3.

[0108] To prevent such access to and retrieval of sensitive information, this paper provides methods for detecting embedders and automating and disabling the devtool protocol running in Enterprise Browser 102.

[0109] In summary, when a request is made to the access control service, the browser 102 provides context. This information is provided in the assertion data mentioned above.

[0110] The access control service (i.e., the browser authenticator 106 mentioned above) examines requests from browser 102. If the request is determined to be from the required enterprise browser 102, but the request originates from automation tool 902 or an embedded application, the login request is blocked and a notification of the blocked activity is displayed to the user. Information indicating the use of automation tool 902 or embedded application can be found in the assertion data.

[0111] Figure 10 Example methods are provided for rejecting browsers 102 driven by automation tool 902 during the authentication phase. This prevents... Figure 9 The attack in step 1.

[0112] Steps 1.1, 1.2, and 1.3 are as follows: Figure 9 As shown.

[0113] Step 1.4 has been modified to include steps 101 and 102. In step 101, browser 102 provides access controller (browser authenticator) 106 with information related to browser activation. This information is referenced above. Figure 2 and Figure 3 The method described is provided in the assertion. Information related to browser activation instructs browser 102 to be launched by automation tool 902.

[0114] Access controller 106 determines whether browser 102 is running outside the automated process based on information related to browser activation. This step is performed before browser 102 returns to application 108.

[0115] exist Figure 10 In the example, browser 102 is launched in an automated process. Therefore, in step 102, access controller 106 blocks access to application 108.

[0116] By blocking access to remote application 108 in this way, malicious users cannot access any part of application 108 and therefore cannot obtain sensitive information.

[0117] In some cases, automation can be activated by a malicious user after authentication has already been performed. In other cases, a certain degree of automation is acceptable. In these cases, it is desirable to provide a method to prevent the use of developer tools rather than completely preventing access to remote applications.

[0118] Figure 11 Example methods are provided for preventing the use of developer tools, including exposing developer tool protocols within the scope of the protected application. This prevents... Figure 9 The attacks in steps 2 and 3.

[0119] Browser 102 allows you to turn the developer tools on and off, and manage activation / deactivation at the tab level. In other words, the developer tools can be active in one browser tab and deactivated in another.

[0120] As part of the authentication process and before returning browser 102 to remote application 108, the protected application or the protected portion of remote application 108 is identified, and the policy is passed to browser 102. This is a modification of step 1.4, as follows: Figure 11 As shown. Here, in step 111, browser 102 provides access controller 106 with a rich login request including assertion data. In response, access controller 106 instructs browser 102 to disable the use of developer tools for application 108, step 112.

[0121] Therefore, the policy is applied before the user navigates from browser 102 to application 108. When the user navigates from browser 102 to application 108, the user cannot use the developer tools.

[0122] This assertion is used to determine whether the context of browser 102 corresponds to the conditions required to enforce the policy. For example, the policy may only apply to user profiles managed by the security service to which authenticator 102 belongs. Other conditions may also apply, such as browser 102 being in public mode.

[0123] refer to Figure 10 The description of blocking access to remote application 108 and references Figure 11 The action described as disabling developer tools can be referred to as an application restriction action.

[0124] As mentioned above, the assertion data is used to determine whether browser 102 is being executed within the context required by the policy. This context includes whether the browser is launched within an automated process, and criteria such as whether the profile is a managed profile. These criteria may be referred to as application environment criteria.

[0125] Security operations personnel expect to be able to fine-tune policies based on context to minimize their impact on users, administrators, and the operators themselves. To address these expectations, security services maintain up-to-date contextual information and provide rich policies with context-based filters that allow actions to be precisely targeted to specific users, devices, applications, and more.

[0126] Strategies are typically based on significant, rapidly changing contexts, and may include: a. Information about users, such as group information, situational awareness, and threat data; b. Information about the equipment, such as its security and management status; and c. Information about connection details, such as location, ISP, and IP address.

[0127] Therefore, the method described above, which requires browser 102 to provide such context information during authentication and before the user can access remote application 108, allows the most relevant strategies to be executed for the current context of browser 102.

[0128] Figure 12A non-limiting example of a computing system 1200, such as a computing device or a system connected to a computing device, is schematically shown. This system can perform one or more of the methods or processes described above, including data filtering and the implementation of the structured knowledge base described above. The computing system 1200 is shown in a simplified form. The computing system 1200 includes a logic processor 1202, volatile memory 1204, and non-volatile storage device 1206. The computing system 1200 may optionally include a display subsystem 608, an input subsystem 1210, a communication subsystem 1212, and / or other components not shown in FIG. 6. The logic processor 1202 includes one or more physical (hardware) processors configured to perform processing operations. For example, the logic processor 1202 may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs. The logic processor 1202 may include one or more hardware processors configured to execute software instructions based on an instruction set architecture, such as a central processing unit (CPU), a graphics processing unit (GPU), or other forms of accelerator processors. Additionally or alternatively, the logic processor 1202 may include (multiple) hardware processors in the form of logic circuits or firmware devices configured to execute hardware-implemented logic (programmable or non-programmable) or firmware instructions. The (multiple) processors of the logic processor 1202 may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and / or distributed processing. The various components of the logic processor may optionally be distributed across two or more separate devices, which may be located remotely and / or configured for coordinated processing. Aspects of the logic processor 1202 may be virtualized and executed by a remotely accessible networked computing device configured in a cloud computing configuration. In this case, these virtualized aspects run on different physical logic processors on various different machines. The non-volatile storage device 1206 includes one or more physical devices configured to store instructions executable by the logic processor 1202 to implement the methods and processes described herein. When implementing such methods and processes, the state of the non-volatile storage device 1206 may be changed—for example, to store different data. Non-volatile storage device 1206 may include removable and / or built-in physical devices. Non-volatile storage device 1206 may include optical memory (e.g., CD, DVD, HD-DVD, Blu-ray Disc, etc.), semiconductor memory (e.g., ROM, EPROM, EEPROM, FLASH memory, etc.), and / or magnetic memory (e.g., hard disk drive) or other high-capacity storage technologies. Non-volatile storage device 1206 may include non-volatile, dynamic, static, read / write, read-only, sequential access, location-addressable, file-addressable, and / or content-addressable devices. Volatile memory 1204 may include one or more physical devices comprising random access memory.Volatile memory 1204 is typically used by logic processor 1202 to temporarily store information during the processing of software instructions. The logic processor 1202, volatile memory 1204, and non-volatile storage device 1206 can be integrated together into one or more hardware logic components. Such hardware logic components may include, for example, field-programmable gate arrays (FPGAs), application-specific integrated circuits (PASICs / ASICs), application-specific standard products (PSSPs / ASSPs), system-on-a-chip (SOCs), and complex programmable logic devices (CPLDs). The terms "module," "program," and "engine" can be used to describe aspects of a computing system 1200 typically implemented in software by a processor to perform specific functions using portions of volatile memory, involving transform processing specifically configured to perform those functions. Therefore, a module, program, or engine can be instantiated by executing instructions held by non-volatile storage device 1206 via logic processor 1202 using portions of volatile memory 1204. Different modules, programs, and / or engines can be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Similarly, the same module, program, and / or engine can be instantiated from different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," and "engine" can encompass individuals or groups of executable files, data files, libraries, drivers, scripts, database records, etc. When included, the display subsystem 1208 can be used to present a visual representation of data stored by the non-volatile storage device 1206. The visual representation can take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data stored by the non-volatile storage device and thus transform the state of the non-volatile storage device, the state of the display subsystem 1208 can also be transformed to visually represent changes in the underlying data. The display subsystem 1208 can include one or more display devices utilizing virtually any type of technology. Such a display device may be combined with the logic processor 1202, volatile memory 1204, and / or non-volatile memory device 1206 in a shared housing, or such a display device may be a peripheral display device. When included, the input subsystem 1210 may include or interface with one or more user input devices, such as a keyboard, mouse, touchscreen, or game controller. In some embodiments, the input subsystem may include or interface with a selected Natural User Input (NUI) component. Such components may be integrated or peripheral, and the conversion and / or processing of input actions may be handled on-board or off-board.Example NUI components may include microphones for speech and / or voice recognition; infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; head trackers, eye trackers, accelerometers, and / or gyroscopes for motion detection and / or intent recognition; and electric field sensing components for assessing brain activity; and / or any other suitable sensors. When included, the communication subsystem 1212 may be configured to communicatively couple the various computing devices described herein to each other and to other devices. The communication subsystem 1212 may include wired and / or wireless communication devices compatible with one or more different communication protocols. As a non-limiting example, the communication subsystem may be configured to communicate via a wireless telephone network or a wired or wireless local area network or wide area network. In some embodiments, the communication subsystem may allow the computing system 1200 to send messages to and / or receive messages from other devices via a network such as the Internet. The term computer-readable media as used herein may include computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media (e.g., volatile memory 1204 or non-volatile storage device 606) implemented using any method or technology for storing information such as computer-readable instructions, data structures, or program modules. Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other article of manufacture that can be used to store information and can be accessed by a computing device (e.g., computing system 1200 or its component devices). Computer storage media do not include carrier waves or other propagated or modulated data signals. Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves or other transmission mechanisms), and include any information transmission medium. The term "modulated data signal" can describe a signal having one or more characteristics set or altered in a manner that encodes information in the signal. As an example and not a limitation, communication media may include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0129] A first aspect of this document provides a method for verifying an application constructed to execute on a client device, the method comprising: sending a challenge request to the application; receiving a candidate challenge response from the application in response to the challenge request; providing the candidate challenge response and a challenge input as input to a verification computation; determining, based on the output of the verification computation, that the candidate challenge response was generated by providing the challenge input to the challenge computation; and verifying the application based on the determination that the candidate challenge response was generated by providing the challenge input to the challenge computation.

[0130] In some embodiments, the application is configured to provide challenge inputs to challenge computation to generate candidate challenge responses.

[0131] In some embodiments, the challenge input includes challenge seed data, wherein the method further includes: generating challenge seed data; sending the challenge seed data to an application in a challenge request; storing the challenge seed data in a memory; and retrieving the challenge seed data from the memory in response to receiving a candidate challenge response, to provide it as input to the verification computation.

[0132] In some embodiments, the challenge input includes a challenge time, wherein the method further includes: sending the challenge time to the application in a challenge request; storing the challenge time in memory; and retrieving the challenge time from memory in response to receiving a candidate challenge response, to provide it as input to the verification computation.

[0133] In some embodiments, a candidate challenge response is a candidate hash value, wherein the verification computation is configured, when performed, to: apply a hash function to the challenge input to generate a target hash value; and compare the target hash value with a candidate hash value to determine that the target hash value is equal to the candidate hash value; wherein, based on the determination that the target hash value is equal to the candidate hash value, the candidate challenge response is determined to be generated by providing the challenge input to the challenge computation.

[0134] In some embodiments, the challenge computation includes a hash function.

[0135] In some embodiments, the candidate challenge response includes encrypted data, wherein the challenge input includes assertion data, and wherein the verification computation is configured, when performed, to: decrypt the candidate challenge response using a decryption key to obtain the candidate assertion data; and compare the candidate assertion data with the assertion data to determine that the candidate assertion data is equal to the assertion data; wherein, based on the determination that the candidate assertion data is equal to the assertion data, it is determined that the candidate challenge response was generated by providing the challenge input to the challenge computation.

[0136] In some embodiments, the challenge computation includes a cryptographic function, wherein candidate challenge responses are generated by encrypting assertion data using a cryptographic key.

[0137] In some embodiments, the encryption key and decryption key are symmetric keys.

[0138] In some embodiments, the decryption key may be derived based on challenge seed data, wherein the verification computation is also configured, when performed, to compute the decryption key using the challenge seed data.

[0139] In some embodiments, the challenge input includes a decryption key, wherein the decryption key is stored in a memory, and the method further includes: in response to receiving a candidate challenge response, obtaining the decryption key from the memory to provide it as input to the verification computation.

[0140] In some embodiments, the challenge input includes assertion data, wherein the method further includes: receiving assertion data from an application; and providing the assertion data as input to the verification computation.

[0141] In some embodiments, the method further includes: determining whether an application environment standard is met based on assertion data; wherein the application is further validated based on the determination that the application environment standard is met.

[0142] In some embodiments, the method further includes: determining, based on assertion data, that the application environment standard is not met; and, in response to determining that the application environment standard is not met, performing application restriction actions (e.g., blocking access to the application, disabling developer tools, etc.).

[0143] In some embodiments, the method further includes granting access to a remote application in response to the authentication application.

[0144] A second aspect of this document provides a method for generating candidate challenge responses at an application executing on a client device, the method comprising: receiving a challenge request from a validator; providing challenge inputs to a challenge computation in response to the challenge request to generate candidate challenge responses; and providing the candidate challenge responses to the validator; wherein the application is capable of being validated by providing the candidate challenge responses and the challenge inputs as inputs to the validation computation.

[0145] In some embodiments, the challenge input includes assertion data, wherein the method further includes: generating assertion data as input to the challenge computation; and providing the assertion data to a validator.

[0146] In some embodiments, the challenge computation includes a hash function, wherein the challenge computation is configured to apply the hash function to the challenge input when performed to generate a hash value, wherein the candidate challenge response is the hash value.

[0147] In some embodiments, the challenge computation includes a cryptographic function, wherein the challenge computation is configured to encrypt assertion data using a cryptographic key when executed, wherein the challenge input includes the assertion data.

[0148] In some embodiments, the challenge input includes challenge seed data, wherein the challenge computation includes a key generation function, and wherein the challenge computation is configured to apply the key generation function to the seed data when executed to generate an encryption key.

[0149] In some embodiments, the challenge request includes challenge seed data, wherein the method further includes obtaining the challenge seed data from the challenge request to provide it as input to the challenge computation.

[0150] In some embodiments, the encryption key is stored in memory, wherein the method further includes obtaining the encryption key from memory in response to a challenge request to provide it as input to the challenge computation.

[0151] In some embodiments, an application is an application used to access resources at a remote server.

[0152] In some embodiments, the application is a web browser used on a client device to access web applications.

[0153] A third aspect of this document provides a computer system comprising: at least one network interface; at least one memory configured to store computer-readable instructions for an application; and at least one processor coupled to the at least one network interface and the at least one memory, and configured to execute the computer-readable instructions, which, when executed, are configured to cause the at least one processor to: receive a challenge request from a verifier; in response to the challenge request, provide challenge input to a challenge computation to generate candidate challenge responses; and provide the candidate challenge responses to the verifier; wherein the application can be verified by providing the candidate challenge responses and the challenge input as input to the verification computation.

[0154] A fourth aspect of this document provides a computer system comprising: at least one network interface; at least one memory configured to store computer-readable instructions; and at least one processor coupled to the at least one network interface and the at least one memory, and configured to execute the computer-readable instructions, which, when executed, are configured to cause the at least one processor to: send a challenge request to an application configured to execute on a client device; receive candidate challenge responses from the application in response to the challenge request; provide the candidate challenge responses and challenge inputs as inputs to a verification computation; determine, based on the output of the verification computation, that the candidate challenge responses were generated by providing the challenge inputs to the challenge computation; and verify the application based on the determination that the candidate challenge responses were generated by providing the challenge inputs to the challenge computation.

[0155] It should be understood that the above embodiments are disclosed as examples only. Other variations or use cases may become apparent to those skilled in the art once the disclosure herein has been given. The scope of this disclosure is not limited to the above embodiments, but only to the appended claims.

Claims

1. A method for verifying an application (102) configured to execute on a client device (104), the method comprising: Send a challenge request (400) to the application (102); In response to the challenge request (400), candidate challenge responses (502, 606, 714, 808) are received from the application (102). The candidate challenge responses (502, 606, 714, 808) and challenge inputs (604, 702, 802) are provided as inputs to the verification calculation (610, 710, 810). Based on the output of the verification calculation (610, 710, 810), it is determined that the candidate challenge response (502, 606, 714, 808) is generated by providing the challenge input (604, 702, 802) to the challenge calculation (602, 704, 804). as well as Based on the determination that the candidate challenge responses (502, 606, 714, 808) are generated by providing the challenge inputs (604, 702, 802) to the challenge computation (602, 704, 804), the application is verified (102).

2. The method according to claim 1, wherein the challenge inputs (602, 704, 804) include challenge seed data (404), and wherein the method further comprises: Generate the challenge seed data (404). The challenge seed data (404) is sent to the application (102) in the challenge request (400). The challenge seed data (404) is stored in the memory (1204); as well as In response to receiving the candidate challenge response (502, 606, 714, 808), the challenge seed data (404) is retrieved from the memory (1204) and provided as input to the verification calculation (610, 710, 810).

3. The method according to claim 1 or 2, wherein the challenge input (602, 704, 804) includes a challenge time (406, 510), and wherein the method further comprises: The challenge time (406) is sent to the application (102) in the challenge request (400). The questioning time (406) is stored in the memory (1204); as well as In response to receiving the candidate challenge response (502, 606, 714, 808), the challenge time (406) is retrieved from the memory (1204) and provided as input to the verification calculation (610, 710, 810).

4. The method according to any of the preceding claims, wherein the candidate challenge response (502, 606, 714, 808) is a candidate hash value (606), and wherein the verification calculation (610), when performed, is configured to: Apply the hash function (602) to the challenge input (604) to generate the target hash value (612); and The target hash value (612) is compared with the candidate hash value (606) to determine that the target hash value (612) is equal to the candidate hash value (606). Based on the determination that the target hash value (612) is equal to the candidate hash value (606), the candidate challenge response (502, 606, 714, 808) is determined to be generated by providing the challenge input (604) to the challenge calculation (602).

5. The method according to any one of claims 1 to 3, wherein the candidate challenge response (502, 606, 714, 808) comprises encrypted data (714, 808), wherein the challenge input (702, 802) comprises assertion data (504), and wherein the verification calculation (710, 810), when executed, is configured to: Decrypt the candidate challenge response (714, 808) using the decryption key (716) to obtain candidate assertion data; as well as The candidate assertion data is compared with the assertion data (504) to determine that the candidate assertion data is equal to the assertion data (504). The candidate challenge response (714, 808) is determined to be generated by providing the challenge input (702, 802) to the challenge computation (704, 804) based on the determination that the candidate assertion data is equal to the assertion data (504).

6. The method according to claims 2 and 5, wherein the decryption key (716) is deriveable based on challenge seed data (404), and wherein the verification calculation (710), when executed, is further configured to: The challenge seed data (404) is used to calculate the decryption key (716).

7. The method of claim 5, wherein the challenge input (802) includes the decryption key, wherein the decryption key is stored in a memory (1204), and wherein the method further comprises: In response to receiving the candidate challenge response (808), the decryption key is obtained from the memory (1204) and provided as input to the verification calculation (810).

8. The method according to any preceding claim, wherein the challenge input (604, 702, 802) includes assertion data (504), wherein the method further comprises: Receive the assertion data (504) from the application (102); as well as The assertion data (504) is provided as input to the verification calculation (602, 704, 804).

9. The method of claim 8, wherein the method further comprises: Based on the assertion data (504), it is determined that the application environment standards are met; The application is further validated based on the determination that it meets the application environment standards (102).

10. The method of claim 8, wherein the method further comprises: Based on the assertion data (504), it is determined that the application environment standard is not met. In response to the determination that the application environment criteria are not met, an application restriction action is performed.

11. The method according to any of the preceding claims, wherein, The method further includes: in response to verifying the application (102), granting access to the remote application (108).

12. A method for generating candidate challenge responses (502, 606, 714, 808) at an application (102) executing on a client device (104), the method comprising: Receive a challenge request (400) from the validator (106); In response to the challenge request (400), challenge inputs (604, 702, 802) are provided to challenge computation (602, 704, 804) to generate the candidate challenge responses (502, 606, 714, 808); and The candidate challenge responses (502, 606, 714, 808) are provided to the verifier (106). The application (102) is able to be verified by providing the candidate challenge responses (502, 606, 714, 808) and the challenge inputs (610, 710, 810) as inputs to the verification computation (610, 710, 810).

13. The method of claim 12, wherein the challenge inputs (502, 606, 714, 808) comprise assertion data (504), wherein the method further comprises: The assertion data (504) is generated and provided as input to the challenge calculation (602, 704, 804). as well as The assertion data (504) is provided to the verifier (106).

14. The method of claim 12 or claim 13, wherein the challenge computation (602, 704, 804) includes a hash function (602), wherein the challenge computation (602, 704, 804) is configured to apply the hash function (602) to the challenge input (604) when executed to generate a hash value (606), wherein the candidate challenge response (502, 606, 714, 808) is the hash value (606).

15. The method of claim 12 or claim 13, wherein the challenge computation (704, 804) includes an encryption function (708, 806), wherein the challenge computation (704, 804) is configured to use an encryption key (712) to encrypt assertion data (504) when executed, wherein the challenge input (702, 802) includes the assertion data (504).

16. The method of claim 15, wherein the challenge input (702) includes challenge seed data (404), wherein the challenge computation (704) includes a key generation function (706), wherein the challenge computation (704) is configured to apply the key generation function (706) to the seed data (404) when executed to generate the encryption key (712).

17. The method of claim 16, wherein the challenge request (400) includes the challenge seed data (404), and wherein the method further includes obtaining the challenge seed data (404) from the challenge request (400) as input to the challenge computation (704).

18. The method of claim 15, wherein the encryption key is stored in memory (1204), wherein, The method further includes: in response to the challenge request (400), obtaining the encryption key from the memory (1204) as input to the challenge calculation (804).

19. The method according to any of the preceding claims, wherein the application is an application for accessing resources at a remote server.

20. A computer system, comprising: At least one network interface; At least one memory (1204) is configured to store computer-readable instructions; as well as At least one processor (1202) is coupled to the at least one network interface and the at least one memory (1204) and is configured to execute the computer-readable instructions, which, when executed, cause the at least one processor (1202) to perform the method of any of the preceding claims.

Images