This is why: “Apple security blunder exposes Lion login passwords in clear text”

No need to go into details as to what happened here; it’s well-researched in the linked article. However, this is exactly the scenario that development security testing is meant to avoid. A seemingly innocent patch disables or circumvents an important security feature. The results are predictable.

It could be worse, though. Here’s the worst case: the problem isn’t detected. Because the security was included in the original version, and because nobody checked, it is assumed that the security is in place, and successive updates are made, with the security feature in question not working, but everyone assuming it does. And successive patches are built upon the circumvented security. by the time the bug is discovered, fixing it is a gargantuan task.

So, it’s not that bad. It’s still a major breach, though. So if you ever wonder if that testing is really necessary during development, you can point to this incident and confidently say “Yes.”

First was with my mechanic. I like my mechanic – they’ve saved me quite a bit in the past. But they’re notoriously bad about answering the phone. However, they are surprisingly up to date for such a shop. They have a website which allows you to schedule your appointments online, no need to call. That’s great!
Necessarily, this means you need to have an account on the website. Okay, this makes sense: they track your name, contact information, kind of car you have, and the car’s maintenance history including mileage. While nothing there is particularly incriminating or dangerous unto itself, it’s not the sort of information I’d like to have broadcast to the world, either. So it’s good that this information is kept in an individual account not available to others.
However, I admit that I couldn’t recall my password for that account. No problem, I put in the username and requested a password reset. The automated tool asked for my email, which I gave, and it sent me a new password.
Do you see the problem? It wasn’t asking me for my email address to confirm that I should be the recipient of that password. It was asking in order to know where to send the new password. There was no confirmation process; it just sent the password to the address I’d provided.
And that’s how I got into someone else’s account. My first clue was that I don’t own a Mitsubishi. No harm done – I didn’t even get the person’s contact information, I simply figured out my correct account name (I was off by one letter) and logged in properly. But that’s no security at all.

On the flip side, I wanted to get support for a piece of electronics I bought recently. I was looking for a driver for it, and couldn’t find anything, so I thought I’d go ahead and contact their support team. In theory this should be a straightforward enough thing. In practice, not so much. You have to open an account with the manufacturer. For which you need to own an actual product. Now, that’s a bit of an issue – what if I was looking at buying a product and wanted to know beforehand if the driver existed? But I already owned this item. So I went to open the account (and set up to handle all the forthcoming spam, I’m sure.) Part of the process involves saying just which device you own. Now, the item I had wasn’t listed. I made the best match, a similar item with a different model number. Shouldn’t make a difference, right?
Oh, but it does. The item I selected is listed, for some reason, as out of warranty. And on that I was frustrated – I cannot make inquiries about an item which is out of warranty.
I’m sure this system reduces needless support requests. In this case it also prevented a real request; I won’t be buying this company’s products in the future.

What can we learn here? Well, two companies, two lessons.

In the first case, make sure your system applies basic security. My mechanic has relatively trivial information on me, sure, but they have some information, and they’re not securing it well enough. The idea of a confirmation before resetting a password has been “best practice” for longer than I can remember. If you’re going to bother having individual user accounts, there’s no excuse to not treat them with at least some security.

In the second case, your security shouldn’t get in the way of your business. Sure it’d be nice to be able to make sure every single contact was authenticated and properly routed, but if you have any reason to deal with the public that’s just not going to happen.

The overall lesson is that even if you’re a small company, your security has to match your needs. An off-the-shelf solution without any thought behind its application won’t do you any good.

No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

Obviously, that’s not the sort of thing you want to put on a postcard; you’d put that in an envelope. (Your brother is notorious about checking his email).

You want him to know that the letter is actually from you, so you sign it – you have a distinct signature that is very hard to forge. And, on top of that, you want him to know that nobody else read the letter, so you also sign across the fold of the envelope, so it can’t just be put in a new envelope.

So, you’ve done the basic security – it’s authenticated (with your signature), it’s not readable by third parties (because of the envelope) and it’s tamper-evident (because you signed the envelope, too). It’s not the most secure communication possible, but you’ve clearly done due diligence.

So what if I told you people were doing that almost 4000 years ago?

Sealing letters in clay envelopes was standard practice. Sometimes it was used for security; other times, in the case of contracts, the contract was written on the inner tablet and the envelope, and both marked with the personal seals of the signatories, making the text of the contract accessible while still having an unalterable copy in case it came into question.

People have known for millennia that secure communication is crucial to business. We’ve known a need for privacy, authentication, and tamper evidence. These aren’t new ideas at all.
However, we seem to have a hard time applying them to modern technology, sadly. That’s the only reason I can figure out to explain why yesterday I had someone asking me to email a scanned image of a check without any encryption.

It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

How? How could I turn an entire manual into a completed questionnaire in 3 days? If you’re thinking “An awful lot of copy and paste” you’re on the right track, but you haven’t fired up the engine yet.

Before I started the project, I had sought and gained permission to try something different. I decided to try Topic-Based Authoring. With topic-based authoring, rather than create complete documents I create small topic “nuggets” (I prefer to think of them as Lego bricks, but the technical term is modules) which consist of one or two standalone paragraphs on a single topic. I acquired some inexpensive software that integrated between Word and SharePoint, and after loading my nuggets into SharePoint I could assemble them in any form I desired, leaving me basically to write the introduction and conclusion to a given document and select what information should be included. Since I had determined what nuggets I would write based on the certification requirements, I knew I already had all the information they needed. So all I had to do was insert them into the questionnaire, check to make sure the formatting was correct and that each question was fully answered – or if not, edit the nugget in the database NOT in the document itself – and sing the praises of topic-based authoring.

Needless to say, I love topic-based authoring. It’s not just about being able to restructure documents quickly. It’s also about being able to rapidly change information. While I was working on the documentation, development was still ongoing. I was able to change single nuggets of information to reflect changes in the system, rather than going in and changing each document. And because I wasn’t sitting and staring at a given document for days or weeks, it reduced burnout. As an added bonus, I was even able to get some of the subject matter experts (SMEs, e.g. developers and system administrators) to write up about specific components, saving time and effort.

Topic-based authoring can be hard to implement. It’s not for everyone: the software can be expensive, the cost of changing documentation methods can be immense, and reusability may be very low. But whatever your documentation method is, you should think about being able to do what I did. Your documentation should always offer the following:

It should be accurate. I can’t say how many times I’ve found outdated documentation that simply doesn’t reflect current systems or processes. As an auditor, that tells me the documentation isn’t maintained, and that means I can’t trust any of it. That means my work will take longer, and ultimately that will cost you money.

It should be flexible. You never know when you’ll need to change formats, add data, or meet some other unexpected demand. A company’s ability to meet new demands is one of its most important skills.

It should be fast. “I’ll get back to you in a month” hasn’t been an acceptable answer since the 80s. No matter what it is, you’re going to have to generate new documentation at a pace that would have been considered simply impossible, regardless of resources, before modern computing.

It should be consistent. All of your documentation should reflect the same information. Anything less will reduce confidence and engender confusion. And that’s never a good thing, no matter who reads it.

Good documentation practices are life and death to any company. It’s always tempting to wait until you need documentation before hiring a tech writer. Let me resolve that quandary: you need good documentation Right Now. Because if you wait until you realize you need it, it could well be too late.

I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way.

Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I resorted to Ebay. Long story short, I found an LG Optimus S – a rather sturdy little phone for its age for $7 plus $4 shipping. The description said that it did not boot. Being the hacker that I am, I generally don’t let simple statements like that deter me.

A few days later I had the phone in my mailbox. It even included the battery, which I wasn’t expecting. I attempt to boot it up, and as described – it doesn’t boot. I plug it in to ensure it has a charge. It won’t charge. I pull out the voltmeter and quickly determine the battery is junk. Fast-forward two more days after a visit to Amazon (Prime). A new battery is awaiting me in my mailbox. Plug it in, viola, Android magic!

Immediately after boot up I notice the first notification is a voice mail. Seems the user never did reset the device. Being nosey, I check the notification. Something about John borrowing the truck for an extra day. I hope Sam¹ didn’t miss that voice mail. I check the contacts, and once again, it is full of names and addresses of people I’ve never heard of. Popping into the app drawer, I notice that not only does all the user data remain, but so do the apps. At this point I’m ready to simply go ahead and do a hard reset as I have zero interest in any of the previous owner’s old apps or information. But then this catches my eye:

Chase Android App

That’s right, the Chase Banking app. Immediately, my heart sinks. I already start to dread what I presume I’m going to find. I open the app, click the login button, and literally face-palm. Username jxxxxx, Password ********. The user’s login details were saved in the application. I’m now one click away from being in someone else’s bank account. At this point I’m feeling extremely paranoid, and my white-hat mindset kicks in. I pull the battery, put it back in, and proceed to hold the home key, volume down key, and power it into the recovery screen. A couple more volume clicks later, and the device is completely formatted and returned to its factory settings. The old data is wiped.

As I mentioned, I was already fairly certain as to what I was going to find before ever even entering into that Chase app. Why? Most people do not understand the consequences of their actions, especially when it comes to security. Nor do they even consider it when dealing with the majority of technical things they do on a day-to-day basis.

So for those of you wondering, let’s review some of the steps that Sam¹ should have taken.

1. Upon boot up, the device went straight to the launcher. No pin, password, or swipe gesture was required. You should always protect your devices with some sort of locking feature. This is especially true if you have sensitive data stored on your device. If you use your device to access your company email or remotely connect to your company network, this should definitely be part of the company policy. It’s easy to configure within Exchange as well.
2. The user stored sensitive credentials within apps. Storing your password for something like your gaming account is one thing. Even allowing Android to automatically log into your email is a little risky, but saving the username AND password to your banking application? That’s just asking for trouble. NEVER store credentials in any application that you wouldn’t want someone else having access to! End of story.
3. The user sold a device (knowingly) without performing a reset or wiping the data. This policy holds true for more than just cell phones. But let’s face it; we are all even more connected to our phones today than ever before. I’d go as far as to say some even use them more than their actual computers (for personal tasks). If/when you sell electronic devices, you should always perform a format, or wipe of all stored data, whether this is a factory reset of a phone, a format and reinstall of a laptop OS, or even a full DoD multiple pass wipe. Always destroy your data before releasing your devices to the public.
4. The fact that Sam¹ even had his banking app on his phone can be viewed as a flaw – but I’ll let that one slide. I personally choose not to keep anything on my devices that can associate me to what my banking information may be. I go even as far as to ensure that any emails I get from my banks are sent to an email address that isn’t associated with my default Android account. Paranoid, perhaps. Secure, you bet!

I will take a slight bit of leniency on Sam¹ based solely on the fact that he thought the device was toast. But this is even more reason why you should take the steps necessary to ensure the device is wiped clean before getting rid of it. And for the average Joe (Sam) it’s not always obvious how to do these tasks. I had to look it up myself for this specific device (Android tends to vary the button combination per device). But in this case because the phone wouldn’t boot with the dead battery, Sam wouldn’t have even been able to perform the reset without some other form of digital magic.

Moral of the story: Wipe your devices, lock your devices, and don’t store credentials to sensitive information!

¹ Sam is a made up name, unless his name really was Sam, in which case it is purely coincidental.

To some people, it might come as a surprise that I’d consider that a good assessment. And I’ll admit, it made me a bit suspicious. Nothing? Seriously? Well, I had to look into why, and I’ll get to that in a moment. But let’s cover something else first.

I’ve been on both sides of the table for security audits. Being audited is Not Fun. You have someone coming in, looking over all your processes, and it’s up to you to prove that you’re doing what you’re actually doing, often for reasons that seem terribly arcane or pointless. And the management directive is almost always “make sure we pass this” which is assuredly not the same thing as “make sure we are actually secure.” It’s a very adversarial relationship.

As the auditor, you’re always looking for the places where they’re trying to hoodwink you, trying to gloss over something, or just outright lying. You’re always suspicious. If you’re not when you start, you will be. Because the people you’re auditing don’t want to be secure – they want to pass the audit. Which is understandable – failure can mean losing their license to operate, losing a major contract (clearly, one that’s big enough to bring in an auditor!) and in extreme cases bringing down the company.

It doesn’t have to be that way. As a security analyst, my goal isn’t to find problems. It’s to locate any security gaps that may exist, and where appropriate offer remediation steps.

Aren’t those the same thing, though?

Well, no. As the old saying goes, “seek and ye shall find.” I’ve met many auditors who took delight in writing overwhelmingly negative, scathing reports. They’d pounce on any excuse to fail a control. Which sounds like they’d at least be informative, but realistically the resultant reports aren’t all that useful – they don’t give much true concept of the security posture of an organization, because they’re invariably negative.

The problem is that nobody is really looking at the true purpose of security audits and assessments. Organizations being audited just want to get through the audit. The auditors are trying to “catch” the organization. But security audits aren’t high school tests or witch hunts. The end goal isn’t the report. The end goal is an organization, system, or project with a good security posture and no known gaps.

That’s what made the assessment I did last week so unusual. You see, they were given the standards in advance. They knew exactly what I was looking for – and so they went out of their way to make sure I’d find it. They had purpose-built the space specifically to meet the standards. There was no gotcha, no hidden agenda, no posturing or hiding. I knew they’d set things up to make sure my assessment would be good – and that’s great. It’s the way it should be, and the result was a completely clean assessment.

Of course, there is a risk. Organizations may know what the standards are and then try to pretend to follow the standard, or look for loopholes. That’s where the auditor really comes into play – to recognize when an organization is trying to follow the letter but not the spirit of the standard. But the most important thing to remember, for both the auditor and the auditee, is that the goal ultimately, is security – it’s not to play gotcha, it’s not to hide gaps. It’s to find and close the gaps that exist.

I plan to facilitate discussions about both what is wrong with Security Policy, and what works to improve it. Google’s new privacy policy will likely come up in discussion, along with some of my notions on prioritizing policy.

I invite all those who have had to write policy, read policy, and/or put policy into practice to attend. It should be a good discussion, and when we’re done I expect everyone will have learned some things that they can put into place the next time they are writing or editing security policy.

To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.

Background

Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.

One feature commonly classified as part of HTML5 is local storage, a method for saving content on a visitor’s device that offers more space and flexibility than previous options (such as cookies). While intended as a client-side analogue to database storage, local storage has increasingly served another purpose: code caching. If a web app routinely requires large blocks of JavaScript, it can avoid downloading those chunks every time a visitor returns to the app by saving a copy of them in local storage. This can provide a significant performance boost, particularly on mobile devices, where bandwidth and typical caches can be much more limited.

Local Storage Attacks

However, this approach opens new possibilities for attacking the app. If the local storage can be compromised, an attacker could inject malicious code that persists in the client-side cache. This payload would then be executed by the web app each time a user opened the site – even if they’d previously closed the browser. In fact, eradicating such code can be quite difficult, and the victim website might not even be able to detect an ongoing attack. Artur Janc, a security engineer at Google, outlined these issues in a talk last December (video) detailing many of the dangerous ramifications they present, but as Janc notes, such an attack was also previously described by a paper from researchers at Berkeley (PDF) in May 2010.

Given the restrictions on access to a site’s local storage, modifying code saved there would nearly always require another vulnerability in the app as an initial attack vector. However, just one entry point for injecting code in a page would be enough to change the cache, and such problems tend to be quite common across the web. Many of these vulnerabilities (described as cross-site scripting, or XSS) are “reflected”, in that they only change a particular request for content, but using local storage automatically makes them capable of launching persistent attacks. Essentially, caching code in HTML5 local storage actually makes any existing cross-site scripting vulnerabities more dangerous.

And as influential researcher Michal Zalewski also noted a few months before Janc’s presentation, “if content from the compromised origin is commonly embedded on third-party pages (think syndicated ‘like’ buttons or advertisements), with some luck, attacker’s JavaScript may become practically invincible”. In this age of mash-ups, data from a variety of sources are often mixed together, creating implicit trust relationships that may have significant effects on the security of an app. When a developer includes third-party JavaScript on his or her site, that code has the same capabilities as any other script on the page. Of course, modifying a static file on a remote server is generally not possible, even if cross-site scripting issues are present. But what if a third-party script from a site with XSS problems also stored code in local storage?

Vulnerabilities in the Wild

As it turns out, this is no longer a hypothetical situation. Apture was a start-up that provided pop-up boxes for exploring content related to highlighted terms in a page. The service garnered praise from various tech media outlets, and the company was bought out by Google a few months ago. Just over a week ago, Google shut down the embedded search functionality, which was still in use by several sites after the acquisition. Apture is one example of a third-party “widget” service that used local storage code caching – and a page on the same domain as those scripts had a reflected XSS vulnerability which could be used to inject malicious code in the cache. This code would then be executed in the context of the site using Apture, meaning the problem with Apture’s service affected the security of many sites across the web.

And while Apture’s widgets are now offline, another service still operating on high-profile sites was recently found to have a similar issue (though in this case, scripts were not executed from the original site’s origin). This problem has been reported and is currently being addressed by the service’s engineers.

Reducing Risk

Ultimately, there isn’t a simple way of avoiding this type of vulnerability while still getting the performance gains of client-side code caching. Another new HTML feature, application cache, is actually geared towards precisely this use case and would be harder to compromise, but it can create UI warnings in some browsers, such as Firefox. (Such warnings are a good practice, but may be unwanted for third-party widgets.) Ideally, any data in local storage should be treated as untrusted, even if it’s just content instead of code. But if local storage is used for scripts, it should be accessed from a domain that only serves static files. This will help reduce the likelihood of an XSS vulnerability that would have direct access to local storage, though the overall structure of an app should be taken into account to prevent indirect access as well. Newer browsers also support features such as sandboxed inline frames and Content Security Policy that could help limit the impact of embedded widgets if they became compromised.

I think it’s important to note that many smart people, including those behind Apture, have used local storage for caching app logic – even Google and Bing use a similar technique on their mobile sites – and that in theory, this method should not make a website less secure. And for many web developers, it may not be immediately obvious why local storage data should not be trusted. This is another case where a clever trick that serves its primary goal very well has unintended consequences when considered in a broader context. It’s also an example of possibly making trade-offs which balance usability with risk. Understanding these conflicts and connections is part of what information security is all about – and what we do at Gemini every day. As browser features continue to expand and sites continue to integrate services from other domains, it’s likely we’ll see many more examples of security issues evolving in complexity – and organizations will need to adapt to such changes while still reducing risk.

Special thanks to @0x6D6172696F, @lcamtuf, @theKos, and @kkotowicz for their help with this research!

Technical Details

For a site to use Apture widgets, the owner included a bit of JavaScript on their pages:

<script id="aptureScript">
(function (){var a=document.createElement("script");a.defer="true";
a.src="http://www.apture.com/js/apture.js?siteToken=XXXXXXX";
document.getElementsByTagName("head")[0].appendChild(a);})();
</script>

This dynamically loaded an external script hosted on apture.com with a site token specified. The external script included various parameters, such as title, logo, and search URLs that are associated with the account identified by the token. This code then loaded another script based on the user’s browser which actually began setting up the framework for Apture to integrate with the site’s content.

For browsers that support it, HTML5 cross-document messaging then came into play. The Apture script inserted an inline frame into the page that loaded a file from cdn.apture.com. A callback function allowed this iframe to pass messages back to the original window context where the script is running (the non-Apture site). This iframe then loaded the actual app logic and passed the code back to the original site via the cross-document messaging interface.

At this point, you’re probably wondering why Apture didn’t simply load the app logic as another script in the original page; in fact, that’s precisely what Apture did if the browser didn’t support newer HTML5 features. But Apture’s iframe setup allowed them to take advantage of another HTML5 innovation that made their service load much faster. Web storage functionality provides the localStorage object, a place to save key/value data on the client which allows for more space and flexibility than cookies. This storage is persistent across browser sessions, but is specific to each domain and access to it is restricted by a same-origin policy.

Apture used a localStorage object for cdn.apture.com not only to save data, such as an ID for tracking users, but to actually cache their app logic code. If the cdn.apture.com iframe detected that this cache already existed, it would simply load the code from localStorage rather than issue another HTTP request for the 272KB worth of JavaScript – saving time and bandwidth. Apture introduced this functionality in January 2011.

But how does one load code from localStorage? For Apture, with this line in the cross-domain callback function:

window.execScript ? window.execScript(f) : window.eval(f);

Seeing code such as this should immediately raise red flags in the mind of any web developer. Those familiar with browser security may have heard the adage that “eval is evil”, and it certainly applies here. The eval function (or the analogous execScript function also seen above) treats its input as valid JavaScript and simply executes it in the current window’s global context. If an attacker can send malicious code to the function, that code will also be executed – a class of vulnerabilities known as cross-site scripting (XSS).

In Apture’s case, though, the code came from the cdn.apture.com storage, so one might assume it can be trusted – in theory, only pages from cdn.apture.com can modify the localStorage cache. But once again, the power of cross-site scripting demonstrates that many seemingly trustworthy data sources are still potential avenues of attack. The presence of any XSS on a cdn.apture.com page, including reflected XSS, would allow an attacker to execute code in that domain’s context and thus modify the localStorage object.

As it turns out, Apture did have an exploitable XSS vulnerability. The cdn.apture.com domain actually mirrored www.apture.com, including a topic page that loaded a topic title from the URL path and a YouTube video ID from a GET parameter. Both of these values were included in the page without being escaped to prevent XSS. This example URL includes a script that appends “alert(document.cookie)” to the app logic in localStorage:

http://cdn.apture.com/search/xss?yt=%22%3E%3Cscript%3Eif%28
window.x%21%3D1%29%7BlocalStorage%5B%27app-49971756%27%5D
%3DlocalStorage%5B%27app-49971756%27%5D%2b%22alert%28
document.cookie%29%3B%22%7Dwindow.x%3D1%3C%2fscript%3E

The window.x logic ensures that the code only executes once, since the parameter appears in the topic page multiple times. In an actual attack, more code would likely be needed, as the specific localStorage key includes a version number that could change depending on the user. This does not stop the attack, however, as the correct version can be loaded by the script before making changes to localStorage.

Once this vulnerability is used to insert attack code into localStorage (e.g. if the above URL were loaded in an invisible iframe on an attacker’s site), visiting any site that had Apture’s widgets would cause the attack code to be loaded from the Apture iframe and executed in the context of the non-Apture site. And since this is essentially an example of DOM-based XSS (the code is loaded dynamically on the client side), requests sent to those sites’ servers would not include any XSS fingerprints, such as <script> in a GET or POST parameter. In summary, the localStorage code caching turned one reflected XSS vulnerability on Apture’s site into persistent, client-side XSS across all domains using their service.

I won’t bore you with the typical arguments about how it’ll infringe on free speech, or weakens safe harbor, etc. These arguments have been made, and they may have some validity, but let’s talk technology.

SOPA is the most recent in a long line of legislation intended to regulate the internet. Such legislation is doomed to failure. The internet was designed to be impossible to regulate. SOPA focuses on preventing search engines from directing users to sites, and ordering domain name registrars to delist sites. While there are other provisions, these are the primary tools for stopping piracy outside of US jurisdiction. They’re supremely ineffective tools, because neither search engines nor DNSes are necessary for the function of the Internet.

To understand this, let’s step back and look at what the Internet really is.

The Internet, or rather its precursors, were created in the 1960s as a result of an initiative by DARPA – the Defense Advanced Research Projects Agency. DARPA is notable for investing in all sorts of interesting projects that might have military applications – many are successful, and result in some of the most powerful technologies of our time. Granted, many are pretty off-the-wall and don’t look like they’ll ever amount to anything, but that’s the risk you take.
The Internet was created to enable communications even against attempts to disrupt the network – even against the loss of most metropolitan areas, such as might happen during a nuclear war. This is actually very hard to do: you have to come up with a design that works even if all of your central nodes are gone.
The Internet as we know it today has a number of elegant solutions which make it the most robust communications network ever known.
The first is in the data packet. All data sent on the Internet is broken up into packets – even when it’s called “streaming”, it actually consists of content that has been broken up into separate packets which are then reassembled at the destination. Each packet, in turn, has a portion that says to where the information is going (the address) and a portion which contains the actual data (payload). This means that any given packet can be lost or corrupted, and the entire rest of the message will still get through. Granted, with encryption or compression this might be a moot point, but on the other hand with error correction it can actually be made even more robust.
Beyond that, there are the routing protocols. Various routing protocols work somewhat differently in ways that are hard to describe, but they all serve roughly the same function. When a router receives a packet, it looks at the destination address and tries to find a route to that address. What’s especially clever is that if a given route fails, the router can then select an alternate route. In this way, the Internet can be self-healing. Bandwidth might drop as alternate routes are used, but so long as a path exists the message can still get through. And that path isn’t limited to even the same medium as was used in the past: Internet data can be sent over copper, satellite, radio, laser, physical media, even carrier pigeon!

Now, I haven’t mentioned DNS or search engines so far. That’s because we don’t need either.

DNS – Domain Name Service – is a technology that renders IP addresses into human-readable names. The addresses to which I alluded earlier are numerical. In IPv4 they’re a 32-bit binary number; in the newer IPv6 they’re a whopping 128 bits. Rendered into decimal, they’re a bit more manageable, but not by all that much – would you like to memorize strings of numbers like “192.168.15.106” for every website you visit? DNS is a service that your computer accesses which translates the much easier to recall names, like www.google.com into 74.125.227.147. It’s a nice convenience, but you don’t actually need it. And you’re not locked in to any one DNS server – you can set up your own, or you can actually use one that’s based outside of US jurisdiction.

And search engines?
Same thing – they’re a convenience. There isn’t even a specification on what a search engine is. And as you doubtless know, you can use whatever search engine you like, again including ones that are based outside of US jurisdiction.

There are technical solutions to these oversights, of course. But, thanks to the structure of the Internet, there are workarounds for those as well. The Internet was designed to be hard to disrupt. From a technical standpoint, attempts to regulate the Internet are basically the same as trying to disrupt it; it’s simply not a technology which was designed to be regulated.