Conceived in insecurity, the Internet's a rotten place for application integrity or transaction trust

Dark Reading Staff, Dark Reading

March 6, 2007

3 Min Read

3:00 PM -- For the last few days I've been thinking a lot about the way the Internet works and, more importantly, how it began and evolved. You can see a clear path from where the whole thing started to where we are today. But let's boil it down even further to understand a basic -- and persistent -- security conundrum.

When did the first program begin?
It all started with a line of code, a simple fragment of a function perhaps. Later on it evolved and added features. The program became more and more robust. Eventually it had beta users, and after many years, we end up with MySpace, voice over IP, and streaming video. But it all started with simple concepts. The program had a beginning, and that's its Original Sin: It was conceived. And unfortunately, it was not conceived with security in mind.

Like humans, programs are half nature and half nurture. By nature, the Internet was never meant for secure transactions, but by nurture we are trying to make it such a place, while still retaining backwards compatibility.

When the Internet was first getting started the wave of the future was going to be Gopher. It was going to be a text-based world, with hyperlinks. More like card stacks than a truly dynamic experience.

Later HTTP overtook Gopher. It was a stateless protocol with very few security features in mind. In fact, other than a few things like basic authentication and cookies meant to remember sessions, it really had no security whatsoever.

Later the industry and consumers demanded security, so things like SSL and secure cookies were invented. They became standard, but the underlying statelessness of the Internet was still a burden. The original sin continued to follow it.

Much later, bad guys came up with a concept of session riding, where they could use people's browsers against them. No problem, the security industry thought, we can just use one-time tokens to protect ourselves.

Yet another bolt-on. Then the bad guys came up with another concept called cross-site scripting (XSS) that broke the same origin policy and allowed the attacker to read the one-time tokens. The security community reeled and then began bickering about the best ways to stop XSS. There are many answers, but the problem is who's using these new bolt-on security methods? They aren't standard in any programming language yet.

Now you tack on things like Ajax and JSON and single sign-on and all the other consumer features that people are coming to know and love. The Internet development is far outpacing security development. That is, the security of the Internet is lagging behind the development of new exploits against the Internet, especially in the last year.

The browser community was fairly shaken with all the new damaging exploits that take advantage of both the Internet and browser software. It's going to be an interesting year as the browser companies try to address all the new issues, while attempting to compete with each other on new features.

Meanwhile the original sin will stay intact, requiring ever more bolt-ons to protect it. But knowing the Internet's original sin and its lack of security by design, the real question remains: Is the Internet the right place to perform secure transactions?

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F* Special to Dark Reading

About the Author(s)

Dark Reading Staff

Dark Reading

Dark Reading is a leading cybersecurity media site.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights