WO2022129772A1 - Procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal - Google Patents

Procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal Download PDF

Info

Publication number
WO2022129772A1
WO2022129772A1 PCT/FR2021/052316 FR2021052316W WO2022129772A1 WO 2022129772 A1 WO2022129772 A1 WO 2022129772A1 FR 2021052316 W FR2021052316 W FR 2021052316W WO 2022129772 A1 WO2022129772 A1 WO 2022129772A1
Authority
WO
WIPO (PCT)
Prior art keywords
validation
component
zone
sending
new
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2021/052316
Other languages
English (en)
Inventor
Karel Mittig
Fabien BIGNON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of WO2022129772A1 publication Critical patent/WO2022129772A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/36—User authentication by graphic or iconic representation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2133—Verifying human interaction, e.g., Captcha

Definitions

  • the present invention relates to the general field of computing and relates more specifically to a process for generating a form from a reference form and sending it to a terminal. More specifically, the process is intended to filter malicious automata on web content intended for a human being, in a manner transparent to the user.
  • the invention applies in a privileged way to securing website transactions and aims to block malicious automata, more specifically to prevent such automata from carrying out malicious actions such as:
  • CAPTCHAs have therefore evolved to make content analysis more complex.
  • One of the aims of the invention is to remedy shortcomings/disadvantages of the state of the art, and/or to make improvements thereto.
  • the invention proposes a method for generating a form from a reference form and sending it to a terminal, said reference form comprising at least one validation zone to be protected, the generation of the form including the following steps:
  • the method proposes a solution making it possible to fight effectively against so-called “basic” malicious bots which carry out a textual analysis of reference forms in order to identify a value to be sent to the server corresponding to a validation action of this form.
  • Such automata are then capable of automatically filling out such forms and perpetrating malicious actions such as dictionary attacks, sending spam, etc.
  • the process complicates, or even prevents, the textual analysis performed by such bots, which then find themselves blocked.
  • the action that allows the user to submit the form is replaced by a set of possibilities, variable over time, i.e. which changes each time the form is loaded. This therefore becomes very difficult to analyze by the malicious program, which relies on a textual analysis of the content of the page corresponding to the form.
  • the process for generating a form and sending it to a terminal comprises:
  • selection value being the unique value specific to the validation component selected by the user, - when the selection value is equal to the value specific to the correct validation component, processing the form data.
  • the method is transparent for a legitimate user: the rendering of a page of a form proposed by the server in response to a request is unchanged compared to the rendering of the reference form which would be proposed if the method were not implemented.
  • the elements to be completed by the user for example, his e-mail address, his password, remain identifiable and accessible in the form.
  • the method of the invention has no impact for this manager whose operation is based on an analysis of the form.
  • the selection of the correct validation component and of its own unique value among the at least two validation components is pseudo-random.
  • one of said at least two validation components can be in a state included in a set of states comprising: superimposed on another of said at least one component, distributed in space, visible, transparent, hidden, able to move dynamically when loading the form, able to move dynamically on a user action
  • the new validation zone is made up of an HTML sub-page nested in the HTML page associated with the reference form in the form of an iFrame tag .
  • the reference form consisting of an HTML page
  • said reference form comprises a specific HTML tag, associated with a javascript library, said specific tag being replaced by a code substituting the - lidation by the new validation zone.
  • the form comprises at least two new validation zones, said new validation zones being partitioned with respect to each other.
  • This example of implementation makes it possible to fight against bots qualified as “standard”, which have an HTML rendering engine and most often have the ability to execute javascript code.
  • Such bots are able to retrieve in an HTML page the visible element, such as a validation component, located at given coordinates. We understand that once this element has been retrieved, it is easy for the bot to extract the associated value and submit it to the server or even programmatically simulate an interaction with a validation form, such as a mouse click. .
  • a validation form such as a mouse click.
  • With the use of several commit zones, each considered as a partitioned space it is impossible for a standard bot to work on a global rendering of a combination of these new commit zones.
  • a standard bot, and a fortiori a basic bot is unable to identify the correct validation component that can be activated by the user among the validation components of the combinations of new validation zones.
  • the method comprises the generation of a pseudo-random offset of the abscissas and ordinates between the at least two sub-pages. pages, the generation of the offset guaranteeing an intersection between an area visible to the user and the at least two sub-pages greater than the size of a validation component.
  • the new validation zone comprises a zone visible to the user, said visible zone being of a size equal to a multiple of the size of a visible validation component, said visible validation component being positioned so pseudo-random in the new validation zone.
  • This exemplary embodiment makes it possible to fight against bots qualified as “advanced” which are capable of simulating actions of the user, such as keystrokes, movements, or mouse clicks. These actions are strictly equivalent, from a software point of view, to those generated by real input devices, and can absolutely be distinguished by solutions based on behavioral analysis and artificial intelligence.
  • This type of approach is based on modeling the behavior of the user before Faction, such as a mouse click, intervenes.
  • behavioral analysis poses real problems for the preservation of privacy. Indeed, it consists in recording data specific to the user in order to model his behavior.
  • the solution proposed here offers a solution that can fight on its own against advanced bots and therefore makes a behavioral analysis optional.
  • the character The randomness introduced in the positioning of the validation component visible to the user does not make it possible to simulate the behavior of the user. This approach can be described as respectful of privacy because it is independent of any behavioral analysis.
  • the invention also relates to a server able to generate a validation form from a reference form and to send it to a terminal, said reference form comprising at least one validation zone to be protected, the server comprising :
  • - substitution means arranged to substitute said validation zone to be protected by at least one new validation zone, said new validation zone comprising at least two validation components
  • - selection means arranged to select one of said validation components as the correct component, the other of said at least one component becoming decoys
  • - second generation means arranged to generate a positioning code in the new validation zone for the correct component and for the others of said at least decoys, the positioning code allowing the correct component to be activated by the user
  • - sending means arranged to send the form comprising the new validation zone to the terminal.
  • the invention also relates to a computer program on a data medium and loadable into the memory of a computer, the program comprising portions of code for executing the steps of the method for generating a validation form and sending to a terminal as described previously, when the program is executed on said computer.
  • the invention also relates to a data medium in which the program as presented above is recorded.
  • FIG. 1 shows the steps of a process for generating a form from a reference form and sending it to a terminal, according to a first embodiment
  • FIG. 2 shows an example of reference form code and code modified using an iFrame tag
  • FIG. 3a shows an example of HTML code generated in accordance with the steps of the method for generating and sending a form, according to a first example embodiment
  • FIG. 3b shows a rendering model of the sub-page shown in Figure 3a
  • - Figure 4a shows an example of HTML code generated in accordance with the steps of the method for generating and sending a form, according to a second example embodiment
  • Figure 4b shows a rendering model of the sub-pages shown in Figure 4a
  • FIG. 5 shows an illustration of a form generated from the steps of the method, according to a third embodiment
  • FIG. 6 is a schematic representation of a server arranged to implement the steps of the method of generating a form from a reference form and sending it to a terminal, according to a first embodiment.
  • the process described here is intended to distinguish an automaton (or "bot” in English), that is to say a computer software performing automatic actions, from a human being when processing a validation form.
  • the example is described here in the case of an HTML type form (for “HyperText Markup Language”), whether or not embedding javascript code.
  • HTML type form for “HyperText Markup Language”
  • the invention can be applied to other types of forms. It should be noted, however, that the current known languages suitable for creating such forms are generally metalanguages arranged to generate HTML pages.
  • an automaton can be arranged to, for example, fill in and send authentication forms in order to perpetrate dictionary attacks against sensitive sites.
  • the word “bot” designates a malicious bot.
  • the process stems from the observation that the mechanisms put in place by the existing bots to automatically process validation forms are all based on an analysis of the content of the structure of the HTML pages which constitute these forms in order to interact directly with the targeted code.
  • These bots automatically fill in the form if necessary, and identify a portion of code associated with a validation component such as a button to click, then programmatically generate an event associated with this component, such as a mouse click for example , so that the form is treated as if a human filled it out.
  • a human relies on the visual rendering of the page to navigate: he visualizes a validation component and performs an action on this component to access the next step in a given process.
  • “Activatable” means a component which, selected by the user by a pointing means or a validation key, causes the generation of an event associated that triggers the sending of the page data and its processing by the server. This may involve, for example, validating the sending of identification and authentication data entered in a form.
  • a computer terminal T is arranged to send requests in order to access resources of a network, for example the Internet network.
  • Resources such as services
  • Resources are accessed using a client-server communication protocol, for example “HTTP” (“HyperText Transfer Protocol”).
  • HTTP HyperText Transfer Protocol
  • the best-known HTTP clients are web browsers which allow users to access, by means of their terminal, data stored on a server S.
  • the computer terminal T is a personal computer, a terminal mobile, a tablet, a “PDA” (“Personal Digital Assistant”), etc.
  • the server S is a computer, host of services, capable of processing service requests emanating from the terminal T.
  • a resource or “URL” (for “Uniform Resource Locator”)
  • URL for “Uniform Resource Locator”
  • Such forms are intended to validate the sending of data to the server, or to validate the passage to a next page in a sequence of web pages which constitutes for example a customer journey.
  • Such a form can for example comprise a zone in which the user enters data such as an identifier, and a button, or validation component, making it possible to validate the sending of the entered data to the server.
  • the input box is missing and the user must press the button to access a next page.
  • the user terminal T sends an access request REQ to a resource of the server S.
  • This request REQ corresponds to a request for access to the server S made by the user from a browser of the terminal T by selecting a URL associated with the server.
  • the request is received by the server S in a reception step El. It is assumed that the URL selected by the user is associated on the server with an HTML page corresponding to a so-called “reference” validation form.
  • This form includes, where applicable, elements for which the user is expected to enter information, either in the form of text or in the form of elements to be selected such as check boxes, lists to be selected, etc., and a validation area to protect, for example a "send” button or a "next" button in a customer journey. It is this validation zone which is protected by the steps of the method.
  • the form is said to be “reference” because the steps of the process will somehow transform this reference form upon receipt of the request into a FORM form, and replace the validation zone to be protected with at least one new validation zone , which is difficult to analyze by a so-called “basic” bot.
  • a basic bot corresponds to a simple automated script capable of perceive an HTML page only as textual content and only do a textual analysis of such a page. Indeed, the action which makes it possible to submit the reference form is replaced in the form sent to the terminal T by a set of possibilities, which vary over time.
  • a server S In a next step E2 of generating an identifier, the server S generates a unique identifier IDU associated with the request REQ.
  • the server S In a following substitution step E3, the server S generates at least one new validation zone and substitutes the validation zone to be protected by the at least one new validation zone.
  • a new validation area includes at least two validation components.
  • the server S generates a single new validation zone, in the form of a sub-window.
  • the server S generates the new validation zone in the form of an HTML sub-page intended to replace the validation zone to be protected of the reference form.
  • This sub-page is nested in the HTML page corresponding to the reference form; it is intended to constitute a new validation zone in the validation form to be sent to the user.
  • This form thus corresponds to the reference form in which the validation zone to protect has been replaced by the new validation zone contained in the HTML sub-page.
  • the generated HTML sub-page is embedded in the reference form, in the form of an “iFrame” tag.
  • the iFrame tag allows you to embed the content of another HTML page in an HTML page.
  • Figure 2 shows an example of referral form code that includes an initial "Submit! and code from a modified form.
  • the “invention.html” sub-page thus created to replace the initial validation button includes HTML instructions describing a new validation zone which includes a set of at least two validation components.
  • This sub-page is of variable size but generally the size of the screen of the user's terminal T. However, only a portion of this pane is made visible to the user and constitutes a visible area.
  • This visible area corresponds in a way to the area in which a new visible validation component is likely to appear to the user.
  • the size of the visible area is adapted so as not to cover text that would be displayed to the user, or input areas included in the initial page of the reference form.
  • the visible area size parameters are defined in the code as an iFrame subpage inclusion parameter.
  • the reference form includes a specific HTML field in the form of a tag, associated with a javascript library and identifying the validation zone. tion to be protected.
  • the tag is replaced by a javascript code which substitutes the validation zone to be protected by the new validation zone, in accordance with the steps of the method.
  • the server S In a step E4 of generation of validation components, the server S generates at least two validation components intended for the new validation zone.
  • the generated validation components denoted Ci, ...Cn, with n > 2, have identical general information: same class
  • each of the validation components has a unique value. It is with this value that a programmatic event intended to carry out an associated processing is associated.
  • the server S generates for each of the validation components Ci of the sub-page a single pseudo-random value V;.
  • the unique value specific to each of the components is likely to change each time a reference form is processed according to the steps of the process.
  • the server S designates in a pseudo-random manner one of the validation components C j of the sub-page as the correct component.
  • This validation component Cj is intended to be the one that the user can activate with a pointing means, such as a mouse or a touch screen.
  • the value Vj associated with the correct component Cj therefore becomes a correct value.
  • the other validation components Ci, ..., Cj-i, Cj-1, ..., C n then become decoys intended to deceive bots. It should be noted that the correct validation component Cj is not necessarily the validation component visible to the user due to the different characteristics attributable to the validation components of the page.
  • the server S In a step E7 of generation of a positioning code, the server S generates for the correct validation component Cj, and for each of the decoys, an HTML positioning code by means of CSS style sheets and javascript code.
  • the codes of the decoys and of the correct validation component Cj are generated so as to position the decoys so that an interaction between the user and the correct validation component Cj can take place.
  • the code for decoys and the correct component Cj cleverly use the order of adding these codes in the subpage.
  • the code associated with the correct validation component Cj may be constrained to a certain location. Indeed, it can be systematically positioned at a location corresponding to the location of a validation component of the validation zone to be protected from the reference form.
  • the analysis of the sub-page thus generated is no easier. Indeed, decoys can be positioned above and/or below the correct validation component, thus complicating a textual analysis of the HTML sub-page by a bot.
  • a next step E8 of sending the form the form FORM with identifier 1DU thus generated is sent to the terminal T in response to the request.
  • the form FORM is displayed on the screen of the user's terminal T.
  • a user action step E10 the user fills in the validation form if necessary and selects the activatable validation component, denoted Ck.
  • the activatable validation component Ck corresponds to the validation component Cl visible to the user.
  • the activatable validation button Ck is different from the visible validation component Cl.
  • the activatable component Ck is transparent and positioned above the visible component Cl.
  • step Ell of sending the sending to the server S of data of the form DATAFORM (data, IDU', Vk) comprising data data entered by the user if necessary, an identifier IDU' of the form and the value Vk associated with the validation component Ck activated by the user.
  • the form data is received by the server S in a reception step El 2 .
  • step El 3 of comparison it is verified by the server S that the pair formed by the identifier IDU' of the form and the value Vk and received from the terminal T is equal to the pair formed by the identifier IDU and the Vj correct value generated for this form.
  • Faction is considered invalid and in a next step E15 for processing an error, the form data is refused and a measure is implemented.
  • the terminal T is suspected of attacking the server S and is placed in quarantine.
  • the terminal T is redirected to a validation page by means of a conventional CAPTCHA.
  • FIG. 3a An example code of the “invention.html” HTML sub-page as generated from the steps described above is provided in Figure 3a, and a rendering model of this sub-page is provided in the associated Figure 3b.
  • FIG 3b the validation area to be protected from the reference form is replaced by an HTML 30 sub-page.
  • the sub-page 30 comprises a visible zone 11 and eight value validation components denoted value_1, , value_8.
  • Each validation component contains identical general information.
  • no button has any distinctive element apart from its css style. Only one of these values is considered valid at a time t and corresponds to the button that can be activated by the user with a pointing device, such as a mouse.
  • the components located programmatically above are in effect respectively: disabled and nnoonn visible for the component with value value_8;
  • the other components are positioned:
  • the positioning techniques used such as the css style associated with a validation component, a javascript code or the order in which the components are added can vary and be present alternately or simultaneously in the same HTML sub-page depending on the iterations .
  • a basic bot will therefore be powerless to identify the active validation component during a textual analysis of an HTML sub-page. This is all the more true since the content of the sub-page is generated pseudo-randomly in such a way that the distribution of the validation components in space varies at each iteration. An analysis of the code of the HTML sub-page of the form for a given service cannot therefore allow automatic filling of the form for fraudulent purposes. Moreover, the user's perception of the form is unchanged, the same form loaded at different times always having the same appearance.
  • the process of blocking a bot is completely transparent to the user. 11 is therefore not necessary to add an additional test in the form of CAPTCHA when validating a form in order to differentiate a user from a bot.
  • the validation of a form is therefore more ergonomic from the user's point of view and simplified from the form processing point of view.
  • the number of validation components included in the validation form thus generated is between 4 and 8. This example is not limiting. However, too many validation components can result in poor rendering of the form at the user terminal T. Too few can, on the other hand, increase the chances of a bot exploiting the form. Tests have shown that the use of six validation components gives very good results.
  • the validation zone to be protected in the reference form is replaced by a new validation zone represented by a single HTML sub-page.
  • This example is suitable for mitigating basic bot attacks.
  • certain types of bots qualified as "standard", use an HTML rendering engine and most often have the ability to execute javascript code.
  • the javascript language offers a function allowing to retrieve in an HTML page the visible element located at given coordinates.
  • the javascript language notably has a “document.element-FromPoint(x, y)” method which allows, for a given HTML page, to retrieve the visible element located at the coordinates (x, y) provided. Once this element has been retrieved, it becomes possible for the bot to extract the associated value to submit it to the server S, or even to programmatically simulate an interaction with a validation form, such as a mouse click.
  • FIGS. 4a and 4b the validation zone to be protected of the reference form is replaced by at least two new validation zones, each corresponding to a sub-window.
  • Figure 4b is a rendering model of the HTML code shown in Figure 4a.
  • the code of the validation zone to be protected from the reference form is substituted by three nested HTML sub-pages.
  • each of the sub-pages is an HTML iFrame which includes, in addition to the part of the HTML form which allows its validation, and validation components generated according to the principles of steps E4 of generation of validation components to E7 of generation of a positioning code described previously, and recursively, another sub-page generated according to the same principles.
  • This set of nested sub-pages, each associated with a new validation zone, has the following properties:
  • each sub-page has a code to submit the original form
  • the only value considered valid at time t is that which is accessible by means of a pointing device, for example, a mouse, a finger on a touch screen, etc.
  • each sub-page can:
  • a pseudo-random offset of the coordinates x and y of the different sub- pages is generated while guaranteeing an intersection of said sub-pages on the plane (x, y) greater than the size of a validation component. This ensures that you can always display a validation component while introducing lag between different subpages.
  • the depth of a sub-page is predefined and corresponds to the order of inclusion of sub-pages: the first sub-page is positioned in the foreground, the second is positioned below, the third below the second, etc.
  • FIG. 4b corresponding to a modeling of the rendering of the HTML code presented in figure 4a, three sub-windows 40, 41 and 42 corresponding to the three HTML sub-pages of figure 4a are visible.
  • the first sub-window 40 appears behind the other two sub-windows, in accordance with the order of inclusion of the HTML sub-pages.
  • the first sub-window 40 comprises the validation components associated with the values value_1 and value_2.
  • the second sub-window 41 includes the validation components associated with the values value_3 and value_4 and finally, the third sub-window 42, which appears above the two others because nested last, includes the validation components associated with the values value_5 and value_6.
  • the coordinates (x, y) of the second and third sub-pages 41, 42 have been the subject of a slight shift generated in the HTML sub-pages in accordance with the instructions “translate(-150%, 50%)”.
  • the value component value_4 is the one that can be activated by the user.
  • the depth of recursion can be variable depending on the desired complexity. However, a value that is too low, i.e. less than three, can make the problem of identifying the correct validation component too simple for a standard bot, while a value that is too high can induce a problem. significant resource consumption at the terminal T and display problems. By way of example, and following various tests, a value equal to six is appropriate.
  • each sub-page being considered by the javaScript language as a partitioned space it is not possible to work on a global rendering of a combination of these sub-pages .
  • the javaScript language currently requires browsing each of the sub-pages to access its elements.
  • a method of the “document.elementFromPoint(x, y)” type which can be used in the first embodiment to determine the component visible at the coordinates provided, becomes inoperative in this second embodiment. Indeed, such a method only returns the component positioned in the considered sub-page, and not the component resulting from the combination of the sub-pages.
  • the position (x, y) provided will be that of the considered sub-page and not that of the space visible to the user.
  • this second embodiment is effective in preventing standard bots, and a fortiori basic bots, from determining the component accessible by the user and the associated valid value.
  • some so-called “advanced” bots are capable of simulating user actions, such as keystrokes, movements or mouse clicks. These actions are strictly equivalent from a system or software point of view to those generated by real input devices and can only possibly be distinguished by a behavioral analysis, known to raise data preservation problems. private life.
  • Such bots can thus simulate a mouse action based solely on the position of the cursor, without interacting or analyzing the generated HTML content.
  • a validation component is systematically positioned at a position (x, y) of the screen which constitutes the visible area of the user, then an advanced bot only has to simulate a mouse action on this position to mimic human behavior. It can thus exploit authentication forms and perpetrate a dictionary attack, exploit contact forms and send spam, etc.
  • a random character is introduced in a third embodiment in the positioning of the validation component visible to the user.
  • the size of the visible zone of a new validation zone has a surface greater than that of the visible validation component and this component has a position which varies inside this zone. randomly, from one form generation to another.
  • the new validation zone is generated in accordance with the steps E3 for generating at least one new validation zone at E6 for selecting a correct component.
  • the generation of the code associated with the visible component further comprises a pseudo-random selection of the position of the validation component from among the possible positions in the visible zone.
  • the form sent to the terminal T thus includes this validation component which can, from one form loading to another, be positioned at a different place in the visible zone.
  • this visible component is also the one that can be activated by the user.
  • the visible component is associated with an activatable component, for example a transparent component, systematically positioned at the same place as the visible component, in this case above the visible component.
  • the size of the visible area is a multiple of the size of the validation component as visible to the user. This multiple can go from one up to a number which can be important. Too high a value can however have a negative impact on visibility and ergonomics for the user. In practice, a visible surface equal to nine times the size of the validation component to be displayed seems reasonable. It can be reduced to improve ergonomics, or increased to improve safety. This embodiment may appear less pleasant and/or aesthetic for the user who may notice, during various accesses to the server, modifications in the display of a form of the made of variations in the position of a validation component. However, it is very effective in fighting bots.
  • FIG. 5 represents a form 50 generated in accordance with the steps of the method according to the third embodiment.
  • the size of the visible area 501 of the new validation areas 502 and 503 is equal to nine times the size of the visible validation component 504 displayed.
  • the form also includes elements of the reference form not modified by the steps of the process, in this case the input areas 505 and 506.
  • the new validation zones 502 and 503 of FIG. 5 are associated with two recursively nested HTML sub-pages associated with the form.
  • a single HTML sub-page is nested in the form.
  • any actions next to the validation component for example mouse clicks on a empty zone of the visible zone, are memorized to be sent with the data of the form during the step Eli of sending and analyzed by the server S.
  • the server S analyzes the actions stored at the level of the terminal T and associated with the form.
  • a server S able to implement the steps of the process for generating a validation form from a reference form and sending it to a terminal will now be described in relation to FIG. 6.
  • the server S is a piece of computer equipment, accessible from a data network such as the Internet. He understands :
  • a processing unit 61 or CPU (Central Processing Unit), intended to load instructions into memory, to execute them, to perform operations;
  • CPU Central Processing Unit
  • Server S also includes:
  • substitution module 64 arranged to generate at least one new validation zone and to substitute a validation zone to be protected from the reference form by the at least one new validation zone, said new validation zone comprising at least two com - validation components.
  • the substitution module 64 is arranged to implement step E3 of the method for generating a form and sending it to a terminal as described above;
  • the first generation module 65 is arranged to generate a unique value specific to said at least two validation components.
  • the first generation module 65 is arranged to implement step E4 of generation of validation components of the process for generating a form and sending as described previously;
  • the selection module 66 is arranged to select one of said validation components as the correct component, the other of said at least one component becoming decoys.
  • the selection module 66 is arranged to implement the step E6 of selecting a correct component of the process for generating a form and sending as described above;
  • the second generation module 67 is arranged to implement step E7 of generating a code, of the method of generating a form and of sending as described above;
  • the sending module 68 is arranged to implement step E8 of sending the method of generating a form and sending as described above.
  • the substitution module 64, the first generation module 65, the selection module 66, the second generation module 67 and the sending module 68 are preferably software modules comprising software instructions for implementing the steps of the process for generating a form from a reference form and sending it to a terminal which are implemented by the server S.
  • the invention therefore also relates to:

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal (T), ledit formulaire de référence comprenant au moins une zone de validation à protéger, la génération du formulaire comprenant les étapes suivantes : - substitution (E3) de ladite zone de validation à protéger par au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux composants de validation, - génération (E4) d'une valeur unique propre auxdits au moins deux composants de validation, - sélection (Έ6) d'un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres, - génération (E7) d'un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins un leurre, le code de positionnement permettant au composant correct d'être activé par l'utilisateur, - envoi (E8) au terminal (T) du formulaire comprenant la nouvelle zone de validation.

Description

Procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal
La présente invention se rapporte au domaine général de l’informatique et concerne plus précisé- ment un procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal. Plus précisément, le procédé est destiné à filtrer des automates malveillants sur des contenus web destinés à un être humain, de manière transparente pour l’utilisateur.
L’invention s’applique de façon privilégiée à la sécurisation de transactions de sites web et a pour but de bloquer des automates malveillants, plus précisément d’empêcher de tels automates d’ef- fectuer des actions malveillantes telles que :
- exploiter des formulaires d’authentification pour effectuer des attaques par dictionnaire,
- exploiter des formulaires de contact pour envoyer du spam,
- exploiter des formulaires de création de comptes pour créer de faux profils utilisateurs,
- exploiter des formulaires de publication de contenus sur des blogs et forums pour du spam et des codes malveillants,
- aspirer des sites web et contenus à accès limité,
- etc.
Distinguer un automate, on parle habituellement de « bot », d’un être humain est une probléma- tique majeure pour les sites web sur Internet. En effet, une portion importante du trafic web mon- dial est liée à des automates, parmi lesquels plus de la moitié correspondent à des codes malveil- lants.
Depuis les années 2000, la solution pour bloquer ces automates malveillants repose sur la mise en place de tests de Turing permettant de différencier de manière automatisée un utilisateur hu- main d’un automate. Ces tests, plus connus sous le rétro-acronyme de CAPTCHA™ (pour « Com- pletely Automated Public Turing test to tell Computers and Humans Apart »), consistent en une boîte de dialogue demandant la résolution d’un exercice simple pour un humain mais complexe pour une machine. Par exemple, ces tests peuvent consister en la reconnaissance de texte à partir d’une image du texte déformée, la reconnaissance d’éléments au sein d’une image, ou encore l’ordonnancement d’images.
Les mécanismes mis en place par les bots malveillants pour contourner les CAPTCHA reposent tous sur une analyse du contenu et de la structure des pages HTML (pour « HyperText Markup Language ») afin d’interagir avec le code ciblé. Les CAPTCHA ont donc évolué de manière à complexifier l’analyse de contenu.
Cependant, la disponibilité en accès libre de services de reconnaissance d’images de plus en plus efficaces a permis aux bots malveillants de résoudre la majorité des CAPTCHA, entraînant une escalade avec des exercices de plus en plus complexes à résoudre. Certains de ces tests sont de- venus maintenant tellement complexes que des automates obtiennent parfois de meilleurs résul- tats que les humains sur des figures trop complexes. L’impact ergonomique est important pour des utilisateurs légitimes qui se voient obligés de répondre à des problèmes absurdes et répétitifs afin d’accéder à leurs services, alors même que l’efficacité de ces méthodes est de plus en plus discutable.
Un des buts de l’invention est de remédier à des insuffisances/inconvénients de l’état de la tech- nique, et/ou d’y apporter des améliorations.
A cette fin, l’invention propose un procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal, ledit formulaire de référence comprenant au moins une zone de validation à protéger, la génération du formulaire comprenant les étapes suivantes :
- substitution de ladite zone de validation à protéger par au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux composants de validation,
- génération d’une valeur unique propre auxdits au moins deux composants de validation,
- sélection d’un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres,
- génération d’un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins un leurre, ledit code de positionnement permettant au composant correct d’être activé par l’utilisateur,
- envoi au terminal du formulaire comprenant la nouvelle zone de validation.
Le procédé propose une solution permettant de lutter efficacement contre des bots malveillants dits « basiques » qui effectuent une analyse textuelle de formulaires de référence afin d’identifier une valeur à envoyer au serveur correspondant à une action de validation de ce formulaire. De tels automates sont alors capables de remplir automatiquement de tels formulaires et de perpétrer des actions malveillantes telles que des attaques par dictionnaires, l’envoi de spam, etc. En subs- tituant dans le formulaire de référence la zone de validation par une nouvelle zone de validation qui comprend au moins deux composants de validation, le procédé complique, voire empêche, l’analyse textuelle réalisée par de tels bots qui se trouvent alors bloqués. L’action qui permet à l’utilisateur de soumettre le formulaire est remplacée par un ensemble de possibilités, variables dans le temps, c’est-à-dire qui change à chaque chargement du formulaire. Cela devient donc très difficilement analysable par le programme malveillant qui repose sur une analyse textuelle du contenu de la page correspondant au formulaire.
De façon avantageuse, le procédé de génération d’un formulaire et d’envoi à un terminal com- prend :
- réception en provenance du terminal d’une valeur de sélection, ladite valeur de sélection étant la valeur unique propre au composant de validation sélectionné par l’utilisateur, - lorsque la valeur de sélection est égale à la valeur propre au composant de validation correct, traitement des données du formulaire.
Le procédé est transparent pour un utilisateur légitime : le rendu d’une page d’un formulaire pro- posée par le serveur en réponse à une requête est inchangé par rapport au rendu du formulaire de référence qui serait proposé si le procédé n’était pas mis en œuvre.
Avec le procédé, il n’est pas nécessaire d’adjoindre au traitement du formulaire un test de type CAPTCHA afin de distinguer un utilisateur d’un bot. L’impact ergonomique du procédé est donc nul pour un utilisateur.
Par ailleurs, les éléments à remplir par l’utilisateur, par exemple, son adresse e-mail, son mot de passe, restent identifiables et accessibles dans le formulaire. Ainsi, si l’utilisateur utilise un ges- tionnaire de mot de passe, le procédé de l’invention est sans impact pour ce gestionnaire dont le fonctionnement repose sur une analyse du formulaire.
Avantageusement, la sélection du composant de validation correct et de sa valeur unique propre parmi les au moins deux composants de validation est pseudo-aléatoire.
Le choix du composant de validation correct et de sa valeur unique propre associée étant pseudo- aléatoire, il est donc impossible pour un bot qui effectue une analyse purement textuelle du for- mulaire d’anticiper le choix d’un composant de validation correct, le choix de celui-ci variant d’un chargement du formulaire à un autre.
Dans un exemple de réalisation, un desdits au moins deux composants de validation peut être dans un état compris dans un ensemble d’états comprenant : superposé à un autre desdits au moins un composant, distribués dans l’espace, visible, transparent, masqué, apte à se déplacer dynamique- ment lors du chargement du formulaire, apte à se déplacer dynamiquement sur une action de l’utilisateur
Ainsi, les possibilités de positionnement et de représentation du composant correct et des leurres sont nombreuses, ce qui complexifie, voire rend impossible une analyse textuelle du formulaire. En effet, il est ainsi possible d’obtenir de nombreux formulaires de code différents avec un rendu parfaitement identique pour un utilisateur.
Dans un premier exemple de réalisation, le formulaire de référence étant constitué d’une page HTML, la nouvelle zone de validation est constituée d’une sous-page HTML imbriquée dans la page HTML associée au formulaire de référence sous forme d’une balise iFrame.
Dans un deuxième exemple de réalisation, le formulaire de référence étant constitué d’une page HTML, ledit formulaire de référence comprend une balise HTML spécifique, associée à une li- brairie javascript, ladite balise spécifique étant remplacée par un code substituant la zone de va- lidation par la nouvelle zone de validation. Da façon avantageuse, le formulaire comprend au moins deux nouvelles zones de validation, les- dites nouvelles zones de validation étant cloisonnées les unes par rapport aux autres.
Cet exemple de réalisation permet de lutter contre des bots qualifiés de « standards », qui dispo- sent d’un moteur de rendu HTML et ont le plus souvent la capacité d’exécuter du code javascript. De tels bots sont capables de récupérer dans une page HTML l’élément visible, tel qu’un compo- sant de validation, situé à des coordonnées données. On comprend qu’une fois cet élément récu- péré il est facile pour le bot d’extraire la valeur associée et de la soumettre au serveur ou encore de simuler de façon programmatique une interaction avec un formulaire de validation, tel qu’un clic souris. Avec l’utilisation de plusieurs zones de validation, chacune étant considérée comme un espace cloisonné, il est impossible pour un bot standard de travailler sur un rendu global d’une combinaison ces nouvelles zones de validation. Ainsi, un bot standard, et a fortiori un bot basique, est dans l’incapacité d’identifier le composant de validation correct et activable par l’utilisateur parmi les composants de validation des combinaisons de nouvelles zones de validation.
Dans un exemple de réalisation, lesdites au moins deux nouvelles zones de validation étant sous forme d’au moins deux sous-pages, le procédé comprend la génération d’un décalage pseudo- aléatoire des abscisses et des ordonnées entre les au moins deux sous-pages, la génération du décalage garantissant une intersection entre une zone visible de l’utilisateur et les au moins deux sous-pages supérieure à la taille d’un composant de validation.
Cela garantit de toujours pouvoir afficher un composant de validation, tout en introduisant une certaine flexibilité dans le positionnement des différentes zones de validation les unes par rapport aux autres.
Dans un exemple de réalisation, la nouvelle zone de validation comprend une zone visible par l’utilisateur, ladite zone visible étant de taille égale à un multiple de la taille d’un composant de validation visible, ledit composant de validation visible étant positionné de manière pseudo-aléa- toire dans la nouvelle zone de validation.
Cet exemple de réalisation permet de lutter contre des bots qualifiés de « évolués » qui sont ca- pables de simuler des actions de l’utilisateur, comme des frappes au clavier, des déplacements, ou des clics souris. Ces actions sont strictement équivalentes, d’un point de vue logiciel, à celles générées par de vrais périphériques d’entrée, et peuvent en absolu être distinguées par des solu- tions basées sur l’analyse comportementale et l’intelligence Artificielle. Ce type d’approche se base sur une modélisation du comportement de l’utilisateur avant que Faction, tel un clic souris, n’intervienne. Cependant l’analyse comportementale pose de réels problèmes de préservation de la vie privée. En effet, elle consiste à enregistrer des données propres à l’utilisateur afin de modé- liser son comportement. La solution proposée ici offre une solution qui permet de lutter à elle seule contre les bots évolués et rend donc optionnelle une analyse comportementale. Le caractère aléatoire introduit dans le positionnement du composant de validation visible de l’utilisateur ne permet pas de simuler le comportement de l’utilisateur. On peut qualifier cette approche de res- pectueuse de la vie privée car indépendante de toute analyse comportementale.
L’invention concerne également un serveur apte à générer un formulaire de validation à partir d’un formulaire de référence et à l’envoyer à un terminal, ledit formulaire de référence compre- nant au moins une zone de validation à protéger, le serveur comprenant :
- des moyens de substitution, agencés pour substituer ladite zone de validation à protéger par au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux composants de validation,
- des premiers moyens de génération, agencés pour générer une valeur unique propre auxdits au moins deux composants de validation,
- des moyens de sélection, agencés pour sélectionner un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres,
- des deuxièmes moyens de génération, agencés pour générer un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins leurre, le code de positionnement permettant au composant correct d’être activé par l’utilisateur,
- des moyens d’envoi, agencés pour envoyer au terminal le formulaire comprenant la nouvelle zone de validation.
L’invention porte aussi sur un programme d’ordinateur sur un support de données et chargeable dans la mémoire d’un ordinateur, le programme comprenant des portions de code pour exécuter les étapes du procédé de génération d’un formulaire de validation et d’envoi à un terminal tel que décrit précédemment, lorsque le programme est exécuté sur ledit ordinateur.
L’invention concerne enfin également un support de données dans lequel est enregistré le pro- gramme tel que présenté ci-dessus.
D'autres caractéristiques et avantages de la présente invention seront mieux compris de la des- cription détaillée, des annexes et des figures annexées parmi lesquels :
- la figure 1 présente les étapes d’un procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal, selon un premier exemple de réalisation ;
- la figure 2 présente un exemple de code de formulaire de référence et de code modifié au moyen d’une balise iFrame ;
- la figure 3a présente un exemple de code HTML généré conformément aux étapes du procédé de génération et d’envoi d’un formulaire, selon un premier exemple de réalisation ;
- la figure 3b représente une modélisation du rendu de la sous-page présentée à la figure 3a ; - la figure 4a présente un exemple de code HTML généré conformément aux étapes du procédé de génération et d’envoi d’un formulaire, selon un deuxième exemple de réalisation ;
- la figure 4b représente une modélisation du rendu des sous-pages présentées à la figure 4a ;
- la figure 5 représente une illustration d’un formulaire généré à partir des étapes du procédé, selon un troisième exemple de réalisation ;
- la figure 6 est une représentation schématique d’un serveur agencé pour mettre en œuvre les étapes du procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal, selon un premier exemple de réalisation.
Les étapes d’un procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal, selon un premier exemple de réalisation, vont maintenant être décrites en relation avec la figure 1.
Le procédé décrit ici est destiné à distinguer un automate (ou « bot » en anglais), c’est-à-dire un logiciel informatique effectuant des actions automatiques, d’un être humain lors du traitement d’un formulaire de validation. L’exemple est décrit ici dans le cas de formulaire de type HTML (pour « HyperText Markup Language »), embarquant ou non du code javascript. L’invention peut s’appliquer à d’autres types de formulaires. A noter cependant que les langages actuels connus adaptés pour créer de tels formulaires sont en général des métalangages agencés pour générer des pages HTML. Lorsqu’il est malveillant, un tel automate peut être agencé pour par exemple, rem- plir et envoyer des formulaires d’authentification de manière à perpétrer des attaques par diction- naires contre des sites sensibles. Par la suite le mot « bot » désigne un bot malveillant.
Le procédé découle du constat que les mécanismes mis en place par les bots existants pour traiter automatiquement des formulaires de validation reposent tous sur une analyse du contenu de la structure de pages HTML qui constituent ces formulaires afin d’interagir directement avec le code ciblé. Ces bots renseignent automatiquement le formulaire le cas échéant, et identifient une por- tion de code associée à un composant de validation tel qu’un bouton à cliquer, puis génèrent programmatiquement un événement associé à ce composant, tel qu’un clic souris par exemple, afin que le formulaire soit traité comme si c’était un être humain qui l’avait renseigné. Au con- traire, un humain s’appuie sur le rendu visuel de la page pour naviguer : il visualise un composant de validation et opère une action sur ce composant pour accéder à l’étape suivante dans un pro- cessus donné. Le procédé décrit ici exploite cette différence et « noie » en quelque sorte l’infor- mation perceptible par l’utilisateur et qui permet à celui-ci de valider les données d’une page d’un formulaire, dans un ensemble de composants de validation dont un seul est activable par l’utili- sateur, les autres servant alors de leurres pour un programme automatisé analysant la page corres- pondant au formulaire. On entend par « activable » un composant qui, sélectionné par l’utilisateur par un moyen de pointage ou une touche de validation, provoque la génération d’un événement associé qui déclenche l’envoi des données de la page et leur traitement par le serveur. Il peut s’agir par exemple de valider l’envoi de données d’identification et d’authentification saisies dans un formulaire.
Un terminal informatique T est agencé pour émettre des requêtes afin d’accéder à des ressources d’un réseau, par exemple le réseau Internet. Les ressources, telles que des services, sont accédées au moyen d’un protocole de communication client-serveur, par exemple « HTTP » (« HyperText Transfer Protocol »). Les clients HTTP les plus connus sont des navigateurs web qui permettent à des utilisateurs d’accéder au moyen de leur terminal à des données stockées sur un serveur S. Dans l’exemple décrit ici, le terminal informatique T est un ordinateur personnel, un terminal mobile, une tablette, un « PDA » (« Personal Digital Assistant »), etc. Le serveur S est un ordina- teur, hébergeur de services, apte à traiter des requêtes de services émanant du terminal T. Par la suite on appelle ressource, ou « URL » (pour « Uniform Resource Locator »), une donnée propo- sée par un serveur ou le serveur lui-même qui sont concernés par la requête. Le procédé s’intéresse plus particulièrement aux pages ou formulaires de validation de pages web. De tels formulaires sont destinés à valider l’envoi de données au serveur, ou valider le passage à une page suivante dans un enchaînement de pages web qui constitue par exemple un parcours client. Un tel formu- laire peut comprendre par exemple une zone dans laquelle l’utilisateur saisie des données telles qu’un identifiant, et un bouton, ou composant de validation, permettant de valider l’envoi au ser- veur des données saisies. Dans un autre exemple de formulaire de validation associé à un parcours client, la zone de saisie est absente et l’utilisateur doit appuyer sur le bouton pour accéder à une page suivante.
Ainsi, dans une étape initiale EO d’envoi d’une requête, le terminal utilisateur T envoie une re- quête d’accès REQ à une ressource du serveur S. Cette requête REQ correspond à une demande d’accès au serveur S faite par l’utilisateur depuis un navigateur du terminal T en sélectionnant une URL associée au serveur.
La requête est reçue par le serveur S dans une étape El de réception. On suppose que l’URL sélectionnée par l’utilisateur est associée sur le serveur à une page HTML correspondant à un formulaire de validation dit « de référence ». Ce formulaire comprend le cas échéant des éléments pour lesquels l’utilisateur est censé saisir des informations, soit sous forme de texte, soit sous forme d’éléments à sélectionner tels que des cases à cocher, des listes à sélectionner, etc., et une zone de validation à protéger, par exemple un bouton « envoyer » ou un bouton « suivant » d’un parcours client. C’est cette zone de validation qui est protégée par les étapes du procédé. Le for- mulaire est dit « de référence » car les étapes du procédé vont en quelque sorte transformer ce formulaire de référence sur réception de la requête en un formulaire FORM, et substituer à la zone de validation à protéger au moins une nouvelle zone de validation, difficilement analysable par un bot dit « basique ». Un bot basique correspond à un simple script automatisé capable de ne percevoir une page HTML que comme un contenu textuel et de ne faire qu’une analyse textuelle d’une telle page. En effet, l’action qui permet de soumettre le formulaire de référence est rempla- cée dans le formulaire envoyé au terminal T par un ensemble de possibilités, variables dans le temps.
Dans une étape suivante E2 de génération d’un identifiant, le serveur S génère un identifiant unique IDU associé à la requête REQ.
Dans une étape suivante E3 de substitution, le serveur S génère au moins une nouvelle zone de validation et substitue la zone de validation à protéger par la au moins une nouvelle zone de validation. Une nouvelle zone de validation comprend au moins deux composants de validation.
Dans un premier exemple de réalisation le serveur S génère une seule nouvelle zone de validation, sous forme d’une sous-fenêtre. Dans le cas de pages HTML décrit ici, le serveur S génère la nouvelle zone de validation sous forme d’une sous-page HTML destinée à se substituer à la zone de validation à protéger du formulaire de référence. Cette sous-page est imbriquée dans la page HTML correspondant au formulaire de référence ; elle est destinée à constituer une nouvelle zone de validation dans le formulaire de validation à envoyer à l’utilisateur. Ce formulaire correspond ainsi au formulaire de référence dans lequel la zone de validation à protéger a été substituée par la nouvelle zone de validation contenue dans la sous-page HTML.
Dans un premier exemple de réalisation, la sous-page HTML générée est imbriquée dans le for- mulaire de référence, sous forme d’une balise « iFrame ». La balise iFrame permet d’intégrer dans une page HTML le contenu d’une autre page HTML. La figure 2 présent un exemple de code de formulaire de référence comprenant un bouton de validation initial « Envoyer ! » et de code d’un formulaire modifié. La sous-page « invention.html » ainsi créée en remplacement du bouton de validation initial comprend des instructions HTML décrivant une nouvelle zone de validation qui comprend un ensemble d’au moins deux composants de validation. Cette sous-page est de taille variable mais généralement de la taille de l’écran du terminal T de l’utilisateur. Cependant, seule une portion de cette sous-fenêtre est rendue visible à l’utilisateur et constitue une zone visible. Cette zone visible correspond en quelque sorte à la zone dans laquelle un nouveau composant de validation visible est susceptible d’apparaître aux yeux de l’utilisateur. La taille de la zone visible est adaptée de manière à ne pas recouvrir du texte qui serait affiché à l’attention de l’utilisateur, ou des zones de saisies comprises dans la page initiale du formulaire de référence. Les paramètres de la taille de la zone visible sont définis dans le code comme paramètre d’inclusion de la sous- page iFrame.
Dans un deuxième exemple de réalisation, le formulaire de référence comprend un champ HTML spécifique sous forme de balise, associé à une librairie javascript et identifiant la zone de valida- tion à protéger. Sur réception de h requête de l’utilisateur correspondant à l’obtention du formu- laire de référence, la balise est remplacée par un code javascript qui substitue la zone de validation à protéger par la nouvelle zone de validation, conformément aux étapes du procédé.
Dans une étape E4 de génération de composants de validation, le serveur S génère au moins deux composants de validation destinés à la nouvelle zone de validation. Les composants de validation générés, notés Ci, ...Cn, avec n > 2, possèdent une information générale identique : même classe
(« button), même nom (« login »), même contenu (« submit »). Ils n’ont aucun élément distinctif en dehors de leur style qui correspond à la façon dont ils apparaissent dans la sous-page. En re- vanche, chacun des composants de validation possède une valeur unique. C’est à cette valeur qu’est associé un événement programmatique destiné à effectuer un traitement associé.
Ainsi, dans une étape suivante E5 de génération d’une valeur, le serveur S génère pour chacun des composants Ci de validation de la sous-page une valeur pseudo-aléatoire unique V;. Ainsi, la valeur unique propre à chacun des composants est susceptible de changer à chaque fois qu’un formulaire de référence est traité conformément aux étapes du procédé.
Dans une étape suivante E6 de sélection d’un composant correct, le serveur S désigne de manière pseudo-aléatoire un des composants de validation Cj de la sous-page comme composant correct. Ainsi, un seul composant et sa valeur associée sont considérés comme valides à un instant t. Ce composant de validation Cj est destiné à être celui que l’utilisateur pourra activer avec un moyen de pointage, tel qu’une souris ou un écran tactile. La valeur Vj associée au composant correct Cj devient de ce fait une valeur correcte. Il est important de noter qu’avec ce tirage pseudo-aléatoire du composant correct et la génération pseudo-aléatoire de la valeur propre unique associée au cours de l’étape précédente à ce composant, seul le serveur S connaît pour le formulaire destiné à être transmis à l’utilisateur en réponse à la requête reçue au cours de l’étape El, la valeur asso- ciée au bouton de validation activable par l’utilisateur et qui est celle attendue par le serveur S pour traiter les données du formulaire. Le composant correct Cj, choisi de manière pseudo-aléa- toire, varie donc à chaque chargement de la page.
Les autres composants de validation Ci, ..., Cj-i, Cj-1, ..., Cn deviennent alors des leurres destinés à tromper des bots. A noter que le composant de validation correct Cj n’est pas forcément le com- posant de validation visible par l’utilisateur du fait des différentes caractéristiques attribuables aux composants de validation de la page.
A noter que le caractère pseudo-aléatoire dans le choix du composant correct et dans le choix de la valeur associée aux composants de validation ne permet pas à un bot de s’appuyer sur l’une ou l’autre de ces informations lors d’une analyse à un instant t d’un formulaire afin d’utiliser ces informations lors du chargement ultérieur à un instant t + 7 de la page HTML associée au formu- laire. Dans une étape E7 de génération d’un code de positionnement, le serveur S génère pour le com- posant de validation correct Cj, et pour chacun des leurres, un code de positionnement HTML au moyen de feuilles de style css et de code javascript. Les codes des leurres et du composant de validation correct Cj sont générés de manière à positionner les leurres de façon à ce qu’une inte- raction entre l’utilisateur et le composant de validation correct Cj puisse avoir lieu. En particulier, le code des leurres et du composant correct Cj utilisent astucieusement l’ordre d’ajout de ces codes dans la sous-page. A noter que le code associé au composant de validation correct Cj peut être contraint à un certain emplacement. En effet, il peut être positionné systématiquement à un endroit correspondant à l’emplacement d’un composant de validation de la zone de validation à protéger du formulaire de référence. Pour autant, l’analyse de la sous-page ainsi générée n’en est pas plus facile. En effet, des leurres peuvent être positionnés au-dessus et/ou en dessous du composant de validation correct, complexifiant ainsi une analyse textuelle de la sous-pageHTML par un bot.
Dans une étape suivante E8 d’envoi du formulaire, le formulaire FORM d’identifiant 1DU ainsi généré est envoyé au terminal T en réponse à la requête.
Dans une étape E9 de réception et d’affichage, le formulaire FORM est affiché sur l’écran du terminal T de l’utilisateur.
Dans une étape E10 d’action utilisateur, l’utilisateur remplit le cas échéant le formulaire de vali- dation et sélectionne le composant de validation activable, noté Ck. Dans cet exemple de réalisa- tion le composant de validation activable Ck correspond au composant de validation Cl visible par l’utilisateur. Dans un autre exemple de réalisation le bouton de validation activable Ck est différent du composant de validation visible Cl. Par exemple le composant activable Ck est transparent et positionné au-dessus du composant visible Cl.
Cela provoque dans une étape Ell d’envoi, l’envoi au serveur S de données du formulaire DA- TAFORM(data, IDU’, Vk) comprenant des données data saisies par l’utilisateur le cas échéant, un identifiant IDU’ du formulaire et la valeur Vk associée au composant de validation Ck activé par l’utilisateur.
Les données du formulaire sont reçues par le serveur S dans une étape El 2 de réception.
Dans une étape El 3 de comparaison, il est vérifié par le serveur S que le couple formé par l’iden- tifiant IDU’ du formulaire et la valeur Vk et reçu du terminal T est égal au couple formé par l’identifiant IDU et la valeur correcte Vj générée pour ce formulaire.
Dans un premier cas où la comparaison est positive (cas « ok » sur la figure 1), alors Faction est considérée comme valide et les données du formulaire sont traitées dans une étape suivante E14 de traitement
Dans le cas contraire (cas « nok » sur la figure 1) alors Faction est considérée comme invalide et dans une étape suivante E15 de traitement d’une erreur, les données du formulaire sont refusées et une mesure est mise en œuvre. Par exemple, il y a génération et envoi d’un nouveau formulaire, conformément aux étapes E2 de génération d’un identifiant à E9 d’envoi du formulaire telles que décrites précédemment. Dans un deuxième exemple de réalisation, le terminal T est suspecté d’at- taque à l’encontre du serveur S et est mis en quarantaine. Dans un autre exemple de réalisation, le terminal T est redirigé vers une page de validation au moyen d’un CAPTCHA classique.
Un exemple de code de la sous-page HTML « invention.html » tel que généré à partir des étapes décrites précédemment est fourni à la figure 3a, et une modélisation du rendu de cette sous-page est fourni à la figure associée 3b. Dans la figure 3b, la zone de validation à protéger du formulaire de référence est substituée par une sous-page HTML 30.
La sous-page 30 comprend une zone visible 11 et huit composants de validation de valeur notées valeur_l, , valeur_8. Chaque composant de validation comporte une information générale identique. Ainsi, aucun bouton ne comporte d’élément distinctif en dehors de son style css. Une seule de ces valeurs est considérée comme valide à un instant t et correspond au bouton activable par l’utilisateur avec un moyen de pointage, tel qu’une souris.
Sur la figure 3a, qui correspond au code HTML de la sous-page dont la modélisation du rendu est présentée à la figure 3b, le composant valide avec lequel l’utilisateur peut interagir correspond au composant de validation ayant pour valeur valeur_5 ; c’est un élément transparent actif situé en avant des autres composants. Ainsi, dans l’exemple des figure 3a et 3b, Vcorrecte -valeur _5. Tous les autres composants de validation, de par leur présence dans le code de la sous-page HTML servent de leurres pour un programme automatisé destiné à analyser la page.
Les composants situés programmatiquement au-dessus sont en effet respectivement : désactivé et nnoonn visible pour le composant de valeur valeur_8 ;
- déplacé dynamiquement en dehors du champ visible pour le composant de valeur valeur_6, dès que l’utilisateur le sélectionne avec son moyen de pointage.
Les autres composants sont positionnés :
- programmatiquement en-dessous du composant de valeur correcte en utilisant la propriété css « z-index » ; c’est le cas du composant de valeur valeur_2. Bien que ce composant soit celui qui soit visible pour l’utilisateur, les composants positionnés devant lui étant transparents et actifs, ce n’est pas celui qui recevra les interactions ;
- implicitement en-dessous du composant de valeur valide ; c’est le cas des composants de valeur valeur_l et valeur_7, visibles et actifs à l’instar du composant de valeur valeur_2. La propriété « z-index » est par défaut considérée comme étant égale à 1 par les moteurs de rendu HTML ;
- hors champ de manière statique grâce aux propriétés css : c’est le cas du composant de valeur valeur_3 ;
- en-dessous du composant de valeur valide du fait de leur ordre d’ajout dans la page HTML ; c’est le cas du composant de valeur valeur_4.
Les techniques de positionnement utilisées, telles que le style css associé à un composant de va- lidation, un code javascript ou l’ordre d’ajout des composants peuvent varier et être présentes alternativement ou simultanément dans une même sous-page HTML selon les itérations.
Ainsi, rien ne distingue un composant de validation d’un autre dans la sous-page hormis son style css. Un bot basique sera donc impuissant pour identifier le composant de validation actif lors d’une analyse textuelle d’une sous-page HTML. Cela est d’autant plus vrai que le contenu de la sous-page est généré pseudo-aléatoirement de telle façon que la distribution des composants de validation dans l’espace varie à chaque itération. Une analyse du code de la sous-page HTML du formulaire pour un service donné ne peut donc permettre un remplissage automatique du formu- laire à des fins frauduleuses. Par ailleurs, la perception qu’a l’utilisateur du formulaire est inchan- gée, le même formulaire chargé à différent instants ayant toujours le même aspect.
Avec les étapes du procédé décrites précédemment, le processus de blocage d’un bot est totale- ment transparent pour l’utilisateur. 11 n’est donc pas nécessaire d’ajouter un test supplémentaire sous forme de CAPTCHA lors de la validation d’un formulaire afin de différencier un utilisateur d’un bot. La validation d’un formulaire est donc plus ergonomique du point de vue de l’utilisateur et simplifiée du point de vue traitements des formulaires.
Dans un exemple de réalisation, le nombre de composants de validation compris dans le formu- laire de validation ainsi généré est compris entre 4 et 8. Cet exemple n’est pas limitatif. Cependant, un nombre trop important de composants de validation peut entraîner un mauvais rendu du for- mulaire au niveau du terminal utilisateur T. Un nombre trop faible peut par contre augmenter les chances d’un bot d’exploiter le formulaire. Des tests ont montré que l’utilisation de six compo- sants de validation donnait de très bons résultats.
Dans l’exemple décrit précédemment, la zone de validation à protéger dans le formulaire de réfé- rence est substituée par une nouvelle zone de validation représentée par une unique sous-page HTML. Cet exemple est adapté pour pallier des attaques de bots basiques. Cependant, certains types de bots, qualifiés de « standards » utilisent un moteur de rendu HTML et ont le plus souvent la capacité d’exécuter un code javascript. Pour ces bots, le langage javascript offre une fonction- nalité permettant de récupérer dans une page HTML l’élément visible situé à des coordonnées données. En effet, le langage javascript dispose notamment d’une méthode « document.element- FromPoint(x, y) » qui permet pour une page HTML donnée, de récupérer l’élément visible situé aux coordonnées (x, y) fournies. Une fois cet élément récupéré, il devient possible pour le bot d’extraire la valeur associée pour la soumettre au serveur S, ou encore de simuler de façon pro- grammatique une interaction avec un formulaire de validation, tel qu’un clic souris.
Afin de pallier des attaques de bots standards, dans un deuxième exemple de réalisation, illustré par les figures 4a et 4b, la zone de validation à protéger du formulaire de référence est substituée par au moins deux nouvelles zones de validation, correspondant chacune à une sous-fenêtre. La figure 4b est une modélisation du rendu du code HTML présenté à la figure 4a. Dans l’exemple de code HTML présenté ici, le code de la zone de validation à protéger du formulaire de référence est substitué par trois sous-pages HTML imbriquées. Dans cet exemple, chacune des sous-pages est une iFrame HTML qui comprend, en plus de la partie du formulaire HTML qui permet sa validation et des composants de validation générés selon les principes des étapes E4 de génération de composants de validation à E7 de génération d’un code de positionnement décrites précédem- ment, et de manière récursive, une autre sous-page générée selon les mêmes principes.
Cet ensemble de sous-pages imbriquées, chacune étant associée à une nouvelle zone de validation, dispose des propriétés suivantes :
- chaque sous-page possède un code permettant de soumettre le formulaire d’origine ;
- les valeurs associées aux composants de validation, tels que les boutons HTML, des sous-pages sont uniques, une même valeur ne pouvant se retrouver dans différentes sous-pages ;
- une seule de ces valeurs est considérée comme valide à un instant t ;
- la seule valeur considérée comme valide à l’instant t est celle qui est accessible au moyen d’un périphérique de pointage, par exemple, une souris, un doigt sur un écran tactile, etc.
A l’instar des composants de validation qui peuvent être représentés au sein d’une sous-page, chaque sous-page peut :
- être distribuée dans l’espace, en fonction de ses coordonnées x et y ;
- être visible, transparente et/ou masquée ;
- se déplacer dynamiquement, au chargement de la sous-page ou sur action de F utilisateur, par exemple lors du déplacement de la souris.
Dans un exemple de réalisation, dans une étape de génération d’un décalage, non représentée sur la figure 1 et préalable à l’étape E7 de génération de code de positionnement, un décalage pseudo- aléatoire des coordonnées x et y des différentes sous-pages est généré tout en garantissant une intersection desdites sous-pages sur le plan (x, y) supérieure à la taille d’un composant de valida- tion. Cela garantit de toujours pouvoir afficher un composant de validation tout en introduisant un décalage entre les différentes sous-pages.
Les sous-pages étant positionnables dynamiquement les unes par rapport aux autres, les coordon- nées d’affichage réelles d’un composant sont donc dépendantes :
- de la position de ce composant dans sa sous-fenêtre ;
- de la position de cette sous-page par rapport aux sous-pages parentes, c’est-à-dire celles dans lesquelles elle est imbriquée.
A noter que la profondeur d’une sous-page est prédéfinie et correspond à l’ordre d’inclusion des sous-pages : la première sous-page est positionnée au premier plan, la deuxième vient se posi- tionner au-dessous, la troisième au-dessous de la deuxième, etc.
Ainsi, dans l’exemple de la figure 4b, correspondant à une modélisation du rendu du code HTML présenté à la figure 4a, trois sous-fenêtres 40, 41 et 42 correspondant aux trois sous-pages HTML de la figure 4a sont visibles. La première sous-fenêtre 40 apparaît derrière les deux autres sous- fenêtres, conformément à l’ordre d’inclusion des sous-pages HTML. La première sous-fenêtre 40 comprend les composants de validation associés aux valeurs valeur_l et valeur_2. La deuxième sous-fenêtre 41 comprend les composants de validation associés aux valeurs valeur_3 et valeur_4 et enfin, la troisième sous-fenêtre 42, qui apparait au-dessus des deux autres car imbriquée en dernier, comprend les composants de validation associés aux valeurs valeur_5 et valeur_6. A noter que certains composants de validation ne sont pas visibles, car situés en dehors de la zone 43 visible de l’utilisateur. Dans cet exemple de réalisation, les coordonnées (x, y) des deuxième et troisième sous-page 41 , 42 ont fait l’objet d’un léger décalage généré dans les sous-pages HTML conformément aux instructions « translate( - 150%, 50%) ». Dans l’exemple de la figure 4a et de la figure 4b associée, le composant de valeur valeur_4 est celui qui est activable par l’utilisateur.
La profondeur de récursivité peut être variable selon la complexité souhaitée. Cependant une va- leur trop faible, c’est-à-dire inférieure à trois, peut rendre le problème d’identification du compo- sant de validation correct trop simple pour un bot standard, alors qu’une valeur trop élevée peut induire une consommation de ressources importante au niveau du terminal T et des problèmes d’affichage. A titre d’exemple, et suite à différents tests, une valeur égale à six est adaptée.
L’avantage procuré par ce deuxième mode de réalisation est que chaque sous-page étant considé- rée par le langage javasScript comme un espace cloisonné, il n’est pas possible de travailler sur un rendu global d’une combinaison de ces sous-pages. Le langage javasScript nécessite à l’heure actuelle de parcourir chacune des sous-pages pour accéder à ses éléments. La conséquence est qu’une méthode du type « document.elementFromPoint(x, y) », exploitable dans le premier mode de réalisation pour déterminer le composant visible aux coordonnées fournies, devient inopérante dans ce deuxième mode de réalisation. En effet, une telle méthode ne retourne que le composant positionné dans la sous-page considérée, et non le composant résultant de la combinaison des sous-pages. La position (x, y) fournie sera celle de la sous-page considérée et non celle de l’espace visible de l’utilisateur.
Ainsi, ce deuxième mode de réalisation est efficace pour éviter à des bots standards, et a fortiori à des bots basiques, de déterminer le composant accessible par l’utilisateur et la valeur valide associée.
Cependant, certains bots, dits « avancés », sont capables de simuler des actions utilisateurs, comme des frappes de clavier, des déplacements ou des clics de souris. Ces actions sont stricte- ment équivalentes d’un point de vue système ou logiciel à celles générées par de véritables péri- phériques d’entrée et ne peuvent être éventuellement distinguées que par une analyse comporte- mentale, connue pour soulever des problèmes de préservation de la vie privée. De tels bots peu- vent ainsi simuler une action de la souris en se basant uniquement sur la position du curseur, sans interagir ni analyser le contenu HTML généré. Ainsi, si un composant de validation est systéma- tiquement positionné à une position (x, y) de l’écran qui constitue la zone visible de l’utilisateur, alors un bot avancé n’a qu’à simuler une action de la souris sur cette position pour reproduire le comportement humain. Il peut ainsi exploiter des formulaires d’authentification et perpétrer une attaque par dictionnaire, exploiter des formulaires de contact et envoyer du spam, etc.
Afin de contrer ces bots avancés sans avoir à mettre en œuvre une analyse comportementale pour les distinguer d’un utilisateur réel, il est introduit dans un troisième mode de réalisation un carac- tère aléatoire dans le positionnement du composant de validation visible de l’utilisateur. Ainsi, dans ce troisième mode de réalisation, la taille de la zone visible d’une nouvelle zone de validation possède une surface supérieure à celle du composant de validation visible et ce composant pos- sède une position qui varie à l’intérieur de cette zone de manière aléatoire, d’une génération de formulaire à une autre.
La nouvelle zone de validation est générée conformément aux étapes E3 de génération d’au moins une nouvelle zone de validation à E6 de sélection d’un composant correct. Dans l’étape E7 de génération d’un code, la génération du code associé au composant visible comprend en outre une sélection pseudo-aléatoire de la position du composant de validation parmi les positions possibles dans la zone visible. Le formulaire envoyé au terminal T comprend ainsi ce composant de valida- tion qui peut, d’un chargement de formulaire à un autre, être positionné à un endroit différent dans la zone visible. La zone visible restant circonscrite, cela ne perturbe pas l’utilisateur outre mesure. Dans un premier exemple de réalisation, ce composant visible est aussi celui qui est activable par l’utilisateur. Dans un deuxième exemple de réalisation, le composant visible est associé à un com- posant activable, par exemple un composant transparent, positionné systématiquement au même endroit que le composant visible, en l’occurrence au-dessus du composant visible.
Dans un exemple de réalisation de ce troisième mode de réalisation, la taille de la zone visible est un multiple de la taille du composant de validation tel que visible par l’utilisateur. Ce multiple peut aller de un jusqu’à un nombre qui peut être important. Une valeur trop importante peut ce- pendant avoir un impact négatif sur la visibilité et l’ergonomie pour l’utilisateur. En pratique, une surface visible égale à neuf fois la taille du composant de validation à afficher parait raisonnable. Elle peut être réduite afin d’améliorer l’ergonomie, ou augmenter afin d’améliorer la sécurité. Ce mode de réalisation peut paraître moins agréable et/ou esthétique pour l’utilisateur qui peut cons- tater, lors de différents accès au serveur, des modifications dans l’affichage d’un formulaire du fait de variations dans la position d’un composant de validation. Cependant, il est très efficace pour lutter contre des bots.
Ce troisième mode de réalisation est illustré par la figure 5 qui représente un formulaire 50 généré conformément aux étapes du procédé selon le troisième mode de réalisation. Dans cet exemple, la taille de la zone visible 501 des nouvelles zones de validation 502 et 503 est égale à neuf fois la taille du composant de validation 504 visible affiché. Le formulaire comprend par ailleurs des éléments du formulaire de référence non modifiés par les étapes du procédé, en l’espèce les zones de saisies 505 et 506.
Aux nouvelles zones de validation 502 et 503 de la figure 5 sont associées deux sous-pages HTML imbriquées de manière récursives et associées au formulaire. Dans un autre exemple de réalisation, et à l’instar du premier mode de réalisation décrit précédemment, une seule sous-page HTML est imbriquée dans le formulaire.
Dans un exemple de réalisation, dans une sous-étape de mémorisation (non représentée sur la figure 1) de l’étape Eli de réception et d’affichage, des actions éventuelles à côté du composant de validation, par exemple des clics souris sur une zone vide de la zone visible, sont mémorisées pour être envoyées avec les données du formulaire au cours de l’étape Eli d’envoi et analysées par le serveur S. Ainsi, dans une sous-étape d’analyse (non représentée sur la figure 1) de l’étape E14 de traitement, le serveur S analyse les actions mémorisées au niveau du terminal T et asso- ciées au formulaire. Une telle analyse permet de distinguer un automate, qui effectue des tests multiples dans la zone visible jusqu’à cliquer statistiquement sur le composant de validation, d’un être humain accédant immédiatement ou avec un nombre d’erreurs très restreint au composant de validation.
Un serveur S, apte à mettre en œuvre les étapes du procédé de génération d’un formulaire de validation à partir d’un formulaire de référence et d’envoi à un terminal va maintenant être décrit en relation avec la figure 6.
Le serveur S est un équipement informatique, accessible depuis un réseau de données tel qu’ In- ternet. Il comprend :
- une unité de traitement 61, ou CPU (de l’anglais « Central Processing Unit »), destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ;
- un ensemble de mémoires, dont une mémoire volatile 62, ou RAM (pour « Random Access Memory ») utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mé- moire de stockage 63 de type EEPROM (de l’anglais « Electronically-Erasable Programmable Read-Only Memory »). En particulier, la mémoire de stockage 63 est agencée pour mémoriser un module logiciel de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal, tel que décrit précédemment. Le serveur S comprend également :
- un module de substitution 64, agencé pour générer au moins une nouvelle zone de validation et pour substituer une zone de validation à protéger du formulaire de référence par la au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux com- posants de validation. Le module de substitution 64 est agencé pour mettre en œuvre l’étape E3 du procédé de génération d’un formulaire et d’envoi à un terminal tel que décrit précédemment ;
- un premier module de génération 65, agencé pour générer une valeur unique propre auxdits au moins deux composants de validation. Le premier module de génération 65 est agencé pour mettre en œuvre l’étape E4 de génération de composants de validation du procédé de génération d’un formulaire et d’envoi tel que décrit précédemment ;
- un module de sélection 66, agencé pour sélectionner l’un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres. Le module de sélection 66 est agencé pour mettre en œuvre l’étape E6 de sélection d’un composant correct du procédé de génération d’un formulaire et d’envoi tel que décrit précédemment ;
- un deuxième module de génération 67, agencé pour générer un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins un leurre. Le code de positionnement d’un leurre permet au composant correct d’être activé par l’utilisateur. Le deuxième module de génération 67 est agencé pour mettre en œuvre l’étape E7 de génération d’un code, du procédé de génération d’un formulaire et d’envoi tel que décrit précédemment ;
- un module d’envoi 68, agencé pour envoyer au terminal T le formulaire comprenant la nouvelle zone de validation. Le module d’envoi 68 est agencé pour mettre en œuvre l’étape E8 d’envoi du procédé de génération d’un formulaire et d’envoi tel que décrit précédemment.
Le module de substitution 64, le premier module de génération 65, le module de sélection 66, le deuxième module de génération 67 et le module d’envoi 68 sont de préférence des modules logi- ciels comprenant des instructions logicielles pour mettre en œuvre les étapes du procédé de géné- ration d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal qui sont mises en œuvre par le serveur S.
L’invention concerne donc également :
- un programme d’ordinateur comportant des instructions de code pour la mise en œuvre du pro- cédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal tel que décrit précédemment et mises en œuvre par le serveur S lorsque ce programme est exécuté par un processeur du serveur S, et
- un support d’enregistrement lisible sur lequel est enregistré le programme d’ordinateur ci-dessus.

Claims

Revendications
[Revendication 1] Procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal (T), ledit formulaire de référence comprenant au moins une zone de validation à protéger, la génération du formulaire comprenant les étapes suivantes :
- substitution (E3) de ladite zone de validation à protéger par au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux composants de validation,
- génération (E4) d’une valeur unique propre auxdits au moins deux composants de validation,
- sélection (E6) d’un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres,
- génération (E7) d’un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins un leurre, ledit code de positionnement permettant au composant correct d’être activé par l’utilisateur,
- envoi (E8) au terminal (T) du formulaire comprenant la nouvelle zone de validation.
[Revendication 2] Procédé de génération d’un formulaire et d’envoi à un terminal selon la revendication 1, comprenant :
- réception (E12) en provenance du terminal (T) d’une valeur de sélection, ladite valeur de sélection étant la valeur unique propre au composant de validation sélectionné par l’utilisateur,
- lorsque la valeur de sélection est égale à la valeur propre au composant de validation correct, traitement (El 4) des données du formulaire.
[Revendication 3] Procédé de génération d’un formulaire et d’envoi à un terminal selon la revendication 1 ou la revendication 2, dans lequel la sélection du composant de validation correct et de sa valeur unique propre parmi les au moins deux composants de validation est pseudo-aléatoire.
[Revendication 4] Procédé de génération d’un formulaire de validation et d’envoi à un terminal selon l’une des revendications précédentes dans lequel un desdits au moins deux composants de validation peut être dans un état compris dans un ensemble d’états comprenant : superposé à un autre desdits au moins un composant, distribués dans l’espace, visible, transparent, masqué, apte à se déplacer dynamiquement lors du chargement du formulaire, apte à se déplacer dynamiquement sur une action de l’utilisateur.
[Revendication 5] Procédé de génération d’un formulaire et d’envoi à un terminal selon l’une des revendications précédentes, dans lequel le formulaire de référence étant constitué d’une page HTML, la nouvelle zone de validation est constituée d’une sous-page HTML imbriquée dans la page HTML associée au formulaire de référence sous forme d’une balise iFrame.
[Revendication 6] Procédé de génération d’un formulaire et d’envoi à un terminal selon l’une des revendications 1 à 4, dans lequel le formulaire de référence étant constitué d’une page HTML, ledit formulaire de référence comprend une balise HTML spécifique, associée à une librairie javascript, ladite balise spécifique étant remplacée par un code substituant la zone de validation par la nouvelle zone de validation.
[Revendication 7] Procédé de génération d’un formulaire et d’envoi à un terminal selon l’une des revendications précédentes, dans lequel le formulaire comprend au moins deux nouvelles zones de validation, lesdites nouvelles zones de validation étant cloisonnées les unes par rapport aux autres.
[Revendication 8] Procédé de génération d’un formulaire et d’envoi à un terminal selon la revendication précédente, dans lequel lesdites au moins deux nouvelles zones de validation étant sous forme d’au moins deux sous-pages, le procédé comprend la génération d’un décalage pseudo-aléatoire des abscisses et des ordonnées entre les au moins deux sous-pages, la génération du décalage garantissant une intersection entre une zone visible de l’utilisateur et les au moins deux sous-pages supérieure à la taille d’un composant de validation.
[Revendication 9] Procédé de génération d’un formulaire et d’envoi à un terminal selon l'une des revendications précédentes dans lequel la nouvelle zone de validation comprend une zone visible par l’utilisateur, ladite zone visible étant de taille égale à un multiple de la taille d’un composant de validation visible, ledit composant de validation visible étant positionné de manière pseudo-aléatoire dans la nouvelle zone de validation.
[Revendication 10] Serveur (S) apte à générer un formulaire de validation à partir d’un formulaire de référence et à l’envoyer à un terminal (T), ledit formulaire de référence comprenant au moins une zone de validation à protéger, le serveur comprenant :
- des moyens de substitution (64), agencés pour substituer ladite zone de validation à protéger par au moins une nouvelle zone de validation, ladite nouvelle zone de validation comprenant au moins deux composants de validation,
- des premiers moyens de génération (65), agencés pour générer une valeur unique propre auxdits au moins deux composants de validation,
- des moyens de sélection (66), agencés pour sélectionner un desdits composants de validation comme composant correct, les autres desdits au moins un composant devenant des leurres, - des deuxièmes moyens de génération (67), agencés pour générer un code de positionnement dans la nouvelle zone de validation pour le composant correct et pour les autres desdits au moins leurre, le code de positionnement permettant au composant correct d’être activé par l’utilisateur,
- des moyens d’envoi (68), agencés pour envoyer au terminal (T) le formulaire comprenant la nouvelle zone de validation.
[Revendication 11 ] Programme d’ordinateur sur un support de données et chargeable dans la mémoire d’un ordinateur, le programme comprenant des portions de code pour exécuter les étapes du procédé de génération d’un formulaire de validation et d’envoi à un terminal selon l’une des revendications 1 à 9, lorsque le programme est exécuté sur ledit ordinateur.
[Revendication 12] Support de données dans lequel est enregistré le programme selon la revendication 11.
PCT/FR2021/052316 2020-12-17 2021-12-14 Procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal Ceased WO2022129772A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2013557 2020-12-17
FR2013557A FR3118229B1 (fr) 2020-12-17 2020-12-17 Procédé de génération d’un formulaire à partir d’un formulaire de référence et d’envoi à un terminal

Publications (1)

Publication Number Publication Date
WO2022129772A1 true WO2022129772A1 (fr) 2022-06-23

Family

ID=74592241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/052316 Ceased WO2022129772A1 (fr) 2020-12-17 2021-12-14 Procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal

Country Status (2)

Country Link
FR (1) FR3118229B1 (fr)
WO (1) WO2022129772A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170034148A1 (en) * 2011-02-10 2017-02-02 Fireblade Holdings, Llc DISTINGUISH VALID USERS FROM BOTS, OCRs AND THIRD PARTY SOLVERS WHEN PRESENTING CAPTCHA
US20190373012A1 (en) * 2016-02-12 2019-12-05 Shape Security, Inc. Detecting and deploying countermeasures against an autonomous browser

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170034148A1 (en) * 2011-02-10 2017-02-02 Fireblade Holdings, Llc DISTINGUISH VALID USERS FROM BOTS, OCRs AND THIRD PARTY SOLVERS WHEN PRESENTING CAPTCHA
US20190373012A1 (en) * 2016-02-12 2019-12-05 Shape Security, Inc. Detecting and deploying countermeasures against an autonomous browser

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VIKRAM SHARDUL ET AL: "NOMAD: Towards non-intrusive moving-target defense against web bots", 2013 IEEE CONFERENCE ON COMMUNICATIONS AND NETWORK SECURITY (CNS), IEEE, 14 October 2013 (2013-10-14), pages 55 - 63, XP032529046, DOI: 10.1109/CNS.2013.6682692 *

Also Published As

Publication number Publication date
FR3118229B1 (fr) 2024-04-05
FR3118229A1 (fr) 2022-06-24

Similar Documents

Publication Publication Date Title
US11356479B2 (en) Systems and methods for takedown of counterfeit websites
US9954841B2 (en) Distinguish valid users from bots, OCRs and third party solvers when presenting CAPTCHA
Kharraz et al. Surveylance: Automatically detecting online survey scams
Edu et al. SkillVet: automated traceability analysis of Amazon Alexa skills
Petsas et al. Two-factor authentication: is the world ready? Quantifying 2FA adoption
Jha et al. The internet with privacy policies: Measuring the web upon consent
Van Acker et al. FlashOver: Automated discovery of cross-site scripting vulnerabilities in rich internet applications
JP2006520940A (ja) インターネット検索エンジンにおける無効クリック検出方法および装置
CN104135365A (zh) 对访问请求进行验证的方法、服务器及客户端
CN113032655A (zh) 一种暗网电子数据提取固定方法
Koide et al. To get lost is to learn the way: Automatically collecting multi-step social engineering attacks on the web
WO2012028817A1 (fr) Procède de recueil de données a caractères événementiel de formulaires électroniques
CN121079671A (zh) 从电子文档检测和移除预定义的敏感信息类型
Laperdrix Browser fingerprinting: Exploring device diversity to augment authentification and build client-side countermeasures
Liu et al. Learning based malicious web sites detection using suspicious urls
CN110321702A (zh) 检测网络资源的修改的系统和方法
Intumwayase et al. Ua-radar: Exploring the impact of user agents on the web
WO2022129772A1 (fr) Procédé de génération d'un formulaire à partir d'un formulaire de référence et d'envoi à un terminal
Koide et al. To Get Lost is to Learn the Way: An Analysis of Multi-Step Social Engineering Attacks on the Web
Vastel Tracking versus security: investigating the two facets of browser fingerprinting
Algwil Click-based Captcha paradigm as a web service
FR2867577A1 (fr) Procede permettant de remplir automatiquement des donnees utilisateur en utilisant une identification d'empreintes digitales
CN118316999B (zh) 数据处理方法、装置、设备、介质和程序产品
Laperdrix Untangling the Web TRacKing Ecosystem to Design Effective Defenses
Goel et al. A Novel and Efficient Multilayered Approach to CAPTCHA: Design, Performance and Usability Evaluation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21851611

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21851611

Country of ref document: EP

Kind code of ref document: A1