![]() |
|
11.12.08 How Can We Protect Web 2.0 From The Cyber War By
Dan Morrill No Surprise security engineers falling behind in hacking skills. There is no reason that we should as a security profession be losing the cyber war, or failing to protect our companies, and our friends from cyber attacks. We have all been through enough training, education, and certification that against the threats we deal with on a daily basis we should be at least holding our own rather than losing. We should at least be able to address the issues procedurally, technologically, and personally to make sure that we can protect our companies. If we look at the number of threats, from Web 2.0 applications, API's, applications, operating systems, and networks, we need to make sure that we are running as an untrusted environment. Where we spend time working out how the untrusted connection can try to usurp the way that our systems work. Web 2.0 opens the door to a number of exciting avenues for hackers and hacking. We have all heard of CSRF, but has anyone ever sat down and said This is how you fix it in ASP Commonly Used: Request.Params["foo"]; Solution: Use HTTPRequest.Form (Request.Form) which grabs POST only. (CGI Security) There are so many simple solutions to solving so many of the attacks that I see in web 2.0 security research that it is amazing, after as many years as we have been trying to do secure code, that we still fail over on the fundamentals. How you code, and how you review code for security should be a team effort, and is often more successful if everyone in the room understands the basics to fixing flawed code.
There are really good ways to see how your page loads, by using firebug and its IE equivalents, or even just going through to see if any of the parameters are hack able. These are the ways that malware gets into the system, and how you end up with an IFRAME that points to some evil server somewhere that is serving up other forms of malware that takes advantage of the security models that browsers use. All it takes is one bad call to open up the entire system to exploitation. These are the things you should be looking for when it comes to securing the code that web 2.0 runs on. All of this kind of knowledge is easy enough to find on Google, the question I have is why we are not paying more attention to it. As we move into cloud computing environments, offsite storage of live data, and other ways that we move the computing and storage parts of the program to third parties, it becomes more important to validate code. It becomes more important to make sure that the code that is being written uses the right techniques to ensure that the program is not easily hacked. The problem is that we are not doing this, and the question is why are we not doing this? Is it education or training, support, money, time, energy, certificates, or what is it that we are not doing that has lead us to hacked web 2.0 applications? As we move deeper into the API mashup, social networking web 2.0 style systems, the ability to protect our data against theft is going to have to be where the code intersects with humans. This means we have to pay attention to code, and how it is written to make sure that it is secure enough, to protect against random hacking, and the theft of information off those systems. So far, we have failed to do this, and we need to figure out why. Comments About the Author: Dan Morrill has been in the information security field for 18 years, both civilian and military, and is currently working on his Doctor of Management. Dan shares his insights on the important security issues of today through his blog, Managing Intellectual Property & IT Security, and is an active participant in the ITtoolbox blogging community. |
|
| ||||
-- EnterpriseSecurityNews is an iEntry, Inc. publication -- iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 2008 iEntry, Inc. All Rights Reserved Privacy Policy Legal archives | advertising info | news headlines | free newsletters | comments/feedback | submit article |