Secure Frame Communication in Browsers Review

Size: px

Start display at page:

Download "Secure Frame Communication in Browsers Review"

Christian Norris
6 years ago
Views:

1 Secure Frame Communication in Browsers Review Network Security Instructor:Dr. Shishir Nagaraja Submitted By: Jyoti Leeka October 16, Introduction to the topic and the reason for the topic being interesting It is common to find content from various sources embedded within a given website. Such a website is called a mashup. The software which performs this binding is called the integrator and the data which is embedded is called the gadget. There are two types of mashups which are mentioned below: 1. In this the integrator does not communicate with the mashup. 2. In this the integrator communicates with the mashup. In this paper the authors try to explore the problem of separating trusted and untrusted web applications but simultaneously trying to establish secure communication between them. Though browsers same origin policy does not allow the data in one frame to modify data in another frame. Yet the same policy cannot be used for one frame trying to navigate another frame, as navigation is essential to support communication between frames.the attacker takes advantage of such a policy of browsers to attack this communication,such an attack has been demonstrated in the paper against Google AdSense login page and igoogle gadget aggregator. The paper explores ways to make the browser s frame navigation rules stringent and simultaneously accommodating present websites. The topic is interesting as there is an increasing need to protect user privacy while the users browser content from sites containing third party content. 2 Questions that the paper asks and how are those questions interesting The paper explores ways to make the browser s frame navigation policy stringent and simultaneously accommodating present websites. The question is interesting as there is an increasing need to protect user privacy while the users browser content from sites containing third party content. 3 How does it answer the questions The paper answers the questions by first describing the Threat model employed. The Threat Model is given below: 1. Web Attacker: A user uses the web browser to view content from trusted websites. An attacker breaches the users privacy by changing the state of the web browser to disrupt the users session. The threat model defines the web attacker as the one who has some computers and a server under his control. The following are the capabilities of the web attacker: 1

2 (a) The web attacker may play the role of an client or server. The authors assume attacker.com to be the web attackers server. The attacker can operate over HTTPS as it has obtained the digital certificate from a certification authority. Man in the middle attack is ruled out from this attack model. (b) The web attacker is confined to the browsers policy and does not do anything to bypass this policy. 2. Gadget Attacker: The gadget attacker has the capability to force the integrator to embed a gadget of its choice. The following threats are not included in the threat model: 1. Phishing: The attacker in this threat model does not try to get users information by masquerading as a trustworthy website. Hence this threat model rules out phishing. 2. XSS or Cross Site Scripting Attacks: The attacker in this threat model does not try to inject malicious scripts into web pages viewed by other users. Hence this threat model rules out Cross Site Scripting Attacks. Web applications can embed frames from third party content. The frame whose URL is displayed in the browser is known as a top-level frame. Whereas the location of subframes is not shown in the browser. The lock icon is displayed in the browser only in the case when all the frames are using HTTPS protocol. Most the browsers adopt the same origin policy, whereby the web pages belonging to the same website are permitted to access each others functions and properties. For performing navigation between frames the author states that the browsers prior to 1999 adopted a permissive policy, which states that a frame can navigate any other frame. Due to the permissive policy of the web browsers which gives any frame the capability to navigate any other frame, an attacker can navigate an honest log-in frame, replacing the login frame with the attacker s login frame, which is alike to the actual log-in frame. Thus the attacker is able to get the users account information. In order to circumvent the loopholes in the permissive policy of the web browsers, Mozilla implemented a stringent policy known as Window Policy. According to the Window Policy a frame has the capability to navigate only the frames in its own window. This policy was adopted to prevent an attacker from navigating frames belonging to an honest website. The loophole in the Window Policy is that it assumes that an honest principle will embed only honest frames. But practically this does not happen, as shown in the scenarios below: 1. Aggregators: igoogle, My Yahoo, etc embed third party content. Such sites are called mashup. These mashup depend on the browsers policy to protect them from malicious third parties. 2. Advertisements: Sites embed third party advertisements into their top frame. Hence such sites are also mashups. Such sites also depend on the browsers policy to protect them from an attacker, who controls the advertisement frame. Since the mashups do embed content from malicious third parties, hence this gives the attacker the ability to perform a gadget hijacking attack. The below mentioned are the ways in which an attacker may exploit the mashups vulnerabilities: 1. Exploiting Loopholes in an Aggregator: Consider the case when igoogle embeds the login form of a bank. In order to carry out the attack, an attacker may replace the bank s frame with his gadget, and thus steal the users credentials such as passwords. 2. Expoiting Loopholes in web pages containing advertisements: Any attacker s advertisement frame can potentially navigate the other advertisement frames to his frame, thus taking away the other advertisers impressions. Some of the policies adopted by browser vendors are mentioned below: 2

3 1. Descendant Policy:In this policy, a frame is capable to navigating only its descendants. In this policy the child frame is prohibited from navigating its parent frame, but the vice versa is possible. However, the loophole in this policy is that a frame can navigate its siblings by writing malicious code into its parent. 2. Child Policy: In this policy, a frame is capable of navigating only its children. In this policy the parent frame may navigate only its child frame but the vice versa is not possible. The loophole in this policy is frame can still draw over its grandchild frame. Also this policy is not compatible with many sites, thus reducing its applicability. In order to overcome the loopholes present in the above two policies the author suggests that the browser should accept a frame s navigation request only if current frame s origin is the same as that of the requesting frames origin. In order to verify this policy of origin propagation the authors implemented this policy in Safari, Firefox, Flash and Opera. Yelp is a website which embeds Google Maps to show the location of business centers. Google Maps can be embedded into Yelp s top frame in two ways: Frame or Script. In order to display locations interactively Yelp needs to perform a high percentage of inter-frame communication with Google Maps. There are many websites like Yelp which need to perform inter-frame communication. Thus in order to perform inter-frame communication, two methods are employed which are mentioned below: 1. Frame Identifier Channel: An example of how messages can be communicated between frames is (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.): Suppose the current value of frames[0].location is: frames[0].location= Now a message can be passed to this frame by adding the message after the # sign: frames[0].location= ; The above way of passing messages between frames is known as inter-frame communication through a Frame Identifier Channel. The frame identifier channel does provide confidentiality but not authentication. The author explains the channel by drawing an analogy with a public key channel. This analogy is described below: Microsoft uses Frame Identifier Channel for inter-frame communication in Windows.Live.Channels API. Microsoft employs the following protocol which is analogous to the Needham-Schroeder protocol (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.): A ->B: N A, URI A B ->B: N A, N A A ->B: N B, Message 1 Here A and B are frames, N A and N B are random numbers and URI A is the uniform resource identifier of A. Frame Identifier Channel also suffers from Lowe anomaly, which was also present in Needham- Schroeder protocol. This anomaly is given below (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.): Integrator ->Attacker: N I, URI I Attacker ->Gadget: N I, URI I Gadget ->Integrator: N G, Message I In this the attacker in the guise of the gadget takes N I from the integrator. The attacker then gives this value of N I to the Gadget and passes the value received to the integrator, the integrator in turn gives the gadget the value of N G and Message 1.Lowe s improvement of Needham-Schroeder protocol can be applied in order to circumvent this attack. Lowe s improvement states that each agent should include its identity while passing messages in the protocol. This improvement is mentioned below (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.): A ->B: N A, URI A B ->A: N A,N B, URI A A ->B: N B... 3

4 A ->B: N A,N B, Message i B ->A: N A,N B, Message j 2. postmessage Channel: HTML5 introduced the postmessage method. postmessage method is used to pass messages between frames. For example, in order to pass message, the sender calls the postmessage method as given below (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.): frames[0].postmessage( Hello ); An event is then generated in the recipient frame to indicate that a message has arrived for the recipient frame. Apart from the message this event contains information about the sender and a pointer to sender. The postmessage channel does provide authentication as the sender can be accurately determined by verifying the cryptographic signature, but the channel does not provide confidentiality, the attacker can thus exploit this weakness of the channel. Some of the attacks are mentioned below: (a) Recursive Mashup Attack: An integrator passes a message to an embedded gadget. An attacker can intercept this message by first loading the integrator inside a frame and then navigating the gadget to attacker.com, which then intercepts the message. This attack can be prevented by first checking if top!=self. If this condition is true then the browser should not render the frame, as the true condition indicates that the integrator is within a frame, and hence prone to attack. (b) Reply Attack: In this attack the Gadget sends a message to the integrator, an attacker can intercept the integrators reply by first framing the gadget and then navigating the gadget to attacker.com, which then intercepts the message. In order to secure the postmessage method the authors propose an API called CommRequest. CommRequest aids to provide confidentiality to postmessage, as CommRequest gives the message only to the intended recipient. 4 Methodology used to investigate the paper The methodology used to investigate the paper is a case study based approach. 5 What I learned from the paper I learned some of the modification which can be made to the frame navigation policy in order to make it secure. 6 How the paper relates to previous work The paper relates to the following previous work: 1. SMash (Reference: Subspace: Secure cross-domain communication for web mashups by Collin Jackson et.al.) is a technique which makes navigation decisions based on frame hierarchy and events. But this method is vulnerable to denial of service attack. Also it takes SMash 20 seconds to generate a response, which an attacker can take advantage of to launch a attack. In contrast to this the modifications proposed in this paper don t suffer from these disadvantages. 2. Another method to prevent an attacker from attacking mashups is to avoid using frames and to put the gadgets and integrators in a single web page by writing code for them safe subsets of HTML and JavaScript. However writing code for such pages becomes difficult as now the developer has to avoid all the pitfalls. The authors feel that frame based web pages will continue to be used because of the safer implementation of postmessage. 4

5 7 Strengths of the paper I like the analogy of public-key channel which the author gives for the frame identifier channel. The authors give the analogy of Lowe s anomaly in Needham-Schroeder protocol to describe the loopholes in frame identifier channel. I like this approach of the author as by understanding the anomaly I am able to understand the flaws in frame identifier channel and also the need to make it secure. 8 Weaknesses of the paper In the paper the authors state that browsers should adopt origin propagation. Then they the state that Additional navigations do not sacrifice security because an attacker can perform navigations indirectly (Reference: Secure Frame Communication in Browsers by Adam Barth et.al.). I find this statement contradictory as if the attackers can perform navigations then the application surely has vulnerabilities, which makes it insecure. 9 Results The authors propose improvements inter-frame communication methods namely, frame-identifier messaging and postmessage methods in order to make inter-frame communication secure. 5

Robust Defenses for Cross-Site Request Forgery Review

Robust Defenses for Cross-Site Request Forgery Review Network Security Instructor:Dr. Shishir Nagaraja Submitted By: Jyoti Leeka October 16, 2011 1 Introduction to the topic and the reason for the topic