無標題文檔

acookie 改进心得

这是工作记录,慢慢的不知不觉就形成篇文章了,就发在这里吧。

-- Split --

acookie 就是段统计代码,它的原理就是发送个 GET 请求到统计服务器,并附上本地用户的浏览器类型、分辨率等其他信息。

问题

有人报告 acookie 的代码出现 XSS ,原理是利用某 GET 参数 bypass 未过滤完全的字符。这里是原先的代码摘录:

(function() {
    function akrand(num) {
        return Math.floor(Math.random() * num) + 1
    }
    var P = location.pathname;
    if ((parent === self) || P.indexOf('{...}') != - 1 || P.indexOf('{...}') != - 1) {
        var R = escape(document.referrer);
        var id = "" + akrand(9999999) + akrand(9999999);
        var title = escape(document.title);
                document.write('<img src="http://foo/1.gif?acookie_load_id=' + id + '&title=' + title + '&pre=' + R 
                       + '&param0={...}&param1={...}&param2={...}"  width="0" height="0" style="display:none;" />');
    }
})();

这段代码「年事已高」每次的修修补补都是治标不治本,于是干脆考虑重写这段统计代码。

目标

在开始重写之前,为将要写的代码列了几条目标:

  1. 流量方面的考虑,代码要尽可能的简短
  2. 尽可能的优化性能
  3. 「绿色」,不干扰页面的其他脚本
  4. 脚本尽可能得做到安全

思考

  1. 使用原先的 document.write 会在页面中加入 DOM,直接使用 new Image 更好
  2. 原先的判断条件很冗余,完全可以考虑个函数搞定
  3. 安全方面虽然可以写个简短的过滤函数,但这样代码又会很长

解决

下面是反复修改后的最终代码:

(function(){
    var M = function(n) {
        return Math.floor(Math.random() * n) + 1;
    },
    I = function() {
        for (var i = 0, P = location.pathname, args = arguments, len = args.length; i < len; i++) {
            if (P && P.indexOf(args[i]) !== -1) {
                return 1;
            }
        }
        return 0;
    },
    D = document, R = escape(D.referrer), S = screen, T = escape(D.title);

    if (parent === self || I('{...}') || I('{...}')) {
        try {
            return new Image().src = [
                "http://foo/1.gif?cache=" + M(9999999),
                '&pre='+ R +'&scr='+ S.width +'x'+ S.height + '&title=' + T,
                '&param0=' + '{...}',
                '&param1=' + '{...}',
                '&param2=' + '{...}'
            ].join('');
        } catch (e) {}
    }
})();

本来想使用 ~function() {}; 这样的闭包, 结果发现效率方面还是原先的理想 (当然不会差很多),加之可能以后阅读的同事会有困扰,还是采用原先的吧。

在这个案例中,其实返回 0 和 1 同比返回 false 和 true 是同样的道理,处于节省代码量考虑,直接使用整型值。

安全方面出于简单原则考虑,没有考虑使用转义函数,而是采用数组拼贴的方式,这样就算有注入也会造成语法报错而不能指定此段脚本,前面加 return 也是这样考虑。

后记

考虑以后的代码可维护性很重要,这个例子中代码虽然简单,当然还会有更极端的写法,不过处于以后同事的合作考虑,尽量不要写得过于的「专业」。

采用 document.write 的考虑是想直接使用脚本在页面上输出,因此在本案例中不是很适用,同时才用这一方法在安全的角度上考虑需要过滤的字符太多,因此如果了解需求(比如仅仅是生成个带参数的 URL)还是避免使用它

XSS 和 CSRF 等虽说后台处理是治本的,但如果使用不当前后台考虑不周全就算加入了对应的过滤函数,也有可能造成注入。也从另个角度考虑,有时候完善的代码也能从一定程度上加大注入的难度,尤其是 Javascript 等这种「每个人都可以看见得脚本」。

-- EOF --

Mac 下禁用 CNNIC CA 证书

有关 CNNIC 的警告这里有个 详细的说明 ,不多做解释。对于 Mac 用户,这里有个简单的办法禁用 CNNIC CA 证书。

https://friable.rocks/_/2010_02_01/1265080937.png

打开「钥匙串访问」,搜索 「CNNIC 」即可看到对应的证书。双击该证书

https://friable.rocks/_/2010_02_01/1265080978.png

下拉「信任」选择「永不信任」即可。

根据上述文中的提醒,同时把有「entrust.net」关键字的证书也禁用掉,这样就没有上述文中的风险了。

先不讨论文中有关证书的风险,但 CNNIC 的流氓 已经众人皆知,这的确让人感到很不安。因此,个人对于这件事的态度,也是「宁可信其有,不可信其无」。

个人信息安全这块,有时候往往会忽视。 国内的大环境如此 ,也只能是人人自危。

PS,这里有个投票号召众浏览器厂商移除 CNNIC 证书, 有兴趣可以看下查看结果 )。

-- EOF --

看不透 iPad

就如我期前所说的Apple 新的平板出来后 ,Google Reader 中有关 iPad 的消息铺天盖地的过来。

总体看来,发现负面的消息多于正面消息,既然已经有那么多有关 iPad 的文章了,那么我也跟个风来说说我对 iPad 的看法。

我们为何失望

发布会后的几个小时,就看到老外就很不客气的这样评价 iPad:

As always, Apple's posted a full video of the iPad event, 
so you can pretend you were right there as Steve Jobs 
unveiled the world's most incredible digital photo frame.

我几乎熬夜看完了苹果的发布会。上述用户的言论虽有偏激之处但也不无道理,我和此用户一样,心里也有点小小的遗憾。

https://friable.rocks/_/2010_01_28/1264734559.jpg

对于 iPad 最多的抱怨大多都是在硬件上 ,有关硬件上的问题又集中在了扩展性、性能等方面 -- 对于用户来看说 iPad 是个大号的 iPod Touch 一点也不为过。

iPad 让用户失望的点太多,让我失望的是我期待的 Apple 平板电脑系统会是精简版的 Mac OS,而事实上 iPad 取而代之的是「增强版」的 iPhone OS,这无疑个人对于 iPad 而言诱惑程度降低了不少。

不过,采用了精简版的 Mac OS,那么可能硬件的改动会比目前的大得多,硬件成本(包括耗电量)可能不会是目前的售价。

另外个可能的可能,就是 iPad 会为 iPhone OS 4.0 开路,种种的现象说明 iPhone OS 的触手会越来越长。iPhone OS 上的应用一点也不比 Mac OS 少(甚至更多),Apple 当然不会放弃这张牌。

Apple 要和 Google 干,那么 iPhone OS 之于 Android 会是很好的竞争对手。iPad 的出现无疑会让 Apple 巩固 iPhone OS 的地位。但换个角度考虑,iPad 可能会成为这场仗中的陪嫁品。

因此总体而言,iPad 在 Apple 产品线中的位置在 Macbook 和 iPhone 之间。我期望 iPad 使用 Mac OS 只是更希望它能更靠近 MacBook 那边些。

不仅仅是硬件

回到 iPad 硬件的这个话题,这次改动最大的可能就是整体的系统架构。Apple 采用自家的 A4 处理器让开发人员们充满了好奇。

http://pic.yupoo.com/feelinglucky/960478c5cb18/medium.jpg

有关 A4 处理器的资料并不多,但值得肯定的是 iPad 肯定不会是简单地更换块处理器那么简单。如果正如 这篇文中所言 ,那么 A4 高达 1g 的处理的 可玩程度可比 iPod Touch 高得多 (这是肯定的)。

扩展性方面,iPad 在夹缝中也是非常的难受,它注定会和 iPhone 和 Mac 不同,因此它没有摄像头和语音输入,同时它也会没有 USB、火线等接口。

其实,我更愿意将 iPad 和 Macbook Air 归为同一条产品线。

iPad 屏幕方面的争议也相当得多,例如为何不用 OLED 以及 16:9 的宽屏等。可能苹果的对于 iPad 屏幕的搭配是出于成本方面的考虑。除此之外,我怎么也想不通 Apple 为何会这样干。

同时,iPad 的 9 寸触摸屏对于设计人员而言也是个挑战。iPhone 和 iPod Touch 的 3 寸「金莲」完全可以搬抄手机设备的设计,想象的空间也相对较小,但 iPad 的「大饼脸」则会不同。

硬件方面还有个可能, 就是 iPad 会不会如当年的 iPod Touch 2g 一样给用户个「惊喜」呢 ?相信我,其实 Apple 很擅长做这样的事情。

注定的,硬件方面从一开始 Apple 就满足的不了用户的 100% 需求。

好戏还在后头

犹如运动员在起跑之前都会将屁股翘起来一样,目前我们看到和听到的有关 iPad 的消息都是它的「屁股」。

我们对于 iPad 的了解也仅仅停留在 Apple 的发布会、几张产品图、网友的评论等。

结论应该在两三月后,看到 iPad 的真机并拆解、SDK 、iPhone OS 4.0 以及 App Store 的应用丰富程度等,再做定论。

论 Apple 功底,绝对不会让 iPad 那么简单,而我们现在能做的也只能是等待。

-- EOF --

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章