
Customer relationship management (CRM) is a broadly recognized, widely-implemented strategy for managing and nurturing a company’s interactions with customers, clients and sales prospects. It involves using technology to organize, automate, and synchronize business processes—principally sales activities, but also those for marketing, customer service, and technical support. The overall goals are to find, attract, and win new clients, nurture and retain those the company already has, entice former clients back into the fold, and reduce the costs of marketing and client service.[1] Customer relationship management denotes a company-wide business strategy embracing all client-facing departments and even beyond. When an implementation is effective, people, processes, and technology work in synergy to increase profitability, and reduce operational costs.[2]
These tools have been shown to help companies attain these objectives:
Many CRM vendors offer Web-based tools (cloud computing) and software as a service (SaaS), which are accessed via a secure Internet connection and displayed in a Web browser. These applications are sold as subscriptions, with customers not needing to invest in the acquisition and maintenance of IT hardware, and subscription fees are a fraction of the cost of purchasing software outright.
The three phases in which CRM can help to support the relationship between a business and its customers are, to:
Despite the benefits, many companies are still not fully leveraging these tools and services to align marketing, sales, and service to best serve the enterprise.[5]
Tools and workflows can be complex to implement, especially for large enterprises. Previously these tools were generally limited to contact management: monitoring and recording interactions and communications. Software solutions then expanded to embrace deal tracking, territories, opportunities, and at the sales pipeline itself. Next came the advent of tools for other client-facing business functions, as described below. These technologies have been, and still are, offered as on-premises software that companies purchase and run on their own IT infrastructure.
Often, implementations are fragmented; isolated initiatives by individual departments to address their own needs. Systems that start disunited usually stay that way: siloed thinking and decision processes frequently lead to separate and incompatible systems, and dysfunctional processes.
One of the primary functions of these tools is to collect information about clients, thus a company must consider the desire for privacy and data security, as well as the legislative and cultural norms. Some clients prefer assurances that their data will not be shared with third parties without their prior consent and that safeguards are in place to prevent illegal access by third parties.
This market grew by 12.5 percent in 2008, from revenue of $8.13 billion in 2007 to $9.15 billion in 2008.[6] The following table lists the top vendors in 2006-2008 (figures in millions of US dollars) published in Gartner studies.[7][8]
| Vendor | 2008 Revenue | 2008 Share (%) | 2007 Revenue | 2007 Share (%) | 2006 Revenue | 2006 Share (%) |
|---|---|---|---|---|---|---|
| SAP | 2,055 | 22.5 (-2.8) | 2,050.8 | 25.3 | 1,681.7 | 26.6 |
| Oracle | 1,475 | 16.1 | 1,319.8 | 16.3 | 1,016.8 | 15.5 |
| Salesforce.com | 965 | 10.6 | 676.5 | 8.3 | 451.7 | 6.9 |
| Microsoft | 581 | 6.4 | 332.1 | 4.1 | 176.1 | 2.7 |
| Amdocs | 451 | 4.9 | 421.0 | 5.2 | 365.9 | 5.6 |
| Others | 3,620 | 39.6 | 3,289.1 | 40.6 | 2,881.6 | 43.7 |
| Total | ,147 |
0 | ,089.3 | 0 | ,573.8 | 0 |
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.
Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.
The attack works by including a link or script in a page that accesses a site to which the user is known to have authenticated. For example, one user, Bob, might be browsing a chat forum where another user, Alice, has posted a message with an image that links to Bob’s bank. Suppose that, as the URL for the image tag, Alice has crafted a URL that submits a withdrawal form on Bob’s bank’s website. If Bob’s bank keeps his authentication information in a cookie, and if the cookie hasn’t expired, then Bob’s browser’s attempt to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob’s approval.
A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob’s Web browser which is confused into misusing Bob’s authority at Alice’s direction.
The following characteristics are common to CSRF:
At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user that is authenticated by a cookie saved in his web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action.
CSRF attacks using images are often made from Internet forums, where users are allowed to post images but not JavaScript.
Here is an example of an attack on Digg. Here is another example of an attack on Amazon.com, and one on Google’s Adsense.
For the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie.
An alternate method is to “double submit” cookies. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. If an authentication cookie is read using JavaScript before the post is made, the stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript, negating the only way a user has to prevent most Cross-site scripting vulnerabilities from being exploited.
Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. Nonetheless, requests that cause side effects should always use POST.[1] Also, POST does not leave a trail of variable data in webserver and proxy server logs, while GET does leave such a trail. It is still clearly best to use POST when coding in a defense-in-depth approach.
Another approach is to check the HTTP Referer header to see if the request is coming from an authorized page. Unfortunately, this technique may not work reliably, since browsers sometimes omit the Referer header because of a user’s privacy settings or because the Referer is a secure https page.
Although cross-site request forgery defenses typically require modifying the web application, individual users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.[2]
This attack relies on a few assumptions:
While having potential for harm, the effect is mitigated by the attackers need to “know his audience” such that he attacks a small familiar community of victims, or a more common “target site” has poorly implemented authentication systems (for instance, if a common book reseller offers ‘instant’ purchases without re-authentication).
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.