 So we go on to the next session. We are a little bit late for this thing, but software vulnerabilities. The next part of your lab will be on web security. So we're going to focus on SQL injection. So before that, just a few things. High assurance software. Can you provide it? So you might have seen this stuff before. What are some of the well-known software vulnerabilities? One of the oldest and best known, Buffer Overflow. Especially for web applications, cross-site scripting, SQL injection, in general C applications, format string attacks, and so on and so forth. What about phishing? What about malware attacks? Are they related to all this? What is your answer? So we're going to talk about malware in greater detail tomorrow. But phishing attacks more related to social engineering. And what about malware attacks? So there's a special class of malware amongst the Worm family called internet scanning worms. And most of these, actually, the vulnerability ended up being Buffer Overflow. And it created great havoc about 10 years ago or 8 years ago by spreading extremely fast. The name of those worms are Code Red and Slammer. And the vulnerability that they were trying to exploit was precisely Buffer Overflow. So how many of you have seen this before, Buffer Overflow? OK. It's one of the oldest and by far the most common of software vulnerabilities. As early as 1988, the Morris Worm was one of the first by a Cornell University student. He designed this Morris Worm, one of the first to exploit this vulnerability. Since then, many creative ways of converting such a vulnerability into an exploit have been devised. Now, what is this Buffer Overflow? It occurs when the space allocated to a variable, typically an array variable or a string variable, is insufficient to accommodate the variable in its entirety. For example, a certain amount of Buffer space is allocated for an array. If the array bounds are not checked while populating it, the array may overflow into contiguous memory and corrupt it. Interestingly, this could cause an attacker to subvert the normal flow of a program. Malicious code supplied by the attacker and the Buffer could then be executed. Now, as it turns out in security, very often you need a background in many other subjects. To understand cryptography, you need some amount of number theory, some amount of discrete mathematics, et cetera. To understand some of these worms and system security, you definitely need operating systems, computer architecture, and so on. So some of you probably are teaching these courses, so you may be familiar with it. If you're not, then you might want to get familiar more with operating systems and architecture, because this part of the course overlaps with that. So to understand Buffer Overflow, we need to understand the virtual memory map of the machine, subroutine calling conventions, and the organization of the program stack. So when I say we need to understand, I mean the hacker needs to understand to design his worm. So here is one simple example. Function A and function B. So integer A, A is the name of function. It calls subroutine B and returns the value zero, and B has all of this. Character Buffer 100, integer J equals three plus K, et cetera, et cetera. So the question is, so the two things to understand over here is, A is the calling program and B is the called program. So what is the organization of the stack look like when you execute a program like this? So here is what's called the program stack. Now the first thing to note is that the stack and the memory grow in opposite directions by convention. So the stack is moving upwards. Each new subroutine that is called, there'll be a stack frame associated with that subroutine. So you see now a subroutine for the stack frame for function B, and the stack frame for A will be just below that. And there are quite a few things that are, so if you see this is the stack frame for B. Now you see quite a few things that are loaded over there. Now you might make a guess as to what you might want to load. So the stack pointer is pointing initially over here. Now just before A calls B, it will push the parameters over here. So the parameters will be pushed. Then the call instruction and assembly language will push the return address because you need to know where to return when the subroutine B is finished. So the return address is pushed over here. There's something called a frame pointer. We'll see later on what's the use of this. This is then pushed. And then all the automatic variables or the local variables in program or in subroutine B then occupy the rest of the space. So this is the convention. We should understand the convention thoroughly. So what's passed on the program stack? When A calls B the following are passed, the arguments or parameters used while calling B, A's return address, a copy of A's frame pointer, and the local or automatic variables of B. So one question you might want to ask yourself, you don't have to answer just now, but what is the meaning of frame pointer? So we'll return briefly to this thing tomorrow when we talk about malware. But you might just want to refresh your mind and ask yourself from your good old days studying computer architecture or computer organization, what is meant by frame pointer? What is meant by stack pointer? And so on. So in this case, the local variable buffer is declared to be an array of 100 characters. So 100 bytes have been allocated on the stack for buffer. Let's go back and just check. There's a variable in program B, a character buffer of 100 bytes. So that's going to be allocated on the stack in B's stack frame. So those 100 bytes for array variable B. Now how do you exploit this thing? So that's all fine in theory, good for a computer architecture course, but as a hacker you want to exploit all this. Provide input to a buffer on the stack which includes malicious code often called shell code. Overflow the buffers so that the return address to the calling program is overwritten with the address of the malicious code. That way when the call function terminates, it will not return to the calling program, instead the malicious code will be executed. Let's look at a picture to understand this clearly. There is another function that starts to load this buffer. So you're trying to populate this buffer in which direction will the buffer be populated? Where is the first element of the buffer? Over here, okay. So I start to populate this buffer and then the C language program, programming language C, doesn't have any provision for checking array bounds. So I can just keep writing and writing and writing and writing into this. And if I'm sufficiently smart and lucky, what I do is I override the return address. Now that's bad news. Okay, so as I said, it's important to see where, how the stack grows and how memory grows. So typically by convention, they grow in opposite directions. So the first element of the array is here and so on and so forth. It keeps getting populated from here. Sadly enough, when I overflow it, it can overflow the return address. So here's what the hacker does. He creates input, which is going to appear over here and then overflows this buffer and then overwrites the return address. Overwrites it for what reason? To point to, for example, malicious code. So this address could be made such that it points to malicious code which incidentally can sit down here itself. After all, what is code? It's just a bunch of bytes, right? Assembly language, machine code. It's just a bunch of bytes. So if I'm very careful with all this, I can do all the calculations and make this address point to this thing. So what will happen is that when the subroutine exits, instead of returning to the calling program, it will actually return to this code and start executing this code over here, which could be malicious code which spawns a shell and allows the attacker to start reading the victims' files and so on and so forth. Is there a Java program there? No, this is C specifically. So the question is, what if it's a Java program? So here is one thing, yeah. Java program. Can I just allow these to come over? Yes, yes. That's why, so the question over here is, what would happen if it was a Java program? So you may not be so lucky in a Java program, though some people have had some amounts of luck, but those are real, real, real hardcore hackers. So typically this is a problem with the C language, that there is no bounds checking. There is no array bounds checking. That is the vulnerability. So as I said before, whenever you look at an attack, always ask the question, what is the vulnerability behind the attack? So here the vulnerability is, there is no bounds checking in many C language functions. So this is one of the reasons why personally I prefer to use Java, but there are many other issues also. There's a lot of legacy code in C. When I started programming in my younger days, I was one of the first languages I used. First was Fortran, but then when I started really programming it was mostly C and then later on C++. It's only later after that that we moved to Java. Java is much younger than C or C++. So there's a lot of legacy code that is still written in C or C++, which has these kinds of bugs. So another exploit is the return into libc. So you might say, okay, the code sits inside this thing. One idea is to defend against this attack, make the stack non-executable. So that's what they did. They made the stack non-executable in the operating system itself. And then guess what? Some smart guy came and said, let's do this. This is called the return into libc exploit. Your malicious code is not placed on the stack. Instead, this exploit makes a call to the C library function system with parameter this thing. And this particular call then spawns a shell. So the library function spawns a shell through which the attacker can enter various commands. Now you don't need the stack to be executable. So we have defeated one defense. So another thing to remember is that security is a race between the attacker and the defender. So the defender made the stack non-executable. The attacker came up with another well-known attack called the return into libc exploit. So there are many other defenses against buffer overflow. The most well-known is the use of a canary. So we will have a demo on this tomorrow where we will show you where if you put a canary, this particular attack will get frustrated. So this attack will not work. And there are certain other things that you can do like address space, randomization, and so on and so forth. So we will show you the attack working if you can disable those features and the attack will fail if those features are enabled. So in today's machines, those features are enabled by default. Okay, so there are some other related attacks like the heap overflow, just like the stack overflow. You know the heap is used to store dynamic variables and automatic variables in a program are stored on the stack. There's also something called format string attacks and some of these are addressed in the textbook. Okay, so for today's lab, we now turn to web security. So we are talking about secure web applications and two of the attacks that you are responsible for in this course are cross-site scripting and SQL injection. So what exactly is XSS? How many of you have seen XSS? This is one of the most fascinating things. A little conceptually, a little bit difficult and it's an attack where many of our students over here in IIT have done considerable amounts of work on. So once again, this race between attacker and defender. So there are many questions that will be raised and you should try to think of these questions. When you try to defend against this attack, is the defense on the server side? Is it on the client side? Can you defend against all of these XSS attacks? Is it a combination of client side and server side defenses? Your latest browser, when I say client, I mean browser. The latest browser, what sort of defenses does it have? Which attack vectors will work against the Google Chrome browser, which will not work, which will work against Microsoft Internet Explorer, against Firefox and so on and so forth. So we will take you down this path, both a little bit today, but more on, I think it is tomorrow, tomorrow afternoon, where we will do the lab on XSS, tomorrow and the day after tomorrow. So what is a cross-site scripting attacker? Website is said to have a cross-site scripting vulnerability if inadvertently includes malicious scripts crafted by an attacker in pages returned by it. So there's obviously going to be, there's going to be JavaScript in any web page that you get, right? Modern day web pages are typically dynamic. So you're going to see JavaScript, but this is now JavaScript that has been actually inserted or injected into a regular page. So the first question that comes to our minds is who put that thing there, an attacker? How did the attacker put that malicious JavaScript in that web page? And what is meant by malicious in this context? So for example, the script could be something that looks like this, script some malicious JavaScript code ending with a script tag. So the malicious code may, for example, read browser cookies on the victim's machine, ship these off to an attacker's website, might even read your user credentials like your login name and password. So it's a very dangerous attack which many websites are vulnerable to. There are two versions of this XSS. One is the so-called persistent XSS attack and the other is the non-persistent or reflected attack. So the persistent case, which is the simpler case to understand, the malicious code or scripts on a web page is saved on the web server. That's why it's called persistent. When an innocent user downloads the web page, the malicious scripts execute on their user's browser. So for example, users update their profile on a social networking site. These profiles are typically read and downloaded by other users through their browsers. Now what in my profile if I put a bunch of JavaScript and it is stored on the social networking site and then it's one of my friends or some other user downloads that code, downloads that web page, then there is script on that page which then gets executed. So there's a JavaScript engine that is part of your browser and that gets executed. What's client and disable the JavaScript? If client disables, so that's a good question. So the first thing is, since JavaScript is causing all this problem, let's disable JavaScript. Do you agree that's a good solution? Why not? I'm very safe, right? Let's just disable JavaScript. I know your friend will go free. Sorry? Do you want JavaScript? JavaScript does all this wonderful stuff. It does some animation. It does error checking. There are many times where you want JavaScript to be there. So it's like this. You want JavaScript. You want HTML in your user profile. You want to enrich the user's experience, those who visit your website or your profile. So you want it there on the other end it's causing this problem. So can we get the best of both worlds? I want it there, but I don't want it to create any problem. We should have a trade-off between both. Yeah. So that's what we're coming to. What exactly is a defense for this thing? I want the JavaScript, but I don't want malicious JavaScript. That's my requirement. But in the browser, sir, we have the facility that we can enable or disable the JavaScript whenever required. Whenever means what? How does the browser know that this JavaScript should be executed, but that should not? Right? Okay, non-persistent attacks. So this is the interesting attack. It's conceptually a little bit difficult. So I'll try to explain it and then go to SQL injection because the lab is on SQL injection. Now, what is this non-persistent or reflected attack? Anybody? Come on, somebody say yes and explain it. You have to do it to your students, okay? What is this non-persistent exercise? What's saved in the server side? Yeah, but how did it come there in the first place? It was not saved. What is exactly going on? When a user is filling a form that, for example, his name, his credit card number and all, then we can have to steal this form, I don't know. Who can steal? We can steal means who's the V? Hacker. Hacker can steal? How do I steal? If I want to steal what you're typing, how can I steal? You've got a form, right? Yeah, I have a form. How do I steal your password? A phishing, I mean. By the hidden variable, no, no. You're partly right. It starts with the form business. Now there are some important ideas over here. So the first thing is. Sir. It is like server process and then return back. Like, for example, search engine. So what is the key over there? What? So what is the key idea? The key idea is, so he says, for example, a search field. So the first thing is, there is a particular web page. There is input that is expected of the user, and some of that input could be reflected. So as he's saying, one of those inputs could be, you're searching a catalog, there's a search field. You know, many of these web pages search for something. So you type something, I want this particular toy. Toy train. And then if this toy shop doesn't have a toy train, it will come back and tell you what? Sorry, we don't have a toy train. Okay, that's an example of something that's reflected. Another example, you type your name. Ramesh, et cetera, et cetera. It comes back and says, good morning Ramesh. Very happy day for you, to you or something. Whatever you typed as your name, gets reflected back. So there are many fields where exactly what you type gets reflected back. So that is the problem. Should it be exactly, should it be reflected back? Or should the server do something more intelligent? So if it's your name, you can't have all sorts of funny tags inside your name, right? So the server should see that and do some kind of sanitization. If the server doesn't do it, then it opens a great opportunity over here to launch an excesses attack. Okay, so let's just read this. For example, a user may be asked for personal details in an HTML form. Suppose he enters his name as Prashant, the server then responds with hello Prashant. Whatever you typed in, the server reflects back. Not everything that you typed in, but certain fields. Note that the server has echoed his name back. Now what would happen if instead of Prashant, the user enters script, alert, fire, and so on. What's your name? I typed my name. You see what it responds with? Hello Bernard. Where did that server get this Bernard from? Whatever the user typed in, right? The user typed in this. It's simply the PHP program or whatever is that server program on the server side simply extracts this from the HTTP request message and reflects it back. Now what if I type this into this webpage? Script, hello, and so on. What is gonna happen? This is a bunch of JavaScript. Most of you have seen JavaScript in some form, right? At least the basics. So I typed this JavaScript and that application is very untrustworthy. It's an insecure application. It is what's called excesses vulnerable. So what does it do? It takes this input and it simply reflects it back. When it reflects it back, the browser simply executes it. If the browser sees that it is JavaScript, it's simply executed. This is what that is. An alert box pops up with the word hello because I've typed in hello over there. Now the question is, how do you convert this into an attack? I notice I've got a vulnerability scanner. We're gonna look at vulnerability scanners tomorrow in some of the little presentations. How does the vulnerability scanner know that your website is excesses vulnerable? And having known that, how can it exploit this fact? So think about how I can exploit this and make it an actual attack, okay? So we will continue this discussion. If I have time, I just want to introduce you to SQL Injection and return to this. So the question to everybody is, knowing this fact, what is this fact? This site is excesses vulnerable. What does that mean? It means that there are certain fields out there that whatever I typed in, it's not gonna check and see, I asked you for your name and instead you typed me some script and so on. It's not gonna check because that code is sloppy. It's sloppy code on the server side. It just takes the input from the HTTP request and simply puts it into that PHP and then ships the thing off. Ships the HTTP response back. That response includes, of course, HTML and all these form parameters. One of the form parameters is the script business and so on, which executes on the browser side. Now the question is, how do you convert this vulnerability? I claim it's a vulnerability. How do you convert it into an exploit, into an attack? Take a session ID from this. Session ID and do what with it? And how did I get the session ID? We must complete the attack. So just think about it, all of you, just think about it a little bit. How to convert this into a, to an attack? I claim that this is a vulnerability. So there are different attack vectors that we've come up with, a whole list of attack vectors. Some can be JavaScript, some can be only HTML. And yet they can do things like stealing your cookies, which contain authentication information or stealing your credentials like user password, et cetera, et cetera. Can just say like some message saying that you have entered a wrong name. Please enter username and password like this pop up. Yeah. So I can steal the credentials. Exactly. So you can, for example, so here's what I'm doing. I'm at a browser and I'm accessing this particular website. I happen to know it's access is vulnerable. So when it asks me for name, I type in all this extra stuff form and please enter your name and your password and so on and so forth. All that thing goes through the HTTP request to the server end. That guy doesn't sanitize my input, just sends the entire thing back because that contains form and everything that I see a form on the screen. Okay. Now is that an attack? Now just think. Why will I attack myself? Script, which user will give permission to get the information of browser, something like. No, but that thing is what you are typing, right? You are typing in your name field. You were asked for your name and you're typing form and so on. That's what I'm doing. Why am I doing that? Do I want to attack myself? Is it really an attack? What I'm trying to tell you is that you have to convert this vulnerability into an attack, into a real attack, right? I mean, it cannot be some phony toy attack. How can you use this fact to make it an attack? I'll give you a hint. The attack will be a combination of XSS and phishing. It will start by you receiving an email with a link over there. I'm giving you a hint. Now take it forward. Sir? You will, just one second. You will receive an email which will contain a link. This guy is not very careful about clicking any link. He clicks on this link and the next thing he knows is that his password and other things have been compromised. At least cookies have disappeared or have been received by the attacker's website. The okay button has the link. Yes, so the form could, the form can contain a link but the question is what is the exact attack? So the form always has an action field which says submit these form parameters to a particular place. So I can submit this password and everything to the attacker's website. So now you see some part of the attack. You click on a link, that link has the query and you've seen the extended query string. So for example, something-something.com and then you have a question mark and then parameter name is equal to this value. Say password equals to this and login name equals to this. Now those are actually the parameter values that the PHP program of the server side will see and it will extract those parameter values. Now inside those parameters, if you put JavaScript and if that program is not sanitized on the server side then it will reflect this thing back and that thing will execute on your browser. Are you seeing it? We'll talk about it a little bit more. Just let me finish this SQL injection which is related to the lab today. Let me just finish SQL injection and I'll be back to this very important subject. It may lead to some sort of bottleneck attacks. Sorry, bottleneck? Bottle neck attacks means denial of service. Bottle neck attacks. Can you clarify what this attack is? I mean, sir, script is continuously repeated itself and- What is repeated? There is some sort of script is there which repeated itself and creating denial of service attack. Sure, sure, sure. There's no end to this thing. Only human creativity can limit this thing. So there is a whole lot of things that you can do. You can put scripts to tease the user. You can put scripts to steal as cookies. You can put scripts to steal as credentials and so on. So I'll just return to XSS in a minute. Just a little bit because we have the lab today. At two o'clock we'll come and see a demo of this thing. So there are two parts of the lab again. The first part is Wireshark where you will go and inspect. You will actually log in to some site or you'll be given some dump and you will try to figure out in that dump where is client hello, where is server hello, what are the different fields inside that and so on. So that will educate you on SSL and whatever we've covered in class, you will understand much better. Number one. Number two is there is an application which is known to be vulnerable. It's available on the internet, so it's not something we wrote. It's known to be vulnerable and you have to hack that application. You have to hack it today using SQL injection and two days later you have to hack the same application using XSS. You have to design the attack vectors on your own. So use your creativity to come up with those attack vectors. I believe SQL injection is a little easier than XSS so we'll have that lab today. So what is this SQL injection? Form parameters may be passed as a query string in an extended URL. This is what I was talking about in an extended URL to the server. So you have a server, something, something, something and then a question mark and then student ID. There is an underscore after S between S and ID over there. So student ID is equal to something and password is equal to something. That parameter value, 0, 8, 9, 3, 5, 7, 1 is what the user typed in the form. There was a form field which asked you for your student ID and another form field which asked you for your password and exactly what you typed in has now left the browser and is on its way to the server. Those two parameter values. The server application, so what does the application do? And the TAs will show you the actual application in PHP and how SQL comes in the picture and so on. The server application retrieves the form parameters and uses them to build an SQL query such as, the typical SQL query, select from where? Select these attributes or columns from a table or relation where these two value, these two column names satisfy the predicate, 0, 8, 9, 3, and so on. So what is the application done? This query is already there. It's a static query. You simply take the form parameter, extract it from the extended query and you just plant it into that thing that is underlined. Okay, whatever is underlined has come from the extended query string or the extended URL. Now, instead of typing your student ID as that and password as whatever you had on the previous slide, instead of that you type in one, two, three, and instead of password being this thing, you type in password as this thing, A, B, C, or X equals to X. So what will happen over here? Suppose the server program doesn't sanitize your input, this entire thing will go and the way this will be parsed is student ID is equal to one, two, three, and password is equal to this or this. Now you know in Boolean algebra that if you have a Boolean expression A and B plus C, A and B will be executed first and then the OR. So one of the disjuncts of the OR is X equal to X which is always true. So you'll have the first thing even if it's false, I don't care. And the second thing is true, so false or true will always be true and what will happen next is somewhat unpredictable, depends on the actual behavior of that SQL engine. It might return you the entire database with everybody's name and password. So these are the things that you can do. So you are crafting, this is an attack vector, you are crafting an attack string. The attack string in this case, the SQL attack string is ABC or X equals to X. There are so many other things that you can do which are simply devastating. You can type student ID as one, two, three, or one equals to one with the two hyphens at the end. So in some versions of SQL, in some variants, those two hyphens are comments, the beginning of a comment. So one, two, three, or one equals one again that evaluates to true and then again, it might be that everybody's name and password is revealed to you. You can do something even worse. Where student ID is equal to one, two, three, semicolon, drop table, student, zero, nine. So these are extremely dangerous kinds of attacks where you have actually, and you know these attacks, actually this is one of the most common attacks. We've actually done it on a neighboring country because some of my students love to tease them and they've gone to one of the sites over there, an automobile site. And in my class, they've actually demonstrated where in this automobile site, you can actually get everybody's password. They haven't deleted any tables though they could have but they've actually got everybody's password in that site. So you can do there are many, many sites that are SQL injection vulnerable. So here you've dropped the table completely. Okay, so we'll talk more about this at two o'clock. Let us, if you have any quick question, we'll answer it or else we'll return to XSS. Sir, is there any method to check out any website whether this is vulnerable or not? Like generally we are firing queries. Many, many tools exist. In fact, the scanners that you will see tomorrow, the vulnerability scanners will actually check precisely all these web vulnerabilities. Whether it is XSS vulnerable, whether it is SQL injection vulnerable, et cetera, et cetera. Anybody knows what these scanners are? So tomorrow we're going to give you nice demos of three different tools. Nmap, Nessus, and Snot. So those were tied in with the lecture sessions. We are not asking you to use these in the lab. The reason being because some of them do port scans and so on and there are too many packets generated and there are about 220 participants in this course. So if each one generates hundreds of thousands of packets, the entire network might come down. So we will tell you how to install it and so on. You can go home and install it on your laptop and with three or four students you can play around with it in your college. Is there any cybersecurity law if we access some website doing the SQL injection and we are trying to see his personal passwords and use a username? Maybe we are not trying to delete it but we are able to see that. So is there any law which prevents us from doing it? I mean, is there any punishment or something like that? The IT Act might have provision for all those things. The only thing is how do I prove that you're doing it? If I can prove that you're doing it, sorry, he has an answer. Very good, very good. Please say it for everybody. Amendment 2000. Amendment on 11-2000 that provides, that has provision for the confidentiality of information. So the person will be penalized. So the only issue over here is penalized for what exactly? What is the exact case against me, number one? And number two, can you prove it in a code of law? So there has to be some kind of footprints of this whole thing before you can charge me. Sir, excuse me. Sir, even though SSL is powerful and... You talk about SSL or XSS? SSL, sir. So is there any attack happened in the protocols? In SSL, I believe that a man in the middle attacks that could be possible under certain circumstances. So it's not 100% foolproof. Is the XSS attack clear? So what do you do to launch an XSS attack? Somebody raise your hand for the benefit of everybody and say, I want to design an XSS attack. Here's how I would go about it. What is the first step? There are many ways in which you can do it, but just give me one way. The first thing is I need to know whether the site is XSS vulnerable. How do I determine that? How do I determine the first site? You're building a scanner, vulnerability scanner, for different websites. What would you do? You would get that page. You would look at all the input fields, sit text boxes, you know, and so on and so forth, which solicit input. And then what would you do? You would type in some input and you would check and see whether that input gets reflected. If it gets reflected without any sanitization, then you can be pretty sure it's XSS vulnerable. So the software asks me, the form asks me for what is my name and I type in script, something, and then it reflects that back without really doing anything. It doesn't check and see, does this look like a person's name? It just reflects that back. I'm pretty sure at that point you can say this site is XSS vulnerable. That is the first step. Now I want to convert this into an exploit. What is the next thing? I craft a URL. What will that URL look like? So say that form field, the name of that field was password. So what do I do now? I create a URL that particular website and then question mark, password equals to some script. And I send it to some victim in an email. The victim is susceptible to phishing attacks. So I say something, click this link to get a prize of 10 crores or whatever. So he clicks on this link and what happens? Because that site is XSS vulnerable, that entire thing is returned. The script and everything. And that script executes on my browser. Now that JavaScript can be written in such a way that you can steal cookies and send them to some site, for example. Or that script, that extra thing, password equals to, could be a bunch of HTML, which could include form and so on. So it might have a very nice caption saying, please, your account is under threat or something. Please renew your account or check your account by typing in your name and password. It has to be done immediately in one 24 hours time. So you get nervous and you see that form and you type in your username and password and then the form parameters are sent to the attacker site. So there you go, a nice phishing attack which combines phishing and cross-site scripting. So you see how these things can be designed. XSS attacks. Once again I repeat, the first step is identifying a site that is XSS vulnerable. Then second thing is crafting the URL and then putting that URL in an email message and sending it to the victim. Now there are many, many different kinds of attack vectors and we will talk about some of them in the lab. What are the different kinds of attack vectors? So I've got, actually let me introduce you. I've got two students sitting there, actually there are many more. There's Nikhil, please raise your hand, Nikhil. Nikhil Limjay and Naman Jain who have done some very, very, very nice work. So we've been doing this over three generations in this place. What happened was about three years ago, I had a student Sudhakar Rao who built a browser extension for the Firefox browser. So as I said before, you can put your defense on the server side by sanitizing the input there or you can put it on the client side. Now there is no guarantee that everybody writes proper web software. So what the one school of thinking is let's put the defenses on the client side, on the browser side. So browsers have been coming up with new versions every three months. It's a very, very fast field and if you look at the Chrome browser, you will see that some attacks, forget sanitizing the input and so on on the server side. Even at the client side, you can defend against some forms of XSS. I'm not guaranteeing you every, but some forms of XSS. So you can try these attack vectors on the earlier version of Chrome, the previous to that version and so on and so forth. You'll see some attacks succeeded but no longer succeed or some succeed on Chrome but not on Explorer or on Explorer but not on Chrome or on Firefox but not the others and so on and so forth. So because these things were not completely defended against and this is a very difficult problem, these guys starting with Sudhakar, they decided to build an extension for the Firefox browser. They wrote the entire JavaScript on their own about 1,500 lines of code or something and it actually works. We can demonstrate it to you. And then I had another bunch of, so he was an MTECH student. I had another bunch of 3BTECHs last year who improved on that extension and re-implemented some parts of it. And now we are trying to write up this whole thing. So these two students, Naman Jain and Nikhil Nimje, spearheading that effort. They're also looking at some new attacks related to XSS called clickjacking that actually exploit features, certain nice features in HTML version five are exploited by them to design new attacks. So they're looking at both the attack side and they're looking at the defense side. So there are many things that we would like to show you probably on the last day when we do trends and so on, we'll show you some of this stuff. Oh, there was another bunch of students, Rahul Gupta and Gang who just graduated right now and they've been working on server side defenses. So that's another very interesting thing and we'll be happy to share these papers with you. I'm not doing this because this is rather advanced stuff so we're keeping this course to the basics. But there is a lot of other stuff that is going on over here in many different things, elliptic curve, cryptography, web security, side channel attacks and so on and so forth. We talk about the trends on the last day. Okay, so I think with that we can probably get ready for lunch.