The Internet's Original SinThe Internet's Original Sin
Conceived in insecurity, the Internet's a rotten place for application integrity or transaction trust
March 6, 2007
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?
About the Author(s)
Tricks to Boost Your Threat Hunting GameNov 06, 2023
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
9 Traits You Need to Succeed as a Cybersecurity Leader
The Ultimate Guide to the CISSP
Protecting Critical Infrastructure: The 2021 Energy, Utilities, and Industrials Cyber Threat Landscape Report
2021 Banking and Financial Services Industry Cyber Threat Landscape Report
5 Reasons To Move your PKI Deployment to the Cloud