Modeling and Analyzing Logic Vulnerabilities of E-Commerce Systems at the Design Phase

E-commerce systems have become tremendously popular and important for modern business processes in the world of the digital economy. E-commerce business processes rely on the distributed and concurrent interaction process among Web applications of participants, such as clients, merchants, third-party payment platforms (TPPs), and bank systems. Such complex business interactions bridge the gap of trustiness among participants and introduce new security challenges in the form of logical vulnerabilities, which are prevalent in the business process at the application level. The most pressing challenge is to guarantee security throughout the checkout process at the conceptual design phase such that the logic errors can be detected before the actual implementation. Maintenance and repair of implemented e-commerce systems can be extremely costly. To this end, this article proposes a novel modeling and analyzing methodology for multiparticipants and multisessions e-commerce interaction processes based on colored Petri nets (CPNs). First, we define a novel model that can efficiently depict the key properties of e-commerce business interaction processes. Second, several modeling principles are formulated based on the design specification of e-commerce systems. Finally, the concept of Transaction-Logical Consistency is defined to analyze and verify the logical vulnerabilities of e-commerce systems. Through a discussed case study, we demonstrate the feasibility and applicability of the proposed methodology and its efficiency in detecting problems those can potentially lead to logical vulnerabilities.

Modeling and Analyzing Logic Vulnerabilities of E-Commerce Systems at the Design Phase I. INTRODUCTION E -COMMERCE with multiparticipants has rapidly evolved worldwide and becomes increasingly popular in the global economy.The prevalence of online network and smart mobile devices contribute significantly to the rise of e-commerce [1], [2].E-commerce systems characterize extreme design complexities, such that the dynamism of business interactions among heterogeneous participants imposes an increased level of practical challenges in implementing a perfectly secure checkout process.Many Web stores today often utilize Web application programming interfaces (APIs) of third-party payment platforms (TPPs), such as Google Checkout, AliPay, and PayPal for enabling their cashier services.As a result, today's e-commerce businesses have become increasingly hybrid, with their program logic being distributed across multiparticipants, including the servers and their clients, along with various third-party API service providers [2], [3].
Despite the third-party service providers bridging the gap of trustiness between merchants and users, their involvement complicates the logic flow in the checkout process.Even a minor logic vulnerability can lead to serious impacts in mission critical financial applications, thus logic vulnerabilities pose serious threats to the security of e-commerce applications [1], [4], [5].In such a hybrid system, coordinating the involved participants in a secure fashion is highly challenging, logic flaws are pervasive in modern e-commerce systems [3], [6], [7], [8], [9], [10].Application and business logic refers to application-specific functionality and behaviors in concurrent business interactions.A logic vulnerability typically exists when a user abuses legitimate application-specific functionality against developers' intentions [11].Developers are usually unaware of the need to implement sufficient server-side authorization checks to the received request parameters.As a result, vulnerable servers are exposed to malicious users who can potentially alternate the control and data flows through concurrent interactions.The success of such attacks mainly relies on logical errors or lack of server-side validations [12].Integrity and logic validation mechanism errors are usually the keys for a successful attack.Logic vulnerabilities of e-commerce systems allow malicious users to purchase products using fabricated payments [1].
Such issue cannot be solved by solely relying on existing techniques like protocol verifications, because different integrators usually follow different ways of incorporating and 2168-2216 c 2023 IEEE.Personal use is permitted, but republication/redistribution requires IEEE permission.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
using API services.Furthermore, misunderstandings among the involved participants often arise logic vulnerabilities in the business processes [3], [6].Logic vulnerabilities are prevalent in real-world services that adopt mainstream protocols.Suppressing the need for integrating security protocols in the online payment systems allows malicious users to successfully get through the purchase process without properly paying for the services [7], [13].A number of methodologies to test the classes of vulnerabilities of the Web applications have been proposed in the past [13], [14], [15].Balzarotti et al. [16] developed a vulnerability analysis approach that characterizes both the extended state and the intended workflow of a Web application.A static detection method of logic vulnerabilities in e-commerce Web applications was proposed in [1].Chen et al. [9] introduced an approach of building provably secure multiparty online services, which is called the certified symbolic transaction (CST).A system that offers security protection to vulnerable Web application integrations was presented in [3].In the work of [17], a scanning method was proposed to resolve the issue of parameter tampering vulnerabilities.However, existing approaches focus mostly on the testing or detection of implementation systems at the code level.In fact, design-level vulnerabilities are indeed a major source of security issues in Web applications.For example, in Microsoft's "security push," about 50% of the security issues has been identified due to design-level flaws [18].System development engineering is a comprehensive discipline that involves many activities, such as requirements engineering, design and specification, implementation, testing, and deployment.The activity of constructing a model is typically done in the design phases of system development.This may in turn significantly shorten the implementation and testing phases and further decrease the number of flaws in the final system.Different from nonformal models in software engineering, this work focuses on the formal modeling of online shopping systems.In most cases, formal models are more accurate and complete than traditional design documents.This makes that the exploration and construction of the formal model can generate a more solid foundation for the implementation phase [19].
Formal methods are mathematical techniques for specifying and verifying the correctness and trustworthiness of software systems.The U.S. Department of Defense Trusted Computer System Evaluation requires that the highest level of security classification (the A-class) use formal specification and verification techniques [20].Petri net-based approaches have been presented to model and verify the correctness and soundness of workflow and concurrent systems [21], [22], [23], [24], [25].Significant progress has been done on cooperative systems and composition of Web services based on Petri nets [26], [27], [28].However, most of the existing works focus on the correctness and soundness of workflow, cooperative systems, and composition of Web services, but fail to concern about the financial security issues.Logic vulnerabilities can be linked directly to the financial losses of legitimate users, and the impact is often severe.
E-commerce business interaction is a typical distributed and concurrent system in the open Internet, the recent developments of which have opened a range of security challenges.A major reason is that the typical online distributed system handles process concurrency in a number of fashions and ways.It is very easy for a designer to neglect significant security interactions and validations during this process concurrency, which might lead to logical vulnerabilities in the system design.To cope with this issue, it is crucial to provide a methodology which enables the detection of logical vulnerabilities of system designs, prior to the actual implementation and deployment.Logic errors in the implementation system might cause irreparable damage, compensation for such defects and modifying the program can be extremely costly.
Furthermore, performing an efficient systematic security analysis of the design specification is still an open issue.Logic vulnerabilities still lack a formal definition, but, in general, they are often the consequence of an insufficient validation of the business process of Web applications [13].Thus, modeling and verifying the e-commerce business interaction processes at the design phase is an important requirement in the current digital economy.With this in mind, this work focuses on the business interaction process at the design phase and proposes a novel formal methodology for modeling and analyzing logical vulnerabilities of multiparticipants and multisessions ecommerce systems.Important contributions of this article are as follows.
1) This article proposes a novel formal model, called interactive business process fusion (IBPF) net, to depict distributed, multiparticipants, and multisessions e-commerce business interaction processes based on colored Petri net (CPN).The business flow, logical structures, data definitions, interaction behaviors, and key properties can be depicted easily using IBPF.2) This article introduces a novel modeling scheme for IBPF according to the design specification, including control structures, data structures, and modeling procedure.With this scheme, the business interaction process can be established based on IBPF.3) This article presents the analyzing principles for logical vulnerabilities, with formal definitions.Transactionlogical consistency is defined as the basic property of e-commerce business interaction processes.Then, a state analyzing method is proposed for discovering logical vulnerabilities.The remainder of this article is organized as follows.Section II discusses a case study.Section III presents the modeling scheme.Section IV proposes the analyzing methods and Section V concludes this article.

II. CASE STUDY
E-commerce systems are facing a wide range of logic vulnerability cases in the recent past, such as the ones in the integration of Interspire and PayPal Express [6], [7], [9], Mongolia [29], osCommerce 2.3.1 with PayPal Payments Standard [13].After reviewing various logic vulnerability cases, this article presents an e-commerce business interaction process derived from real scenarios.For illustrating our method clearly, it is abridged, and we only concern about the Merchant systems can incorporate various payment methods of TPP, and Fig. 1 shows an integration case.The dotted rectangles represent the pseudocode of ValidatePara, FinishOrder, and UpdateStatus.During the checkout process, the merchant makes two calls to the TPP.The first one notifies the TPP with an upcoming payment (step 2) with authentication data (identity).Then, the TPP sends a message attached with a payment token for identifying the payment transaction, which the merchant passes to the shopper with transaction gross (step 4).The shopper then presents the token and gross to the TPP.The TPP sets and confirms certain information about the payment (step 5).After that, TPP redirects the shopper's browser to merchant API FinishOrder with payerID, gross, and token as arguments (step 6).The merchant directly contacts the TPP to check and complete the payment.The function ValidatePara is used to validate the integrity of the transaction gross, and the payment is completed by steps 8 and 9, where the TPP is contacted to complete the fund transfer.If the identity and other payment information is valid, TPP records the payment and returns result = true.This result is saved in the session variable SESSION["result"].By this time, the payment is completed, and the merchant updates the status of the order.Since the browser needs to be in synchronization with merchant state, the merchant cannot directly call the merchant-side API, thus needs to redirect the shopper's browser to call merchant API UpdateStatus, by passing orderID as an argument, which updates the status of the order (step 11).Then, the merchant retrieves the order using orderID, to set the order status as "PAID" if the session variable is true (SESSION["result"] = true).
For security, sometimes, digital sign and encryption are used in data transmission.However, for enhancing the efficiency and usability of the distributed business interaction process, some messages are not signed in the checkout process, which cannot be regarded as a security weakness, as the merchant directly verifies the data integrity with the TPP.This interactive mechanism guarantees the security in many real cases [1], [2], [6], [7], [13].In the above-discussed scenario, the two calls sent to TPP ensure the data consistency among the merchant and TPP.Supplemented by the key validating function APIs, such as ValidatePara, FinishOrder, and UpdateStatus, this complex interactive mechanism of the business process assures security, as illustrated in Fig. 1.
However, the aforementioned business interaction process is still characterized logic vulnerabilities.As long as a valid orderID assumes a session in the success state, updateStatus marks the corresponding order as PAID, no matter whether the payment is successful or not.When the shopper obtains a valid orderID for an unpaid expensive order, the orderID can be replaced in step 11, so that he/she can use the current session state in order to change the order status as PAID.This enables the shopper to get through the checkout process by paying relatively low price for an expensive item [7], [13].Except this logical vulnerability, the case may have other ones.For a design specification, although it appears to be secure, it is impossible to judge whether it is secure or not, and it is impossible to know in advance where and what the vulnerabilities are.This article uses this case to illustrate our proposed methodology.

III. MODELING SCHEME
In this section, we propose the modeling rules and formal definitions, including data definitions for real e-commence systems, naming scheme, and the structures used in constructing e-commerce business interaction processes.

A. Data Definitions and Naming Rules
CPN is a graphical language used to construct the models of concurrent systems and analyze their properties.CPN ML embeds the standard ML language and extends it with constructs for defining color sets and declaring variables [19].The color sets can be defined as the data types corresponding to the real e-commerce systems, and the variables or constants in the modeling process.According to the specification of the case discussed in Section II, based on the CPN ML language, we define the data elements used for modeling as follows.The colsets User, Merch, and Tpp are used to represent the participants, such as the user (shopper), merchant, and TPP.UserMerPara, UserPara, MerPara, and TPPara are the types that depict the trading parameters used in the trading process which are passed and exchanged among different participants.Such trading parameters are constructed using union and product types of CPN.TP, User, and Mer are the prefixes of the data produced by the TPP, user (shopper), and merchant, respectively.UserMer represents the prefix of the data type closely associated with the user (shopper) and merchant.
The e-commerce systems with logic flaws are vulnerable to Web Parameter Tampering, depending on the operation of parameters exchanged between the clients and servers in order to modify the application data, such as user credentials and permissions, quantity of products and price, etc. Especially, any HTML form controls can be tampered with, and the form submissions can be intercepted.Thus, one can bypass the client-side validations [17], [30].A malicious user however can interact with a vulnerable Web application using a browser of which he has full control to manipulate any client-side code as well as HTTP request parameters [17].For example, an attacker can tamper with URL parameters directly.Thus, in this article, we adopt the following underlying assumptions [1].
1) Requests from shoppers are untrusted.
2) Unsigned cashier requests that are sent via insecure channels are untrusted.3) Cashier responses that are transmitted by shoppers to merchants via HTTP redirection are untrusted.Therefore, order total, order ID, currency, and merchant ID can be tainted during the trading process.Then, we use BOOL type to depict this scene, and a BOOL value is assigned to every trading parameter.The expression "parameter name" + "BOOL" is used to name them, e.g., orderID and orderIDBOOL.

B. Formal Definitions
A CPN is a nine-tuple CPN = (P, T, A, , V, C, G, E, I) whose basic definition and more related concepts, such as multiset, color set, and inscription, can be found in [19].The CPN modeling language is a general-purpose one, i.e., it is not aimed at modeling a specific class of systems [19].The formal representation of CPN forms the foundation for defining various behavioral properties and their analysis methods.According to the characteristics of e-commerce business interaction processes, we impose some restrictions on the structures and data types of CPN for accurately depicting the business logic of multiparticipants e-commerce systems.Thus, we propose the following definitions.
Definition 1: A logic business process (LBP) is a CPN LBP = (P, T, A, , V, C, G, E, I), where: 1) LBP has three special places α, β and γ , where α ∈ P is the initial place, β ∈ P is the terminal place, γ ∈ P is the memory place, and in which E : {(τ, α), (β, τ ), (γ , τ )} → EXPR V , and a∈A→E (a) = E(a); t∈T→G (t) = G(t), and τ has no guard.Then, LBP E is strongly connected.An LBP is a special CPN and corresponds to the internal business process of a participant in the entire e-commerce interaction process.Fig. 2 shows the LBPs with initial markings of the shopper, merchant, and TPP as of the case discussed in Section II.An LBP starts from an initial place α and ends at terminal place β and memory place γ , where α depicts the beginning state of a participant, β represents the end of an executing process, and γ is used to store the internal data after the transaction.For example, in Fig. 2, the place Merch is the initial place of the merchant.MEnd and MStore are the terminal place and memory place, respectively.If we connect Merch with MEnd and MStore using a transition and three arcs among them, the LBP of the merchant would be strongly connected, and it is used to guarantee the intercommunication feature of LBP.
1) P IN is a set of input channel places, P O is a set of output channel places, An LBPC is an extension of LBP integrated with some interaction places (channels) which are used to depict the communication channels of trading parameters among different participants.For the channel places, we use the convention "prefix" + "Chank" for naming, k ∈ N+.For example, Fig. 3 is the LBPC of the merchant, which is extended from the LBP shown in Fig. 2 by using five input channel places, UChan1, TppChan1, UChan3, TppChan3, and UChan4; and five output channel places, MerChan1, MerChan2, MerChan3, MerChan4, and MerChan5.UChan1 represents a channel place launched from the user; MerChan2 represents a channel place launched from the merchant; and TppChan3 represents a channel place launched from TPP.
Definition 3: be two LBPCs which are disjoint, and have common places, such that T, A, , V, C, G, E, I), where Definition 3 is a rigor formal definition of fusion operation of two LBPCs.It is just like the synchronous synthesis method in the original Petri net.It specifies a synthesis method based on places of CPN, by which an integrated e-commerce business process can be built in a step-by-step manner.The benefit is to help designers understand and analyze a business process with different views by composite operations.Note that, for two LBPCs, only their input and output channel places with the arc inscriptions have intersection and their corresponding LBPs have no intersection.
Definition 4:  6, a complete business interaction process-IBPF is constructed by composing the LBPCs presented in Figs.3-5, in accordance with the shopper, merchant, and TPP, respectively.The three LBPCs synthesized by 12 channel places, such as UChan1, MerChan2, TppChan1, and TppChan1.Then, the properties of IBPFs are described as follows.
Let IBP i and IBP j are any two LBPs of IBPC i and IBPC j , respectively, in an IBPF, ε i1 , ε i2 ∈ (T i ∪ P i ).According to Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Then, there is a directed path from ε i1 to ε i2 , and vice versa.Likewise, LBP jE is strongly connected.From any ε i ∈ (T i ∪ P i ), there is a directed path to τ .As (τ, α j ) a directed arc in IBPF E , there is a directed path from ε i to any ε ∈ (T j ∪ P j ).For any p ∈ ( m n=1 P INn ∪ m n=1 P On ), ∃t k ∈ T k and ∃t l ∈ T l , k, l∈N+, k, l≤m, making that (t k , p), (p, t l ) ∈ A. Then, there is a directed path from p to any ε ∈ (P ∪ T ∪ {τ }) in IBPF E .Thus, IBPF E is strongly connected.
Condition 1 represents that an IBPF has an initial place set, a terminal place set, and a memory place set; condition 2 means that every input or output channel place would be a message interaction bridge between two IBPs, and had predecessor and successor nodes; and condition 3 guarantees the connectivity of IBPF.Definitions 1-4 and Property 1 construct a complete formal specification based on CPN.These definitions are related and progressive.

C. Basic Structures
Here, we illustrate the basic structures used for modeling including routing, control, and data Basic routing structures are used for the control and data ones in internal processes of participants, and business interaction processes among participants.1) Routing Structures: Petri nets are suitable to describe distributed and concurrent properties.True concurrency is allowed instead of the interleaving-based semantics based on some special structures.In this article, we define several basic structures for constructing an IBPF according to WFMC [31].As shown in Fig. 7, sequential structure depicts the scene where several events or APIs fire one after another.The concurrent structure illustrates the way of constructing the concurrent scene.When there exists selective routing in a business process, it would be depicted by the conditional selection structure.
2) Control Structures: In this work, control structures mean the places and transitions that are used to coordinate the activities among the participants.In this work, we present three kinds of control structures.
a) Internal control structures: Internal control structures are used to construct the internal business process of a participant based on routing structures.The flowing tokens in the control structures belong to the colsets that represent the participants, and the vars belong to these colsets, we can call them participant vars.For the LBP of TPP shown in Fig. 7, the participant vars t and t1 belong to the colset Tpp which represent the TPP.The arcs which have participant vars, together with their associated places and transitions belong to the internal control structures, e.g., the path from Tpp to TpEnd, and SetInfo to PayDone.This means that the internal business process, which is composed of APIs, functions, and operation events, is controlled and conducted by a participant.
b) Multisession and multiparticipants: As we know, although Petri nets are good at constructing models of concurrent systems and analyzing their properties, their structures are relatively fixed.Petri nets are effective in modeling and analyzing flexible manufacturing systems [32], [33].However, e-commerce systems based on the Internet are often open and dynamic, characterizing multisessions, multiparticipants, and multitasks.A user can open many Internet browsers and sessions, and simultaneously place different orders during the same business process.Then, this scenario can invite security attacks [15].
CPN has the concepts of colsets and colors.Thus, in the modeling scheme, we can make the business structure of IBPF as the relatively fixed business process of the e-commerce system, and use different colsets to express multiparticipants, and different colors to depict multisession.In Fig. 2, colsets User, Merch, and Tpp represent the user (shopper), merchant, and TPP, respectively.The colors a1 and a2 depict two users, and they can start two sessions according to the same business process.b1 and b2 depict two merchant sessions that are ready to be started.In the business process, the flowing tokens express the trading parameters of some session.The complex color types can also help constructing the parameters, e.g., product and union types.For example, in Fig. 2, gross((u, m, grossBOOL)) represents that the trading parameter gross belongs to a session started by u and m.Therefore, these design rules can control and implement multisessions and multiparticipants in the e-commerce business processes.

c) Validation functions:
In distributed e-commence systems, the designed interaction mechanism is used to guarantee the funds security [6], [7], [12], [34], in which validation functions play important roles.The trading parameters flowing among the distributed participants are checked by the Validation functions in order to guarantee the legality.In LBPF, we use guards [19] to depict these validation functions.For instance, as in the case discussed in Section II, there are some validation functions, such as ValidatePara, FinishOrder, and UpdateStatus.Such functions are depicted by the guards of some key transitions, e.g., SdGross, FinishOrd, and MUpdate in Fig. 6.
3) Data Structures: Data structures depict the data flow (trading parameters flow) in the business processes, including channels of Definition 2, memory places of Definition 1, and internal flowing paths of data.Channels depict the transmission paths of the trading parameters among different participants.Memory places are used to store the internal data after the transaction process, and the data can reflect the trading result of a participant.Internal flowing paths represent the data flow inside the business process of a participant.For example, the flowing path of parameter orderID in the LBP of the merchant in Fig. 2. According to the case in Section II, orderID is a trading parameter produced after the merchant accepted the order from the shopper, and this event is represented by the transition RecOrder.This corresponds to the event of Receive and send token in the case of Fig. 1.Then, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.the parameter flows through other events and forms a data flow path until it is transmitted to the memory place MStore.So as other parameters.
In CPNtools, for easy modeling, avoiding the two complex parameters holding the same variable is a basic rule.For example, Fig. 8(a) presents a data structure, including two parameters va1((u, va1BOOL)) and va2((u, va2BOOL)) belonging to the union type of Parameter, in which var u:User, var va1BOOL, va2BOOL:BOOL, and every parameter includes three elements: one constructor, and two variables belonging to the basic types [19].Although this looks correct, there would be a binding error at t2.As for the input of t2, there are two parameters belonging to complex data types holding the same variable u.Through our experiments, we found that splitting can effectively avoid this binding error, which ensures that complex parameters have distinct values.For example, Fig. 8(b) represents an improved data structure.As for every transition, there is just one complex parameter.

D. Modeling Procedure
To construct an LBPF, we elicit the intended functions in terms of the design specifications derived from the requirement analysis during the system design phase and construct the model based on the following steps.
1) Data Definitions of LBPF: Acquire the trading parameter set from the design specifications, and declare and V. 2) Construct LBPs of Participants: Identify the order of operation events and APIs in business interaction processes of participants in accordance with the key functionalities and design specifications.Then, construct the control and data structures to depict the internal business functionalities of different participants aided by Definition 1.
3) Construct LBPCs of Participants: Confirm the message delivering mechanism, and identify the input and output channel places according to Definition 2.Then, connect them to their corresponding LBPs using arcs with E.
4) Fusion Operation of LBPCs: According to Definitions 3 and 4, synthesize the obtained LBPCs and get an IBPF.It is worthy of note that an initial marking should be added at last.

IV. ANALYZING LOGIC VULNERABILITY
In this section, based on LBPF, we present the methods of analyzing the logic vulnerabilities.First, we define the transaction-logical consistency as the basic property of trustworthy e-commerce business systems.Then, we illustrate the verification procedure.

A. Transaction-Logical Consistency
In e-commerce protocols, atomicity is the basic property [35], which usually applies to the network level, but not to the application level.The validations of protocols in the network level cannot reveal such logic errors and defects in business processes as lack of calibration and inconsistency among data [28].Therefore, based on the existing properties, we propose the following transaction conditions to guarantee the security goal of an e-commerce business interaction process.

Transaction-Finished State depicts a completed state of a
Condition 1 illustrates that a participant had finished a transaction.If a shopper has paid and TPP is at the paid state, then merchant has to reach the state of a finished transaction.On the other hand, if a shopper has not paid and TPP is not at the paid state, then the merchant cannot be at the shipping state of a to-be-finished transaction.For any terminal place β m , its token number is equal to that of input variables on the input arcs.This ensures the completion of a single transaction.Condition 2 represents that any memory place γ m should have obtained the necessary trading parameters.Likewise, the token number in γ m is equal to that of the input variables on the input arcs.
Here, The notation means the union operation.However, in CPN, the set is based on Multisets [19].The symbol ++ is the operator used to construct a multiset consisting of the tokens, for example, in Fig. 6, the expression 1'b1++1'b2 represents that there are two tokens which are b1 and b2, respectively."||" depicts that the token values binding with the arc inscriptions.As E is the set of arc expressions, we see the expressions as the multiset of tokens that are transmitted to the next transition.For example, in M represents that a transaction is completed, however, it does not satisfy Transaction-Logical Consistency.Although all BOOL variables are true, there are two values for the shopper and merchant variables u and m, i.e., a1, b1, a2, b2.This state illustrates that the shopper has paid for orderID((a1, b1, true)), and received the goods of orderID((a2, b2, true)).It damages the interest of the merchant and does not meet the Transaction-Logical Consistency, which is caused by the interaction process that leads to states inconsistency among distributed participants.

B. Analyzing Procedure
A logic vulnerability in a distributed e-commerce business interaction process exists when the merchant or TPP cannot validate whether a given shopper has paid for the correct order total with the expected gross or not.Based on logic vulnerabilities, it is easy to launch attacks in the trading browser extensions simply, attackers can withhold requests, modify or forge requests.addition, attackers can exploit a signed token to mimic as a cashier, reuse payment information from previous orders or even change the URLs in HTTP forms to intercept cashiers' responses.To sum up, logic vulnerabilities are caused by the tainted trading parameters as shown in Table I [1].
For depicting these malicious behaviors, in Section III, we know that multisession or multiuser can be depicted by IBPF conveniently.Then, tampered parameters can be depicted by changing the BOOL values corresponding to the parameters.Adhering to the principles of the modeling process in Section III, together with specific initial marking, we can build a specific application behavior scene and then verify the business process.We present our analyzing procedure with related definitions as follows.
Definition 7: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.V, C, G, E, I) is rational under an initial marking M 0 if: 1) IBPF is bounded [19]; 2) IBPF is terminable.Definitions 7 and 8 are used to ensure that an IBPF would not run indefinitely.Instead, it must reach some ended states to represent that a transaction process has either been successfully completed or terminated for some reason.Then, the state space is limited.These properties can be validated by CPNtools.If an IBPF is rational, we can search the state space and verify the Transaction-Logical Consistency.T, A, , V, C, G, E , I).
The construction of Initial Configuration is based on the logical vulnerability which is to be verified.It can be seen as an initial state of an IBPF, which represents the behavior conditions before an online transaction begins.E either shows some variations from E such that changes will be noted on some BOOL values on the corresponding arcs, or E = E.For example, we can make the IBPF and the initial marking of Fig. 6 as an Initial Configuration, which is used to verify the vulnerability of "a user can pay for a cheap order but check out an expensive one," "a user pay for another user's order," and "a user can pay himself/herself for an item he/she buys in an online shop" [7], [13].In this case, E of the Initial Configuration is the same as E, and of course, IBPF' is the same as IBPF.If we want to verify the vulnerability of "a user can pay less" [7], [13], which is also listed as "Tainted gross" in Table I, we can make a new Initial Configuration and change the IBPF presented in Fig. 6, with the following changes M 0 (Tpp) = 1 c1, M 0 (Merch) = 1 b1, M 0 (Shopper) = 1 a1, and E (SendPay, UChan2) = 1 token((t, tokenBOOL)) + +1 gross((u, m, false)) where E(SendPay, UChan2) = 1 token((t, tokenBOOL)) + +1 gross((u, m, grossBOOL)).A payment is assumed secure when both the authenticity and integrity of the payment status are verified, and this is guaranteed by the Transaction-Logical Consistency in this work.Algorithm 1 is the process of searching the state space and verifying the Transaction-Logical Consistency under an Initial Configuration.The marking set that does not satisfy Transaction-Logical Consistency is the output of Algorithm 1.For example, Fig. 9 is a marking belonging to which is found under the initial configuration of Fig. 6.
Theorem 1: Algorithm 1 can be terminated.Proof: According to Definitions 7 and 8, the input IBPF' of Algorithm 1 has a finite state space under an initial marking M 0 .Algorithm 1 searches the markings from M 0 and adds the markings those not satisfying Transaction-Logical Consistency to in step 3.1.Other constructed markings are added to in steps 3.2 and 3.3.In step 3.3, new produced marking those do not belong to is marked as "Intermediate," and the notation "Intermediate" of current marking is removed in step 3.4.This represents that the marking set of "Intermediate" is continuously updated until it becomes empty, so it is limited.The above descriptions illustrate that Algorithm 1 can be terminated.Algorithm 1 is a breadth-first traversal method.It only searches a part of the state space.
We summarize the verification procedure based on the above methods as below.
1) Establish the IBPF according to the design specification.
2) Construct the Initial Configuration according to some logic vulnerability.3) Use Algorithm 1 to obtain and to analyze the corresponding logic vulnerability.4) Goto step 2 to verify another logic vulnerability.Algorithm 1 is a part of the verification process, and the summarized verification procedure is the sketch of the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

TABLE II
VERIFICATION RESULT OF THE CASE whole verification procedure.Thus, notable logic vulnerabilities of the case discussed in Section II can be identified using our proposed methodology.Table II illustrates the Initial Configurations and their corresponding vulnerabilities, where the third column represents whether the vulnerabilities exist in the e-commerce business interaction process.
Our methods can be potentially implemented to detect various kinds of logic vulnerabilities of various real cases, with suitable modifications to the Initial Configurations and arc expressions.If the system development process is strictly consistent with the proposed methods and the obtained system design, the implementation system is accordant with the model, and ultimately more secure than the system without our modeling and analyzing process.Under the Initial Configurations, using the proposed modeling and analyzing methods, the known or unknown vulnerabilities can be discovered.Existing related works introduced in Section I focus mostly on the testing or detection of implementation systems at the code level, where our approach is at the design level and application level.Our approach is a formal methodology that is generic for the relevant types of logic vulnerabilities.The proposed methods can be applied to other design specifications of e-commerce business processes as well.Compared with previous related works, this article has different research objectives and emphases.The proposed methodology can complement the traditional methods.However, the proposed work in this article cannot deal with the vulnerabilities of the network level, the ones caused by hardware accidents, and the nonlogical flaw issues like the account leaking and decryption.

V. CONCLUSION
This article proposed a novel methodology to detect the rising logic vulnerabilities in the distributed business interaction processes of e-commerce systems during the design phase.A systematic approach is presented in this work, including formal definitions, modeling scheme, and analyzing procedure.The efficiencies of our proposed approach in detecting logic vulnerabilities have been discussed and demonstrated through a case study.The proposed methodology can also be potentially applied to other similar e-commerce business interaction processes by suitably defining the business processes and datasets.This methodology can determine whether a system design is immune to logic vulnerabilities.Then, it can help modify the incorrect design, and eventually guarantee the security of system design against logic vulnerabilities.Despite the effectiveness of our proposed approach, there is scope for further developing the related tools or functions for supporting the full automation of the proposed methodology, or combining third-party components with CPNtools.

Fig. 1 .
Fig. 1.Case of an e-commerce business process.
m≥2, be m LBPCs satisfying Definition 2, and m n=1 P INn = m n=1 P On .Then, IBPF = (P ∪ P IN ∪ P O , T, A, , V, C, G, E, I) = LBPC 1 LBPC 2 • • • LBPC m is called a IBPF net.Definition 4 is based on Definition 3. A set of LBPCs can construct an IBPF.Definition 4 defines the Fusion Operation between two LBPCs, and an IBPF is the union of m LBPCs LBPC 1 − LBPC m based on the Fusion Operation, via a set of common places, i.e., m n=1 P INn and m n=1 P On .Not that input channel places can only be combined with output ones.Based on Definitions 1-3 and the examples in Figs.3-5, as shown in Fig.

Fig. 5 .
Fig. 5. LBPC of TPP.Definition 1, the subgraph of IBPF E LBP iE = (P i , T i ∪ {τ },A i ∪ {(τ, α i ), (β i , τ ), (γ i , τ )}, i , V i , C i , G i , E i , I i ) is strongly connected.Then, there is a directed path from ε i1 to ε i2 , and vice versa.Likewise, LBP jE is strongly connected.From any ε i ∈ (T i ∪ P i ), there is a directed path to τ .As (τ, α j ) a directed arc in IBPF E , there is a directed path from ε i to any ε ∈ (T j ∪ P j ).For any p ∈ ( m n=1 P INn ∪ m n=1 P On ), ∃t k ∈ T k and ∃t l ∈ T l , k, l∈N+, k, l≤m, making that (t k , p), (p, t l ) ∈ A. Then, there is a directed path from p to any ε ∈ (P ∪ T ∪ {τ }) in IBPF E .Thus, IBPF E is strongly connected.Condition 1 represents that an IBPF has an initial place set, a terminal place set, and a memory place set; condition 2 means that every input or output channel place would be a message interaction bridge between two IBPs, and had predecessor and successor nodes; and condition 3 guarantees the connectivity of IBPF.Definitions 1-4 and Property 1 construct a complete formal specification based on CPN.These definitions are related and progressive.

Definition 9 :
Let IBPF = (P ∪ P IN ∪ P O , T,A, , V, C, G, E, I).Then, a 2-tuple (IBPF , M 0 ) is called an Initial Configuration that is rational, in which M 0 is an initial marking of IBPF, IBPF = (P ∪ P IN ∪ P O , 2 Definition 7guarantees that an IBPF can terminate after the running process.Condition 1 means an IBPF has a terminated state set, in which the terminated state cannot fire anymore.Condition 2 depicts that ∀M ∈ R(M 0 ) can reach a terminated state by firing a transition sequence.