Web Services E Commerce
User Rating: 0 / 5
- Details
- Hits: 14629
Risk has always been a part of business, an enduring reality that every company must address. To compete, grow and capture benefit, organizations must accept risk. It’s what businesses do. Risk also has many more faces: cash flow crises, supply disruptions, quality failures, cyber intrusions, and financial fraud and technology breakdowns. We will discuss all the risk assessment in this paper.
Security is fundamentally about protecting assets. Assets may be tangible items, such as operations or your customer database, or they may be less tangible, such as your company’s reputation. It is important to recognize that security is a path, not a destination. As you analyze your infrastructure and applications, you identify potential threats and understand that each threat presents a degree of risk. Security is about risk management and implementing effective countermeasures. One of the most important concepts in security is that effective security is a combination of people, process, and technology. The following paragraph will discuss way to implement security and risk assessment of the E-commerce system.
We will apply the three tier architecture on the E-commerce system. E-commerce architecture must be separated physically and logically into three separate components: the Web server; the Application server; and the Database server (E-commerce systems). The data should be stored behind a firewall and accessed through an application proxy. Single tier E-commerce architecture exposes the web server a single point of attack.
The web server must be placed behind a firewall, and the firewall must be configured to allow connections to the web server only on ports and services required for business reasons. The Web server should reside on its own segment, separate and distinct from other servers. Not having the web site behind a firewall exposes the web site to direct attacks.
The server access must ensure no update or write access is allowed to the web server file system. Update or write access could be misused to hack the web site. The compromised web server could then be used to launch attacks on the other E-commerce systems.
Authentication addresses the question of who you are? It is the process of uniquely identifying the clients of your software enterprise and services. These might be end users, other services, processes, or computers. In security world, authenticated clients are referred to as principals. Strong authentication mechanisms such as digital certificates and hard tokens should be used for proprietary or highly restricted systems. Insecure access to a customer account could result in misuse of customer specific information.
Effective auditing and logging is the key to non-repudiation. Non-repudiation guarantees that a user cannot deny performing an operation or initiating a transaction. For example, in an e-commerce system, non-repudiation mechanisms are required to make sure that a consumer cannot deny ordering 50 copies of a particular book.
Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across a network. Encryption is frequently used to enforce confidentiality. Access control lists (ACLs) are another means of enforcing confidentiality.
Integrity is the guarantee that data is protected from accidental or deliberate (malicious) modification. Like privacy, integrity is a key concern, particularly for data passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.
From a security perspective, availability means that systems remain available for legitimate users. The goal for many attackers with denial of service (DoS) attacks is to crash an application or to make sure that the application is sufficiently overwhelmed so that other users cannot access it.
Stored transaction data encryption to ensure that transaction data is encrypted as it is stored. If transaction data, which is comprised of customer specific confidential information, is not stored securely, an unauthorized user could access this information in a readable format.
All transactions must initiate and complete on the application server, not the web server. Transactions contain critical data and if not secured could result in unauthorized access of that data. Because the web server sits in the de-militarized zone (DMZ) it is considered to be in an insecure.
Session keys must be unreadable, have unique values, and should provide for secure sessions to be logged out by the user or to time out automatically. If sessions are not terminated properly they may allow a user to connect to a session without getting authenticated again, which can be misused to gain access to a customer's account.
E-commerce systems should be backed up regularly, and restoration procedures should regularly be tested to validate the integrity of the backups. Failure to properly backup the E-commerce systems could result in the loss of configuration information as well as system files, security log files, and data.
All necessary recommended vendor software and security patches should be installed and properly configured for E-commerce systems. Failure to install the latest recommended security patches could result in the systems becoming vulnerable to new attack methods.
System and configuration files for all E-commerce systems should only be viewable by the Administrator. Failure to properly secure system and configuration files could result in modifications by unauthorized personnel that could result in the addition of significant security vulnerabilities.
To prevent software conflict, the web server should only be running web server software. No other software packages should be installed unless a sufficient business need exists. Rogue processes could compromise security not only of the web server, but also the internal hosts, through the introduction of back doors. Unnecessary processes could also strain the operating system resources thereby affecting web server performance.
The E-commerce systems should periodically be scanned with vulnerability scanners to determine if the system is vulnerable to new exploits. Without periodic vulnerability scanning, a new vulnerability or exploit may be introduced into the system without the system administrator’s knowledge.
The E-commerce infrastructure must include a real time intrusion detection system. This must also be supported with incidence response procedures to ensure incidences are responded to and escalated in an appropriate and timely manner. Lack of an Intrusion detection system and incidence response procedures may result in unauthorized activities being undetected. Undetected intrusions are likely to result in increased damages due to a longer period of unauthorized access.
An E-commerce web site must have a Seal of Trust or a Cyber Process Certification performed. This helps build web site credibility and customer trust, thus increasing the value of the site. The certification process is usually performed by a trusted third party. This will help mitigate customer’s fear of operating in an insecure environment.
Security settings, authentication, authorization, logging, and other parameters can usually be set in configuration files. Improper configuration can lead to security vulnerabilities, as can a lack of protection on the files themselves, which can lead to improper modification or theft of connection strings and other sensitive information. Threats and attacks include unauthorized access to configuration stores. An attacker gains access to configuration files and is able to modify binding settings, and retrieval of clear text configuration secrets. An attacker gains access to configuration files and is able to retrieve sensitive information such as database connection strings. Vulnerabilities include using insecure custom administration interfaces, failing to secure configuration files on the server, storing sensitive information in the clear text, having too many administrators, and using over privileged process accounts and service accounts. Countermeasures include use access control lists (ACLs), encrypt sensitive sections of configuration files, and use secure settings for various operations of Web services using configuration files.
Impersonation and delegation are techniques used to flow the original caller to back-end resources. Impersonation is used to access resources on the same machine where the service code is running. Delegation is used to access network resources on other machines. Threats and attacks include an attacker is able to run in the context of a higher-privileged user. An attacker gains access to data that should only be available to another user. Vulnerabilities include Failure to revert to a lower privilege after using impersonation and the improper use of global impersonation across the entire service. Countermeasures include use a Using statement to automatically revert impersonation. Granularly impersonate only those operations that need it.
Message replay detection is a feature that allows your code to detect some instances in which an attacker is trying to replay messages in order to steal a session from one of your clients. Threats and attacks include an attacker steals messages off the network and replays them in order to steal a user's session. Vulnerabilities include failure to use a mechanism to detect message replays. Countermeasures include use any platform-provided replay detection features, and consider creating custom code if the platform does not provide a detection mechanism.
Message signing is used to protect the integrity of messages in transit over the network and to provide proof of the original sender. Signing does not protect the confidentiality of the data, but only its integrity and confidence in the original sender. Message signing can be provided by either message security or transport security. Message security signs each message individually, while transport security protects the entire communication channel (e.g., with SSL). Threats and attacks include an attacker modifies the data in a message in order to attack the client or the service. Vulnerabilities include not using either message or transport security. Countermeasures include turn on message or transport security.
Message validation is used to protect your service from malformed messages and message parameters. Message schemas can be used to validate incoming messages, while custom validators can be used to validate parameter data before your service consumes it. Threats and attacks include canonicalization attacks can occur anytime validation is performed on a different form of the input than that which is used for later processing. For instance, a validation check may be performed on an encoded string, which is later decoded and used as a file path or URL. Failure to validate input can result in SQL injection if the input is used to construct a SQL statement, or if it will modify the construction of a SQL statement in some way. XPath injection can result if the input sent to the Web service is used to influence or construct an XPath statement. The input can also introduce unintended results if the XPath statement is used by the Web service as part of some larger operation, such as applying an XQuery or an XSLT transformation to an XML document. XML bomb attacks occur when specific, small XML messages are parsed by a service resulting in data that feeds on itself and grows exponentially. An attacker sends an XML bomb with the intent of overwhelming a Web service's XML parser, thus resulting in a denial of service (DoS) attack. Vulnerabilities include using non-validated input used to generate SQL queries, relying only on client-side validation, using input file names, URLs, or usernames for security decisions, Using application-only filters for malicious input, looking for known bad patterns of input, trusting data read from databases, file shares, and other network resources, and failing to validate input from all sources including cookies, Simple Object Access Protocol (SOAP) headers, SOAP parameters, databases, and network resources. Countermeasures include do not trust client input, validate input: length, range, format, and type, validate XML streams, constrain, reject, sanitize input, encode output, and restrict the size, length, and depth of parsed XML messages.
Sensitive data refers to any confidential information that your service processes or transmits. Protection of sensitive data includes protecting the information over the network, in configuration files, in local memory or file storage, or in databases and log files. Sensitive information includes user identity and credentials as well as any personally identifiable information such as social security number. Threats and attacks include an attacker is able to read sensitive data out of memory or from local files, an attacker listens to and intercepts unencrypted sensitive data off the network, and an attacker steals sensitive information, such as connection strings, out of configuration files. Vulnerabilities include storing secrets when you do not need to, storing secrets in code, storing secrets in clear text in files, registry, or configuration, and passing sensitive data in clear text over networks. Countermeasures include do not store secrets in software, encrypt sensitive data over the network, secure the channel, and encrypt sensitive data in configuration files.
Designing a Web service with security in mind presents developers and architects with an interesting set of challenges. Some are unique to service-oriented architecture and some are similar to the challenges that face enterprise Web application development teams.
A Web service is most commonly implemented as a wrapper—that is, as an interface between a client consuming the service and back-end business logic components doing the actual work. A Web service acts as a trust boundary in your application architecture. By its nature, a Web service acts as a gateway between trusted business components and less trusted or untrusted client components. For this reason, it is impossible to think about the security of a Web service without also thinking about authentication, authorization, protection of sensitive data on the network, and handling potentially malicious input. Each of these areas represents key decisions you will need to make in order to maintain the security of your application.