We don’t know how to build a general-purpose computer that is capable of running any program except for some program that we don’t like, is prohibited by law, or which loses us money. The closest approximation that we have to this is a computer with spyware: a computer on which remote parties set policies without the computer user’s knowledge, or over the objection of the computer’s owner. Digital rights management always converges on malware.

In an effort to stamp out piracy, we are stamping out legitimate fair-use rights, and accepting invasions of privacy by corporations in a way that also happens to dovetail nicely with the intelligence gathering goals of governments everywhere.

I don’t mean to sound too much like a conspiracy theory-loving whack job here. But the fact is that the same software that enables corporations to manage their intellectual property or make a profit on targeted advertising also makes it easier to spy on citizens. I’ll refer you to Evgeny Morozov’s enlightening, yet sobering book on this very subject, The Net Delusion: The Dark Side of Internet Freedom (of which I have read about half thus far).

[h/t: Ben Ramsey]

Remember the fake boarding pass that was in Schneier’s hand? Actually, it was mine. I had flown to meet Schneier at Reagan National Airport because I wanted to view the security there through his eyes. He landed on a Delta flight in the next terminal over. To reach him, I would have to pass through security. The day before, I had downloaded an image of a boarding pass from the Delta Web site, copied and pasted the letters with Photoshop, and printed the results with a laser printer. I am not a photo-doctoring expert, so the work took me nearly an hour. The T.S.A. agent waved me through without a word. A few minutes later, Schneier deplaned, compact and lithe, in a purple shirt and with a floppy cap drooping over a graying ponytail.

That’s from Vanity Fair‘s wonderful article Smoke Screening.

Flash, like JavaScript, more-or-less adheres to a same-origin policy by default. Under a same-origin policy, requests for data must come from the same scheme, hostname, and port. If http://foo.example tries to request data from http://bar.example, the request will usually fail.

Same-origin policies are designed to prevent the unauthorized leakage of data to a third-party server. Without it, a script or SWF hosted on http://mightbeevil.foo could read data hosted on http://goodsite.foo and send it to http://muhahahaevilsite.foo. This kind of cross-domain activity could be used to exploit cookie and authentication data. It’s clearly a bad thing.

Recent browsers have safeguarded against these kinds of cross-site scripting exploits by preventing JavaScript from making cross-origin requests. XMLHttpRequest, for example, will throw a security exception if you attempt a cross-origin request.

Flash, meanwhile has long supported a means for enabling cross-origin requests: the policy file. The policy file is a way of white-listing requests for data or credentials from specific origins. It lives on the server from which you are requesting data, and gives the Flash player a “yay” or “nay” when asked whether the request from a specific origin should be allowed to complete.

Cross-origin restrictions, though necessary, are also quite limiting. You can’t (or couldn’t), for example, request data for a mash-up using XMLHttpRequest. Though there are workarounds — using dynamic script insertion, or using the document.domain — those workarounds also leave the DOM vulnerable to cross-site scripting.

To to mitigate the dangers of cross-site scripting while still enabling it, the W3C is developing the Cross-Origin Resource Sharing (CORS) specification. It functions similarly to Flash’s cross-domain policy file, but uses HTTP headers instead of an XML configuration file.

CORS request headers are automatically generated by conforming browsers when a script attempts a cross-domain request. Response headers must be set in the server’s configuration file, or dynamically per URL using a server-side language.

Let’s compare a sample cross-domain.xml file to how we’d achieve the same thing using CORS.

Cross-origin requests from Flash

To use the domains from our example above, if http://mightbeevil.foo made a request to data hosted on http://goodsite.foo, http://goodsite.foo would need to permit the request by including mightbeevil.foo it in its policy file. For example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="mightbeevil.foo"/>
</cross-domain-policy>

This file must be stored in the web root of http://goodsite.foo. It explicitly permits mightbeevil.foo — and permits only mightbeevil.foo — to make requests for its data (from within a Flash movie).

Cross-origin requests from the DOM

To reuse our example from above, let’s use XMLHttpRequest to make a request from http://mightbeevil.foo to http://goodsite.foo.

var xhr, onLoadHandler 

onLoadHandler = function(event){
     alert('It is done!');
}

xhr = new XMLHttpRequest();
xhr.open('GET','http://goodsite.foo/data.json');
xhr.onload = onLoadHandler;
xhr.send(null);

It looks just like a regular XHR request, except for the fact that we’re requesting data from another origin. Let’s take a look at our headers.

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding:gzip, deflate
Accept-Language:en-us,en;q=0.5
Connection:keep-alive
Host:goodsite.foo
Origin:http://mightbeevil.foo
Referer:http://mightbeevil.foo/make_cross_domain_request/
User-Agent: Awesome/9.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) FantasticEngine/8889876 Awesome Browser/9.0

Notice that our headers include Origin:http://mightbeevil.foo.

Goodsite.foo responds with the following headers.

Access-Control-Allow-Origin:http://mightbeevil.foo
Connection:Keep-Alive
Content-Length:1349
Content-Type:application/json
Date:Mon, 26 Sep 2011 04:44:50 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.20

Here we see that an Access-Control-Allow-Origin response header is returned by the server. Like allow-access-from, it indicates which domain(s) are allowed to make requests. Here, we want to know whether mightbeevil.foo is allowed to request data. It is, so the request will be completed.

Acceptable values for Access-Control-Allow-Origin include an origin (scheme + host + port), a comma-separated list of origins†, or a wildcard (*). As with cross-domain.xml, if the value of Access-Control-Allow-Origin had instead been http://notevil.foo, the request would have failed. Using a wildcard allows requests from any domain.

Of course, both specifications are more complex than what I have covered here. These examples illustrate how to enable a basic cross-origin request. It is also possible with both CORS and Flash to permit or exclude custom headers. And in the case of CORS, it is possible to use methods such as PUT or DELETE if the user agent supports it.

Learn more

• Flash cross-domain policy file specification
• Cross-origin Resource Sharing
• XMLHttpRequest Level 2

† Most browsers do not yet support multiple origin values. The specification is also a working draft, and subject to change.

Heilmann explains:

• Why client-side storage can be a good thing;
• The origins of and need for local storage;
• How to use local storage;
• When to use local storage;

I implemented local storage in browsers that support it for our wedding web site. It saves the open or closed state of each content chunk. It was easy enough to save the data. And it gives the user a bit of added convenience.

Read the piece.

Keep in mind: local storage can be — and will be, and right now is probably being — used to create hard-to-delete “super cookies” for advertising, marketing, and other privacy-eroding things.

The good news is the web storage specification and all browsers that support it restrict local storage data to the originating domain. The bad news is that most browsers don’t offer an easy way to local storage objects. In Safari, for example, you’ll need to fire up Terminal (quit Safari first) and navigate to /Users/tbrown/Library/Safari/LocalStorage to delete items individually or collectively.

This isn’t a new issue. Flash ‘cookies’ have existed for years (view, manage or delete yours). But what is new is that some (most?) browser makers have made it hard to manage and control what gets stored and for how long.

Yeah, as I type this, I’m getting hit with an attack. I’m not precisely sure of the motive. I just know that there are two directories on my server that should not be there and the attack appears to be coming through a specific URL. It’s been happening for several days nowIt just started today, according to my server logs, and the attacker is using / attempting to use PHP functions that interact with the shell.

He was also able to grab a whole bunch of data about my server as you can see from the above-linked code. I have my suspicions about how it is getting through, but nothing I can prove just yet. I’m going to look into it and see what I can come up with.

In the meantime, I’m just going to ask nicely that he (assuming this is a guy) please, please stop, and don’t mess up any of my stuff while visiting.

And please take steps to disable certain system-affecting functions in your php.ini file (if you have access).

UPDATE: This crack appears to involve a ShellBOT as well.

UPDATE 2: ShellBOTs are bad. Apparently they open a connection to an IRC server allowing all kinds of nasty things to happen. So hoping nothing serious was compromised.

UPDATE 3: Interesting to know: when working in the shell, your file name does not need to have the ‘proper‘ extension that it would on a web server in order to be executed.

Let’s say you have a plain text file named ‘hello.txt.’ It contains one line: <?php echo 'hello world';?>. In order for this file to run as a web page, it would need to have a .php (or whatever is designated in your server configuration file). But as a shell script, it could have just about any name and still be executed by typing ‘php hello.txt’ at the command line.

In this case, the attacker grabbed (or attempted to grab) a ShellBOT written in Perl from another server (file name b.txt) and execute it by sending the ‘perl b.txt’ after the wget command.

UPDATE 4: I’m pretty sure my suspicions have been confirmed. It seems that at least one other person has had an issue with WP Super Cache opening their server to attack. I suspected this early on, and deleted the plugin and its associated files. As an added measure, I disabled those functions that can execute system commands. So far, so good. I can’t say my server is now secure, but I’m hoping that hole has been filled.

I ran across an example of this today and it’s just a really bad practice. These files are web-readable, and by saving it as an .inc file, you are exposing your data to whoever stumbles across ‘db.inc’ or ‘globals.inc’.

If you must save files in your document root, save them with a .php extension (.php files are better, but at least one developer argues not by much.)

UPDATE: Ben Ramsey fills me in on the reasoning behind Chris Shiflett’s mandate.

There is a twofold reason Chris says that storing PHP includes within the Web root is not a good practice (there may be more than two reasons, but there are two that I know of):

1. your PHP scripts should never be accessed out of context, and leaving an include file within the Web root allows users to execute it out of context, potentially doing things you didn’t intend them to do, and
2. on the off-chance that the server crashes and reboots — but Apache doesn’t quite load PHP successfully — and it takes 30 minutes to an hour or more to get your hosting company to fix it, then all of your PHP files will be readable to the public as plain text, exposing your code and any passwords contained therein.

Both reasons are enough to convince me to place only those files that need to be accessed directly by the client in the Web root and all others above it.

Sound advice.