We can get started just a little but early since we've run out of books.
So a couple of things, first, thank you all for coming.
These — these talks are sometimes done on short notice so I appreciate you all keeping up on your email.
Thanks to — to Mike for — for doing the presentation.
Thank you to Haika and the QA managers for supplying the books.
Google put in an order for 150 of the books in order to get everybody thinking about Web software and insecurity.
For the talk today, Mike has agreed to have the talk videotaped and we're going to put it up on Google Video externally.
So questions are okay, but if you have any questions at the end that are of a confidential nature, just wait until we finish videotaping and then you can ask questions.
And at about noon or so we lose this spot and we're going to head over to lunch, so although it hasn't been done officially or anything, you're very welcome to join us for that.
Okay, thanks very much and Mike Andrews.
[Applause] Thanks a lot Harry.
Well, thanks for inviting us up here and thanks Harry for the great quote on the front of the book.
I'm sure it's, you know, more than doubled the amount of readership of it and everything.
So let me just introduce myself very quickly, I'm Mike Andrews, I'm a senior consultant at Foundstone which is a professional services company.
Mostly what we do is, we do security testing and — and them kind of things.
I lead up the — the Web testings; so I lead up the — the application Web services evaluations and that and also I teach ultimate Web hacking classes.
So that's my background and before that I was professor at university and before that as you can club by the accent I was from the UK.
So please don't hold that against me too much.
As you guys obviously are aware by seeing history here, we're living in a Web Utopia now.
Pretty much everything's now is becoming on the Web and if you look back in just this early history, November 1992, there were 22 Web servers out there in the world.
Everybody knew where they — where they were.
Everybody knew where to go and get their, you know, their physics poem, so off they went to a particular server to get that.
Today, April — April 2006, there's about 80 million host names out there when you look at the survey from a company called NetCraft.
Now I actually think that maybe that number's a little bit low, especially with, you know, the number of pages that you guys index.
Now, break it in pages, it might be a little bit low.
But these are — these just goes to show even if these — even if these figures isn't completely accurate, it just goes to show how much things are growing.
So, the growth of the Internet or the World Wide Web, the initial idea was, you know, geeks sharing physics documents and a little bit before that it was effectively an online phonebook.
Where as nowadays you've got like 6.
5 billion people on the World Wide Web according to, you know, Internet statistics.
Everything is on the — everything is on the Web now — from the phonebooks, just before that, to your email, companies trading on the — trading on the Web; you've got companies that just solely exist on the Web.
They don't have any other — any other kind of — any other kind of outlet, you know, Amazon — Amazon is a good one.
They have no physical bookstores or anything like that, yet they ship physical goods.
So this kind of stuff has changed a lot over the years and now what we've got is we've obviously got the next — the next big push of that, Web 2.
0, which is a bit of an old saying the next — the next generation thinks.
But, you know, a good picture says thousand words and everything.
That's one half of the picture.
All these companies out here, you guys will probably recognize a few of them in there, you know, there is Blogger in there, there's Riley, there's Gmail and on the other page there's a whole bunch more than you'll recognize.
But you'll see that what's happening is more and more applications are going on to the Web.
It's not just information out there now.
Everybody is actually using it as a delivery platform and as a way of pushing software — not just statically browsing pages and things like that.
So obviously we're talking about security and we're talking about, you know, how to break Web software and stuff like that.
So what is the state of play out there? So I think just before I come along I went and had a look at two days worth of vulnerabilities from security focus.
You guys must know that site, it's a — it's a pretty well known Website that basically, you know, lists the vulnerabilities as they occur and a place where you can track them and see what's going on.
And just by scrolling down you can see that, you know, there is a fair few Web vulnerabilities and things like that.
Another good place to go to see the kind of — the kind of what's happening out on the Web in terms of security is the Web apps sec community and the — and the vulnerabilities.
Yeah, — sorry guys, I can't scroll up any more than that, but you can see the kinds of things that are going on all the time.
So what is — what is generally the state of play out there? The state of play looks something like this.
45% of the Web — the vulnerabilities that I looked at over Monday and Tuesday were to do with the Web in some way.
In fact the Monday and Tuesday statistics are a little bit skewed slightly because there was a fair few vulnerabilities that are released for internet explorer which might the app portion go up — the app percentage go up and also there are a good few vulnerabilities released for the — for the Linux kernel which pushes the OS up a little bit more.
Now that's — that's pretty uncommon in terms of the statistics.
Where as if you look at things like the lib which I'm saying is library and things like network libraries and stuffs like that, there is a lot less vulnerabilities being released, you know, being notified on these day on day.
Where as if you go back just 10 years ago, the number of vulnerabilities that would've been on, you know, network stacks and stuff like that would be a huge proportion.
Back of it further five years ago it would be the OS vulnerabilities would be a lot bigger, then it was the application vulnerabilities were a lot bigger and now you will see that, you know, Web vulnerabilities are taking up more and more of a slice of the pie.
So what are these vulnerabilities that are out there? Well, they look something like this.
This is un — this isn't unusual, although the stats are a little bit skewed to do with the platform, the actual vulnerabilities seem to be pretty — pretty standard with this.
Cross-Site Scripting being the biggest – the biggest cause of vulnerabilities out there — the biggest cause of reporting them.
SQL injection used to be the one that was the biggest, although people are getting more and more in tune with what SQL injection means and why it's a bad thing and how they protect against this.
So that slice of the pie is going down slowly.
It's being replaced by Cross-Site Scripting.
Cross-Site Scripting will start to be addressed and it's one of the big things that I'll talk about here.
So that will get smaller.
So what do I think are the next things that are going to start becoming more of an issue? Things like authentication.
Authentication takes a very tiny slice of the pie mostly because the attackers or hackers or whatever you want to call them go for the most easy thing that they can do and Cross-Site Scripting is shooting fish in a barrel with a lot of applications.
Authentication flaws and stuff like that might take a little bit more effort.
So what they're going to do is they're going to look at them later.
So over time some of these portions will start going down a little bit more and some of them will start to grow since this is just a quick snapshoot in time.
So what the hell happened here? We were doing pretty well with addressing of the vulnerabilities in the network stack and now addressing vulnerabilities in operating systems and addressing vulnerabilities in applications.
Why is Web in such a bad state? Your idea is it should get better each time; there should be less and less and less.
What happened? Well, HTTP, which is also know as UFBP; does anyone know what that acronym stands for? No on out there? Yeah, pretty much.
The amount of stuff that's being transported over HTTP just because it bypasses proxies and bypasses firewalls and gets inside the net and it gets inside the — the security is just — so that's in the security industry sometimes we like to call HTTP, the Universal Firewall Bypass Protocol.
Because generally what happens is your application and your network and your internal assets are built like a fortress.
All the sensitive information and everything is on the inside.
It's in the keep and you try to make sure that it is nice and secure.
So build nice big strong walls around them and hopefully you guys have heard of, you know, defensing depth.
What happens is, you build more walls around them.
And on this example you build another wall again and then you dig a nice big ditch and fill it with water and put guards on the tower.
What does HTTP do in terms of the network nowadays? Well, it blows big holes in the wall.
So anyone could walk just straight past.
And also, you know, even though you might have guards on the walls that will shoot arrows at people that they don't want, they may be wearing the wrong color — the wrong color jersey or something like that, they're known enemies.
Wrapping stuff up in SSL basically encrypts it and if it's encrypted to the source, the guards don't know what's coming through.
They can't analyze it because it's encrypted.
So this is one of the — this is one of the issues.
Web apps is becoming more and more of a target because of the where they are and because they're inside and they can bypass through a lot of the security controls.
Just have a quick look at what some of the security controls out there are for different things.
So security controls to the network.
We've got firewalls as we said before, we've got intrusion detection devices, the guards standing on the towers looking and saying, okay, is that a friend or a foe? Do we let them in or not? We've got vulnerability scans — vulnerability scanners that look for known issues, known configuration problems, patches, patch levels and things like that and we've got some procedures to help harden network devices and network servers and things like that.
We've also got VPNs to segregate traffic from different places and all that kind of stuff.
In software we've got access control lists.
Not only on files now, you know, files on who can read — who can read things, but also on the actual code.
You know we've got sandboxes the code run in.
So that, you know, even if the code is not well-behaved, it can't escape that sandbox and it can't do anything really bad.
Also, you know, we've got things that are saying what kind of permission is that code allowed to — allowed to do.
We're starting to get, you know, reasonable ways of buffer overflow protection.
Everybody knows about buffer overflows now; the amount of them that are out there are starting to go down.
It's only probably taken us 30 years.
Buffer overflow was known as a major problem and there was a paper written about it in 1970.
And so now we're starting to address it.
So we've got some lead time on these things.
We've got least privilege so we know, you know, not to run a Web server as root and not to run, you know, critical services as local system and things like that and we've also got libraries and frameworks that are out there that have — that have some level of quality that we know of.
We know, you know, they've been reviewed to a particular level.
We know that they're less vulnerable to things, so we use them more because reuse is good in software engineering, but also it gives us some control over security because the quality of the code is known.
This is what we've got for networks and networks and traditional software.
What have we got on Web software? Anyone? Yeah, — you know, it's not quite this bad, there are things out there, but there is nothing, you know, the de facto standard of — of things.
There is no, you know, really well known framework that everyone programs onto the Web for and SQL injection and Cross-Site Scripting don't happen on that because it's known to go through particular functions that strip all these — all these kind of things.
So what's happened is, we've found out that the Web's different.
The Web is different from networking and it is different from traditional software and what happened is as we did the paradigm shift from the, you know, the Fat Client module of everything sitting on your local machine and processing it there to processing it — going back actually from the — going from the mini or the main frame to the local machine and doing all the processing there and now slowly removing stuff back again.
Some kind of amnesia set in and we forgot all the things that we learnt before.
So we underestimated the target that Web servers would become.
Web servers are great target for attackers for a number of reasons.
First of all is, they're in this really odd position in — in the network topology.
They're semi-trusted machine because you have to publish data to them and stuff like that, but you have to have anonymous users access them at the same time.
So then too security things are against each other.
Also generally Web servers are — are very high powered machines with a nice big fat network pipe and if the attacker wants to use it for even, you know, service against something else or a worm, it's a great target.
If they can get over that, then they've got much more powerful machine than they could possibly get any other ways.
We also rushed into development and we forgot a lot of the things that we learnt from previous development.
You know, we've got perhaps this, you know, the rapid prototyping and — a year on the — seven months on the Web is effectively a year in real life and all them kind of great, you know, — let's push things forward, but we lost track of some of the things that we were doing previously in networks and in software, in the quality and the and the checking and stuff like that.
So we forgot a lot of the lessons, we forgot a lot of the software engineering lessons.
We also forgot that the Web's different in that it's a different environment.
There are different issues than there are; there's a lot less — there's a lot less control that you have on have things operate in the Web.
There's different kind of attacks.
You know, buffer overflow attacks on the — on the Web are very, very small in terms of — in terms of, you know, by application percentages or vulnerability percentages.
So — all of the things that we did learn were thrown out of window and we didn't start to address the new things that were out there.
Sometimes I wonder that we actually got as far as we did.
We're just hanging on there by the finger nails, some people say.
I don't think it's quite that bad, but it could be a hell of a lot better.
So the Web was never really designed to be secure.
It was designed for geeks sharing physics documents.
It was designed to be static, just information gathering.
It wasn't ever designed to be a platform to run architectures off; it certainly wasn't designed for a platform to run multimillion businesses off of.
So what kind of things are in there that are against security or security concerns with the actual design of the Web — the things that we have to overcome.
One of the ones — one of the big ones is that we intermix code and data all the time on the Web.
It's like having a signal channel and a control channel.
If signals can start getting misinterpreted as control, then all of a sudden you can make free telephone calls if it's on the telephone network.
The same — it's exactly the same that happens with buffer overflows.
The stack is considered to be data, but there is code in there and return addresses and if you can push enough data on to there, that overwrites the return address and it becomes code that helps to control and that's how you can overtake this.
Exactly the same with the Web.
Having Java Script embedded into HTML markup is — is the same kind of thing.
We also have no control over the client.
Because of the Web being so open, which is a good thing, it means if you want to develop on it, it also means that anybody can write their own Web app and can also their own Web client and can also, you know, do commands directly to a Web server using Telnet or NetCats or something like that.
Anything that you set on the client, you can completely not trust that it will behave correctly.
And that's one of the assumptions that people have.
Another big problem with the Web in terms of security is there is no state.
You have to add state on to — on to it; it doesn't come as a part of, you know, the Web infrastructure.
So if you take things like when someone authenticates against — authenticates against — against the system, you want to know who that person is, so then you can track what their permissions are every time they access a resource or something like that.
You have to have that state of who that person is and what they're allowed to do.
Follow them with them all the time.
It's an extra thing you have to keep — you have to — you have to keep considering.
And also, what we've done is a lot of these issues, the ones above we've talked about, we've effectively patched them.
We've added something on top of this, sort of addresses it, maybe not quite.
So things like for state we've added cookies.
Cookies help us with state.
Things like authentication, HTTP basic and HTTP Digest for authentications, things like that, to stop data from being — from being viewed.
For man in the middle type, we've got SSL and stuff like that.
They're all things that have been added on top of the Web — on top of things.
And one of the mansions that I like to do is you can't patch for security.
You have to add it in at the very beginning.
So we've got these — we've got these technological problems.
We've also got the educational problems and the — and the learning problem is that the learning curve of writing stuff of the Web isn't that steep really.
If you gain more complicated stuff, then — then — then, yeah.
But, anybody can publish a page or can put a shopping cart up online and things like that.
So the writers of Web apps are becoming — are becoming, you know, they're not what I would call the hard-core developers that were writing the applications previously.
You have things like, you know, pre-billed shopping carts for mom and pop shopping stores, which they go and, you know, they see a book and they go, "Oh, e-commerce, e-commerce for dummies.
" There's some stuff in this and some code in the back of that, I'll just copy it out, I'll put it on to my site and everything must be just fine.
And they wonder at the end of the — at the end of the — at the end of the month why they actually get a credit card bill, because someone's been messing around with their systems.
Before I wrote the book, sometimes I was a bit reluctant about writing stuff and getting it out because you have to think of, you know, I know this stuff, so everybody else out there must know it as well.
So I went to my local Barnes & Noble and I went through some of the books that were on there to do with Web programming and I was pretty horrified that out of — can't remember how many I looked at, but there was something like 34 books that I went through that the code actually had security flaws in them — in there.
So as I went through and thought — oh, someone's learning how to do something, then this code is teaching them how to do it and it's teach them how to do it wrong and they have no idea.
So, you got the — you got the — you got the writers, you've also got the attackers and the attackers, the skill for attackers on Web apps are not nearly the same as the skills to attack normal Web apps — normal apps.
If you got things like a buffer overflow, actually crafting an exploit for a buffer overflow is pretty difficult.
There are some serious loops that you have to go through.
To actually find a buffer overflow on some applications, you have to do, you know, reverse engineering and really understand the underlying, you know, the instructions the processor executes and how things go from there.
As we see on some of these, it's not difficult.
Some of the attacks on Web apps are not difficult at all.
So what happens when you get hacked? Well sometimes you don't know about it until it's too late.
How many of you guys have heard of card systems? There were a credit card processing company who were like say for instance — it wasn't one of their clients — say for instance McDonald uses credit cards, it goes to this place, it verifies the transactions and passes them on.
They had their database stolen of all of their credit card numbers and peoples — peoples data from that through an SQL injection vulnerability was the — was the talk.
Harvard Business School, anyone heard of them being attacked? Harvard Business School has an online locking application thing where you put your application in so the way you — the way you put, you know, what your SAT scores and your SI and things like that and it goes off an it gets reviewed and it comes back and it says, you know, well you've been accepted to Harvard Business School or no, sorry, go to one of the other schools.
What they found was one of the — one of the guys that was going through that found — he went to the application and he saw ID equals 1234 and he thought so what do I change — what happens if I change that to 1335? All of a sudden he was viewing someone else's application.
The unfortunate part of that was I believe that that application hadn't finished yet, it hadn't finished going through all its processes.
So it hadn't got an approval or rejection and so therefore all of the comments were on that as well.
And I hope they wasn't saying, you know, this applicant's a moron and shouldn't be in.
So one of my favorite ones is the Paris Hilton hacker.
Have you heard about that? There is a lot of whether — how this happened or not, but anyways Paris Hilton got herself phone hacked and a lot of pictures were released on to the Web including some of her friends phone numbers who also had to go and change their phone numbers because they were getting harassed and something like that.
How did it happen? Well what happened was one of the — one of the — one of the stories is that you've got — what happens if you forget your — your login? What happens if you forget your password? You need some system to say, it is me, let me get back in and let me change your password.
And so what a lot of them to do is they say, what's the secret question? And her secret question was — anyone? What's your pet's name? And so with the marvels of you guys — so I blame you guys for having her system hacked.
How did Paris Hilton get hacked? Well she answered what's her dog's name and there we go.
That was it; they were in.
That's all your fault.
So that's what happens sometimes.
Sometimes though it's just good old fashion graffiti and I say that you guys are great fans of graffiti, so I think you might appreciate these.
Coding Artist Industry of America; looks exactly like their normal homepage.
Apart from — piracy can't be beneficial to the music industry, Ado Entertainment, now I wonder where that link is off to? Inside the RIA with Eric Hoffman and I doubt that he is a very good spokesman for the RIA and my absolute favorite, where can I find information on giant monkeys? Another one — doesn't look too bad, until you know it's actually Al Jazeera's homepage.
You see that these are starting to get less and less subtle A lot less subtle.
So let's have a look at, you know, what is a — what is a security bug? Let's just start off from the very, very beginning.
So a security bug is a mixture of one of a — is a combination of three things.
It's a combination of an asset, a vulnerability and an attacker.
If you guys were back in, you know, back in high school when you used to stand by, you know, what is — what is fire made out of.
A fire is made of oxygen, heat and a fuel source.
If you want the fire to go out, you remove any side of the triangle and the fire goes out — yeah.
So if you've got these big, you know, oil fires, where the rescue teams come along, what do they do? They spray water on it? No, because you're probably not going to get the temperature down enough to do anything different.
What do they do? They set an explosive off next to the pipe which sucks all the air out of it and then you've just got a stream of oil.
You have to be really careful around, but the fire has gone out.
It's the same for a security bug.
You've got an asset, a vulnerability and an attacker.
We start off looking at the assets.
If there is no assets, then who cares where vulnerability — whether there is a vulnerability or an attacker can get in there because there is nothing for them to steal.
Attackers, you can say that, you know, attackers may not be — you can't get rid of them completely.
But some companies like to think the — like to say for risk — risk assessment point of view that internal, once we're inside of our firewall, there is no attackers.
We'll forget fotr the moment the — some stats say that 70% of attacks against the system come from the people inside the firewall.
So there now, the lunatics are already inside the asylum.
Don't worry about the people on the outside, 'cause they are still doing enough damage.
But some people say that based upon a risk assessment point of view, we'll trust all the people inside.
And if your application is only accessible to inside, that side of the triangle is gone; we don't have to worry about it anymore.
That's two sides we've managed to knock out.
The third side, the vulnerabilities, is the difficult one.
To make sure your software has no vulnerabilities whatsoever is a particularly difficult thing to do.
Just have a look at where security bugs hide.
Now a couple of you guys were saying, you know, like the previous book that I did and it would be nice to take James's credit, but, no, I didn't write the other book that went along with this series.
It's with James or Hugh Thomson wrote it, but software is part of two things.
It's part of how it's designed and how it's implemented.
It would be nice to think that these two circles overlap completely and that how you design things and how your programmers write them are completely the same and unfortunately that's not the case.
Functional bugs usually lie in this part of the diagram.
What there are is, they're things that you designed but the programmers haven't implemented them correctly.
So they're are things like, you know, doing two plus two equals five.
The design was it was supposed to add things correctly, but it didn't.
Security bugs on the other hand are in this part of the diagram.
What they are was a system that's designed to do a particular thing, the program is coded into that particular thing, but it does something extra as well.
So let's say for instance we've got a media player.
Media player is supposed to play encrypted content.
What I might also do is to help it with buffering and for performance it might store — it might download the stuff and un-encrypt it and store it in a temporary file and then play from the temporary file.
According to the functionality, it works just fine, but there is this extra little side effect that there is this temporary file which has a little bit of the unencrypted data in it.
So this is where these kinds of security bugs lie.
So how do you look for them? Where about do you look? But where as with the functional bugs, functional bugs can lie anywhere in the software.
If we've security bugs, we've got some kind of head start in that because of the triangle, they are only going to exist in certain places.
So what first I've done is I've created this Security Frame consisting of, you know, Configuration, Authentication, Authorization, User and Session management, Data validation, Data protection, Error Exception handling, Auditing and Logging.
These are the kind of places where we found security bugs generally lie.
Now depending upon the type of software, you can generate checklists to go through and you can say, okay, so for instance authentication check that you can't do direct accesses.
So, you know, if I know the — if I know the address of a page, what happens is that if I request that before I've authenticated.
And so there is a series of checks that you can do with that.
So it gives us a set of common bugs to look for while going through these kind of checklists.
The thing is — it's naive to believe that any kind of checklist is going to be comprehensive enough and cover all of the kind of things that your applications do.
So you've got things that are applications specific.
That your application does that none others do out there.
The way that it works is different and it doesn't fall into all of these standard kinds of tests.
What happens if new attacks come out there? The — the — you haven't got a check for.
Do you just say, "Well I'm not worried about any kind of vulnerabilities that released 3 months ago, they don't exist as far as I'm concerned.
" You can't do that cause your system is still vulnerable.
So thinking about new tests and new things to do is actually pretty hard.
It's like, it's like if you're any kind of, if you're an artist, I haven't got not one artistic bone in my body but I'm told that artists when they get this nice big blank canvas can sit there and stare at it for ages.
I'm like first of all what am I going to draw on this and second of all once they've got a view where do they start.
Do they start in the upper left corner and work in or do they start in the middle and work out.
Sometimes it's hard because you've got this nice blank canvas, where do you start; that's such a big problem, where do you start looking? Also you got the phrase, if all you have is a hammer, have you heard that phrase before? If all you've got is a hammer — what's the other part of that — all you see is nails? If you have a particular tool then all you're going to see is bugs that that tool can address.
If you've got a framework or some kind of checklist and that checklist incorporates these kinds of things, all you're going to see is bugs that that checklist finds.
So you've got to widen, you've got to widen things up a little bit more.
So frameworks, like that framework that I showed you earlier and mental models of how to look at software, help.
So have any of you guys heard of STRIDE? Couple of people, — couple of people, are more laughing at the Ministry of Silly Walks picture, aren't they? Yeah I'm English I've got a picture of some Monty Python sketch in there somewhere.
So STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and — come on click, — Escalation of privilege.
What these are, these are mental models to help you think about bugs and how to, how to look for new bugs.
So what you do is you look at each of the functions of the application and you go through the security frame.
So you go through the — you go through your security frame or wherever your checklist is and you look for the common bugs.
Learn by your mistakes.
Previous mistakes that you've had, if you've had, if your application has been really vulnerable to cross-site scripting or SQL injection, look for them kind of bugs because you know that they're there.
There's a professor at MIT called John Gutak that has a really nice quote on this.
It is, 'Bugs are a lot like cockroaches in your kitchen.
If you have one you probably have more and it's not something that you should be happy about.
' So, go through and look at the common ones that you find; but also go through STRIDE and think of potential attacks.
So you go through and think, what could an attacker do if they could — S — spoof a user? Yeah, what would they do if they could do that? Not necessary how they could, because that comes later in your test cases and your Xploy, but what happens, what would happen if they could? Would they be able to access your application, would they be able to do anything nasty? So let's go through a little example.
We've got a particular bit of functionality — we've signed up for a new account for instance.
We need to do authentication; so obviously there's standard authentication checks in there and then we go through the framework one at a time.
Thankfully you guys have got a great application, which exhibits a lot of these things.
The Gmail sign up.
So we look at the spoofing first.
When you sign up could you spoof yourself as another user? Well because you have to put your cell phone number in and it puts that back actually saying that you're someone that you're not you've got some kind of an indication of who that person is.
Tampering with data, well there's not much there but you might want to try some SQL injection or stuff like that.
Repudiation, what if someone signs up for an account and then says it wasn't me.
You've got their phone number.
You've got some kind of method of saying this person actually did go through that, did go through that process.
We did send an SMS message to tell them that they'd signed up.
Information disclosure, so what would happen on here if someone's, if peoples' telephone numbers got out? So think about them kind of tests.
What about Denial of service, — well Denial of service most people think about on the actual server itself, but you can also have Denial of service applications.
One of the good ones with self sign up is what happens if I write a script that would automatically just say, sign up User A, sign up User AA, sign up user AAA — eventually what would happen is you'd run out of database space and then no other users could or you go through the, you know, the birth register or the census information and you sign up all the cool names.
No one wants to use your application because I don't believe anyone logging in as Mike384972; I'll never remember it.
So what in this it does is you have that sign up on another channel.
So you have to do something and then you get a token back that then allows you to complete the sign up.
So that two factor helps; it stops it.
Actually being able to try and script that is pretty difficult because you have to have that SMS delivered to a place where another script could pick it up and reuse it and also you've got phone number and unless there's someone that has unlimited phone numbers, I believe is — what happens is you're only allowed to sign up like 10 accounts on one phone number.
So that helps me to — an escalation of privilege might not be an issue on this because everyone pretty much has exactly the same privileges as everyone else on sign up.
You're only signing up for one account here; if you're signing up for different types of accounts you know a paid version where you had more space or more facilities, more functionalities, stuff like that, it might be a little different.
But this is like a, an example of how to walk through this kind of thing.
When I was talking about Information Disclosure it's mostly about not echoing back too much information.
One other thing that you guys are sometimes good at is — error messages.
Not only are they, they tell you what's going on and that there's been a problem, they don't give away too much information and it's nice to have at least you know some kind of bit of funny in there, shouldn't all be serious like Error 54 or something like that.
So one of the things we said earlier is, rule number one, you can't trust the client.
Let me show you just a quick video.
Of — This is a great example of not trusting a client.
We're a — a company that sells software testing books.
I did this particular presentation at one of the company's main conferences.
So what I'm going to do is, at the moment I'm storing that page locally and then I'm going to go in and edit it and you see there's a drop down saying how many of these I want to buy.
So rather than buying 3 I'm going to say I'm going to buy -3.
Now there's a restriction in there and the restriction is from the user interface.
Normal user would only be able to choose between 0 and 10 books.
What I'm doing is I'm changing that on the client.
Now reload that page and now instead of saying 3 books I'm going to buy -3 books and you see that you know 49.
95 times by -3 gives me -149.
85, — I'm getting a credit back.
Let's see whether this application actually does this now; all the while I'm doing this in the conference the person who runs this site is having absolute kittens in the back of the room He's saying, Mike's hacking our Website live and he's showing thousands of people how to, how to rip us off.
Well, before I've done this and one of the things I show to you in just a bit is that a lot of the examples that I show on the Website are already fixed, already recognized and stuff like that; I don't show any live exploits on these kind of things.
So always give enough information so that you can track these back and — great, there we go.
Anyone worked in retail before? What happens if we put a negative value on a credit card charge? That gets put back on to the credit card.
So I've now got 150 odd dollars on my credit card.
They even gave me, even gave me tax back but unfortunately — [Laughter] — unfortunately I still have to pay for shipping.
So I earned 4 bucks out of that, so that's not too bad — and when actually talking to the guys, when I told them about this vulnerability, they said that yes that would have happened.
You know it's that 4111, that's a credit card number that does exist and gets verified and okay, but it's a credit card number that never ever gets billed against, so, I didn't profit out of it at all.
But what would have happened if it would have been a real credit card and it would have gone through it would have printed out a little thing so that guys in the warehouse could gone and pick the books up and they would have gone to the shelf and they'd have gone, Mike wants Web testing handbook and he wants -3 of them? That can't be right; it's either got to be a printer malfunction or a software malfunction or a bit of speck, speck of dirt or something on the paper.
So they would have probably picked the books up and shipped them to me anyway.
So not only did I make $150 but I got the books shipped to me as well.
So you can't trust the client and that's using no tools what so ever, that is just using the browser and notepad.
So you can't trust any of the stuff that the client does.
– How common is this? Well it's pretty common.
Let's just say that this is a, this is a major hotel in Las Vegas and it's $109 a night but in this case my internet charge for using internet in the room was -$10.
95, so I got a little bit of a discount.
The next day actually my Internet cost -$109, so I effectively stayed there for free and then what happened is some nice big guys in suits come and knocked on the door and said Mr.
Andrews someone in security would like to see you and try to stand there and then they get told yes it's a security review and it's good that you found this but it means that one of our systems is vulnerable and we have to fix it.
It's all over the place this kind of thing.
So, obviously you guys want to have a look at some hacks for today, and we'll step through some of them.
We're going to step through some of the most common ones.
We're going to step through session hijacking, we're going to step through page defacements, we're going to have a look at some other security assumptions that people have and how they lead to, and how they lead to security bugs and what I'm going to try and do is, I'm going to try and illustrate some of these with previous vulnerabilities at Google as an example and this isn't a case of trying to show you guys up or anything like that.
It's a case of, if you know that there is cockroaches in your kitchen, you know to go and look at other ones and also, don't be surprised if there are cockroaches in your kitchen because there are in so many other companies as well.
It's just a case of if you know what you're looking for and you can see that you've had these kind of things then you know what to look for next time and you know how to fix them and you know how to sort of address them.
So why no live exploits — why no live examples? Well two things is that this is being videoed, I don't want it going up online and someone going, Ah that's how we hack Google and we've got a video showing us how to; somehow I don't think Harry would be very happy about that.
The other thing is security vulnerabilities on Web apps get fixed very quickly because you got this nice instant service pack phenomenon.
If there is a problem either a security bug or even a functional bug on a Web app, as soon as you find it and report it, the next time you visit the site when it's been fixed, you get the new code.
You can't actually create a snapshot of that doodey exploit again because it's already fixed.
It's one of the great things about doing stuff on the Web.
You've got a great advantage with that over traditional software.
So anyway, let's start going through some of these.
We'll look at session hijacking.
Session Hijacking comes about because of one of the security problems that we've talked about before, because there's no state on the Web, so you have to add state on to that.
One of the ways of doing it is to give users session ids when they go and then that session id tracks them around and then you can associate that session id with who that user is and what permissions they have and all them kind of things.
So you can go through your checklist and you can think what would happen if a user id could be guessed, what happens if I can guess a user's session id.
What happens if a user's session id can be stolen and you think, well what would happen in them circumstances and the effect is pretty much the same.
Someone else can masquerade as another user that's not them because they have the same session id and the Web app doesn't know any different; but there are different ways of attacking the problem.
There are different types of vulnerabilities and there are different ways of looking at the manner of how to fix them.
So guessing session ids is a case of entropy; it's a case of what the size is of the session id and how random it is.
Good session ids always have a high entropy.
They have long numbers that change very frequently and are very, very difficult to guess.
So let's just quickly show you an example here, I'd like to put the mike — So here we go, this is a neat little Web tool called Web Scarab and what it does is it's got this nice little tab here called session analysis and what you can do on here is you can say, okay give me a hasty message and somewhere to get it from.
And the hasty e-version — and what you do is you say test and that does a quick test to see whether, Oh actually I need to go to — oh yeah, that's not going to help is it.
So no session id's there but I think if I go — no, let's go straight to the Google one — test, and this basically shows me that there's probably at least one session identifier in there, — by analyzing it, by analyzing the result and this ones in one of the cookies.
So it's told me ok this one here, now I could start to do an analysis on that, but actually there's quite a lot of other information in there that's not part of the session id, so how do I get them out.
So I know that this is part of the session id, so I could start doing a bit of rig exercise to say, okay, so start with some number of characters and then it goes id and then when the id equals and then what I want to do is I want to pull out anything that's not a colon.
So colon's the end, it's the end thing and there's going to be one or more of them and I've closed that and then I don't really care what comes after that.
So I've got the regular expression to try and match what the session id value is.
How many of these do I want? Well I want 500 of them and I hit fetch — and it looks like it's not doing anything — in the background — and it's probably not doing anything, why is that? That looks good, if all else fails grab the example that you had earlier that worked.
Yeah id was probably in capitals so we didn't get it.
There we go; so what it's doing now is it's doing 500 requests and pulling that id out and it's doing a different spacer from ones it had before and I don't know about you but I look at them numbers they look pretty random to me but it's a lot easier if you look at the visualization of what's going on and each dot is one of the values and you can see that that's pretty random.
If it's not random you can start to see certain things.
If you saw a line going up just like what I was going to show on the flower shot one, what I'll do is after the talk I'll show you what they look like.
But if you saw a line going up or a line going straight across it's probably some kind of, one that's based on sequence or probably one that's constant.
So in fact they're all over the place, makes it look like it's pretty random.
Sometimes you might see that they're in, they're in bands, which means that the algorithm favors certain values over others.
Sometimes there might be big gaping holes in here, so you know there might be like a big hole in this area here and that might be based upon a particular time it favors certain values and things like that.
So look into cookie values over time, look in any kind of session values over time.
Helps us have an idea of what the entropy is and so ensuring good entropy and ensuring a good address space for session id's helps us protect against guessing what them values are and people masquerading as other users by that.
So, the address space is dependent upon the number of users that you've had logged into your system at any particular time.
So let's say we've got a 128 bit session id about 16 ASCII characters and what we can do is on a machine we can do about 10,000 guesses per second.
We also have 100,000 users logged in.
We've got a really popular application.
Lots of people are logged in to it at each time so that reduces it; I only need to get one by the way.
How long is it going to take me? Would anyone care to guess? A day, — 2 days, — any longer than 2 days, — a week, that's 300 years.
So having long session ids and making sure that, it's, making sure that the entropy's good.
If it's a case of it's not, if the entropy's no good and it's sequential, it's going to take me seconds to guess what the next one is.
So actually guessing session ids if you just take care of these few little things, it's much easier to either steal a session identifier or to fix one and sometimes it's easier to fix one.
So let's have a walk through of how to fix one, — let's say we're at a cyber café.
We've got some shared machine that we're going to use.
We're just going to log in and we're going to check our email or actually we're going to check our bank account.
Along comes our little hacker guy.
The hacker guy goes to the bank account.
The bank account homepage gives him his session cookie.
So he retreats off and he has a think and says ok I'll remember that session cookie what it was.
Some unwitting person comes along later on sees the machine and goes to log in; goes to the bank account.
What happens with cookies? They're automatically sent whenever you go to the next, whenever you visit that same site.
Cookie's already set, doesn't have to be issued again, so these cookies are saved 1,2,3,4.
He visits the, he gets the homepage back, he provides his log in details, he logs in and he gets his account info back.
What does our attacker guy do? The attacker guy goes to a completely separate machine and fixes that cookie information.
So he goes to the account page and provides the cookie id and as far as the application's aware, it thinks it's the same person because that cookie id is the same as what the other person's using and there's no state on the Web.
It doesn't know that two people are logged in and that they're are two different pages.
So effectively you get the account value back, — that's one way of doing it.
Very easy, isn't it? So, protecting against the session id guessing and protecting against fixing, ensure good session id entropy and always give people a new session id when their role changes.
Whenever that, when that other person logged in if they were given a new cookie value based upon when they logged in.
So they log in, they get a new cookie that tracks them through that value that the attacker knows, isn't useful anymore because it was only for a particular role that doesn't have any permissions.
What would have had to happen was the user would have had to log in and then gone to grab a coffee or something, the attacker quickly sneaks over and generally you know that's an attack that you can't protect from technologically.
More common approach is to steal session ids; there's two methods of doing this, steal them in transit and stealing them from the browser.
In transit hasty piece of clear text protocol, so what do you do to protect stuff in transit? Stick it over SSL — yeah.
What happens if you get a box like this that comes up, — what does this mean? It means that there's something wrong with the SSL connection and that the certificate was issued to a different company than where you're actually, than where you're actually heading.
I promised my wife I wouldn't take the Mickey out of her on this one but I'm going to break this right now.
What do these two buttons mean to most people? This button means, no, I can't do what I was after; this button means, yes, I don't care just let me get on with my activities.
Yes let me get on with my activities, could be now suffering from a man in the middle.
Could be either someone in the middle of that transaction is presenting another certificate and decrypting the SSL traffic between the two; you'll see it with tools like Paros and stuff like that.
So make note of some of these warnings — stealing them through the browser, oh sorry, let's go back it's, for sensitive information over HTTP protected using SSL, make sure that the SSL configuration actually matches the box that it's on and also make sure that it doesn't go and get parameters.
Any kind of sensitive information like, you know, credit card information, get parameters are also logged on the browser.
You can protect cookies and – protect cookies with session ids in some way by having a Secure flag set.
What the Secure flag does is make sure that a cookie will only get transmitted over a secure connection, over SSL.
Most pages get billed with multiple requests not only the one request for the page but also requests for the images and stuff like that and Java Script.
Now if the page itself is pulled over HTTP, great, because it's protected, but if images aren't secret, so why pull them over HTTP? If that's the case then the cookie goes with it and the cookie's unprotected for that moment, for that particular transaction.
So this is mostly configuration issues; more common way of stealing session ids is cross-site scripting.
I'm sure you guys are aware of, so let's walk through a quick example.
We've got this flower shop.
We've got somewhere in the flower shop where we can leave messages for other people say you know Guest book, someone saying what a great sight.
What happens is our little attacker comes along again and says, oh this is a great place; I can leave things for other users to pick up.
So what he does is he leaves this little thing here, leaves a Java Script.
As we said before you know code and data intermix, once that gets displayed, it's going to pop up a little message box.
Now that might be annoying as hell, but it's not a security vulnerability because it's not attacking any kind of asset.
What's one of the assets on here? One of the assets is your session id; so what we do instead is we put an image in there.
Now that image is a 1×1 transparent pixel — users aren't going to be able to see it, aren't going to be able to notice it at all.
What that pixel does, when it goes and requests that it also sends a parameter to the attackers' Website with the cookie value, his document.
So when our jolly user comes along to visit the site and goes to the Guest book, the code automatically runs.
He goes there, the script starts executing and the browser goes, oh I need another image, where do I get this image from? Well I get this image from the evil attackers site but the image tells me I have to, I have to add that session id parameter on to it, which it does.
So he's got that and then the image comes back on and it looks no different to the user at all, but in the meantime on the evilhacker.
Com it's logging all of the session ids into what's known as a cookie jar and so at any point this hacker can come along and pick out these and they could be scrolling them in real time and know what kind of session ids are being used and start using them to hijack other peoples information.
Once again how common is this? Pretty common.
— How easy is this to find? A 14 year old found it couple of months ago.
The story was he was sending java scripts to his friends.
Now that's just, no.
He'd learned about cross-site scripting from some kind of, from some kind of Webpage or some kind of book and thought what happens if I put alerts in an email that I'm going to be sending to one of my friends and this was in the subject, in the subject header BANG cross-site scripting error.
Now rather than just doing the, rather than just doing the, rather than just doing an alert message box what he could have done is he could have stolen his friends session identifier and reuse that in his own requests and all of a sudden he's logged in as that person and you can do all of the things that they needed to do.
So how do you protect against this? Now — generally I can say this over and over again and I'm asked sometimes during interviews of the book, what's the one thing that I recommend people to do.
I recommend people to validate their inputs — things like Java Script and stuff like that has no business being in filled or displayed to users or stuff like that.
So validate the inputs so you're getting what you're expecting.
Now in some kind of, in a header you're expecting you know alphabetic characters, numeric characters, maybe some punctuation, you're not expecting script tags.
Also validate application output; just because it's in there don't trust the data that's in the application is ok.
You know, do this defense in-depth; validate on the way in and validate on the way out.
The easiest way of doing this and that would solve 80% of cross-site scripting problems and stuff like that is really these tags here.
This open tag and the close tag is what separates code from data, mark up is still code so you know a bold tag or something like that, but also Java Script tags.
Change them; the user probably doesn't mean that they want this angled bracket.
They probably mean they want that bracket displayed.
So change them from that to its HTML equivalent which is < and >.
Then it gets shone and you don't cross that boundary between code and data.
Don't just think that that's the only way of doing it though.
There's a wide list of the kind of inputs that you want, the kind of things that you're expecting data to see because there are so many different ways of encoding these, its — ways of doing it; there's a lot of them.
So be aware of these things, also be aware of the protection of the actual session cookies themself.
Sharing session cookies between applications extends the, the attack surface because there might not be a vulnerability in one application, but if there's a vulnerability in the other application which shares the same identifiers over — over a single sign-on, the other app becomes vulnerable at the same time and you might not have any control over that at all, so you can restrict the session identities and cookies and stuff like that by using the domain and path attributes.
Say that, this cookie for a session is only valid for this particular part of its application.
It shouldn't be used and shouldn't even be considered to be part of an ID for another application and that limits your attack surface.
HTTP only in Internet Explorer provides some kind of limited amount of, of benefit.
What this tag is, is a non-standard tag, just like, we've you know Secure, if Secure equals True, basically it's just HTTP only on the end of a, on the end of a tag and what Internet Explorer does, is it says this cookie here is only really for me to send to the, to send to the, send to the server.
Local codes shouldn't have anything to do with it, so most session identifiers, local codes don't have to have anything to, don't have to have any knowledge of session ID's at all.
It's really just to help the server keep track of whose is where.
So if there's a cross-site scripting vulnerability and your cookie that is holding that session ID, has only HTTP on it, that Java script will basically return null — because its marked as that cookie should not have any access from — from local code and it's one little word and you might as well put it on there.
Most people use it, most people using, using Internet Explorer will get that benefit straight away.
It's in as a bug feature request for the Mozilla code base.
They think it's a great idea; don't expect Microsoft to have any great ideas, but they do occasionally and — it's been down there on about a year, maybe they'll get around to adding it on it at some point.
So how do we do page defacements? That's one of the things we were going to show.
So, we've pretty much covered session — session hijacking.
What about page defacement? Well cross-site scripting can be used just as easily for page defacement as it can for session hijacking.
So cookies have just a small amount of information you can get for the document object that you can get by going through Java script.
Java Script can not only gather stuff, but it can also change elements on a page, that's how, you know, dynamic menus and those kind of things work.
When we are talking about assets and assets might be your ID, but your asset is also how your page looks, because if you're a site that people trust, the information that's on your site is still an asset.
People might, might do certain things based upon what your site says.
Let's have a quick walk-through of cross-site scripting page modification.
We've got a Website, — it a news Website.
People might believe you know the stuff they see on the news is exactly what's going on so they might do certain actions based upon current news.
Our attacker comes along and finds a cross-site scripting vulnerability and he uploads an image and he puts that on his evilhacker.
Along comes Joe user and the attacker sends him an email message, that might be a friend that's trying to trick the user into doing something; it might be some kind of spam message that goes out.
But the email says start dumping your Microsoft stock.
Why? So, the user goes along and looks at a page and instead of seeing the page that's supposed to be there he sees a page that looks completely different.
How did that happen? Well the email said something like this; the email was a link to the page and it's found a particular vulnerable, vulnerable parameter and instead of you know, picking up a cookie or something like that, what they've done is that they've fed document.
So 38th image in that page, change it to the one I've created rather than that one there and it happens almost immediately and they see that information rather than the one's that's there.
But if you saw that link, would you click on it? Some people shaking their heads, some people are not too sure.
What happens if you saw a link like this? So, you can obfuscate these things, you can hide them.
This does exactly the same thing; tinyurl was a great thing for hackers to hide, fishing links and stuff like that.
This was found October 2004 — 2005 by a guy called Jim Leigh who's got a great Website, great blog; said all sorts of things.
Found exactly this vulnerability and in the, in the search engine home page, I managed to make it look like it's against subscription.
You not are you? — Because I'm going to sign up for this now if you are.
5 — 5 bucks, well worth it and certainly sad to some of his friends.
I — I dread too think if anyone actually filled this out and sent him any, — send him credit card details.
But it's pretty common.
So one more for the road of cross-site scripting and we'll call it a day on, we'll call it a day on this and we'll start, we'll start wrapping stuff up.
Cross-site scripting can be used for actions, so you can do things like cross-site request forgeries which embedding a particular action onto a page gets you information, gets you information back.
It's like a user clicking on something — but they didn't do it.
It was the Java Script that did it.
So this, you know, this piece of AJAX code, what it would do would be, oh — there goes all me Gmail contacts, put into, put into maybe an image tag which then gets sent off to someone else through all their emails and stuff like that.
What about if I was buying a book, what happens if I was doing something like this, what happens if I had a script that said document.
Location equals this — oh yeah, that looks like a good book to buy.
If I've manage to put this into a review, whenever someone went through review, bang, all of a sudden they're at this page and they wondered how they got there.
What if, — hold on a second.
So I'm just using Firefox because Firefox has got some pretty cool plug-ins, that I can, that I can use to show these, show what happens on these kind of things.
What happens in, if this review there was a cross-site scripting vulnerability? Now I'm going to just use the Domain Inspector just to show the kind of thing that you can do on this.
There we go — there's the page.
What would happen if instead of — instead of just a document.
Location equals, if I did — what would happen? It's basically saying, Document, some Form, click the Submit button.
Oh look, book's in my shopping cart without the user having any control over what happened at all.
Now I could probably change the quantity as well — maybe some way of authors maybe boosting their, their sales or anything and I wouldn't possibly dream of doing something like that.
But you can see the cross-site scripting has so many different places that it could affect users and it's hardly getting any recognition out there.
SQL injection most people are starting to understand what that is and why that's, why that's a bad thing.
So now everyone's looking at cross side scripting and there's even more vulnerabilities out there of cross-site scripting, than there is, than there is SQL injection.
So start having a look at them kind of things So other attack vectors that we could look at; cross-site scripting is a temporary attack.
Users have to actually participate in the attack to some, to some degree.
They have to visit a Web page or they have to click on a link that has a vulnerable parameter or something like that and some people say you know maybe there could be unobservant.
If they have a page with load and load and load of CGI parameters and some of them look decidedly dodgy, would they click on it any way? But that's beside the point.
Cross-site scripting is a temporary attack; it has to have some kind of user involvement.
HTTP Response Splitting on the other hand is a new attack; it only really has been talked about recently in the, in the first couple of months.
We're probably pretty new in finding out what kind of vulnerability we can use with HTTP Response Splitting and what kind of attacks we've got.
The HTTP Response Splitting is an interesting attack in that, it's a one shot attack, you do it once but it can have multiple effects.
It's like one of these gifts they keep on giving, you do it once and it keeps on giving stuff more and more and more.
It can potentially affect more than one user.
If one user suffered from the vulnerability with HTTP Response Splitting, it might be that the user that didn't do anything wrong at all also suffers from that vulnerability as well.
Let's do a quick walk through of it.
Let's say we have a, we have a machine, which is the bottom one, the black one, and it's going up and doing a request to the Web server.
So a quick walk through of the http that goes backwards and forwards.
Get request goes up to the server, the server then replies with a, with a code, says yes it's ok, sends the stuff back down including all the HTML.
One of the possible ways of doing redirect is to send a parameter to say ok, redirect me to a particular page.
The Web server replies with a 302 message and it sends the location header to the place where you want to go to.
What happens with the browser, the browser goes, ah, the 302 has moved to this location, so the browser then does another request for that particular location and the server sends the right thing back.
Yeah, follow me so far? What happens if we attack this mechanism? What happens if we say, instead of it being a proper page, what happens if we start embedding characters in there that starts to affect what the response is? So in this we can see that you have to encode these up by the way, rn, you have to actually encode them as — you have to URL Encode them otherwise they get changed, but what happens is this request comes up, the response that comes back from that is actually two responses.
The response, the real one from the server, which is the 302 moved temporarily in the location and then where it says no is the location that we've asked for and everything else after that is faked.
The stuff that we do, we're now creating our own http response.
That http response is 200 ok and here's a page for you and that page might have a payload, might have a cross-site scripting, it might be a completely different looking page then it was originally and then that lower part at the bottom would be the leftovers.
But the browser ignores it because of the </html> tag.
How do we use this as an attack? What we do is we do two requests from our machine, very quickly one after the other.
They have to use sequential, sequential requests.
So the first request does this does — does the exploit and the second request requests the page normally.
What's happening? We get back two responses from the first one and we get back a third from the other one but that's ignored because the browser's only expecting two requests to come back.
So the other one through index.
Html is just isn't, — it's just completely ignored and we get these two coming back.
The first one is this move temporarily, which is a No, which is what we've seen.
The second one is the payload.
So, what does this mean? This means that the first page, the first request is associated with this, — nothing really.
Html is associated with this.
Now that is bad because that's not the index.
Html page, that's the one that we faked up and it means that if someone goes to that index.
Html page from the browser's cache, they get, — they get the payload.
So we can affect not only the location we can affect caching and things like that.
Now I said you know it gives, — it keeps on giving.
As long as you don't refresh the cache, you keep on getting back the, you keep on getting back the malicious page.
How does it affect the multiple users? Well most people go through some kind of Web proxy, some kind of Web cache to speed things up.
Anything that goes through the page and anything that comes back gets cached by the Web proxy.
What happens if you have another machine over here that sends a request for index.
Html and index.
Html has already been seen by the Web cash? What does it give you back? Gives you back the payload page.
So this is quite new, this is only really been discovered and starting to talk about in the last couple of months.
So we'll see how this, how this works.
If you really really do want to have a good understanding of how this works and including in all the mechanisms and stuff, this is a great paper.
This is great white paper to go and have a, to go and have a look at and it gives you a lot of in-depth of how it works.
How common? Starting to get common.
It always suffered from this vulnerability pretty earlier this year.
So, I would imagine that a lot of sites that do redirect based on 302 also suffer from this vulnerability, because they trust the data that's given to them; they trust that someone's going to give them the right page.
Well, what is it? It's exactly same protection measure as cross-site scripting.
Validate the inputs.
What this is is in the location where it asks for a page is that carriage return line feed, breaks the line, the next line down, the browser assumes it's a HTTP Header when it's not; it's still a follow-on from the location.
So, validate the inputs and validate the application outputs.
And you have to be extremely cautious of all the data that you put in HTTP headers because if they use a control, they can affect everything; they can affect things from location, they can affect things that cache in, they can affect cookies and all that kind of stuff.
To start wrapping up, we'll have a look at a couple of security submissions and I'll take the questions.
It's that — the Web's got no standards; that's all.
Everyone says that there's RFCs on HTTP and all the way that things work, but there's not.
One of the examples was, everyone can play nice.
Everyone whenever they go to a page that does not exist, it'll give them a 404 page.
But it doesn't.
So, the site minder or the analytics and stuff like that suffered from a vulnerability where it asked for someone to say, here's a page that exists on my site and now use that as your — as proof that you own that Web Server because that page must only exists because you can put them there.
However, not your fault, but other people's fault if that page didn't exist, certain sites like IOL for example didn't do things properly; they didn't give back a 404.
They gave back a 200 okay page where the page just said, couldn't find that.
It breaks the standard.
But it means that I could register myself as a user of the IOL site statistics and not much information in there, but if I was a competitor I can see what kind of things people are searching on to get to that page.
Other assumptions; trust the data that's given to you.
Google News does this; grabs data from PR news feeds.
So many people have Google News alerts of anything that has a title in there.
Someone made a press release and said the Google hires a 15-year old.
And all of a sudden it's on this homepage because they trusted the data that comes through there.
They should only be trusted from know authority of sources.
Don't feel bad about this because it gets a lot worse.
North Carolina news team had a Web page that had closing tickets for scores and businesses and things like that.
What happened was, they put up a page that said, Ascots closed today because of boiler malfunction in ALB closed or such and such business won't open until 10:15 or 10:30 because of Web or something like that.
So the idea was there was a particular flow — used to submit information, used to get human approval for that information, used to allow the companies to do any kind of changes to update the time or something like that and then it was published out to the TV.
Our little hacker has come along and just goes straight to the — changes, which what does that do? Propagates it straight out to the TV.
Now, a bunch of students from North Carolina University managed to figure this out and this link here is the chat page of them absolutely laughing away as they put things up on the screen.
Anyone want to have a look on what they put up? Yeah, some people do.
Here's a good one.
[Laughter] For all you hackers out there.
And of course one of my favorites.
[Laughter] So they took it down after that and thought that it was mostly unamusing.
So, we can out bad filter input; I'm going to skip through these and I'm going to look at why all the problems.
So, what are the problems? Web servers are a great target.
Web servers are a great target for all the things we've talked about before and also as you've seen, these attacks are not rocket science.
They're dead easy to do.
Mostly entry for skilled people are low and the rush to innovate is out there.
Get these applications out before someone else comes out.
It's like the gold rush; I'm going to stake my claim to this part of the river because if I'm not there someone else will and it doesn't matter whether the code is bad or not.
The thing is, some of these security vulnerabilities can kill a company.
We've had loads and loads of companies out because of particular security and because of security breaches and stuff like that, have suffered from not only PR problem, but also financial problems.
Companies being shut down for this.
An example, Guest James got fined a few years ago for having SQL injection on there and someone found it and the FTC fined them because they were releasing, you know, customers' information.
Also, finally there's a drop in share prices.
One of the professors from Maryland University tracked share price against when vulnerabilities were released in a company, and he found that on certain vulnerabilities, share prices dropped by 5%, which can affect quite a lot.
Main reason why they're there is education, and — nice picture of one of my colleagues — is people aren't taught about security; they are taught about algorithms, they are taught about Bubble sort and they're taught about Quick sort and they're taught about linked lists and doubly linked lists and all them kind of good things and they are not taught about validating for input and why not validating for input is a bad idea.
But unless you start to push it back to there, people are going to come out and they're going to still start creating the same problems.
So, if you want to go back and start fixing it somewhere, you start fixing it at education by telling people what they are.
We start fixing it by companies, being responsible and doing the right thing; training the developers up, making sure the code is clean, by doing them kind of things.
So, next wave of things coming up — how're we doing for time by the way? Am I overrunning or is it okay? So, the next wave of things going to come along is Buffer Overflows and DoS.
We look at Web Services; they're going to be done in things like Recursive payloads and stuff like that.
It's all going to come back again.
SQL injection; Web services is going to be XPATH injection.
Next, I'll start coming back again.
Cross-site scripting, same vulnerability in Web service, external entity attacks including other pages from somewhere else.
Parameter tampering is going to stay parameter tampering; there's going to be nothing different there.
It's going to be a different arena.
XMS actually helps us with — helps us attack with payloads because it is a standard format.
They don't have to worry about doing it specifically for an application; it's a standard.
So, just because we start to solve all these things like cross-site scripting, it doesn't mean it'll all go away.
The next technology that is going to come along is going to have exactly the same thing.
So, even though I've shown you a couple of examples here and I've shown you the vulnerabilities and how to look for them, be aware of how these kind of attacks affect the next wave of software that you are going to develop.
AJAX is coming along and is being more and more used, which means more and more code pushed to the client, which means less control and less validation at the server.
So, we've seen what happens when we trust the client and just because it's AJAX rather than Forms or instead of Java Script, it doesn't mean that we should trust it any more.
Web-based Worms; Web-based Worms have already been done to some degree.
They've had limited impact and you know, you guys have brought out things, Web pages with success and you know, we've noticed a lot of requests for a particular thing.
So, blocking it from there.
We've got stuff like Web-based key loggers and backdoors like, you know, like a back office but for the Web.
It's the next Holy Grail for Web software.
And as Web software becomes the next platform for developing applications and things like that, that's what the attackers are trying to look at.
That's what the hackers are gunning for, for their next big go.
Bi-directional communications with arbitrary domains with no refresh and preserve between sessions.
In some cases they're getting close.
Some of it is already done.
XSS Proxy is a bunch of scripts that's already written for cross-site scripting in a frame that you.