This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The term "mashup" has been originated from the music field where it means that producing a new song by mixing of mixing of songs, lyric and background music  . A number of new techniques for creating web applications have been resulted into the rapid growth of Web 2.0, one of these techniques is meshing up of required content/services from several independent sources for the purpose to create a new content/service . Web mashup (started as a result of security violation of hole in Google Maps web application by a hacker named Paul Rademacher ) can be defined as a situational web application or web page that is created by pulling out, parsing, and aggregating required relevant content/service from diverse and different publicly available web application to satisfy user needs and tasks through displaying it to them on their compute screens . A simple example can be of a web page extracting map information from one source and location information of some sort of service (such as restaurants or houses going to be sold ) from another site and display the map with services placed on it as shown in Figure 1 . Obviously the mashup result will be more valuable to the user than a single piece of information. A web site containing a web page that combines these resources is called integrator and the web site that contains the contents that integrator want to use is called provider .
Figure 1: Example of mashup 
For the purpose of making mashup creation process easier, several frameworks have been suggested in the last few years to ease experts as well as users with no programming experience. Many content provider have offered their Application Programming Interfaces (APIs) allowing other users to interact, make data/service request and responding to their request; thus making the creation of mashup easy . Google is the pioneer and is letter followed by Flicker, Amazon, Twitter, and YouTube etc. The number of web mashups is increasing tremendously and programmableweb (directory service for web mashups) is registering three new web mashups every day . This directory recently contains more than 9000 registered mashups and more than 3000 registered content providers APIs. The number of web mashups provided in the different areas along with their percentage to the total number of web mashups available up-to-date is shown in the Figure 2.
Several technologies have been invented for making the request and response of information efficient and understandable as well as storing such as Ajax, syndicated feeds like RSS or ATOM, REST, SOAP and JSON etc and data is transferred in XML format . Screen Scrapping is another way of using software tools to parse and analyze the content originally written for human beings and extract required information to be used and manipulated programmatically  .
A web mashup can be either consumer mashup or enterprise mashup: consumer mashup combines different data types and uses public web site that made their content available through well defined APIs and feeds etc, thus requiring less programming expertise such as Wikipediavision combines Google Map and Wikipedia API etc, whereas, enterprise mashup also called data mashups combines similar types of data/information from diverse sources into a unique representation and create a new web service; architecturally, mashups can be either web-based or server-based: web-based mashups user's web browser is used to integrate and represent the data, server-based mashups uses a remote server to analyze and reformat the data, which is send back to the user's browser for displaying to the user  .
Figure 2: Web Mashup categories
Likewise, each web mashup addresses a particular purpose such as (a) mapping mashups: uses maps and location data to be graphically displayed, (b) video and photo mashups: combines other information with videos or photos using the metadata associated with videos or photos, (c) searching and shopping mashups: searches different content provider for a product, compares their offered prices and gives up with a optimum result to the user, (d) news mashups: uses RSS or ATOM syndication and disseminates news feeds to the users  .
2. MASHUP SECURITY
Mashup is concerned with integrating content/services from different sources into a new services and therefore creates new security issues like who made the information to be combined available? What are the intentions behind the availability (e.g. commercial reasons etc)? What is the trustworthiness of the content available? etc . Security issues can arise either from the security problems or loop-holes of the technology being used or nature of the mashups to be performed .
The security model Same-Origin Policy implemented by browsers also creates problems for mashups security; SOP uses origin to classify documents: documents belonging to the same origin can openly access each other's contents whereas documents from the different origins are not allowed to access; origins are recognized by hostname/Internet domain, protocol along with port . SOP imposes some restrictions on scripts and violation of any of them can result in security breach :
One origin script should not be able to read or write content to another document or frame belonging to another origin.
One origin script should not use XMLHttpRequest to communicate with a site with another origin.
Scripts' access to cookies and browser plug-ins is restricted by the Same-Origin Policy.
iframe tag was introduced to solve the problems  but still there are several ways to attack browsers: most well-known are Cross-Site-Scripting (XSS) and Cross-Site-Request-Forgery (CSRF) .
Techniques used to create mashups completely ignores the SOP( Same-Origin Policy); therefore needs a new security framework to be built, where issues like user privacy, data integrity, data confidentiality, and user authentication are needed to be addressed .
User Privacy: User entering content to a web page may be wishing that they should be available to a particular web site and not to any other unwanted parties.
Data Integrity: The user should be guaranteed that the content received by his web page is not corrupted by any untrusted parties on the way before receiving, in other words, the user will receiving the content as it is send by the sending body.
User Authentication: The communicating entities may wish to guarantee and verify the identities of each other to build trust measures.
Data Confidentiality: The communicating entities may wish to guarantee that the content being exchanged should be readable to them only, any other third party on the way should not be able to disclose the content of a message.
.3. PROPOSED SOLUTION
As two of the most common attacks on mashups security are XSS and CSRF. XSS can be avoided by specifying session timeouts or regenerating session identifiers with each request and CSRF can be avoided by enabling servers not to accept HTTP GET request, which is practically impossible, therefore, another way is: a token should be transmitted to the server with each HTTP POST and GET request . Most of the current research work basically focuses on providing solutions to XSS and CSRF, whereas, the issues of data integrity, data confidentiality, user privacy, and user authentication has not been addressed explicitly and might be left for the web protocols or technologies used for sending, receiving, and storing of data. It is, therefore a composite framework is needed that will take into account all these issues. Using of cryptographic techniques can help us in this regard.
The proposed solution considers server-side mashup architecture, where the mashup components are combined on the server and users requests them for data providing. The proposed solution uses cryptographic techniques. Proposed architecture consists of two phases: Phase 1 and Phase 2.
3.1 PHASE 1
Phase 1 consists of three steps (three-way handshake) taking place between user and mashup server shown in Figure 4.
In step 1, user sends a message consisting of a request along with user ID, users' public key and a nonce ( a number generated with each session request uniquely and to provide guard against replay attack). The message has been encrypted using the public key of mashup server (available to the user).
In step 2, mashup server responses with a message encrypted using users' public key, where the message contains request-specific array of tokens for the user, session timeout policy, session ID, a nonce (unique with each user unique request) and a function applied to the nonce send by the user (showing that the user request message is received and correctly interpreted by the mashup server).
In step 3, user responses with a message encrypted using mashup servers' public key, where the message contains a function applied to the nonce send by the mashup server (showing that the server message is received and correctly interpreted by the user), and request specific array of tokens send by the mashup server for the user (showing that user has agreed upon on the server selected request-specific array of tokens for the user).
The basic reasons of these three steps is the introduction of user to the server as well as the transmission of some control information selected by the Mashup server for the user such as session timeout policy, session ID and request-specific array of tokens which can be used for useful functions such as session time out policy specifies the session termination policy that can be used to guard against XSS attack and request-specific array of tokens can be used to guard against CSRF attack.
3.2 PHASE 2
Phase 2 consists of two scenarios a bit different from each other as shown in Figure 5. Figure 5 (a) shows transmission of user request to the mashup server and Figure 5 (b) shows mashup server response to the user request. Both of them uses PGP (Pretty Good Privacy) protocol that is commonly used with email, but Figure 5 (a) slightly modify it for the transmission of token information. PGP is basically aimed to provide data
Figure 3: Server-side Mashup model
Figure 4: Phase 1 -- Exchanging of control information between user and mashup server
confidentiality and user authentication and that is what we actually want to achieve through its usage as well as other objectives.
DATA AUTHENTICATION AND USER CONFIDENTIALITY
User authentication and data conditionality is required for the protection of information to be communicated and is achieved in similar way in both of the scenarios.
User Authentication: On the sender side, the hash value calculated is encrypted using the private key of the sender (KRA), the encrypted hash value is decrypted using the public key of the sender (KUA) at the receiver side.
Data Confidentiality: On the sender side, sender selects a session key (Ks). Encrypt the concatenated message using the selected session key. The session key is also encrypted using the public key of the receiver (KUB), and is combined with the encrypted concatenated message to be transmitted to the receiver. On the receiver side, the receiver first extracts the encrypted session key and decrypts it using the private key (KRB) of the receiver. The encrypted concatenated message is then decrypted using the decrypted session key. Thus an unauthorized user having no knowledge of the concerned keys, thus if he/she catches the message on transit would not be able to decrypt it and disclose the message contents.
Figure 5: Phase - 2 (a) Request from user to mashup server
(b) Response from mahup server to the user
Again achieved in the similar way in both of the scenarios. On the sender side, the hash code is generated using SHA-1, which is then encrypted using the senders' private key (KRA). The encrypted hash code is combined with the original transaction message and send to receiver. The receiver side separates the hash code form the message, decrypts it using the senders' public key (KUA). At the same time, the receiver will also calculate the hash code of the received message using the same SHA-1 algorithm. If the calculated hash code and the decrypted hash code are the same, the message received is accurate (as it is as that was send by the sender) otherwise some problem has been occurred on the way.
CSRF attack has been initiated on the mashup server. SOP, user name/password, cookies, and SSL will not provide protection against CSRF attack; therefore, a request-specific token should be included within each HTTP GET and POST request to protect against CSRF attack . A request-specific token is associated with the message by the sender as shown in Figure 5 (a), which is verified by the receiver and if found correct the message is accepted otherwise rejected. Response from the mashup server to the user is not needed to use token as shown in Figure 5 (b).
4. CONCLUSION AND FUTURE WORK
A new era in the web has been started by Web 2.0. Instead of creating web application form the scratch, relevant content can be extracted from the online available sources, they can be mesh together and presented in a unique way. This new phenomenon can pose many security challenges that cannot only be limited to cross-site referencing but others such as data integrity, user authentication, and data confidentiality are as well of very importance. The inherent security model (Same-Origin Policy) implemented in web browsers as well as cookies, and SSL etc cannot deal with these security challenges, therefore, a new security framework is needed.
This research paper presents a security framework through using cryptographic techniques that can be used in server-side mashup model and will provide solutions to most common mashup security attacks such as CSS, CSRF, and other security issues discussed above.
But, the story has not been ended here. There are certain other parameters such as access control, and non-repudiation which are also essential for a systems' security. In the future, it has been desired to extend the proposed framework to accommodate these security parameters as well.