 Hello everyone, so this is the title of the talk, last script is in serious and third party content with care. Sounds a little crazy I know, let's see what's about. So by the way, I am Fishnade Tanya and I work at security and privacy research lab at Info's lab. I have my microproff and gave you two. So how many of you have built mashup for finance? Okay, anyways let's see what a mashup is first of all. As the definition says, it's a web application which combines content from multiple audience to create a new service. It's like you have a service A and you have a service B. You combine both the services and you create a new service, that's a mashup. Okay, we'll see the examples shortly. And then the integrating party is called an integrator. The party combining the content is called integrator whereas the integrated content is called a gadget. So have you heard about gadgets? Gadgets, you heard about it right? And then what's the benefit of doing a mashup? It provides more value at than individual services. It's fun, it's easy to meet yourself and then it's all about JS madness. Okay, here it's about. So have you seen any of these? You've seen any of these? I Google, it's very popular. That's housing maps. Here it's like the, whether it's from some other website or some other origin. And then the gallery is from some other origin. It's from some other origin. You can copy everything and then you can create an application which gives you more value. Okay. So yeah, this is the Facebook widget. So anyone has embedded Facebook widgets in their web pages. And then if anyone tried to embed ads in their pages, at least Google ads and all. So if you have done any of these, you already created a mashup. So it's not something, it's not a new technology. If you have created any of these, you would have already created a mashup. Okay. So mashup and security. So why should we talk about security? First of all, what are the approaches in which you can build a mashup? The whole day we have seen a lot of sessions which are about JavaScript, maybe including JavaScript libraries, Ajax libraries or maybe data visualizations and all these things. So what is the common thing in all these sessions? It's like you try to get the third party JavaScript file and then embed in your web page. Right. So how do you build a mashup? It's basically one very good and very easy approach is to embed excellent JavaScript in your files. Okay. So what is script tag to some other.js file? So it could be a jquery.js or some visualization.js or anything. Right. So the easiest way is to point to an excellent JavaScript file. What is the other way? Loading content via iframes. So you know what iframes are? Vegetable iframe tag. Iframe src equal to you give the URL. So basically what an iframe does, when you give the src, you try to load a content from a remote page and then embed in that particular page. Those are basically iframes. So that's a very basic tag in this chamber. So interestingly, even iframes can be used to create mashups. If you go back and see this iGoogle, so this one gadget or widget. Okay. And then this is another widget. So you can visualize this as an iframe containing src equal to some other information. Right. So you have a couple of iframes in this particular page. And then if you see the other case where it's about Google Maps and having some data on it. For example, let's say I'm a newcomer to Chennai. And then I want to know all the petrol bumps near IIT Madras. Okay. So I can create an application like this where I have a Google Maps API. And then I put all the petrol bumps near I query, all the petrol bumps near IITN. And then I can plot it on a whole map. So there how do I achieve it? I achieve it using JavaScript. So I embed HTML JavaScript files in my web page. And then I can create a simple application like that. So you have iframes way of doing it. You have the JavaScript way of doing it. So there are basically two different ways of doing it. And then what are the requirements of any given measure? It's like you need an interaction between the different components. In this particular case, let's say you have a calendar control here. If you change the date in the particular calendar, or if you say tomorrow's date, I would be happier if I can get the weather of tomorrow. Okay. That's what I mean by interaction. Okay. And then communication. So if you have different widgets, they can communicate to each other. That would be really awesome. So that would be one of the major requirements of a mashup. And then security. So what are the problems related to security we see in mashups? Isolation of origins and secure data exchange. Okay. We'll end this well between these things very briefly later. So same margin policy. How many of you have heard about same margin policy? Okay. We need very good. Awesome. Actually, I'm happy with this. So more people have heard about SOP rather than mashups. Endless you'll come to the point. So what is same margin policy? Let's say you have two different domains. A script from one domain cannot access the DOM of another domain. That's basically what same margin policy defines. Right. So browser has to isolate different origins. Otherwise, what will happen? I have a hacker. I create an email gadget. And then with that email gadget, I can steal the information of your complete web page. For example, I have a web page where I have advertisements. How does an advertisement come into web page? First of all, by some external JavaScript file. Right. So I embed some, maybe Google's advertisement JavaScript file or some other JS file. So when I embed the JS file, that JS file is having access to my entire DOM. So if you're able to read your Facebook friends list, even that JavaScript file can read your Facebook friends list. And it can export to some other domain. Right. So how does browser differentiate between different origins is the main question. So there's a policy in browser called same margin policy, which tries to, does this task for us? Okay. By origin, what do I mean? It's key or protocol, colon slash, host, quote, quote. Okay. That's a good thing. It's as simple as this. HTTP, colon slash, wing dot com. So HTTP or HTTPS, they are different schemes or protocols. And then wing dot com, host and quote number. By default, it's 80 and then there you can see 81. Okay. These examples are from, these are different examples of different origins. Okay. All the three are from different origins. You can see there. Now, if a script is in a different origin, what are privileges does it have? Okay. Let me put it in a simple way. You're saying script src equal to some jql dot js. So what are privileges does this jql dot js have? Or in fact any other js file in your webpage have? It can have full network access, which means it can make index calls and then whatever a genuine, complex work you're doing, the same thing the script can do. Right. You can read and write access to the ROM. That's how jQuery and all the JavaScript libraries work. And then it also stores data. You can store data and DOM, maybe local storage or different mechanisms, cookies or whatever it is. So scripts of one origin cannot access DOM or another. That's the basic policy which is embedded in all the browsers. That's the reason why we are safe and secure at least to some extent. But then even there are workarounds in which this can be violated. So there comes the actual problem. The problem of security comes at this particular place where an SOP is violated. But if you observe strangely, scripts themselves are resulted from SOP. You can always create script src equal to google.com slash something.js. You can always do that, right? So when scripts can't access DOM or another, they can still be loaded from a different origin. So somehow this sounds like a content-free idea. In fact you can see in many of WS Crockford's statements, you can see these are common statements in many Crockford's videos. And then what else are eliminated or resulted from SOP? Any other guesses? Images. Awesome. So image, src you need not give to a genuine image. You can even give some JavaScript code and then that's how a type of accesses attacks are done, right? Image src equal to you can give some JavaScript code there. So even, yeah. If scripts are exempted from SOP, let's say I build an email gadget. You include the JS file from my gadget. What I do is I replace that your script with my same copy from my domain. Now I can access all the DOMs. See, when scripts are exempted, what I mean is, see, let's say you're the developer, you can always say script src equal to, you can load it from your own domain. Yes. Right? You can post the site in whatever domain.com, whatever it is. But then that particular page can load the JavaScript file from your domain, isn't it? Yeah. The statement which I said is exactly the same point. That is not what he was asking. You have a JavaScript, you are creating some DOMs using your JavaScript. Yes. You load my JavaScript. I mean, you use my JavaScript for a plugin. Okay. Okay, what I do is I delete your JavaScript and... How do you delete it? You said that the DOMs are accessible, right? It's good. Okay. Through your JavaScript you're saying... Yeah. Through my JavaScript, I delete your JavaScript. Okay. But I have a copy of the same JavaScript in my domain. Okay. I load that. Okay. I have a change. Yes. But I was able to access your domains. All right. Your DOM elements. Yeah. That's what I'm saying. See, when I'm embedding your JavaScript, I'm trusting you, right? Okay. How should I trust you? That's the whole point of security there. Okay. That is what you were saying. So, the script is not perfect, right? No, no, no. See, it's like I'm trusting you and I'm embedding your script. The script still loads from your server. But it executes under my context, for the user's context. Okay. See, as per SOP, even if it shouldn't even load from your server, if it applies to a script, but it loads from your server, but executes in the browser's context. Okay. Right? It's as if... So, it creates a cookie from a third-party script also. It will go in your domain, not the third-party domain. Exactly. So, it's executed in the context of the user who is using it. Essentially, script is nothing like... It's working the same thing as the user. Okay. Right? That's the whole point. Okay. Good that you brought this earlier because now, at least, the context can be that clear. So, similar to script, you may just... Even they do the same thing. In fact, if I'm src equal to, you can point it to some other domain. So, all these are like violations of the same origin possible. Okay. So, coming back to the ways of building mashup, one approach we said is script-based approach. Right? When we embed external JavaScript file into our web page, and then we do some coding there. The benefit this one has is very good interactivity. For example, you can see, on Google map, you can plot some petrol bugs, and then you can drag and drop all this. So, the benefit is like... We can clearly see the benefit. It's very interactive. But, the only problem is, as he rightly said, we are assuming that the script is from a trusted source. It may not be from a trusted source. Okay. I'll trust Google, or I'll trust Yahoo, or I'll trust all the big companies. But, I don't know whom I should trust. There's some guy who's saying, okay, my job is to do this job for you. I'm trusting that. Okay. That'll do. Just say, and then I'm including it in my web page. But then, it could be insecure or it could do all the malicious things like that I just said. Right? And then, no isolation of origin. Okay. Okay, let me call these ones. Embedded scripts have religious of important page, not the source server. So, how many of you have tried something like openfacebook.com, paste this script in the address bar, and then you'll be able to see who all listed your profiles? Did you see anything like this? There are a lot of... I think it was more popular in the awkward days. Exactly. It's popular in the Facebook days also, but it's in a different way. It's like this, some flash movie is playing. It's like, it looks like YouTube, but not exactly YouTube. So, when you click on it, there's some JavaScript file which is copied into your flipboard. And then, you'll say, put your cursor in the address bar, press J, and press Ctrl-V. And then, hit Enter. Basically, what he's trying to do is, he's making you copy and paste the manuscript in your address bar. So, it's like a different way of doing it. So, it's still popular, right? We do... I mean, at least, out of the video sense, we try to do such kind of things. So, what happens is, you do all sorts of different things, and then you will say, on your watch, you will see some things like, okay, this guy has brought a free Facebook t-shirt. Why don't you try this? Or maybe, oh my God, how did she do all this in company? These kind of things we never really see. So, how does all that happen? It's because the embedded scripts have the same privileges of the equal-to-place source server. So, the scripts are originating from a malicious server, but then they're executing the browser's context, right? So, that's the main problem of embedding scripts in your web page. Of course, they offer the very good benefits, but do you press them? That's the important question you should ask. And the last example that we have is, ads, widgets, execs, libraries, all have the same rights, right? So, if you're using an execs library and doing some very good job, the other kind of scripts we use by widgets as well as ads, they also can do the same good things, all the same bad things. But do we ever care about this? I'm not sure. We don't care here. As long as our work gets done, okay, that's fine. Yeah. So, he's a guy who almost all the JavaScripters respect Douglas Rockford, he's the JavaScript architect at Jamco. So, these are the quotes he himself had in most of the presentations. So, these are really interesting. SOP prevents useful things, allows dangerous things. It's clearly an interesting thing. So, what useful things it prevents? Obviously, cross-out in the execs course would be useful, but then that's stopped. So, that's a useful thing. Then, dangerous things, allowing images and allowing scripts to load from other domains is a dangerous thing. And then, if they just spit from two or more sources, the application is not secure, period. So, he says, it's okay. So, if you're having more than two JavaScript files, your application is not secure. So, whatever is the benefit you get, he says it's not secure, which is true. We know that it's not secure. For at least, we don't care about the security part of it, but we try to get things done, right? Fundamentally, as I said, this is a conclusion of interest. This is really interesting. So, what is the confusion about? You know what access is, right? Cross-site scripting. So, you have a text box. You don't sanitize the input. If I say, script alert high, and then it enter, boom. I can get that alert on my web page. That's basically a basic access example. So, fundamentally, access is a conclusion of interest. I know that access is evil. Cross-site scripting is evil. I don't want it on my page. But at the other end, I know match-ups are useful, and I create match-ups by putting different JavaScript files on my page. So, it's like, you guys are interested in this, you guys are interested in this. So, it's a confusion of interest basically. That's what it tries to say. Then, a match-up is a self-inflicted access setup. So, all of us know that it's an access setup indirectly. But then, we try to create match-ups. That's what it tries to say. The point is, it doesn't say that match-ups are bad. It says, match-ups are the things we changed under a web platform, which was not seen in 20 years. Match-ups brought a change. That's what it says. But the point is, it's being done by language, which has several bad parts, as well as developers who don't have a complete idea of the specificity of match-ups. That's what it tries to say. I think all of us respect all these points, right? Obviously, we can't negotiate or, I mean, we can't say no to this because he's a master in whatever he has seen. I think it's very much perfect. Then, script isolation. So, if you have seen Facebook, we try to enter different types of comments and all. Or, if you have ever tried to inject a script tag into it, ever tried to have Facebook, insert script elements into it, whatever, have you ever tried that? We try to keep all the good comments. But even if you try to insert a script tag and say, not hi or whatever it is, you still get it as script only. You actually see script executing inside Facebook. Why? Because Facebook is doing something very good. So, he says, okay, sorry. So, script isolation is... Now that we know JavaScript doesn't have any isolation of origins, there should be some way in which one origin has to be protected, has to... should not attack another origin and script should isolate each other. So, how do we do that? Restricting JavaScript to a subset. So, what is a subset? So, it is like agreeing that JavaScript has certain bad parts. We create a subset of JavaScript which does not have all the evil features. Okay, that's why I'm trying to say restricting JavaScript to a subset. So, how do we do that? There's something called Object Capability Security Model. I know it's a very... So, but take a term. So, the idea is very simple. Let's say, okay, if an object in JavaScript has no reference to XML, it has to be requested. And as I said, it cannot be made. For example, you have... Okay, you can say, we are obviously equal to new image. When you are not able to create new image, you can't access anything related to that image. So, that's what I'm trying to say. If we can build a language using this Object Capability Security Model, it does not have all the features of what actual JavaScript has. That's what this particular thing says. So, what are the popular JavaScript subsets? Google, Kaha, it's pronounced Kaha, C-A-J. It's very popular. And then, F-B-J is Facebook JavaScript. And then, Accent. So, these are the different JavaScript subsets which are available. So, what do these basically do? They try to rewrite. So, whatever JavaScript you write initially as a developer, maybe create new government. Do an exact sequence, get some data, map it, put it into your DOM. You do all sorts of things. But then, what do these JavaScript subsets, what do they do? They have a compiler which will translate your entire code into a safe subset of JavaScript in which you don't have access to objects like this. Okay? You don't have access to this object. You don't have access to such kind of things. But why these JavaScript subsets click very well as compared to the other parts of it? Because of the running curve, and usable issues. In fact, even the JavaScript compiler is, even they are like working. And then, I think, as the compiler is for Caha and all become more user friendly, I think this option is like a very good way of creating new subsets. Yes. So, what do these suppliers do? They take your JavaScript and verify that you are not using its industry request. They throw an error and use that or something like that. Yeah, exactly. So, it's like, they take your JavaScript, they do complete rewriting. They do static analysis and then, they do complete rewriting of the JavaScript so that you don't have access to basic objects like example history. It does a couple of things. It also does some level of sandboxing also. So, make sure you're not polluting the globals and all. It essentially rewrites a lot of stuff. It's a development time thing, though. Yeah. No, not at all. No, no, no. So, it's kind of both. So, it's like, you can also take third-party modules, at least the ones I know, Caha and Archive. They kind of try to rewrite your code even for third-party. Okay. So, if you're looking for script isolation, ideally, when you're including JavaScript files in your page and you know that there's a possibility of attack, ideally, you should have done this script isolation by using these JavaScript subsets, but we never care for this. That's another, that's a different query altogether. And then, isolation with frames. Okay, we have seen that one type of matchup can be created using JavaScript, whereas the other type of matchup is like iGoogle, and you can use it in the same way the other type of matchup is like iGoogle. You can create by frames, right? Each widget or gadget is like an iframe, and then they can talk to each other and then exchange data and all these things. So, the benefit of using frames is you have a well-defined, separate security context for each origin. Like, each iframe is like a different sandbox, and then one frame, the script in one frame cannot talk to script in another frame. So, by this, we can say that frames come like the same origin policy. For example, you can see the script here. If you can say SRC equal to the same page in the same domain, okay? And then in JavaScript, you can say frames of 0.content.com.body, which means you are trying to access the content of that particular frame. If it is from the same domain, it is allowed. If it is from a different domain, this script is called such as cross-domain.com. The same code will not allow, you will get an error, you will get security error. So, that's because of the same origin policy. So, one good point with the frames which we have seen is they complicate the SOP, and they can clearly separate different origins. Whereas, JavaScript can't separate different origins. That's the main difference we have here. But then, frames also have a particular problem. This is likely misunderstood and requires a little inter-contest standing. Frames can also be navigated to different origins. Frame navigation is not the same as same origin policy. Now, I think many developers get mistaken in this second point here. Frame navigation is not the same as same origin policy. It's like you have frame SRC equal to some URL here. You can't read the SRC using some remote script. You can't read this SRC attribute, because that's a same origin policy restriction. But what you can do is you can always redirect that SRC to something else. This is not a part of same origin policy. This is something defined as frame navigation policy. This is like increment in all the process, but this is not officially documented anywhere. This is a research lab, and then they publish a research paper which is there in the differences. So, you can see that. So, there were this frame navigation policies. In fact, all the process follows this. Now that we know frames separate different origins and also frames navigate each other. What are we saying? Can script in frame A modify the DOM of frame B? Is this possible? If they're from different domains, it's not possible to go to the same origin policy. But can script in frame A navigate frame B? Yes. You can always do that. So, this is not same origin policy. The next set of slides are based on this particular point. So, are you clear with this? Cross window attack. So, this is possible. I think in maybe I7 was just released or something like that. In fact, it's possible in all browsers. Since I don't have any screen shot or something, I'll definitely look it from the standard security in people's equity. So, it's like you have an advertisement here, and then you have a login form there. Right? If this entire thing is directly JavaScript, what can this advertisement do? As you type the email ID and password, you can actually look into the DOM and you can get your details. Right? So, a good idea is to embed or include the data login form in an I-frame. If this particular login field is in an I-frame, then the script cannot insert into it can't access the DOM of the I-frame. That should be a secure case. But how is that secure? Because the ad has been loaded with the script from a different domain. That's the idea. That script is still running in the same context as this stage. And that I-frame, okay, so you're saying the I-frame should be loaded from some domain other than Google. Subdomain. You have to change the domain in the I-frame. I-frame must be a different domain. Subdomain should be fine unless you have domain relaxation and things like that. Subdomain should be fine. But the problem here is since frame navigation is possible, this ad can navigate this frame to a different frame. Now this like a phishing, a typical case of phishing, this is called frame phishing. Now in this case what we can do, what this guy does is he redirects it to an attacker's page and then whenever you enter your credentials you're actually entering the credentials in there in an attacker's page, okay? There will not be any leader action, no history button, nothing, everything will be the same because it's already a frame redirection there. So this is called cross window attack. This was due to some question. This is due to some wrongly implemented policy in the browser, okay? After these set of attacks okay, this was finally patched and I think it's patched long ago, okay? Now this doesn't work if you're trying to do this in the same thing. Okay, this is already patched. Another type of attacks came. So when matchups were first developed, like for example like Google, you have different gadgets here and then these are legal gadgets. Now you can write some script and then you can navigate all the gadgets to legal gadgets. Now this is like dangerous. Yes, sir? This is a pretty good example. How is it patched? I mean, because the policy still allows that. I'm going to the point. There are a couple of slides there. Okay, so these were the set up. Sorry? Yeah. So this is cross window attack. This is possible because of one wrong call in the browser. This is patched. Again, after that patched a new type of attacks came. Same window attacks where one gadget can redirect the brains of other gadgets. Now this also patched. So what's the actual problem? So they seem to be some problem other than same origin policy. Right? So am I trying to hear? Able to follow through here? Past, slow? Okay. You said in same origin policy something can't access other domain's DOM element. Right? Script of one domain can't access those script of another DOM. Other domain. Okay? So this evil gadget is one domain and the other gadgets are other domains. Right? My frame is Google domain. Okay. So how can evil gadget access Google domain's DOM? That's what. You're not accessing the DOM. So if I'm able to access the content inside this. Okay. You're just navigating it. Okay. Okay. If I'm able to say if I'm able to read this gadget. element or do something then that's variation same origin policy. I thought the element or source is also reading kind of thing. No, no, no. So only that we are navigating this to an evil gadget. Okay. So even more dangerous, right? So you can create some fake login problems or whatever and you can steal your data. Right? You navigate, can I navigate from other DOM and frame? Let's say I have an iFrame which is from the same domain. Okay. And I have five more and it's from the same team. Okay. Like I can navigate the other's iFrame from a different DOM and iFrame. So you're saying it now? Yeah. This was possible previously. Now it's not possible. This was possible previously. See all these gadgets are from different domains. Okay. Now this guy can navigate any other guy and it's kept on the domain. He can't even be able to access that I think I'm right, from the other domain. How could he change it that way? When he says that iFrame of zero, it will throw error, right? No, he can access the parent, right? Top dot, he can access. Okay. When he says top dot, you get all the elements inside that top domain which is the parent, right? Now he has access to the parent. Now he's saying parent dot iFrame of zero iFrame of one or whatever. Right? But it's possible. Is it possible? Yeah, it was possible. Top is always accessible even if you're from different domain. Yes. Not all the properties with some properties of it. Some properties like location can be accessed. Exactly. That's the entire concept of neavigation based on that. Right? So, we are hopefully aware of this. So we are not accessing the content inside this. We are already navigating this. It's possible because he's accessing his top then top dot, framework, location or whatever it is. Right? So what are the real culprits? So here is the main culprit. There's a policy called Commissive policy. What it says is, okay, imagine this outer box is a browser window. Okay? And imagine the inner box is a iFrame. And this arrow means this fellow can navigate this fellow. Okay? So, reduting this particular way. So, if you see the last one, you have two different windows. Okay? And then the second window has an iFrame. Now, this window can navigate the iFrame of this. This is cross-window attack. This is what we have seen in the first window. But we need to have to get a handle of the window. All right. Window doesn't open. So only those windows? Right. Okay. But you can't only see the window open, I guess. That's the only way you can get a handle of a window, right? Yeah. We cannot get a handle of the window. The opening browser is the only case. If a browser gives you a way of getting handle to other windows, that will be rather scary. Yes, of course. You can just open a window that has a Gmail and read all the content out of it. At least I haven't read it. At least I never had read it. I think it's only window to open it. Yeah. Because it's like opening browser contest. So that's really the only way. So let's say this guy opened this window. This window is opened by this guy. Even that is sufficient, right? And at this moment we have to handle this eye frame. That's even dangerous, right? So this is cross-window attack. If we have seen that this is passed. Now this is a window having two eye frames. This is another eye frame. So it's like nested eye frames. Descendants. Now this parent can navigate child one as well as child two. Okay. This is another case. And in this case you have only an immediate child. You don't have a descendant below the child. Right. Only one child here. So this is called curvy suit policy which means an application, a premium application in any of this case is possible. Okay. So a quick question Krishna. Yes. So let's say I have my ad network also. Can I just migrate all the other people's eye frames to my domain? Sir, my ads on their eye frames is it possible? Now. No, it's not possible. They fixed it always. This is existing if something like that would be really cool. I can run my ad network much better way than that. In fact, many have become millionaires during the days of, you know, I have to end all these things. Okay. This is fixed in all the cross window attacks is possible. They eliminated this off and then they had only these three things in place. So this is the window policy. This was existing till some phase, but again they said same window attacks is possible. They have knocked out this one. This is the descendant policy. So you don't have the last two ones here. You don't have cross window thing and the same window attacks here. This is a descendant policy. All the let's say a new presenter is coming up. You can follow this policy. That's what W3C says. There's also something about China policy. It even doesn't allow the descendant navigation. But there's a problem here. If you don't have a descendant navigation, it will be like too strict or almost all the communication will be breaking here. So they said let's maintain compatibility. Let's not be too strict. Let's follow the descendant policy. So that's what finished. So that's what they defined this descendant policy to be followed. One more thing. Nothing is in the hands of photographers. All this is in the hands of browser vendors. What are the huge fears for the descendant policy? As in the second part, there's a child policy in mind. You're asking about this one? Yes. It's different actually. Yes, I can actually I can think in the terms of attack on it. No, I just actually there's okay. There's a concept called some space. Okay. So before the post pieces came I came about a smash. They came with a a product. Okay. So what does this? Let's say you have content from two different domains and then you need to exchange data between domains. There's no genuine way of doing it. So what did it is? Let's say it's from a sub domain of Facebook. Now you can relax. There's something called domain relaxation. You can relax that sub domain and then you can exchange data between these two. Now this becomes a data object. Using similar thing, let's say you're having a partner. You can have partner.facebook.com. That is this one. Again you go to domain relaxation and you can exchange data between these two. What's the point? So it's like a a broker where this guy is trying to get his product. So other than that I can't see any genuine use case where this will be used. But then it's a particular point which I'm going to show in time. Yeah. Five minutes. Oh so so many things to cover. Okay quickly. So fragment identifier messaging. So all of us know this. We use something called hash message. We use this for communication. So previously how to do two different friends communicate. It's like if I can have it passed the other way. So previously before instrument post message came this was the way which two different friends communicate with each other. But then once instrument came we have a lot of good things. For them we have post message API. Using post message API you can post data one way frame to another way securely. Could the window.name hack could be used for transferring data across if you have a frame can you say frame window across. In fact that used to be one of the ways. You won't get an event like hash change on it but you can use it for transferring. In fact there's also this resize event. People try to resize when you resize the window resize event will be fired. Even using that we can exchange data. So all these are different hacks but then not so popular because the amount of data if you use if you interchange is like really less. So post message using this you can exchange a lot of data. You know to whom you are actually sending the message for example post message you have post message message and target origin. So you can say whatever message here it is then you can you can have your target origin like this Hello partner and then you are secure because you know to whom you are transferring this particular message right and then there's no but from this you also have this Sandbox and CRS specifications in HTML5 so what does this Sandbox thing do it will it takes a write listing approach for example when you say write listing Sandbox it will not allow scripts form submissions form works it will not do all this it will not allow all this kind of things so it's a write listing approach wherein say you want scripts and respect to E-Altern has support for these Chrome existing version supports all of these in fact Chrome is the first one to support I think this one Sandbox are not secure and then okay so we have Ajax here we have Site-A and the server of Site-A Site-B server of Site-B now this this blue communication is Ajax from a browser now this this one is the CRS specification one problem see the frames have now if you frame an application you have all very good benefits but the only problem is framing attacks where this clickjacking is there you know you heard about clickjacking so there's a dangerous way in which your clicks can be stolen in fact all your Facebook spams are due to this clickjacking stuff and then there's frame phishing attack we have seen then I go we have to yeah okay so this is the partner website so this is my partner's website it's posted on board number 81 so this is a different domain from my actual website okay so my actual see here it doesn't have anything just says the part of website this is my actual website okay now I want to communicate to my partner the same thing which I have shown so if I say hello partner or this is a poster fine now coming back to the dissonant policy which I have said where you have nested frames approach you have the nested frames approach now this is this is the same site this is my actual site and this is my partner okay now what I have done here is I have grabbed the entire site in an eye frame okay now this is the this is actually an eye frame here you can see the border here this is actually an eye frame this blue one is the actual site but this one is the parent site but since I am opening the entire thing in an attacker window okay now this attacker is redirecting this gadget to an evil gadget it's because of dissonant policy now this guy is redirecting to this guy right now you have an evil gadget here yeah so click that in let's say there's some site where you can vote up I am voting it up votes 1, 2, 3 whatever I go to a feedback site how is this session going on manually then I submit so what it is happening see because there's a little button there it's actually an eye frame which it's containing the other site the previous site so this is a simple click jacking okay so actually this is an eye frame this contains the previous site so in a way the vote up button is above the submit button similarly you can also do in the JavaScript way I keep super like in this and then I come back to my page and I refresh it votes got English now what happened here can you see this button here below my cursor you can completely hide it and nobody will notice yeah that's how click jacking does that's how whatever I click there's gonna be a vote up yeah wherever I click I'm just going to vote up right so I can increase my session this can be a Facebook like button also you can just get I have a Facebook like button demo not for the vote but still like my code like my session okay I don't have I don't have internet access but then if you can see the code of this it actually has like button here when you click it like for Facebook so these are the craving attacks which are there so you should be careful of these craving attacks and then so the best summing up quickly of using measures you have to use you have to go for JavaScript subsets if you are using life frames you have to take care of all you have to use all the HTML5 specifications and also take care of HTML5 the craving attacks that's the security of doing our measures so that's it Krishna can I add something to this sure sir so the thing is Krishna's talk precisely about if you are a consumer of a third party script or third party library and all and he precisely covers most of the most important points but let's say if you are a producer of a third party library and you want to write a third party component that others can consume there are a series of articles by one of our regular presenters Rakesh just look up for Rakesh by third party library if you are building third party widgets go through that as well he did that in Pune and Bangalore he couldn't come to Chennai because of some personal work but go through that that will be a really good complement with this talk yeah five minutes five minutes extra thanks Krishna