Process of Security Assurance Technique for Application Functional Logic in E-Commerce Systems

Security practices such as Audits that often focus on penetration testing are performed to find flaws in some types of vulnerability & use tools, which have been tailored to resolve certain risks based on code errors, code conceptual assumptions bugs, etc. Most existing security practices in e-Commerce are dealt with as an auditing activity. They may have policies of security, which are enforced by auditors who enable a particular set of items to be reviewed, but also fail to find vulnerabilities, which have been established in compliance with application logic. In this paper, we will investigate the problem of business logic vulnerability in the component-based rapid development of e-commerce applications while reusing design specification of component. We propose secure application functional processing Logic Security technique for component-based e-commerce application, based on security requirement of e-business process and security assurance logical component behaviour specification approach to formulize and design a solution for business logic vulnerability phenomena.

sub-component or sub-system or system, both of which represent components in their own right) the steps required to complete or perform a particular action as defined by the business component-based application to automate business process; it uses logical component-ware and each component business logic makes a set of functionality by integrating these components business processing logic to make logical component-ware, which then makes overall application's business logic in the e-commerce system at middle tier [1].
Business logic layer within the application is developed with two kinds of components, Business Processing components and Business Entity Components.
The "Business Process Components" handle the services or transactions that are requested by users through the user interface. They determine the operations of the business entity components that must be invoked and the order in which they must be executed. The "Business Entity Components" are persistent. They represent the business entity types of the application domain whose state must be stored by the application [2].
The middle tier contains wide range of components from different layers such as web components managed by web servers and business object components managed by application servers. The web component dynamically process user requests and constructs response to client application. The business object components implement business logic of a business domain. Both components are managed by an infrastructure environment such as J2EE or CORBA platform servers that provides important system infrastructure services for these compo-  The middle tier of e-commerce servers implements the business application logic. The business application logic represents the functions or services that a particular e-commerce site provides. As a result, a given site may often employ custom-developed logic. As the demand for e-commerce services grows, the sophistication of the business application logic grows accordingly [1] [3]. Traditionally, e-commerce sites implement the middle tier of software on web servers using the common gateway interface (CGI). CGI scripts are programs that run on the web server machine as separate processes from the web server software.
The web server invokes these general-purpose programs in response to user requests. The CGI scripts' main function is to process user input and performs some services (such as retrieving data from a database, or dynamically creating a web page) for the user because CGI scripts process untrusted user input, the security risks associated with the CGI (and other forms of middle tier software) are extremely high. Many attacks against web-based systems exploit CGI scripts [1] [4]. A very simple example of business application logic would be a customer adding an item to an online shopping basket & then being required to provide a name, address & payment details before being able to complete the purchase. application logic (also called business logic because it perform action as per defined business process which integrated through CBS application by developer, so it's called business logic, it's also noted that it does not refer to the general functionality of a web server, but to the specific operations of the application's function, such as product discounts, postage pricing rules, etc. Cyber-attacks are the core of any security assessment of Web based e-Commerce systems [1]. One of the more promising research fields in this context is related to the representation of the Vulnerabilities, Attack patterns Classification. Several models are proposed to represent these; these models usually provide a generic representation of attacks. According to the Purdue University Researchers, Conversely, the experience shows that attack profiles are strongly dependent upon several boundary conditions these conditions could be based on three well defined Areas: 1) Environmental (faults discovered by I. Krsul, 1998); 2) Coding (fault); 3) Configuration errors [5] [6]). Whereas in 2004 University of Luton researcher Faisal Nabi first time identified that design flaw could also be a cause of attack profile boundary condition of design specification in e-commerce systems (Faisal Nabi, 2004). In this paper, we will investigate design flaw attack profile boundary condition (that caused business logic attack) interms of reuse design specification in the CBS e-commerce systems. ways (diverse communication) [8]. Web-based software systems are created by combining a variety of components from various sources, such as custom-built special-purpose applications, customised commercial-off-the-shelf software components, and third-party software [7]. Much of the new complexity found with web-based applications also results from how the different Software components are integrated. Not only is the source unavailable might be hosted on computers at remote, even competing organization. To ensure high quality for the web systems composed of very loosely coupled components, which seriously required evaluate these Components connections [9].

Web Software Application Complexity & Component-Based-Development Risks
Web software components are coupling more loosely than any previous software application [7]. AS it is stated above that e-commerce sites offer more than This meant that an anonymous user with trail account could see the logic behind the administrator-level service call. The locations of all administrator service script were disclosed, providing invitation a definitive map of application to a potential attacker to attack business logic in the middle tier. Therefore, in this scenario EASI framework also get failed to protect the system integrity & security. Another example, developing a simple script that allows one to use thousands of e-coupons or using a similar script to open thousands of brokerage accounts that can each receive small deposits from a bank-usually around five cents-to verify transactions. In the end, one could end up making tens of thousands as shown in Figure 2.
Web sites are now fully functional software systems that provide businessto-customer e-commerce, business-to-business ecommerce & many services to many users. The growing use of third-party software components & middleware represents one of the biggest changes in the e-commerce web software-Application systems so as security; integrity has threaten because of the flaws in the design, up to 50% of software defects leading to security problems are software architecture & design flaws [11]. In other words during the high-level-design stage of software architecture design & technology architecture design decisions correspondence of web software structure that how various components will be integrated & interact, and which technologies will requirement define software function interpreted, failure in this cause 50% of software defects which then leading to security problem & threaten the internal software application integrity itself compromise because of software architecture & design flaws at the high-leveldesign.
In commerce systems, especially e-commerce applications, relatively little security analysis are done at the business logic level. Most analysis at this level is focused on detecting what we would call mistakes in the implementation of a set

Research Design Strategy
Since our main scope of this research study is to focus on business component-based application logic problems and identify vulnerability that is because of mismatch between business process specification and logical component-ware specification at design level while using rapid development business component-based-software approach for business application logic in e-commerce system.
In the light of business logic vulnerability definition [12] [13], we have taken a case study from the industrial sector (Bank Case Study of business application logic), research process would go through stages as explained in the paper, these are based on vulnerability risk analysis in terms of security perspective, for that, it is very important to integrate the knowledge contained in the attack method with boundary knowledge related to vulnerability of the target Component-based-Software application e-commerce system. Our focus is to consider multi-layer specification based on components business event scenario using Bank Case Study. In this technique, process is divided into two phases: 1) High level view of system tier 2) Component layers. The High level view of system tier focus on the high level view of the design product, and component level layers will consider the design, test, and diagnostics specification for a separate entity component that take part in the system building.

Security Properties Violations [Problem Area] in Business Tier
The layer. Therefore, a strong risk management plan will focus on providing rigorous software assurance for the middleware software [3].

Web Software Application Vulnerability
We define web software application vulnerability definition as web software application vulnerability includes mismatches between application software architectural/design logic & the assumptions about the environment made during the development/Implementation (code writing), operation of the programme and the environment in which the programme executes [13].

Logical Vulnerabilities in Application Layer
Since our main scope of this research study is to focus on investigation web software application logic problems & identify vulnerability that is because of mismatch between business process specification and component ware specification at design/Architecture level while using rapid development business component-based-software approach for business application logic in e-commerce systems. Our attack patterns are more specific to what components can pinpoint vulnerability in a system design. We will only target business application Logic vulnerabilities.

Problem Cause Definition & Explanation
Application Logic Attacks Operation: Unlike, common application technical attacks, such as SQL injection or Buffer overflow, each application logic attack is usually unique, since it's not been mentioned or part of any taxonomy of web application attacks, and since it has to exploit a function or feature that is specific to the application. Since, application logic attacks are not based on characteristics like buffer overflow which can be characterize them as other technical vulnerabilities in the web application (SQL, SSI or buffer overflow).This makes it more difficult for automated vulnerabilities testing Tools to identify or detect such vulnerability class of attacks because they are caused by the flaws in application Logic & not necessarily faults/bugs in the actual code. The application enabled existing customers who did not already use the online application to register to do so. New users were required to supply some basic personal information, to provide a degree of assurance of their identity. This information included name, address, and date of birth, but did not include anything secret such as an existing password or PIN number. When this information had been correctly entered, the application forwarded the registration request to back-end systems for processing. An information pack was mailed to the user's registered home address. This pack included instructions for activating their online access via a telephone call to the company's call center and a one-time password to use when first logging in to the application.

Bank Case Study Component-Based-Rapid Development
The Design Logic of Application: The application's designers believed that this mechanism provided a very ro- 1) A modest amount of personal data was required up front, to deter a malicious attacker or mischievous user from attempting to initiate the registration process on other users' behalf.
2) The process involved transmitting a key secret out-of-band to the customer's registered home address. Any attacker would need to have access to the victim's personal mail.
3) The customer was required to telephone the call center and authenticate himself there in the usual way, based on personal information and selected digits from a PIN number.
This design was indeed robust. The logic flaw lay in the actual implementation design of the mechanism. The developer was implementing the registration mechanism needed a way to store the personal data submitted by the user and cor- After the user's information was captured, this object was instantiated, populated with the supplied information, and stored in the user's session. The application then verified the user's details, and if they were valid, retrieved that user's unique customer number, which was used in all of the company's systems. This number was added to the object, together with some other useful information about the user. The object was then transmitted to the relevant back-end system for the registration request to be processed. The developers assumed that making use of this code component was harmless and would not lead to any security problem. However, the assumption was flawed, with serious consequences.
Attack Pattern Birth: The same *component (code)* that was incorporated into the registration functionality was also used "use case logic (+Process and Entity Type Logic)" within the application, including within the core functionality, which gave au- Exploiting the Logic Flaw Scenario: To exploit the logic flaw, therefore, an attacker needed to perform the following steps: ■ Log in to the application using his own valid account credentials.  ■ Using the resulting authenticated session, access the registration functionality and submit a different customer's personal information. This causes the application to overwrite the original "CCustomer" (Component) object in the attacker's session with a new object relating to the targeted customer. ■ Return to the main application functionality and access the other customer's Account. A vulnerability of this kind is not straightforward to detect when probing the application from a Black-box perspective. However, it is also hard to identify when reviewing or writing the actual source code. Without a clear understanding of the application as a whole and the use made of different components in different areas, the flawed assumption made by developers may not be evident. Of course, clearly commented source code and design documentation would reduce the likelihood of such a defect being introduced or remaining undetected. Attacking Method in This Scenario: ■ In a complex application involving either horizontal or vertical privilege segregation, try to locate any instances where an individual user can accumulate an amount of state within their session which relates in some way to their identity. ■ Try to step through one area of functionality, and then switch altogether to an unrelated area, to determine whether any accumulated state information has an effect on the application's behaviour.

Investigated Reason of Vulnerability in the Light "State of Art CBSD" in Business Logic
Component-based-rapid development approach is a method to make business that an application is made up and composed of a number of individual parts, and that these parts are specifically designed for integration in a number of different applications. It also captures the "idea that one component may be part of another component" [14], or part of a sub-system or system, both of which represent components in their own right). Integration of all this process, then develop overall business processing logic for a business component-based software to develop an application in the middle tier, which is connected with information system in the back-end systems of organization.
Since business process integration is made on the base of business functional concern; it cannot be dealt with technological point of view, because problem is not based on technical or technological specific principle of Integration, which is based on related to some particular physical component model such as (J2EE, CORBA, COM), but as it is stated, issue identifies that business processing designed solution based on business components and their business processing integration. This is the point, where the focus is set to the logical structure of the "business solution", this is the stage where logical problems occurs due to lack of paying attention to the design-based business component interfaces used and offered testing environment within the logical structure of the business solution, are known as Business Logic Vulnerabilities [12] [13] [15].
Moreover, during the investigation we also discovered that Bank developer

Existing Methods and Approaches to Application Functional Logic Security
In modern times, the ruling perimeter security approach does not fit the e-business environment's security challenges. Due to the fact that e-business mode of doing business implies "openness" to the external world, while the perimeter security implies existence of boundaries, that separate between the organization and the external world.
Traditional security paradigm, which is as stated parameter security approach, does not relevant to e-business process. Therefore, business process appears to present most important change from traditional way to e-process [16].
E-business/e-commerce is the subject of a huge volume of ongoing research.
Some of this relates to e-business information security, and just a small part (with regard to information security relates to business process identity security requirements of electronic processes.
Traditionally, enterprises have prioritized and focused their IT security strategies and budgets on protection of network perimeter and physical or logical access control to the application system environment. Following the common approaches, organizations security goals are defined to protect company's information systems by eliminating the external threats, and by providing logical access control and restrictions to the application, but business process can be attacked even when a very good network and infrastructure security programme is in place. For example, good network perimeter defence using firewalls, honey pot, intrusion detection systems and other network security components must still ensure the applications can be accessed by legitimate users and therefore at the same time can facilitate an opportunity for legitimate users to attack the organization business information systems by abusing the vulnerable e-commerce business process at application interface level. This is reason why, e-commerce business process build on base of two blocks; business logic and information flow.
Therefore, there is a clear need for such technique or framework that could work for as an alternative approach for design e-business information systems security.

Proposed a Technique Secure Application Functional Processing Logic
We propose secure application functional process logic for e-commerce component-based application based on security requirements of e-process and security assurance logical component behaviour specification approach to formulize and design a solution for business logic vulnerability phenomena. First section of methodology follows security risk analysis in the CBSD rapid business logic and defensive strategy. In addition to this, we also propose in the second section, "A security Assurance Model process" to deal with logical component-ware reusing

Effect of Attacks on System Design
One of the first steps in system design should be the analysis of the possible attacks on specific system and their consequences when successful, such as above stated case of e-commerce component-based web software application, and discovered logical vulnerability in the application layer of business-tier. The technique of identifying vulnerability achieved via mismatching a sequence of components in a system's application design logic and problem caused by ignoring business process integration of component at the time of application's business process logic(which can be mapped through scenario-based approach modelling business scenario, which represent a basic end-to-end system function, also decomposed into sub-scenario, which identify functionality of important sub-system's component) that permits the sequence of "Event Trigger" in the attack pattern to occur analysis of the description mentioned in the light of case study and vulnerability attack pattern reveals the event that transpire, what component is used to exploit the vulnerability in Barclay Bank case. This analysis can be used to define the countermeasures that need and will also be useful later to evaluate the system security.

Layers Pattern
Security encompasses all the architectural levels of a system. The layers architectural pattern is therefore the starting point of the design of secure systems.
This pattern provides a structure where we can define patterns at all levels that together implement a secure system as defined in Figure 6. Its main idea is the decomposition of a system into hierarchical layers of abstraction, where the higher levels use the services of the lower levels.
Here it provides a way to put

Architectural Risk Analysis for Component-Based Business Logic
Security Design flaws account for 50% of the security problems in the component-basedsoftware system [17]. Architectural risk analysis is, at best, a good general-purpose yardstick by which we can judge our security design's effectiveness [14]. Because roughly 50 percent of security problems are the result of design flaws, performing a risk analysis at the design level is an important part of a solid good secure component-based-software system engineering.
To encompass the design stage, any risk analysis process should be tailored.
The object of this tailoring exercise is to determine specific vulnerabilities and risks that exist for the software [17]. Architectural level risk analysis Approach n-tier Web application design model by the Cigital USA does not clarify the each layer in the tier and its components, as its very important for a functional decomposition of the application into major components, processes, data stores, and data communication flows, mapped against the environments across which the software will be deployed, allows for a review of threats and potential vulnerabilities, as its defined in the new proposed n-tier e-commerce web system architectural risk analysis & security management model as defined in Figure 7.  During the risk analysis process must consider the following: 1) The threats those are likely to want to attack the system.
2) The risks present in each tier's environment.
3) The kinds of vulnerabilities that might exist in each component, as well as the data flow.
4) The business impact of such technical risks, were they to be realized.

5)
The probability of such a risk being realized.

Designed Defensive Strategy as a Solution to Deal Business Logic Concerns
This part of methodology will provide a strong risk management control plan focusing on providing rigours component ware assurance for rapid development of CBSD business application logic for e-commerce applications as projected in

Strong Risk Management Plan
Ensure that every aspect of the application's design must be clearly & sufficiently detailed to understand every assumption and designed function logic within the application by designer.

Solution Artifacts
As that there is no unique signature by which logic flaws in component-basedrapid developed web software application can be identified, because there is no silver bullet so far developed which could protect. 2) Security assurance requirements.
The Security Functional Requirements: Describe the desired security behaviour or functions expected of an IT system to counter threats in the system's operating environment. These requirements are classified according to the security issues they address, and with varied levels of security strength. They include requirements in the following classes: security audit, communication, cryptographic support, user data protection, identification and authentication, security management, privacy, protection of system security functions (security meta-data), resource utilization, system access, and trusted path/channels.
The Security Assurance Requirements: The security functional requirements mainly concern the development and operational process of the IT system, with the view that a more defined and rigorous process delivers higher confidence in the system's security behaviour and operation. These requirements are classified according to the process issues they address, and with varied levels of security strength. The process issues include: life cycle support, configuration management, development, tests, vulnerability assessment, guidance documents, delivery and operation, and assurance maintenance. Therefore, in the Bank case security assurance requirement was also an issue. In the light of above stated security assurance CBSD process model. There are two further more important.
Moreover, There are two further more important artifacts which we dived to consider 1) Security focus review of application design (falls under Separation of business logic) 2) Security focus code reviewing review (Falls under the Implementation logic).
1) During Security-Focused Review of Application Design: Refers to tackle logical design flaws, during the security-focused review of design, must reflect upon every assumption made within the design of logical component ware stage and its business process integration, and try to imagine circumstances in which each assumption and logic might be violated. Focus particularly on any assumed condition that could conceivably be within the control of application user based on business process, rule and policy.
2) Security-Focused Code and Implementation Review: Refers to technical vulnerability issues that could be due to environment level, Infrastructure concerns or software artefact based multiple technology integration at the time of implementation. Carefully, think laterally about three key concerns at this stage; a) The ways in which unexpected user behaviour and Input will be handled by the application.
b) The potential side effects of any dependencies and interoperation between different code components and physical component-model specification with  Figure 9. This will cover integration strategies of components as compare to its requirement specifications, their offered and used interface focused design specifications, obtaining test scenarios from business events based on contracts involved between business components and their flow, and analyzing business data to achieve test cases. Therefore, our focus is to consider multi-layer specification based on components business event scenario using Bank Case Study. In this technique, process is divided into two phases 1) High level view of system tier 2) Component layers. The High level view of system tier focus on the high level view of the design product, and component level layers will consider the design, test, and diagnostics specification for a separate entity component that take part in the system building.
The most important point is to set focus on multi-tier specification .These will be system tier and the component tier. Model-based design for test approach for components business process integration testing, this will confirm the validation and verification of the whole process, in terms of system and component layer and tier specifications that encompass the overall Model based Design for test approach [19]. This approach based on the concept which confirms the philosophy of accuracy depends on precise construction; this reveals that discovering the design flaw in the product can be achieved early at design stage by using model based testing technique, for example integration flaws can be identified through "DFT method". Therefore, this philosophy invites researchers to apply Model-based approach that helps to refine and detection design flaw, those exist between the components interfaces, while interacting with other components in the system in order to deliver a service, trigger by the event, which call the particular service, composed with the business components based business process integration to develop "business process logic" in the e-commerce systems.

Lesson Learned
Therefore type specifications. It's also case of "Test by Contract", which means not only design specification of component ignored but also contract establishment among the interfaces and their designed logic throughout the process, which created security assurance problem among the interface-focused designed components behaviour through e-process, while developing component-oriented business logic. The boundary condition of this attack falls in between functional specification and design specification. The attack triggering method is "Event-basedgenerated" e-process flow to violate business logic.

Contribution
Our contribution, proposed secure functional processing application logic for e-commerce component-based application, has covered the gap as stated above between traditional approaches and e-business process security requirements that will increase level of assurance during the practice of designing component-based rapid developed e-commerce applications from existing software components and deploying component based business logic into e-commerce system. Which reminds that focus on e-process security beside the functionality is also very important, because this functionality can be productive only when it works as per and within its functional control defined by the business logic in the e-commerce applications.

Conclusion
Much of the security today is addressed as an audit activity that mostly relies on penetration testing such testing activities often attempt to identify vulnerabilities that belong to certain categories of threats & use tools that are tailored around these threats. They may have security policies that auditors follow which require them to check a specific list of things, but they often fall short of identifying vulnerabilities that a result of the way the application logic has been custom developed. The fact is that many attacks that are reported today fall under what we define as application logic attacks. Therefore, our contribution of proposed methodology and approach will increase level of assurance during the practice of designing component-based rapidly developed web application software and deploying component based business logic into e-commerce system. This reminds us that focus on security besides the functionality is also very important because this functionality can be productive only when it works as per and within its functional control defined by the business logic in the e-commerce application.

Conflicts of Interest
The authors declare no conflicts of interest regarding the publication of this paper.