|
|
||||||||||||||||||||
| Home > Software Quality News > One simple rule to make your Web apps more secure | |
| Software Quality News: |
|
||
The book itself doesn't teach anything about secure coding. The only thing the book teaches is examples and techniques of how hackers break into Web applications. If a developer reads it, it will hopefully open their eyes to see exactly what kinds of things a hacker can do with mistakes that they make, and allow them to realize that security holes aren't just bugs—they're not simple little bugs that they can fix later. These are big problems that they have to deal with in their code. What threat do you consider the most dangerous to Web applications and why? SQL injection requires no third-party intervention like cross-site scripting (XSS) does; all it requires is a hacker finding a hole and exploiting it, and you get access to all the data right there. Finding a cross-site scripting exploit in a Web site allows you to affect a lot of people, but the fact still remains that the user has to view that link or view the cross-site scripting exploit or at least click on it. It still requires third-party intervention, and even if that third-party intervention is there, it still requires the hacker to obtain usable information from that third party. We'll give you an online dating Web site example. In terms of a SQL injection problem, what a hacker can get access to is the back-end database of this site. That database will contain profiles, user information, passwords to accounts and credit card data. Not only does the SQL injection vulnerability give them [access to this], but it probably also gives them the ability to control that back-end database to get access to the internal network of the company that runs the online dating Web site.
Say this online dating Web site has cross-site scripting. And say I infect every user of that system with my cross-site scripting exploit. Now what do I do with it? Well, I can try to capture the keystrokes in their Web browser and capture any data they have for the instance of their Web browser being open and hope they enter things like credit card numbers. I could also do something like make them click on banner ads that might make them pay me money in terms of clicks, but here's the thing: I don't get it immediately, and it's not guaranteed I'll get everybody, and it's not guaranteed that I'll get other types of information. So you can see where the severity breaks down. SQL injection by far is much more dangerous and much more critical. Why is cross-site scripting getting so much attention? Now let's add Web 2.0 social networking. In order for cross-site scripting to have any impact or to make any danger or damage to a user, that user has to view the exploit or click on the exploit. Now that social networking is a big deal, everybody wants to view everybody else's stuff. Now I have a venue that's very popular for people to view things that other people have written. I have a nice attack avenue for my cross-site scripting. So all three of those together [Ajax, cross-site scripting and Web 2.0] makes cross-site scripting the new hot thing today. You talk about new SQL injection techniques in your book. Can you hit upon one that is very dangerous? Is there one thing a company should absolutely do to help make their applications secure? [In] companies today, usually their developers' time is spent on functionality and getting things out the door. They are very time-constrained, and in order to make developers learn about security, it takes a lot of time, a lot of education and a lot of looking over the developers' shoulders to see that they do the things correctly. That can take years to do properly. And even if you do that, there is going to be a certain percentage of developers who pick it up and apply it and a certain percentage who just don't care. And in most organizations, that percentage of people who care and apply it are probably 5%, while 95% just goes about and does what it does. So if you want to write secure Web applications and you want to do it quickly and efficiently, give them one simple rule to apply. Don't worry about anything else; just do the one thing. Once they do that well and they take that step, you have successfully made your Web application 80% more secure, guaranteed. I'm not saying ignore those vulnerabilities in your code. You have to fix them, but if you do input validation first, that at least gives you the time to go through and fix the others. There's been a significant increase in the number of Web application attacks over the last year. Are there really more attacks or are companies more willing to report them now?
Should hackers contact a company first if they find a vulnerability and give them a chance to fix it before posting it in a public forum? Should they even be testing the sites without the company's permission? Caleb Sima is a well-known expert in emerging security threats and penetration testing. He is the founder and CTO of Atlanta-based S.P.I. Dynamics Inc., a Web application security testing software and services company. He is also a co-author of the recently published book Hacking Exposed Web Applications, Second Edition.
'); // --> |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
| |
|
|||||||