A method for defending against CSRF attacks based on mobile phone tokens

Abstract

A method for defending against CSRF attacks based on mobile phone tokens, comprising the following steps: S1: a client registers an account containing mobile phone number information, logs in to the account, and after the client sends an HTTP request to a server, the server obtains the mobile phone number registered in the client; S2: the client randomly generates a server dynamic token, sends it to the client, and the server saves the server dynamic token at the same time; S3: after the client receives the server dynamic token, it edits the mobile phone dynamic token and sends the mobile phone dynamic token to the server number exclusive to the server; S4: the server compares whether the mobile phone dynamic token and the server dynamic token are the same; S5: if the mobile phone dynamic token and the server dynamic token are different, the connection between the server and the client is cut off; if the mobile phone dynamic token and the server dynamic token are the same, the connection between the server and the client is established. This method can effectively prevent attackers from operating on different servers under the same root domain name.

Description

Technical Field

[0001] The present invention relates to the field of mobile phone website access security, and in particular to a method for defending against CSRF attacks based on mobile phone tokens. Background Art

[0002] A cross-site request forgery (CSRF) attack is when an attacker uses a user's login information on a website to send a request to any website in the same root domain as the website, thereby sending emails, modifying information, or purchasing goods in the name of the user.

[0003] In the prior art, if a user successfully logs in to a website under the root domain, it is considered that the user is in a logged-in state on any website under the root domain. Therefore, if an attacker impersonates the user and sends a request to the website under the root domain to purchase goods, modify user information, etc., the website under the root domain will perform corresponding business processing based on the request.

[0004] Specifically, since the login information of different websites under the same root domain name is the same and is stored in session cookies, an attacker can impersonate the user by carrying the cookie value of the website that the user has successfully logged in to in the http request and send an http request to the target website with the same first-level domain name as the website that the user has successfully logged in to.

[0005] The existing technology uses two common methods to protect against CSRF attacks: one is to limit the request source in the HTTP Referer. However, based on the consideration of user privacy protection, the server cannot obtain the Referer under all circumstances. Summary of the invention

[0006] In order to overcome the deficiencies in the prior art, the present invention proposes a method for defending against CSRF attacks based on mobile phone tokens, which can prevent attackers from using different websites under the same root domain name to perform operations such as purchasing goods that do not belong to the customer, thereby effectively ensuring the security of customer network information.

[0007] In order to achieve the above-mentioned purpose, a method for defending against CSRF attacks based on a mobile phone token of the present invention comprises the following steps: step S1: a client registers an account including mobile phone number information, logs in to the account, and after the client sends an HTTP request to a server, the server obtains the mobile phone number registered in the client; step S2: the client randomly generates a server dynamic token, sends it to the client in the form of a text message, and the server saves the server dynamic token at the same time; step S3: after the client receives the server dynamic token, it edits the mobile phone dynamic token, and sends the mobile phone dynamic token to a server number exclusive to the server; step S4: the server obtains the mobile phone dynamic token and the mobile phone number in the server number by calling the server number, and then obtains the server dynamic token corresponding to the mobile phone number according to the mobile phone number, and the server compares whether the mobile phone dynamic token and the server dynamic token are the same; step S5: if the mobile phone dynamic token and the server dynamic token are different, the connection between the server and the client is cut off to prevent the attacker from counterfeiting and attacking the client of the client through the server website; if the mobile phone dynamic token and the server dynamic token are the same, the connection between the server and the client is established, and the client can access the server normally.

[0008] Furthermore, the server dynamic password is composed of one or more combinations of numbers, letters or symbols.

[0009] Furthermore, the server dynamic password is at least 4 characters.

[0010] Furthermore, in step S3, the time for editing the mobile phone dynamic token is three minutes. The time for editing the mobile phone dynamic token starts from the time the server sends the server dynamic token. If the time for editing the mobile phone dynamic token exceeds three minutes, the server deletes the server dynamic token saved in step S2 and cuts off the connection between the server and the client.

[0011] Furthermore, the server is multiple websites under the same root domain name.

[0012] Furthermore, in step S3, the client sends the mobile phone dynamic token to the server number via SMS, or the client sends the mobile phone dynamic token to the server number via a mobile phone app.

[0013] Beneficial effect: When an attacker uses the customer's login information to visit different websites under the same root domain name, when switching to the latter website, the website server will send a server dynamic token to the mobile phone number under the login information. After the operator checks the server dynamic token on the mobile phone, the server can only allow the client to continue to access the server if the same mobile phone dynamic token is sent to the server. If the server does not receive the mobile phone dynamic token, or the mobile phone dynamic token does not completely match the server dynamic token, the access connection between the server and the client will be cut off, avoiding losses in operations such as purchasing goods caused by the client's continued access to the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The present invention will be further described and explained below in conjunction with the accompanying drawings.

[0015] Figure 1 It is a flow chart of the steps of the preferred embodiment of the present invention. DETAILED DESCRIPTION

[0016] The technical solution of the present invention will be more clearly and completely explained below through description of preferred embodiments of the present invention in combination with the accompanying drawings.

[0017] like Figure 1 As shown, a method for defending against CSRF attacks based on a mobile phone token in a preferred embodiment of the present invention comprises the following steps:

[0018] Step S1: The client registers an account including mobile phone number information, logs in to the account, and after the client sends an HTTP request to the server, the server obtains the mobile phone number registered in the client.

[0019] Specifically, when a client visits a website, it first needs to register and log in to an account. Since the account contains the mobile phone number used by the client when registering, when the client accesses the server with the account, the server can obtain the mobile phone number in the client account. The way to obtain the mobile phone number is to call the program code of the mobile phone number value under the cookie under the account.

[0020] There are two situations at this time: The first situation: If the client continues to operate on the website under the root domain name, that is, the client is always accessing the above server, it means that the client has not abandoned the session with the server, which indirectly means that the real customer of the client is still operating on the server. At this time, the attacker cannot use the account information to carry out illegal purchases and other operations. The operations between the client and the website belong to the operations of the real user of the client. At this time, the client can normally contact the server of the website, and the client's access to the server is not affected in any way.

[0021] The second case: if the client abandons the session with the above server and selects other servers under the root domain name, it means that there is a certain risk for the client to access other servers under the same root domain name, and it will enter step S2.

[0022] Specifically, for example, after the client logs in to http: / / blog.163.com, it also logs in to http: / / mail.163.com or http: / / www.163.com. These three websites belong to three different servers under the same root domain name. When the client has been accessing the server of the website http: / / blog.163.com, it is a real operation of the client; if it switches to the server of the website http: / / mail.163.com or http: / / www.163.com, the operation at this time belongs to accessing different websites under the same root domain name, and it will enter step S2.

[0023] Step S2: The client randomly generates a server dynamic token and sends it to the client via SMS. The server saves the server dynamic token at the same time.

[0024] Specifically, when accessing different servers under the same root domain name, the server accessed later will directly call the cookie information under the previous server, instead of the client directly logging in and accessing the later server. Due to the above difference, the later server will execute step S2.

[0025] Specifically, the server accessed later uses a code tool, for example, a random generation tool, to generate a string, which is the server dynamic token belonging to the later server. In order to ensure the complexity of the server dynamic token and to prevent it from being cracked, the server dynamic token is at least 4 characters; and the 4 characters are composed of one or more combinations of numbers, letters or symbols, such as 7834, A47B, %4Q2, etc.

[0026] After generating the server dynamic token, the server performs two steps.

[0027] Step 1: Save the generated server dynamic token to the database.

[0028] Step 2: Send the server dynamic token to the client via SMS.

[0029] Step S3: After receiving the server dynamic token, the client edits the mobile phone dynamic token and sends the mobile phone dynamic token to the server number exclusive to the server.

[0030] Specifically, after the client receives the server dynamic token, it is available for the client user to view. The client here can specifically refer to a device that can receive text messages, such as a mobile phone, iPad, etc. After the client learns the server dynamic token, it edits the mobile phone dynamic token to ensure that the mobile phone dynamic token is exactly the same as the server dynamic token, and then sends the mobile phone dynamic token to the server's exclusive server number. The server's exclusive server number refers to the server's exclusive telephone number, such as 10086 is a mobile exclusive number, and 1069364020164362 is a Tencent exclusive number.

[0031] There are two ways for the client to send mobile dynamic commands to the server's dedicated server number.

[0032] The first method: the client, such as a mobile phone, directly edits the text message, enters the mobile phone dynamic command that is the same as the server dynamic command in the text message content, and the recipient is the server's exclusive number, and then sends it.

[0033] The second method: Use the mobile app corresponding to the server to directly send the mobile dynamic instruction to the server in the mobile app. For example, if the server is Taobao, the mobile dynamic token is sent in the function area on the mobile Taobao app. The mobile app must have a server channel that directly communicates with the website server of the website.

[0034] Step S4: The server obtains the mobile phone dynamic token and mobile phone number in the server number by calling the server number, and then obtains the server dynamic token corresponding to the mobile phone number based on the mobile phone number. The server compares the mobile phone dynamic token and the server dynamic token to see if they are the same.

[0035] Specifically, after receiving the information sent by the client, the server will first obtain the two parameters of the mobile phone number and the mobile phone dynamic token carried in the client information. Among them, the mobile phone number is the information brought by the client, and the mobile phone dynamic token is the information typed by the client. The server can obtain the two parameters of the mobile phone number and the mobile phone dynamic token carried in the client information by calling the client information command.

[0036] After the server obtains the client's mobile phone number, it will traverse the database information to find all the information matching the mobile phone number. Since the server dynamic token stored in the database is mapped one-to-one with the client's mobile phone number, the client's mobile phone number is the same as the mobile phone number that sent the information to the server. Therefore, the server can easily find the server dynamic token corresponding to the mobile phone number based on the mobile phone number. Then the server compares the server dynamic token with the received mobile phone dynamic token.

[0037] Step S5: If the mobile phone dynamic token and the server dynamic token are different, the connection between the server and the client is cut off to prevent the attacker from impersonating or attacking the client through the server website; if the mobile phone dynamic token and the server dynamic token are the same, the connection between the server and the client is established, and the client can access the server normally.

[0038] Specifically, there are three situations for the comparison results between the server dynamic token and the mobile phone dynamic token.

[0039] The first type: the mobile phone dynamic token is the same as the server dynamic token. After the mobile phone token is verified, the client can normally access the website under the same root domain name. In particular, if the client accesses two websites under different domain names, it will not receive the server dynamic token, because if the latter server is not under the same root domain name as the former server, the latter server cannot obtain the cookie information in the former server, so naturally it cannot perform a series of operations based on the cookie information. The latter server is in a state of having no login information.

[0040] The second type: If the mobile phone dynamic token is different from the server dynamic token, the server will no longer respond to the client's HTTP request, and the server and the client will be disconnected.

[0041] The third type: the client times out and does not respond. Specifically, the client fails to send the mobile phone dynamic token to the server within 3 minutes. At this time, the server will consider that the client has timed out and will reject the client's HTTP request. At the same time, the server will delete the server dynamic token stored in the database. The client cannot access subsequent websites under the same root domain name at this time. The aforementioned 3 minutes refers to the time from when the server sends the server dynamic token to when the server compares the mobile phone dynamic token. In other words, ignoring the server comparison and query time, the maximum time for the client to enter the mobile phone dynamic token is 3 minutes.

[0042] The above specific implementations are only descriptions of the preferred implementations of the present invention, and do not limit the protection scope of the present invention. Without departing from the design concept and spirit of the present invention, various modifications, substitutions and improvements made by ordinary technicians in this field to the technical solution of the present invention based on the text description and drawings provided by the present invention should all fall within the protection scope of the present invention. The protection scope of the present invention is determined by the claims.

Claims

1. A method for defending against CSRF attacks based on mobile phone tokens, characterized in that: The following steps are involved: Step S1: The client registers an account including mobile phone number information, logs in to the account, and after the client sends an HTTP request to the server, the server obtains the mobile phone number registered in the client. The way to obtain the mobile phone number is to call the program code of the mobile phone number value under the cookie under the account. At this time, there will be two situations: the first situation: if the client always continues to operate under the website under the root domain name at this time, that is, the client is always accessing the above server, it means that the client has not abandoned the session with the server, which indirectly means that the real customer of the client is still operating on the server. At this time, the attacker cannot use the account information to implement illegal purchase operations. The operations between the client and the website belong to the operations of the real user of the client. At this time, the client can normally contact the server of the website, and the client's access to the server is not affected in any way; the second situation: if the client abandons the session with the above server and chooses other servers under the root domain name instead, it means that the client has a certain risk of accessing other servers under the same root domain name, and it will enter step S2; Step S2: The client randomly generates a server dynamic token and sends it to the client in the form of a text message. The server saves the server dynamic token at the same time. When accessing different servers under the same root domain name, the server accessed later will directly call the cookie information under the previous server, instead of the client directly logging in and accessing the subsequent server. Due to the above difference, the subsequent server will execute step S2 and use a random generation tool to generate a string. The string is the server dynamic token belonging to the subsequent server. In order to ensure the complexity of the server dynamic token and make it difficult to be cracked, the server dynamic token is at least 4 characters; and the 4 characters are composed of one or more combinations of numbers, letters or symbols. After generating the server dynamic token, the subsequent server performs two steps: the first step is to save the generated server dynamic token to the database; the second step is to send the server dynamic token to the client in the form of a text message; Step S3: After receiving the server dynamic token, the client edits the mobile phone dynamic token and sends the mobile phone dynamic token to the server number exclusive to the server. The time for editing the mobile phone dynamic token is three minutes. The time for editing the mobile phone dynamic token starts from the time when the server sends the server dynamic token. If the time for editing the mobile phone dynamic token exceeds three minutes, the server deletes the server dynamic token saved in step S2 and cuts off the connection between the server and the client. The client sends the mobile phone dynamic token to the server number by SMS, or the client sends the mobile phone dynamic token to the server number by mobile phone app. Step S4: the server obtains the mobile phone dynamic token and mobile phone number in the server number by calling the server number, and then obtains the server dynamic token corresponding to the mobile phone number according to the mobile phone number. The server compares whether the mobile phone dynamic token and the server dynamic token are the same. The server is a plurality of websites under the same root domain name. After receiving the information sent by the client, the server first obtains the two parameters of the mobile phone number and the mobile phone dynamic token carried in the client information, wherein the mobile phone number is the information brought by the client, and the mobile phone dynamic token is the information typed by the client. After the server obtains the mobile phone number of the client, the server traverses the database information to find all the information matching the mobile phone number. Since the aforementioned server dynamic token stored in the database is mapped one-to-one with the mobile phone number of the client, and the mobile phone number of the client and the mobile phone number sending the information to the server are the same mobile phone number, the server can easily find the server dynamic token corresponding to the mobile phone number according to the mobile phone number, and then the server compares the server dynamic token with the received mobile phone dynamic token. Step S5: If the mobile phone dynamic token is different from the server dynamic token, the connection between the server and the client is cut off to prevent the attacker from impersonating or attacking the client through the server website; if the mobile phone dynamic token is the same as the server dynamic token, the connection between the server and the client is established, and the client can access the server normally; Specifically, there are three cases for the comparison between the server dynamic token and the mobile phone dynamic token: The first type: the mobile phone dynamic token is the same as the server dynamic token. After the mobile phone token is verified, the client can normally access the website under the same root domain name. If the client accesses two websites under different domain names, it will not receive the server dynamic token. Because, if the latter server is not under the same root domain name as the former server, the latter server cannot obtain the cookie information in the former server, so naturally it cannot perform operations based on the cookie information. The latter server is in a state of having no login information; The second type: If the mobile phone dynamic token is different from the server dynamic token, the server will no longer respond to the client's HTTP request, and the server and the client will be disconnected; The third type: the client times out and does not respond. Specifically, the client does not send the mobile phone dynamic token to the server within 3 minutes. At this time, the server will consider that the client has timed out and responds, and the server will reject the client's HTTP request. At the same time, the server will delete the server dynamic token stored in the database. The client cannot access subsequent websites under the same root domain name. The aforementioned 3 minutes refers to the time from the server sending the server dynamic token to the server after it compares the mobile phone dynamic token. In other words, ignoring the server comparison and query time, the maximum time for the client to enter the mobile phone dynamic token is 3 minutes.

Images