CN107844290B

CN107844290B - Software product design method and device based on data stream security threat analysis

Info

Publication number: CN107844290B
Application number: CN201711168824.XA
Authority: CN
Inventors: 程威
Original assignee: 北京思源理想控股集团有限公司
Current assignee: Langxin Data Technology Co ltd
Priority date: 2017-11-21
Filing date: 2017-11-21
Publication date: 2021-04-30
Anticipated expiration: 2037-11-21
Also published as: CN107844290A

Abstract

The invention discloses a software product design method and a device based on data flow security threat analysis, wherein the method comprises the following steps: acquiring the functional requirements of a user; converting the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis and reconstruction; coding the data flow graph to obtain a final product; compared with the prior art, the method has the advantages that the functional requirements of the user are converted into the data flow graph which can be used by security designers and research and development designers, and the data flow graph is coded after security threat analysis and optimization analysis, so that a product required by the user is finally obtained; the process of designing the product is safe, visual, standardized and controllable in flow, and is easy to learn; through the division of participating in the role, senior designer plays more important role, and first-line developer also can greatly increased development efficiency through the dataflow graph, and the efficiency of safety analysis and safety design will also be promoted to the safety designer.

Description

Software product design method and device based on data stream security threat analysis

Technical Field

The invention belongs to the technical field of information security, and particularly relates to a software product design method based on data flow security threat analysis.

Background

At present, standard processes and methods are lacked in safety analysis and design in the development process in the market, so that safety threat analysis is not uniform and thousands of people are available; the development design is static and lacks dynamic security analysis; without a set of methodology, the method can be practiced in the process of safety development, and organically combines users, product designers, research and development designers, safety designers and developers; the security threat analysis only depends on security experts, and meanwhile, the security experts are often not proficient in business, so that the analysis result of the security threat is difficult to form a touchable security design; the first line developers have too many important roles in the security development process, resulting in a security bottleneck.

Disclosure of the invention

The present invention is directed to solving some of the problems of the prior art.

In order to solve the above problems, the present invention provides a software product design method based on data flow security threat analysis, including: step (1), acquiring the functional requirements of a user; step (2), converting the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis and reconstruction; and (3) coding the data flow graph to obtain a final product.

In some embodiments, the business process comprises the steps of: step (2.1), the client calls a service API of the server; step (2.2), the service interface checks the parameters; step (2.3), the service interface of the server side calls an authentication interface; and (2.4) returning response information to the client according to the return interface of the authentication interface.

In some embodiments, the business process includes at least one data stream; the data stream includes: setting a data stream starting identifier, setting a data stream API identifier, setting a data stream request variable identifier, setting a data stream judgment variable identifier, setting a data stream intermediate variable identifier, setting a data stream response variable identifier and describing a data stream variable.

In some embodiments, the business process specifically includes: wireless circulation can not occur, and each judgment can finally go to the end of the process; the judgment logic has only one inlet, can only aim at the judgment variable, and has at most 2 different branches as a judgment result; the request and response must be only one for the same data stream; in a complete business process, the data flow should be controlled within 5; the key variable cannot be present in the url; and a plurality of judgment variables influence results to be completely consistent and need to be merged and expressed.

In some embodiments, the step (2) specifically includes: optimizing and analyzing, specifically comprising judging variable combination, service combination, response combination and abnormal variables; and safety threat analysis, specifically comprising confidentiality, integrity, anti-replay, identity authentication and authorization, parameter format verification, attack protection and service logic loopholes.

The invention also provides a software product design device based on the data flow security threat analysis, which comprises the following components: the acquisition module is configured to acquire the functional requirements of the user; the conversion reconstruction module is configured to convert the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis reconstruction; and the coding module is configured for coding the dataflow graph to obtain a final product.

In some embodiments, the conversion and reconstruction module specifically includes: the first calling unit is used for configuring a service API used for the client to call the server; the checking unit is configured for checking the parameters by the service interface; the second calling unit is used for configuring a service interface calling authentication interface for the server; and the response unit is configured to return response information to the client according to the return interface of the authentication interface.

In some embodiments, the conversion and reconstruction module specifically includes: optimizing and analyzing, specifically comprising judging variable combination, service combination, response combination and abnormal variables; and safety threat analysis, specifically comprising confidentiality, integrity, anti-replay, identity authentication and authorization, parameter format verification, attack protection and service logic loopholes.

By adopting the technical scheme, compared with the prior art, the method has the advantages that the functional requirements of the user are converted into the data flow graph which can be used by security designers and research and development designers, and the data flow graph is coded after security threat analysis and optimization analysis, so that the product required by the user is finally obtained; the process of designing the product is safe, visual, standardized and controllable in flow, and is easy to learn; through the division of participating in the role, senior designer plays more important role, and first-line developer also can greatly increased development efficiency through the dataflow graph, and the efficiency of safety analysis and safety design will also be promoted to the safety designer.

Description of the drawings:

FIG. 1 is an exemplary system architecture diagram in which the present invention is applied;

FIG. 2 is a flow diagram of an embodiment of a software product design method based on data flow security threat analysis of the present invention;

FIG. 3 is a schematic structural diagram of a software product design apparatus based on data flow security threat analysis according to the present invention;

FIG. 4 is a block diagram of a computer system suitable for use with a terminal device or server implementing an embodiment of the invention;

FIG. 5 is a data flow diagram of an embodiment of the present invention.

Detailed Description

The following detailed description of embodiments of the invention refers to the accompanying drawings. It should be noted that the specific embodiments described herein are only for illustrating and explaining the present invention and are not to be construed as limiting the present invention.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. Various communication client applications, such as shopping applications, search applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the

terminal devices

101, 102, 103.

The

terminal devices

101, 102, 103 may be various electronic devices including, but not limited to, smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 105 may be a server providing various services, such as a background server providing support for shopping-like applications, search-like applications, etc. on the

terminal devices

101, 102, 103. The server can store, analyze and the like the received data and feed back the processing result to the terminal equipment.

As shown in fig. 2, the present embodiment provides a software product design method based on data stream security threat analysis, and the present embodiment is mainly applied to the server 105, and includes the following steps:

step 201, acquiring the function requirement of the user.

In this embodiment, the server 105 receives the function requirements input by the user using the

terminal devices

101, 102, and 103.

In some optional implementations of this embodiment, the terminal device may be a mobile phone, a tablet computer, or a notebook computer, and the user may also perform input on a kiosk or a desktop computer.

Step 202, converting the functional requirements of the user into a data flow graph through a business process, wherein optimization analysis and security threat analysis reconstruction are performed on the data flow of the business process.

In this embodiment, the server 105 converts the functional requirements input by the user into a data flow graph through the business process.

In some optional embodiments of this embodiment, the service flow specifically is a login service:

step 2021, the client calls a login (USM-login) API of the server;

step 2022, checking the parameter by the logic interface;

step 2023, the service side login interface calls a recognition interface (Ldap-Auth);

step 2024, according to the return interface of the Ldap interface, returning the information of the response to the client.

In some optional implementations of this embodiment, as shown in fig. 5, the business process includes one or more data flows; the data stream includes:

setting a data stream start identifier: a rectangle using blue ground color; the name of the data stream generally corresponds to a specific interface of the server; sequence number, since we include multiple data streams in a business process, it is required that the beginning of each data stream must be added with a sequence number, which indicates the execution sequence of the current data stream in the whole business process.

Setting a data stream API identification: the following example using a green background color is shown; the data stream corresponds to the name of the API and must correspond to a specific interface of the server; sequence number, because we include multiple data streams in one service flow, it is required that the beginning of each data stream must be added with a sequence number, which indicates the execution sequence of the current data stream in the whole service flow; the number in parentheses indicates that the interface is http, otherwise, the http protocol.

Example (c): logic ().

Setting a data stream request variable identifier: the following example using a green background color is shown;

example 1:

X-API-TOKEN-Black moiety

Username-white moiety

Password-white part

validateCode-white part

Example 2:

X-Toon-User-Agent-Black moiety

TeleCode-purple moiety

Moblie-purple fraction

uuid-purple moiety

The request variable marks different variable types according to variable name colors; black represents the header variable; purple represents the url variable submitted by get; white represents the variables submitted at post.

Setting a data flow judgment variable identifier: the data flow corresponds to the judgment variable identification, each data flow has at least one judgment variable, and when a plurality of judgment variables exist, a judgment logic should be individually identified for each different shortening variable; the following example using a red background color:

example (c):

Username

Ifnull or“”

judging the variable to be the key variable, which determines the data circulation direction; the names of variables are to be written, for example: a Username; the judgment criteria to be written are, for example: username cannot be empty.

Setting an intermediate variable identifier of a data stream, wherein the intermediate variable is a new variable generated in the program running process; the following example using yellow undertones is shown;

LdapContext(Username+pwd+ldapUrl)＝>ctx

type of variables are indicated: LdapContext;

attribute information constituting intermediate process variables: username, pwd, ldaprul;

name of intermediate Process variable: ctx.

Setting a data stream response variable identifier;

the following example using a light red undertone is shown;

{ "meta" { "code": 401, "message": password could not be empty "}," data ": {}}

The response variable must be a JSON result;

attribute value indicating return object: code, message, data;

the response variable can eventually only point to other data streams or end.

Data flow variable description: a variable name;

variable level: whether it is a nested variable, or there is a child attribute (lower level variable);

example (c): variable values are exemplified;

a data type;

whether transmission is necessary, whether the transmission is empty, length definition and content format definition;

extent of affecting data flow: which data streams use the variable.

In some optional implementations of this embodiment, the service flow specifically includes: wireless circulation can not occur, and each judgment can finally go to the end of the process; the judgment logic has only one inlet, can only aim at the judgment variable, and has at most 2 different branches as a judgment result; the request and response must be only one for the same data stream; in a complete business process, the data flow should be controlled within 5; the key variable cannot be present in the url; and a plurality of judgment variables influence results to be completely consistent and need to be merged and expressed.

In some alternative embodiments of the present embodiment,

flow optimization analysis

1) Judging variable merging

a) The mobile + telecom is empty, the business logic does not care which one is empty, and the flow carries out the respective judgment of the two variables.

b) And (3) verifying 11-bit digits of ' 0086 ' + mobile ' of the telecode + mobile, wherein the business logic only concerns whether the format of the mobile phone number is normal, so that the format of the mobile phone number only needs to be verified.

2) Service merging

a) The password login interface and the password interface for the switching equipment to check have the same password checking process.

3) Response merging

a) The response may unify the variable names, giving different responses with different values.

4) Abnormal variable

a) The variable terminal is generated by empty, which can be empty, and introduces a potential safety hazard.

Second, security threat analysis

Confidentiality:

1) transmission encryption

The following steps are described: channel encryption is not carried out, so that the clear text information can be checked after https decryption;

the solution measures are as follows: channel encryption is used from the user to the pre-service.

2) Individual encryption of sensitive information

The following steps are described: password is transmitted by using md5 code without one-time pad encryption.

The solution measures are as follows: the password is encrypted using a salted encryption algorithm.

3) URL variables contain sensitive information

The following steps are described: the sensitive variable mobileVerfiyCode is present in url, MD5, which is the plaintext cipher.

The solution measures are as follows: the transport sensitive variable is passed and encrypted using the post method.

4) Weak encryption/encoding

The following steps are described: and the password uniformly uses md5 codes, so that a larger cracking risk exists.

The solution measures are as follows: password is encrypted using symmetric or asymmetric encryption.

Integrity of

5) Tamper-proof

The following steps are described: parameter signatures are made that result in the manipulation of the select, mobile, uuid, isRelogin, passcode, mobileVerfiyCode, x-ton-user-agent.

The solution measures are as follows: signature measures are added to the key variables to prevent message tampering.

③ preventing replay

6) Sensitive interface message replay

The following steps are described: the login message of the mobile phone number + the password md5 can be replayed, so that the message is intercepted, and the login is successful; the message of the password verified by the switching equipment can be replayed, and the success of password verification can be simulated.

The solution measures are as follows: adding an anti-replay strategy.

Fourth, identity authentication and authorization

7) Identity authentication

The following steps are described: when the short message code logs in, a super password of a mobile + fixed character string is generated to log in, and no matter whether the user sets the password or not, the user can log in by using a default password.

The solution measures are as follows: and different auth interfaces are used for login by the mobile phone number + the short message code and the mobile phone number + the password, and the super password is removed.

Checking the parameter format

8) Type safety definition

The following steps are described: the number of the short message verification code is only 4 digits, and the probability of collision is high, so that any user can be directly logged in.

The solution measures are as follows: the short message code is set to 6 bits.

9) Content security definitions

The following steps are described: and (4) verifying the mobile, only comparing whether the number is 11 digits regularly, and not conforming to the correct format of the mobile phone number.

The solution measures are as follows: the mobile format to be verified is the domestic normal mobile phone number:

^((13[0-9])|(14[5|7])|(15([0-3]|[5-9]))|(18[0,5-9]))\\d{8}$。

sixth, attack prevention:

10) attack by hitting the garage

The following steps are described: the database collision attack can be carried out in batch by using a specific mobile phone number + MD5 (plain text password).

The solution measures are as follows: the number of password attempts of a specific terminal with different mobile phone numbers is limited.

And seventhly, business logic loopholes:

11) information enumeration and malicious locked account

The following steps are described: the mobile phone number registered in the system can be verified and taken out by using different mobile phone number inquiry; through the mobile phone number + wrong password, a login process is continuously initiated, all mobile phone numbers can be maliciously locked, and if a normal user quits in a locking period and logs in again, the service can be unavailable;

the solution measures are as follows: binding mobile phone numbers according to the device fingerprints, and limiting the number of the mobile phone numbers which can only try to log in every day to be 5; the difficulty of message simulation is increased by measures such as message encryption, signature and the like; and (4) counting the query times in unit time according to the two dimensions of the ip and the equipment fingerprint, exceeding a threshold value, and performing temporary interception control.

12) Short message bomb

The following steps are described: by changing the mobile phone number, 10 short messages can be sent to any mobile phone number in batch.

The solution measures are as follows: and the difficulty of batch sending is increased through a signature and channel encryption mechanism.

13) DOS service layer

The following steps are described: by sending short messages in batches, the number of short messages acceptable by normal mobile phone numbers every day is exhausted, so that normal users cannot log in the service by using the short messages.

14) Business specific logic vulnerabilities

The following steps are described: 1. the uuid is changed, so that the identifier of the switching equipment becomes true, and potential safety hazards are caused; 2. judging whether equipment is switched or not according to the changeDevice value in response only, and intercepting and responding to the deception client; 3. and the Toontype number is changed, so that short message messages of different platforms can be simulated.

The solution measures are as follows: 1. the device switching mark must participate in signing to prevent tampering; 2. the subsequent data flow verifies whether the uuid is changed again to judge whether the equipment is replaced; 3. signature and channel encryption mechanisms are added, and the counterfeiting difficulty is increased.

15) Business logic information leakage

The following steps are described: 1. by using different mobile phone numbers, whether the corresponding mobile phone number opens password login, whether the password problem is opened, whether equipment is switched, whether a safe mailbox is set, whether the password is set and the number of times of password errors can be inquired; 2. after login is successful by using the mobile phone number and the password, a plaintext mailbox, an md5 password, a plaintext birthday and an md5 safety question answer are returned from the response.

The solution measures are as follows: 1. when the login is unsuccessful, no effective information is returned; 2. and clearing the sensitive information in response after successful login.

And step 203, coding the data flow graph to obtain a final product.

In this embodiment, the server 105 encodes the dataflow graph into a product that the user desires.

As shown in fig. 3, the present embodiment provides a data flow graph drawing apparatus based on threat analysis, including: an obtaining module 301 configured to obtain a functional requirement of a user; a conversion reconstruction module 302 configured to convert the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis reconstruction; and a coding module 303 configured to code the dataflow graph to obtain a final product.

In some embodiments, the transformation reconstruction module 302 specifically includes the following components not shown in the figure: the first calling unit is used for configuring a service API used for the client to call the server; the checking unit is configured for checking the parameters by the service interface; the second calling unit is used for configuring a service interface calling authentication interface for the server; and the response unit is configured to return response information to the client according to the return interface of the authentication interface.

As shown in fig. 4, the computer system 400 includes a Central Processing Unit (CPU)401 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)402 or a program loaded from a storage section 408 into a Random Access Memory (RAM) 403. In the RAM 403, various programs and data necessary for the operation of the system 400 are also stored. The CPU 401, ROM 402, and RAM 403 are connected to each other via a bus 404. An input/output (I/O) interface 405 is also connected to bus 404.

The following components are connected to the I/O interface 405: an input section 406 including a keyboard, a mouse, and the like; an output section 407 including a display device such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 409 including a network interface card such as a LAN card, a modem, or the like. The communication section 409 performs communication processing via a network such as the internet. A driver 610 is also connected to the I/O interface 405 as needed. A removable medium 411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 410 as necessary, so that a computer program read out therefrom is mounted into the storage section 408 as necessary.

The preferred embodiments of the present invention have been described in detail with reference to the accompanying drawings, however, the present invention is not limited to the specific details of the above embodiments, and various simple modifications can be made to the technical solution of the present invention within the technical idea of the present invention, and these simple modifications are within the protective scope of the present invention.

It should be noted that the various features described in the foregoing embodiments may be combined in any suitable manner without contradiction, and various combinations are possible in order to avoid unnecessary repetition.

In addition, any combination of the various embodiments of the present invention is also possible, and the same should be considered as the disclosure of the present invention as long as it does not depart from the spirit of the present invention.

Claims

1. A software product design method based on data flow security threat analysis is characterized by comprising the following steps:

step (1), acquiring the functional requirements of a user;

step (2), converting the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis and reconstruction;

step (3), the dataflow graph is coded to obtain a final product;

the business process comprises the following steps:

step (2.1), the client calls a service API of the server;

step (2.2), the service interface checks the parameters;

step (2.3), the service interface of the server side calls an authentication interface;

step (2.4), according to the return interface of the authentication interface, returning response information and sending the response information to the client;

the business process at least comprises one data flow; the data stream includes: setting a data stream starting identifier, setting a data stream API identifier, setting a data stream request variable identifier, setting a data stream judgment variable identifier, setting a data stream intermediate variable identifier, setting a data stream response variable identifier and describing a data stream variable;

the service process specifically includes: wireless circulation can not occur, and each judgment can finally be carried out until the process is finished; the judgment logic has only one inlet, can only aim at the judgment variable, and has at most 2 different branches as a judgment result; the request and response must be only one for the same data stream; in a complete business process, the data flow should be controlled within 5; key variables cannot be present in the url; a plurality of judgment variables influence results which are completely consistent and need to be merged for representation;

the step (2) specifically comprises:

optimizing and analyzing, specifically comprising judging variable combination, service combination, response combination and abnormal variables;

and safety threat analysis, specifically comprising confidentiality, integrity, anti-replay, identity authentication and authorization, parameter format verification, attack protection and service logic loopholes.

2. A software product design apparatus based on data flow security threat analysis, comprising:

the acquisition module is configured to acquire the functional requirements of the user;

the conversion reconstruction module is configured to convert the functional requirements of the user into a data flow graph through a business process, wherein the data flow of the business process is subjected to optimization analysis and security threat analysis reconstruction;

the coding module is configured for coding the dataflow graph to obtain a final product;

the conversion reconstruction module specifically comprises:

the first calling unit is used for configuring a service API used for the client to call the server;

the checking unit is configured for checking the parameters by the service interface;

the second calling unit is used for configuring a service interface calling authentication interface for the server;

the response unit is configured to return response information to the client according to the return interface of the authentication interface;

the conversion reconstruction module specifically comprises: