Field of the Invention

[0001] The present invention relates to the field of Internet transactions, and in particular discloses the malware resistant processing of Internet based queries.

Background of the invention

[0002] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.

[0003] Malicious attacks on websites often take the form of controlled continuous queries by malware software that may have infected a third party's computer device.

[0004] This can include the constant sending of form based responses in an attempt to guess passwords and discover vulnerabilities in web based systems.

[0005] Many systems have been built to counter such attacks through the monitoring of traffic and the like. One such system is that marketed by Shape Security and disclosed at: https://www.shapesecurity.com/product/ - Section 3. Polymorphism.

Summary of the Invention

[0006] It is an object of the present invention to provide for an enhanced secure internet query transaction processing system.

[0007] In accordance with one aspect of the present invention, there is provided a method of enhancing the security of an internet transaction which includes the transmission of structurally formatted information, the method including the steps of: transmitting a request for the structurally formatted information across a network environment; receiving the request and sending a formulated response requiring calculation and decoding to determine the nature and content of the structurally formatted information; receiving the structurally formatted information. [0008] In some embodiments, the structurally formatted information comprises form data. The formulated response can comprise a seed having a series of missing elements and an answer, with the calculation and decoding including determining the missing elements. The complexity of the formulated response can be altered in accordance with the perceived risk of insecurity of the network.

[0009] In accordance with another aspect of the present invention, there is provided a system providing enhancement against malicious attack over a network, the system including: a client side computer and a server side computer interconnected over a network; the client side computer despatching a first message request for structured information to the server side computer; and the server side computer providing the structured information to the client side computer in the form of a formulated response requiring calculation and decoding by the client side in order to determine the structured information.

[0010] In accordance with a further aspect of the present invention, there is provided, in an internet query and answer environment, where a server accepts structured queries from an externally located client over a network, a method of rate limiting the submission of valid data over the network, the method including the steps of: (a) receiving a first structured query request from the client over the network; (b) providing an encrypted answer in response to the request, the encrypted answer requiring the exercise of a computational resource of a first expected level by the client to determine an answer by the client; (c) receiving a second response to the encrypted answer and determining if the second response preferably can include a correct answer; and (d) upon receipt of a correct answer, processing the second response as a valid response.

[0011] In some embodiments, the step (d) further can comprise, when the second response preferably can include an incorrect answer, flagging the client as a suspect client for receipt of future requests. In some embodiments, the encrypted answer requires the exercise of a computational resource, involving the calculation of the answer to a one way hash function. The calculation preferably can include attempting successive integers in the solution of the one way hash function. The server can adjusts the level of exercise of the computational resource in response to the load of first structured query requests received by the server.

Brief Description of the Drawings

[0012] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings in which: [0013] Fig. 1 illustrates a client server interaction;

[0014] Fig. 2 illustrates the dispatch of a first request for information;

[0015] Fig. 3 illustrates the server dispatching a decodable problem to the client;

[0016] Fig. 4 illustrates the client dispatching the form data in the correct format; and

[0017] Fig. 5 illustrates the server responding to a correct answer;

[0018] Fig 6 illustrates the server responding to an incorrect answer.

[0019] Fig. 7 illustrates the flowchart of an alternative description of an embodiment;

[0020] Fig. 8 illustrates the polyform encoding module of Fig. 7;

[0021] Fig. 9 illustrates the polyform decoding module of Fig. 7;

[0022] Fig. 10 illustrates the polyform challenge module in more detail; and

[0023] Fig. 11 illustrates the process of challenge solving.

Description of Preferred and Other Embodiments

[0024] In the preferred embodiments, there is provided a method and system for reducing the ability for malware to attack a given website through the utilisation of a polymorphic protocol.

[0025] The protocol, denoted a Dynamic Cryptographic Polymorphism (DCP), combines traditional polymorphism of web forms and Application Programming Interface (API) endpoints, with the addition of a cryptographic challenge to be solved, in order for form data to be successfully submitted to a web server.

[0026] Whilst many different scenarios are envisaged, one example of how a DCP works will now be described with reference to Fig. 1 to Fig. 4. [0027] Fig. 1 illustrates a standard client server architecture, wherein a client 1 and server 2 communicate over an insecure network. A transaction, such as a login request, proceeds by the following steps:

[0028] 1. In Fig. 2, the User of the Browser requests 3 a login page from Server S.

[0029] 2. Instead of the normal response of form data, as illustrated in Fig. 3, the Browser is sent the seed of '6987236471826498' and the answer of Od001257bd36d459065f72631e97534e' by the Server S.

[0030] 3. Given a seed and answer, the Browser is then required to complete the cryptographic hash problem by generating numbers, combining them with the seed and performing a hash in a loop. Once the browser finds the number that, when combined with the seed produces the same hash, it can fill out the relevant form field names to submit to the server. In this way, the server has the ability to control the level of computational processing required by the browser side resources before an answer can be provided.

[0031] 4. After working this out, as illustrated in Fig. 4, it will then be able to submit the forms correctly as it knows the answer (which in this case is simple as it is '9').

[0032] The process is repeated for any other data input with a different seed and answer, each time requiring a corresponding calculation by the client.

[0033] If the browser requests are being driven by malware control, the malware is unable to pre-empt the required field names, in order to submit the data successfully in the background. This means the malware would have to legitimately request the web form and figure out how to solve that particular challenge before submitting. This would require a significant increase in the complexity of encoding of the intelligence to be built into the malware.

[0034] Further, the difficulty of the challenge can be scaled up, in the event of a brute force attack, to allow legitimate requests to get through and severely hinder brute force attacks, without being too computationally expensive on the defenders side.

[0035] The DCP can be offered as a software development kit (SDK) for various programming languages. This allows for the utilisation of 'engineers as a service' to help install and use the DCP system continually on a licensed basis. [0036] In the second embodiment, there is provided a more detailed illustration of a resilient html serving of web pages that are again resilient to denial of service type attacks.

[0037] The overall architecture is as illustrated 70 in Fig. 7. This architecture is based around three parts, including Web Server for receiving and serving web pages 71, Polyform intermediatory 72 for controlling access to the web server 71, and client browser 73.

[0038] The Polyform module 72 is responsible for serving cryptographic challenges. It includes a Web communications module 75, a cryptographic code masking and encoding module 76, a cryptographic assigning module 77, a client communication module 78, a cryptographic challenge validation module 79, and a cryptographic code masking decode module 80.

[0039] The module 72 is responsible for formulating the cryptographic challenge 76, 77 which can be decoded by the browser. The challenge is dispatched to the browser for solving 78.

[0040] The received HTML webpage is received 85 by the browser. The Cryptographic Challenge Code is then decoded 86. In order for the cryptographic challenge code to be solved, it is necessary for the browser to iterate through a series of guesses to the hash challenge to test a proposed answer 87, 88. Once an answer has been determined, the answer is utilised 89 for decrypting the web page, which can then be loaded with the query data 89 and submitted 91.

[0041] Turning now to Fig. 8, there is illustrated the encoding unit (steps 76, 77 of Fig. 7) in more detail. The encoding masking module 95 is designed to take static HTML form fields and apply a 'mask' over the original content, thus protecting it from any malicious user. The module performs the following steps:

[0042] 1. The Masking module receives the raw HTML of the web page it has to mask from the web communication engine 96.

[0043] 2. The module identifies all of the form fields that are present on the page and separates them out 97.

[0044] 3. The module then performs masking 98 on the submission URL, this is done by generating a large, random string and replacing the submission URL. [0045] 4. The masking module then takes all of the original identifiers from all of the input fields and replaces them with more long, randomly generated strings

[0046] 5. The Cryptographic Challenge module (77 of Fig. 7) is then invoked 100 and the output of that is applied to the current form.

[0047] 6. The new, masked HTML for all the forms is used 102 to replace the original content of them all.

[0048] 7. The new content is then sent 102 to the client communication module (78 of Fig. 7) for dispatch to the browser.

[0049] 8. The modified content is also saved in a database 104.

[0050] The Decoding process (79, 80 of Fig. 7) is illustrated in more detail in Fig. 9. The decoding masking module is designed to take the masked input from forms, validate and return it to its original state, protecting a web resource from many different types of web attacks. The decoding module can consist of the following steps:

[0051 ] 1. The Masking module receives a masked HTTP request from an end user 111.

[0052] 2. The cryptographic challenge answer is then analysed to determine if it is valid 112. If the answer is not valid, the HTTP request is moved from the masking module to another module (threat mitigation module). If the answer is correct, the HTTP request continues through the current module.

[0053] 3. The original form content is then loaded from the database 113.

[0054] 4. All of the masked strings in the HTTP request are changed back to the original, unmasked strings 114.

[0055] 5. The HTTP request is then forwarded 115 to the web communication engine (75 of Fig. 7) to be sent to the protected web server resource. [0056] Turning now to Fig. 10, there is shown the steps 120 involved on the server side in generating the random challenge for the browser to solve in order to provide the ability to rate limit all HTTP data requests. These steps can include:

[0057] 1. Generate a random long string to act as the seed for this unique, cryptographic challenge 121.

[0058] 2. Generate a random number between 0 and X to become the secret answer to the challenge 122.

[0059] 3. Store that number for use in the validation of the challenge 123.

[0060] 4. Perform a hash on the Secret and the Seed to generate the answer that the browser will use to find the secret 124.

[0061] 5. The JavaScript template code for solving the cryptographic challenge module is then loaded and the new data is placed into the template 125.

[0062] 6. The new code is then injected into the HTML response 126 and the script attached to the HTTP response 126.

[0063] Fig. 11 illustrates the corresponding browser side execution of the injected code 130. In this arrangement, the browser executes the injected challenge code to derive the answer. This piece of code is designed to solve the challenge that the server issues in order to allow it to submit data. The steps involved include:

[0064] 1. Load the challenge solving script and the answer and seed 131. [0065] 2. Start a loop of guessing the secret to the challenge 132.

[0066] 3. The loop 133 can consist of a process of guessing a number, hashing the number and the seed, and comparing the hashed result with the answer. If they do not match, one is added to the number. If they do match, the number is utilised for loading into the protected web page. [0067] The embodiments of the invention therefore provide a system whereby the server can rate limit queries requests by means of imposing a cryptographic hash problem that must be solved by the client before form submission is possible.

Interpretation

[0068] The foregoing describes only some forms of an embodiment suitable for use in accordance with the present invention. Modifications, obvious to those skilled in the art can be made thereto without departing from the scope of the invention as defined in the following claims.

[0069] Reference throughout this specification to "one embodiment", "some embodiments" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment", "in some embodiments" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0070] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0071] In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements/features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising. [0072] As used herein, the term "exemplary" is used in the sense of providing examples, as opposed to indicating quality. That is, an "exemplary embodiment" is an embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality.

[0073] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, FIG., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

[0074] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0075] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[0076] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or optical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other. [0077] Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.