Security Use Cases
From MemberWiki
Contents |
Introduction
This wiki page lists the key use cases that the Security Task Force will focus its efforts.
Definitions
(this section needs expansion and refinement)
- Mashup... (define broadly to include portals?)
- Control - a visual or non-visual Ajax element that serves a finite functional purpose. Controls may have associated APIs. Visual controls include concepts like tabsets, data grids, sliders, text boxes, date pickers, accordions, fisheyes, etc... . Non-visual controls include concepts like data objects and communication objects. (Synonyms: Widgets, Gadgets though in use this usually connotes controls that have visual interfaces with which one can interact.)
- Library - a collection of Controls and/or APIs.
- Toolkit (in the context of "Ajax toolkit") - A collection of technologies, products, and other supporting materials such as documentation, that help a customer to produce an Ajax-based solution. In some scenarios, a toolkit might just be a library, but in other cases will consist of some combination of libraries, server components, authoring components, associated utility software, and supporting materials such as documentation.
Scenario - Used Car Purchasing Mashup
The customer arrives at a used car buying portal main page. This contains the widgets for the main interface allowing users to choose a make, model, and vintage of the car. A third party mapping component allows the user to localize search to a particular geography (zip code, town, etc). Once the user chooses a car and a particular geography, the user car portal shows a list of the cars satisfying the customer’s criteria. Note that even at this stage the used car portal component must invoke services on the dealers’ servers to obtain a list of vehicles and prices for that particular dealer. This is displayed as lists sorted by price and other criteria. Clicking on a link displays components from the chosen dealer, which contain details of the chosen car. When a car link is clicked the used car portal component also loads a component from a vehicle history service, hereafter referred to as CarArchaeology (got a better name that is not already used?), with instructions on how to use the service.
The user can view cars, look at the details, change the geography, change the specs of the cars etc. When viewing the details of a car, the user can drag and drop the vehicle Identification Number (VIN) of the car into the CarArchaeology component. (is it possible to drag and drop across iframes?). Drag-n-drop of the VIN can be replaced by a button to send the VIN to the CarArchaeology component. Or, the used-car portal page can have a UI control, in the portal component, to accomplish the DnD. (Any further reference to drag-n-drop will be replaced by some mechanism as above.) The CarArchaeology component will then prompt for the user to enter his/her authentication/creditcard/coupon/other credential information. Alternately, the car dealer component can advertise a “I’ll pay for your CarArchaeology search” feature. Dragging and dropping that dealer’s VIN info will cause the CarArchaeology component to avoid prompting the user for authentication info.
The dealer component can optionally be a hierarchical mashup consisting of the car details and a car reputation component (read: Consumer Reports or Consumer Digest). For this one, the user can drag and drop the VIN/car details into the reputation component and it gives you the consumer reputation. At least a couple of authentication scenarios are possible -- one where the dealer pays for the report, and another where the customer pays for the report.
Configuration variations for this scenario
The following is the breakdown of possible configuration options for the application described above. Note that any given mashup application might use combination of the options listed below (i.e., A through D are not mutually exclusive).
A: Mashup components hosted from same base domain as mashup application
Let's suppose a mashup server from www.mashup.com and a given mashup component CompA.
In this setup, mashup components are available only from the same domain as the mashup application. For example, CompA might be available at either CompA.mashup.com or www.mashup.com/components/CompA. Typically the mashup server will need to perform server-to-server communications with the Web service corresponding to a given component (e.g., www.CompA.com).
(Perhaps highlight at least one security issue that arises from the scenario)
B: Mashup components hosted from the components' domains
Let's suppose a mashup server from www.mashup.com and a given mashup component CompA.
In this setup, mashup components are pulled into the mashup by directly accessing the CompA domain, such as with an <iframe src="http:/www.compA.com/..."> or via JavaScript logic with a <script src="http:/www.compA.com/...">.
(Perhaps highlight at least one security issue that arises from the scenario)
C: Mashup components placed inside of an <iframe>
Some mashup applications leverage the same-domain restrictions that browsers implement around the iframe tag to ensure that 3rd party components are sandboxed relative to the main mashup application and other components.
This approach sometimes helps achieve greater security with mashups but at the expense of complexity and difficulty in achieving getting the components to communicate with each other.
D: Mashup components placed inside of an <div>
Some mashup applications place 3rd party components within the same HTML frame as the mashup container. This is the approach used by the 1.0 version of the Java portal specifications (which disallow <script> tags). (??? Is all of this true???)
This approach is often the most convenient for mashup and component developers, but it is difficult to achieve security because there is no sandboxing on the client side. Mashup servers often analyze and filter the Web content for mashup components to ensure that the component restricts itself to a safe subset of available technologies (particularly HTML).
Associated requirements
- Need to support mashup components that use Comet (server-push) techniques
- Need to take into account information that is cached or stored persistently on local machine. Cookies fall into this broad topic, but so does local storage associated with Google Gears.
- Need to ensure that we understand identity and authorization workflows
Scenario - Shipment Mashup
We describe a shipment mashup scenario which provides a (hopefully) rich shipment process function by combining UI mashups with data mashups. A UI mashup uses third party UI widgets and (local) enterprise UI widgets. A data mashup aggregates third party data and backend data. A data mashup accesses data through web services.
The main goal of this (simplified) shipment process is to find qualified carriers for a specified shipment request. The qualification of a carrier for a shipment request is based on different parameters including shipment rate sent by the carrier, public reputation value about the carrier, trusted supplier rating, wheather conditions of the cities (or related airports) given in the shipment route of the carrier etc.
The shipment application user arrives at the shipment page of the enterprise portal. The page contains a main enterprise widget allowing the user to enter shipment data (from_city, to_city, item type, # of items, date, etc). Once the user enters the from_city and to_city values a third party mapping widget localizes the cities on the map. The user clicks for searching for potential carriers. The results will be displayed on another widget which shows a lists sorted by carrier rates. Clicking on a link displays more details on the carrier’s response. The user has also the option to get public reviews on the carriers. The user selects first three carriers and clicks on a button to get the public reviews on the carriers. The position of the selected three carriers may change depending on the received ratings. Since the company which aims to ship its products works with various suppliers, the user also wants to get more trustworthy ratings from the company’s suppliers. The user presses a button (this can be replaces by drag-n-drop) gets the ratings (e.g. wrt on time delivery) from a selected supplier whose response changes again the positions of the three potential carriers. Another third party widget is weather widget which shows weather information for a given route. Before making a final decision the user also passes the route information of a chosen carrier to the weather widget. The whether conditions in all cities within the route will be then displayed on the other third party mapping widget. Finally the user selects a carrier and sends a booking request to the selected carrier which in turns sends a confirmation for the booking.
The variations given in the “used car purchasing scenario” are also possible here. We assume that trusted suppliers and carriers provide web services for the communication with the company hosting the shipment mashup application. In order to achieve secure dynamic web service interactions between different parties, in addition to providing web service descriptions, the service providers (suppliers and carriers) publish the security requirements (e.g. message confidentiality) and security capabilities (e.g. RSA encryption) related to their web services. The mashup application has also security requirements with respect to its external communications and provides support for certain security protocols and mechanisms. Before communication can take place between the mashup application and external services, a common security policy must be negotiated which is compatible with both party's requirements/capabilities. Once a common configuration has been determined the next step is to create a collection of security proxies which will act as intermediaries for all future communication between the composite and the service which the specific proxy masks. The core component of a security proxy is its constituent SOAP handlers. Upon construction, each security proxy associates itself with a “handler chain” based upon the common configuration determined during policy negotiation. e.g. The handler chain might consist of two handlers, one to deal with ensuring confidentiality of communications, and another to deal with ensuring message integrity. In addition to message confidentiality and integrity, the agreed policy between parties can also specify which security tokens with which authorization information should be included in the SOAP messages.
In this discussion the focus was more on securing the communications with external web services and regulation access to web services based on the submitted security tokens. These problems have been well understood in the context of process centric composite applications. There are security specifications like SAML, WS-Policy, WS-Security which can be used to address the problems discussed above. I think there is a need to revisit the existing web services security problems and solutions in the context of web mashups.
Invoking SOAP Web services from within a Web browser can be a tricky exercise. Do all popular web browsers handle generating and processing of XML in different ways? Is there a way to deal with namespace-intensive XML formats like SOAP in a browser-independent manner? More questions???
We may use and extend this scenario to address interesting security related questions around browser security and web services security.
(this is a last minute draft of a scenario discussion)
Scenario - Wiki, Blog, Social Networking Service (SNS)
Social computing software and services such as Wiki, Blog, and Social Networking Service (SNS) now become a major communication medium in the Web 2.0 era. Each individual can upload text, pictures, and movies to servers, and these content are shared with many other users. The value of the user generated content is increasing, but it will lead some serious security issues at the same time.
One of most well-known attack against the social computing software and services is Cross-site Scripting (CSS or XSS). Though it's not specific to such Web 2.0 applications, but it often pinpoints their weak point.
Here is a attacking scenario of the XSS attack.
- Many SNS systems allow users' input with HTML/CSS tags. The intention of providers is to allow decoration of users' pages with the tags, but malicious users could inject malicious JavaScript code in the HTML/CSS fragment.
- Most servers validate (sanitize) users' inputs, but it is often not perfect. There could be various tricks to bypass the validation checking. In this case, malicious JavaScript code is passed the input validation, and stored in database on the server.
- The content which contains malicious code could be accessed by innocent users. Note that the malicious content comes from trusted service providers. The code is downloaded to the users' browsers and executed.
Actual examples of the attack used with XSS is the Sammy worm against MySpace.com, the Yamanner worm agist the MySpace.com, and etc.
(Placeholder) Scenario: B-to-C System, where Web 2.0 features are added to existing Web 1.0 system
(This is just a placeholder)
It would be nice to add one more scenario -- B-to-C System, Converted from Web 1.0 (but Non-mashup, so it is different from other scenarios in the above page).
On BlackHat 2007, Bill Hoffman from SPI Dynamics presented a practical use case of B2C, an airticket booking system, full of Ajax vulnerabilities. There is no public link to that presentation yet (should be available at http://www.spidynamics.com/spilabs/education/presentations.html after a while).
Features by design of that system:
- User Authentication;
- Airticket lookup, booking and billing;
- An admin subsystem.
Vulnerabilities of that system:
- Generic SQL Injection;
- Generic Cross-Site Scripting;
- Information Disclosure, such as exposing admin methods in javascript file (mitigation: expose methods in a separate javascript files);
- Tampering by subverting business logics, such as booking after billing (mitigation: expose no methods as atomic as database operation but only methods at transaction level);
- Deny of Service, such as holding seats without releasing them (mitigation: similar to above);
- Priviledge Escalation, such as omitting user auth in admin methods (mitigation: enforce user auth in every method).
