Welcome to the Sirius Seminar for February 4th, 2009.
It's our pleasure today to welcome Cassio Goldschmidt, who is with the product security division at Symantec and has a well known or long established and well known history in computer security.
In particular, you will find him as one of these white hats who frequently are finding where there are problems, where there are vulnerabilities.
And Dr.
Goldschmidt has a, actually not doctor, he has three degrees but that third one is not actually a Ph.D.
He has a bachelor's from, I won't try to say, Catolica Francifica in Brazil and before obtaining a master's in CS and then an MBA from USC.
And so, proud to introduce Cassio Goldschmidt.
Thanks.
If you ever build or use applications that run on a network such as the internet, you are going to be attacked.
From a user perspective, what means is that all the assets that you have in your computer are at stake.
For example, I'm sure a lot of you do online banking using the internet.
I'm sure a lot of you do your taxes on the internet.
So that can be a real problem.
The other thing is, as software engineers, your reputation is also at stake whenever you have a problem in your application that is running on the internet.
If you have a vulnerability, your customers may look at that and may never come back to your site.
They may never use your products again, which ultimately can damage your company revenue.
In this talk, I'll be presenting some of the problems that we see with applications and all the vulnerabilities that we see today, the most common ones, and most importantly of all, what we can do to prevent them and prevent all the greed that would come from doing an application that doesn't work or works malicious for some reason.
The first kind of attack we're going to see is actually cross-site scripting.
I'm pretty sure that some of you already heard about it.
Cross-site scripting is quite an interesting attack because a lot of people think because a server is vulnerable, you're going to attack the server.
And that's not the case.
You're actually attacking the client.
The server is vulnerable.
However, you are attacking the client.
Here's an example of cross-site scripting, what I call cross-site scripting 101.
What you see here is the attacker, which knows about the server, which is vulnerable.
The attacker could go and attack the server and inject some type of script in that server, and the script would be redirected to his browser and executed.
In other words, he could attack himself, which is not a lot of fun.
So, what this attacker can do instead is actually send a message to the victim with some really interesting topics, something that would coerce the victim to open the attachment, such as, click here to win a million dollars.
Well, a million dollars, you know, perhaps they could have some use for that.
Let me click in this email.
This email comes with a special URL.
This URL has the address of the server plus some data that actually falls out of bounds from being data and becomes a script once it's processed by the vulnerable server.
So, what just happens is, once the server is actually processing this data, it embeds the script in the page and serves back to the client.
Suddenly, this data that was sent by the attacker becomes legit, and it's part of the data that is in the web page.
The client executes, and in this case of my example, what it says is, send your cookie to the attacker.
So, here's the cookie, goes to the attacker, and once you have somebody's cookie, you can impersonate the person, if you want.
And that's one of the ways you can do a cross-net scripting attack.
Once I show this slide, a lot of people think, okay, I got it.
So, you can't steal cookies, that's really bad, and that's why you have to protect it.
Well, there's a lot more than you can do.
Consider what happened here during the presentation election campaign.
The site you see here is called voteshillary.org.
Well, this site had a cross-net script vulnerability, and what Obama supporters did is actually change the way the site works in order to redirect to somebody who they think it was a better candidate and now are present.
Another thing you can do with cross-net scripting is basically deface some page.
Here's a real website of a bank in Italy, and you can see in this website that you have a place to, you know, just like other websites, to enter your username and password.
This site had a cross-net script vulnerability that somebody actually was able to change things a little bit.
What you see in this slide is actually a page where you would put your PIN number, you would put your code, and it really uses, you know, all this fake information is really coming from the bank website.
So if you look at the URL, it's really hard to look here, but it's HTTPS, and it's coming from the real bank.
So your padlock in the bottom of the browser is on.
Any user who clicks on this thing would swear that this is a real page server served by the bank server.
And in fact it is, but it has some content which is malicious.
Once you click the confirmation button here, it's probably going to send the information to the attacker.
So as for cross-net scripting, there are three types of attacks.
One of them, and the one we've been talking about, is type number one.
In other words, it's non-persistent web data you send as a URL, and then once you send as a URL, the person has to be coerced to actually click on that URL, and it can do a bunch of things, such as the potential damage could be to steal cookies, or to modify web content,
as we just saw in the slides.
Type zero is kind of interesting, and a lot of times people overlook this kind of attack.
It's against the local desktop.
And people think, okay, HTML, local desktop, I don't get it.
Well, basically a lot of the applications you use today, they have HTML and they are based on HTML.
Some examples, if you use any IAM client, you see all those smiley faces.
All that rendering is done most of the times by Internet Explorer.
You see interfaces such as InstalShield, VMware, Northern Internet Security, they all use HTML in order to do that interface.
Winamp is another application that uses HTML.
If you can't get a cross-site scripting going on in one of those applications, you pretty much own the desktop.
So it's really, really a powerful way of leveraging cross-site scripting.
By the way, help systems in Windows, they're all based in HTML.
The CHM files are actually HTML.
Type 2 attack is actually with persistent data.
What you see usually in, for example, guestbooks, where you can leave a message, if you could break out of bounds and actually put some script on that message, then it would be persistent for the next person who actually looks at the page.
And that's one of the most interesting attacks because once the data is saved on the page, then you have the opportunity to do things like cross-site script warms, which we've seen a couple of years ago in MySpace.
Somebody was able to create a warm called Same is My Hero.
So we talk about different types of cross-site scripting.
Here are a couple of variations that are worth mentioning.
One is called cross-site request forgery.
Cross-site request forgery, also known as CSRF, is a very interesting attack.
Basically, what it allows you to do is to do requests on behalf of the user, although the person didn't request such things.
Here you see a user going to the www.bank.com and doing normal online banking.
Now, let's say the person receives a mail saying, click here for some reason, and decides to click on this link.
What's going to happen next is the person is going to go to a server that is controlled by the attacker, and notice I didn't say owned by the attacker, it might be just another server from somebody that he just happens to control, and get a web page from this web server.
Notice this web page has something very interesting here.
The image source for this web page is actually not a image.
It's a URL to the bank that will actually do some actions on behalf of the user.
This page is going to be served back to the user, so the client is going to be the one actually executing it.
It's going to the server and do this transfer, this money transfer to the devil.
One thing that you can also do with cross-site request forgery, which is kind of interesting, is called drive-by farming.
Most of us these days have more than one computer at home, and for this reason we have small routers, wireless or wired routers, but those routers serve for a lot of things.
One of them is actually, it serves to direct us, our queries, to a DNS server.
So, for example, when you go to www.bank.com, you're actually asking the router to go to the DNS server and give you the IP address for that bank.
And then you can go to your bank.
Now, we just saw a cross-site request forgery against the bank, where you would forge some clicks from the user or even a transfer of money that the user didn't intend to do.
What you can do with this attack here is actually leverage the fact that a router has a HTML interface, and a lot of times the password is just the full or there's no password at all, and make this router be reconfigured to go to another DNS server.
So let's see how it happens.
You have here the click me message that the user would receive.
Let's suppose the user decides to click on this thing.
It would go to the rogue server, and this server would serve a page with some JavaScript that would go to the client and would do a request, a cross-site request forgery, and reconfigure the router to point to a new DNS server.
Once it's pointed, the next time the user goes to www.bank.com, your home router would go and lead you to a wrong DNS, a rogue DNS server, and serve you a wrong IP address.
You really would think you're going to your bank because you type it up www.bank.com.
However, you're going to something that is not your bank.com.
So we've seen the attacks, and a lot of times, even inside Semantic, I like to say that what we really teach to our engineers is defense against dark arts.
So here I'm going to tell you about some of the hopeless defense against dark arts, the things that don't work that a lot of times the engineers, when they panic and they see this kind of attacks, they try to do in order to prevent them.
The first one, and this is very common out here, is to use JavaScript to sanitize the input that you get from a browser.
This doesn't work because JavaScript can always be bypassed.
So you can do a lot of JavaScript, and I encourage you to do for performance purpose.
In other words, you want to validate in the client.
However, you always want to validate your data in the server whenever you're doing web applications.
The other thing that a lot of people try to do is to strip out some words that they see that every script would have, such as the word script.
But this is a problem because sometimes the attacker can use something like that, which is a script.
In other words, when you remove the substring script from that word, guess what happens?
It becomes script.
Another thing that people do is sometimes they allow some HTML elements to be used, such as the B for bold or I for italic.
And they think, well, those are quite innocent tags.
You have to make sure you really understand what kind of tags you're allowing.
One thing is open angle brackets, B, and close angle brackets.
But it's quite different from allowing something like this, which is B, onMouseMove, document location, a website, and then send your cookie to some other place.
So it's quite important for you to understand what kind of things you are really allowing.
Now for some real defenses and some things that you can actually do in your code.
The first one is to know your programming language, whatever is the programming language you're using.
Chances are there are good libraries that are available out there that you can use in order to sanitize input.
Here I'm showing a couple.
At the end of this talk, I will leave the slides.
And at the appendix, there's a bunch of other functions to encourage people to take a look at that can be used.
A couple of things that are worth mentioning in this slide is, again, JavaScript.
Never rely on it as a defense.
Rely as a performance enhancement mechanism, some way to offload your server, but never as a security mechanism to sanitize your input.
Also, if you don't have anything to rely on, most of the languages that I know have some type of regular expressions.
Regular expressions are debatable in the field still.
There are some authors that would say you should use it whenever you have.
Some others would say, well, I don't think it's a good idea to use because regular expressions can get very complex.
Encoding is really hard.
And if you're looking at all the encoding that we have on the Internet, which I'm going to talk later here in this talk, there's quite a lot.
What I want to call your attention here is that the encoding you do for HTML attribute, it's quite different from the one you do for plain HTML, or even for a URL, JavaScript, DBScript, or XML.
For each one of those type of entries, there is one type of encode that you should use.
So some libraries, such as the Entry Cross-Site Script Library from Microsoft, actually have different functions you should use whenever you're encoding user data that goes to HTML attribute rather than user data that is going to plain HTML.
So I want to switch gears a little bit here and talk about another very popular type of attack, which is called SQL injection.
The first attack we've seen is a way to attack the client.
Now, SQL injection is a way to attack a server.
Consider for a moment a web page like this one from General Motors.
It asks for username and password.
Very plain, everyone's seen several times pages like this, and probably you know that somewhere in the back, in the back end, there is a query like this that is running.
Select star from users, where user ID equals whatever is typed, and password equals whatever is the password of the person.
What happens if somebody enters some information like this?
Basically, the password that this person provided was single quote or one equals one, dash dash, and the last quote was commented out.
So, what happens here is basically the password is null, which is clearly not the password for Joe.
However, the next part of the statement actually says one equals one.
And last time I checked, one is always equals one, so it's always true.
So, what's going on here is this is always going to be true.
So, and true, it's always true.
So, the query becomes select star from users, where user ID equals Joe.
You don't need Joe's password in order to enter the system.
And here you see the dash dash.
What's this dash dash?
Basically, it's the way to comment out the rest of the SQL statement.
So, you comment out the last quote.
But you could make good use of it if you want.
Instead of using this dash dash, you could enter something like here, what you have in red, and then reuse that quote.
Instead of doing one equals one, you do the character one equals the character one, and that would also equate back to true.
If you don't want or you can't mess up with the password because the field is too small or because there's some restrictions, what you can do is actually do user ID equals Joe, close quote, and then do dash dash and comment the rest of the statement.
Very interesting ways of getting access to a system without providing the real password.
Now, people look at that and think, okay, with SQL injection, I can actually change one of the tables that doesn't have input validation.
Well, you can actually do more than that.
If you have the semicolon, what you can do is actually put other commands after the SQL statement.
So, one of them is drop table.
And here you have a funny cartoon, at least I think it's funny, about the Bobby drop table.
And by the way, don't try this at school.
I mean, that's not nice.
And the other thing you could do is actually use a SQL command, which is union or union all, which gets two tables and puts them together.
So, you could get some other table that is more interest for you and then try to concatenate those and use the S keyword in order to set up the name of the fields you want to show correctly.
And if you don't know how many fields you need or what their types are, you can always use type null, which goes back to any type in the system.
So, again, as we saw with cross-site scripting, we saw some flawed defenses.
Here I want to call out some of the defenses that I see over and over, and they just don't work.
So, don't fall for them.
The first one is people looking, okay, somebody is actually entering this single quote all the time, and the single quote is pretty bad.
So, I'm going to actually remove the single quote from the input.
Well, basically, if you're doing that, you don't have a security problem.
You have a usability problem.
People like Mr.
O'Reilly or O'Donoghue or O'Brien, they're going to be very mad at you because they no longer can use the system correctly.
So, don't do that.
On the other hand, some people think, okay, I can't also escape the quote if I cannot remove.
And the way you escape in SQL is basically doubling up the quote.
And here's some code that is very typical for somebody who just found out that in order to escape the quote, you have to double up the quote.
The person just put a replacement here, and then whenever you have a single quote, you just double up.
And look what happens in this quote.
Basically, before, you used to have the username, which was varchar25, and the old password, new password, which is 2525.
If you do the quick math, you end up with 75 characters here, and the command is 100 characters.
Now, let's suppose for a minute that suddenly I put the old password, and it's all quotes.
Basically, instead of 25 characters, I'm going to end up with 50 characters.
If I do that for the username and the old password, I have over 100 characters already.
And look, the size of the command is 100 characters.
What happens whenever you have a SQL statement that is bigger than the size of your variable?
In C++, a lot of people would say buffer overflow.
Well, that's not the case in SQL.
What happens is actually truncation.
So, what can it... one thing an attacker can do here is something like that.
If the person passes 18 single quotes, one capital letter, two lower case, and one digit as the new password, and the username as administrator, what's going to happen is that SQL is going to truncate the rest of the statement, which happens in the second line right after the plus,
if you do the math.
Basically, what's going to happen with this statement is the old password is going to be truncated and no longer part of the query.
In other words, you can replace the old password for the administrator with a new one without knowing the old password.
Very interesting attack.
Another thing that people... you see people doing over and over that is wrong
is actually to use store procedures instead of having the SQL statements in their code.
They just hear, store procedures is a good way to avoid SQL injections.
And that's not the right story here.
Basically, if you do a store procedure as the one you're seeing on the screen, you're actually concatenating data, which is always bad from a SQL perspective.
The right way of doing things is actually the way we see on the screen right now.
And here's an example with C Sharp.
It's using parameterized queries.
And here's the parameter, the at name that you see in the first line.
And then this parameter is added to the query whenever needed.
If you like this topic about seeing how vulnerabilities really work, giving a try, understanding more about them, I definitely encourage you to do this kind of things because the more you understand, the harder it's going to be for an attacker to use them against you.
A very good tool for that is called WebGult.
WebGult is made by oasp.org.
It's a free tool.
And this tool is a web server that was made vulnerable on purpose.
Here's the lesson on SQL injection.
If you don't get it right, it will give you tips on how to get the things right.
And you keep trying until you get, for example, the lesson accomplished.
So we talk a little bit about SQL injection.
We talk about cross-site scripting attacks.
And I want to spend the rest of this lecture talking about encoding.
I think encoding is just insane in all the types of encoding you have today.
Einstein once said, insanity is doing the same thing over and over again and expecting different results.
My question to Einstein would be, what about the opposite?
What about doing things different in many different ways and then having the same result for those things?
Wouldn't that also be insane?
In other words, if you have to do all this filtering, if you have to look at all this input that could be completely different sometimes, and make sure this input is valid, that would be completely mad.
What you see on the screen here is a web page.
And in the first line in the body, you see is this insanity.
And then you see the same thing over and over, but represented using the decimal notation, hexadecimal, Unicode hexadecimal.
So in JavaScript, you notice the way you represent the characters in Unicode is slightly different from HTML.
And you see again in hexadecimal, octal, you see is in functions.
In the last one, you actually see doing some math.
It's doing actually a bitwise AND between some number and 127.
So it's really hard for somebody to actually parse all those things and realize they all mean the same thing.
Why I'm showing this to you?
Because when you do input validation, if you don't do it at the right time, you might end up having to analyze all these kind of inputs, all these goofballs that somebody can actually throw at you and make sure they're okay.
So whenever I talk about encoding, I think about JSON, because it always comes back to haunt you.
If you consider, for example, the less than character in URLs, there's a bunch of ways they can be represented.
You can do the %3C, or you can represent %253C.
%25 is actually the percent, and it's just double-encoded.
And that would work, and the URL would be resolved.
So likewise, for Unicode, there's several ways you can represent a character.
For example, the question mark, there's two ways you can represent the same thing.
And if you are going from multibyte to Unicode, there's some ways that you can do the conversion, and some flags that you can use, such as the best fit.
And what best fit does is actually whenever a character is not present in a certain code page, it will use whatever is more, how can I say, similar to that character.
So for example, for the infinity character, it would translate to 8, because it thinks it's kind of similar.
For the prime symbol, it would actually translate to quote, the single quote, which could be a problem for sequence injection.
So you've got to be really careful when you're working with all this encoding.
So just to demonstrate this problem that we had with Unicode characters and encoding, I asked 5.0, he had a really interesting problem.
Basically, he didn't know how to translate the %c0%af Unicode for the forward slash.
And what happened is somebody was able to actually break out of the sandbox where all your webpages are and go into the system32 directory where the command.exe is and execute it.
If you can execute command.exe running as ias or system, you can do pretty much whatever you want with the box.
You could go and create the user joe and add user joe to the administrator group, you know, some of the things that you can do.
So when you find that all this encoding madness was over, there's one more attack here.
Basically, if you don't put in your webpage the character set you're going to use, some browsers such as IE are just going to guess what character sets you're using.
And something like UTF-7 could be validated by IE and used.
And here's a different way of showing the less than and greater than signs.
So just to send this issue of encoding home, let me show you some encodings for URLs.
Different ways you can say Yahoo or go to Yahoo website.
First one is just putting www.yahoo.com or using the IP address.
Everyone here probably knows about this IP address.
How many people have seen this type of way of representing a URL?
Just raise your hand if you have.
Okay.
So basically, here you see the hexadecimal representation.
And as you know, the IP address is just a big 32-bit number.
And each part of this number is actually composed of this very big number.
So here is 52.
The second part would be 93 times 256 and so forth.
If you add up all those numbers, you would end up with one big number in decimal.
And if you convert to hexadecimal, you can actually use this as the URL.
Now, if you think that is strange, you can do things that are even worse.
For example, if you use the hexadecimal representation that you just saw above and put 1, 2, 3, 4, 5, 6, 7, 8, 9 in front, it will actually work and will direct you to Yahoo.com.
So imagine you're creating an application that is actually blocking access to a certain web page.
Imagine how many ways somebody could actually get to this web page.
If you're not satisfied, here's the decimal representation.
And there's more.
There's also the octal representation.
And by the way, you can mix and match things.
So for example, you could use HTTP 0, 3, 2, 1, dot, and then use the one from the second line, 1, 9, 1, and then the dot, and then use the 5D from the hexadecimal representation, and that would all work.
So you can use all of them together.
And if that was not enough, you can do some really weird things.
So for example, Google has a button which is, I'm feeling lucky.
Whenever you type it up a query, you get a bunch of results.
If you click in that button, you're going to a random page that Google decides.
So what if Google just returned one single page and you click in that button?
What would happen?
You would go to that page, right?
Because there would be no other choice.
So here's a cross-request site forgery on Google.
They could force it to click on the I'm feeling lucky button and have one single result, which is Yahoo.
So that page, although looks like it's going to Google, is actually going to redirect you to Yahoo.
Once you see all those things with IPv4, you would think, okay, probably IPv6, they actually solve, and there's only one way to represent the IPv6 address.
Well, actually, there's several.
If you consider this IPv6 address on the top, here you can represent the same address, but without the zeros.
You just put a bunch of dots there, and you can compress it.
Likewise, you could do with just one zero instead of writing all the zeros.
Or you could compress all the two zeros that you have there and put in between the dots, or even have no zeros at all.
And that would also be a valid IPv6 address.
So in order to get your data entry correctly, you would have to know about all those things.
If you're talking about paths, paths are also kind of messy.
You have this way to get to calc.exe on Windows, or you could get using the forward slashes.
This is all valid, right?
You can also use the slash slash question mark.
And a lot of people look at that and say, hmm, what server name is that?
Well, it's not a server name.
So usually a slash slash is for server names, right?
Here you're not using.
This is the Unicode representation of a path.
And that's quite interesting.
A lot of people say that whenever you do coding, you should always prepend with a slash slash question mark.
And the reason is because if you're programming for Windows, you always have...
a lot of times you have two representations of a file name.
One is the long name, and the other one is the legacy 8.3 name, right?
If you always use the slash slash question mark, you're going to have only one representation, which is the long name.
The problem with that is that while paths in Windows are usually bounded to MaxPath, whenever you use the Unicode path, MaxPath is actually each segment of the path.
So that thing could be MaxPath, that thing could be MaxPath.
So if you're doing some programming in C, C++, you might end up with a lot of buffer overflows if you don't know how to use this thing correctly.
You can use the file protocol to get to Calculator.
If you do a start run, that would work.
You can use system variables.
And by the way, remember that system variables can be composed of other system variables, so it's kind of recursive.
You can point to your own machine and then point to Calculator.
You could use dots and dot dots, notations in the middle of the path to confuse whatever input entry you're doing.
And finally, you could use with a single dot at the end.
So encoding is really hard.
What can you do about it to prevent it?
Well, very first thing, whenever you have a system and you require data entry, make sure that you are only dealing with things you know about.
For example, my bank allows me to do transfer to other people and there's a comment field.
All I can enter in that comment field is alphanumeric characters, no more than that.
They think some characters such as question marks, single quotes and so forth are bad and they know they are.
But most important of all, they know that if I stick with alphanumeric characters, there should be no vulnerabilities.
A lot of times people try to create this blacklist.
I'm going to prevent people from using single quotes.
I'm going to prevent from using angle brackets.
I'm going to prevent to use the word script.
That often doesn't work.
The best way, the best practice in the industry is always to stick with what you know to be good.
The other thing to keep in mind which is really, really important is about decoding data.
This is the wrong way of doing and that's what Microsoft did with IAS 5.0 and the vulnerability I showed you a couple of slides ago.
Basically, they first decode part of the URL and then they did their access control.
Is the person still inside the IAS sandbox?
And they thought yes.
And then they did the last decode and that's where they decode the forward slash unicode character and that's why that attack actually worked.
The right way of doing things is actually to process all your encoding first and always be careful that some of the encoding are recursive.
So you have to process several times to get it right.
Also, there's a bunch of APIs out there that will help you with encoding.
They're going to get things in the normal form for you and those APIs are usually made by professionals who actually spend hours and hours, you know, it's a project by itself to get those APIs right.
Each language has its own APIs and I encourage you to take a look at the end of the slides in the appendix session.
There's a bunch of APIs or look at your manual.
Or if you want to look at something else, there's also OWASP.
There's this ES API, which is a collection of security features and security, how can I say, functions that can be used in your Java or .NET application.
Also, a very good collection of APIs you can use.
So, to conclude this talk, after talking about how easy it is to do cross-site scripting attacks, how easy it is to do SQL injections and so forth, I want to leave one thought with you.
We need to raise the bar.
In other words, in the past, in order to steal a bank and get the most valuable asset, your money, you would have to blow up a vault.
You would have to pass the guards.
You would have to, you know, use guns or use violence in order for that to happen.
This way, to a big extent, it seems that all this protection became into your username and password, which is something that is our duty to do it right and to prevent those kind of things from happening.
I thank you for your time, and I'm open for questions.
Do you have any questions?
Yes.
Can you turn on your mic?
You may have to repeat the question.
Click-checking is about having an overlay over a web page.
So, you can say it's a frame that is transparent that goes over the web browser.
So, you would think that you're clicking in some part of the page, but actually you're clicking in this frame, which is in front of the page.
And then you could, you know, go to other websites or do things that you didn't intend to do otherwise.
So, the question was what's click-checking and whether it's a vulnerability of the browser.
It's an interesting question because the people who found about click-checking, R Snake, he actually felt it was a vulnerability of the browser.
But when that was reported to Adobe, which was the makers of Flash, they felt that it was a vulnerability in their code and they had to fix it.
Because you shouldn't have a Flash applet that goes in front of the browser and that is transparent.
So, that's debatable.
I'm more leaning towards it's a vulnerability in the browser.
Do you think that it's possible to make a system that doesn't have a security vulnerability?
This morning I was reading a quote from Professor Spaff and he was saying that a secure system is the one that is spared.
I can't remember how many feet it's underground and it's in a safe and so forth.
I agree with that.
Basically, the way we build systems these days is based on technology.
The underlying technology is already flawed.
So, for example, if you add two numbers in a computer, two positive numbers may lead to a negative number.
We try to simulate math, which is infinite, with finite data.
So, just looking at that, it makes it really, really hard to make a system without flaws.
So, what I believe is you cannot make a system that is completely secure, but you can raise the bar.
Just like the bank.
You could steal any bank you want, but at some point you're going to spend more money trying to steal the bank than it's worth.
So, if you raise the bar enough, we're going to keep honest people honest.
And I think that's pretty much our goal here.
Yeah, I have a question.
Some of these SQL injection attacks, what that really is is a problem of you have a bad API and a good API.
Use the good API, the attack disappears.
Yes.
To what extent are some of these other things a case of we've designed bad APIs, and if we could just eliminate those bad APIs and only use the good APIs, we'd be okay?
There's a lot of the problems that we see often out there.
They're based on bad APIs.
People learn how to program in C, C++ using store copy, store cat, for example.
They learn how to do PHP or ASP.NET.
And the first application is hello, your name.
And that application, in most of the books that I've seen, is vulnerable to cross-site script attack.
I honestly hope that those problems are going away as languages become more secure and APIs evolve.
However, there is also the security problems, such as how to handle authentication, which are more complex.
And I think moving forward, those are going to be the big problems to tackle.