Fwolf’s Blog

有的同学认为邮件、邮箱是很保密的东东，没有我的密码，别人怎么能够打开我的邮箱，或者查看我的邮件呢？这是非常错误的，我告诉你们，不管你们邮箱的密码有多复杂，邮件在服务器上一般都是明文存储的，在服务器上有文件读取权限的人一般都可以查看到。另外邮件在传输过程中要经过很多邮件服务器（邮件头中就有邮件经过的所有邮件服务器的记录），每个邮件服务器都是可以拷贝一份放在自己这里的，更不用说离你更近的采用sniffer嗅探器的黑客了。所以，要想邮件不泄密，就必须对邮件进行加密。

邮件加密方式有很多种，有人可能会把文件用压缩工具带密码压缩作为加密，虽然可行但仍然需要告诉别人密码，而基于对称密钥算法的pgp加密就方便多了，你公开你的公钥，别人给你发送邮件的时候用这个公钥加密，这样信件就只有用你自己持有的私钥才能打开了。pgp是一个商业软件，不过GNU为我们提供了它的免费替代品——gnupg。

另外pgp加密并不是每个邮箱或者邮件客户端软件都支持，比如web的gmail和客户端的foxmail就都不支持，不过在这种情况下，可以使用pgp加密所要传输的内容（文件形式），再把加密的结果用“明文”方式传输就可以了。本文中，我的使用环境是ubuntu edgy 6.10，客户端软件为Mutt 1.5.12 (2006-07-14)。

Gnupg

首先，我们要使用gnupg软件生成我们的密钥对：

现在密钥就生成好了，并且自动存为了你本机的可信任密钥（自己给自己发信当然是“信任”了），上面的1024D/B7D37EE7和4096g/D4CF3DF0分别是两种形式公钥的长度和号码，DSA公钥的Key fingerprint（就是那一长串像windows注册码的东东）是公钥的指纹，和号码一样可以用来下载你的公钥。从哪里下载？原来网上有很多gnupg的公钥存储服务器，很多人都把自己的公钥上传上去，让别人给自己发信的时候可以从那里下载，而不是直接向收信人索取。更好的是，这些公钥存储服务器是全球联网同步的，你只要上传到其中一个服务器，就可以在其他任何服务器上下载了。

要把我们刚才生成的公钥上传到公钥存储服务器，首先编辑一下$HOME/.gnupg/gpg.conf文件，增加一行：

这里我指定的是荷兰的服务器，不过不重要，反正会自动同步到其他服务器的，常用的keyserver还有：

有些keyserver上还可以用web界面来查询、下载别人的公钥。指定了keyserver之后，我们可以先查查上面有没有自己的公钥：

没有找到，因为我们还没有上传嘛，现在上传：

上传很简单也很快的，传完之后再查询一下：

服务器会先查出有几个符合条件的key，然后选择显示哪一个。在本机管理key的主要命令有：

Mutt

gnupg这边基本上就搞好了，下面来配置mutt，首先把gpg的例子配置拷贝一份到自己的mutt配置目录：

然后在mutt的配置文件~/.muttrc中添加引用这个gpg.rc的命令：

最后编辑gpg.rc，添加如下内容：

这样，再次启动mutt，在发信的时候，在显示发信人、主题等信息的那个界面，按“p”就可以打开pgp菜单了，内容大体为：

e代表加密，s代表签名，a代表使用非默认的签名，b说明又加密又签名，i指定加密或者签名是直接嵌入正文（inline）还是以附件形式（mime）的，推荐使用兼容性比较好的mime形式，c则是取消加密和签名状态，明文发送。

管理公钥

要给别人发送加密邮件的话，要先下载并导入别人的公钥，并用pgpewrap来管理，不过有些系统上pgpewrap的路径不对，手工ln一下就可以了：

gnupg有一套本机的公钥管理机制，可以对所有导入的公钥设置信任级别，还有一套相关的规则，比如如果一个公钥被3个人信任，那么就把他也设置为信任状态什么的，不过下面只简单演示一下设置已导入公钥的简单功能，更复杂的估计一般很少用到了：

现在，如果你发信对方的公钥在本地存储中有的话，就会自动调出来并用上了。

局限性

我已经使用gnupg有一段时间了，大部分情况都是作签名，也有加密发送的，感觉效果还行，就是在mutt中收到又加密又签名的邮件的时候，界面上的显示会比较乱而已。还有一个损失就是，如果再像以前那样把要保密的内容用gnupg加密发送到自己的gmail邮箱中的话，gmail中只能显示一堆乱码——加密了嘛，但是搜索是肯定搜索不出来的了，除了按标题搜索，gnupg一般是不对标题进行加密的。

参考：

Everything You Need To Know To Start Using GnuPG with Mutt，非常好的说明，还重点讲了gpg加密的原理，为什么要使用签名和加密等等。

mutt+gnupg实战

Related posts

• No related posts.

已经不止一次有这种想法了，文档管理系统（document management system，简称DMS）或者数字资产管理系统（digital asset management system，简称DAM），主要是用来管理我们常用的一些文档、照片等东东。

从几年前，大概2001年开始我就在想如何管理自己的文档才好？那时候主要是wps，doc等文件什么的比较多，还没有数码相机，所以只有几张网友的照片，而随着时间的推移，无论是照片，还是文档都在增加，我现在只能是每年建一个目录，然后下面大致分上几个子目录，把文件名尽可能的写长一些，方便以后查找，最后每年的文档一打包就扔到角落里面去了。但是这样作的直接结果就是旧文档很少被用到，能不用就不用，因为使用的时候找要找半天，解压也麻烦。

还有，现在联网方便了，我要从家里直接连上公司的电脑，或者反过来，无论是在公司还是在家办公，调用以前的文档都非常方便才行。gmail和groups出现之后我也尝试过把文件放在邮箱里（自己给自己发信），不过gmail中文搜索并不理想，尤其是不太常用的行业词汇，很难搜出来，结果还是要找半天才能找到。所以，要想通过互联网管理或者共享文档的话，还是要专门的文档管理系统才行。

所幸，除了一些商业的DMS之外，还是有一些免费的文档管理系统，不过在挑选之前，先考虑一下我期望的DMS应当具有的特性：

• web方式在线使用，这样可以方便自己或者同事调用。
• 具备完善的用户权限控制，可以对每个节点进行授权，但也要能选择无需登录就可查看的文档；如果能够支持按ip或其他条件来定制游客权限就更好了。
• 服务器运行环境要是nix平台，讨厌windows；apache或类似服务器，php或类似语言，java的不要，块头太大。
• 支持多种类型的文件，比如支持pdf预览，支持图像exif信息查询等等。
• 完美支持中文等字符集。
• 文档仓库要按照时间或分类建立目录树，不要强制修改文档在仓库中保存时的文件名，这样即使暂时脱离DMS，直接在文件系统中查找也不会太麻烦。
• 支持文档的版本，支持文档之间的关联。
• 支持批量导入，我把目录拷贝到仓库中，可以快速批量进行设置，导入进来。
• 最好能夠支持多个“文档仓库”，这样现在的工作文档和以前的历史文档就都能夠管理起来了。

应该说我的要求不算高吧，可是找了一个上午，仍然没有满意的结果，有些是以前就试用过的，有些则是不适合我。当然肯定不止我一个人在寻找，很多人都在找呢，比如这个、这个，下面说说这些系统都怎么让我不满意的吧：

DocMgr

这大概是在功能上我最满意的DMS了，但是他使用的是postgresql数据库，这个我可以克服，但是它的文件居然也都是存储在数据库中的，我可不想动辄备份几个G的数据库，放弃。

KnowledgeTree Document Management

KTDMS是比较成熟的一款了，除了开源的版本，还有商业版本可用，不过以前试用过，更偏重文章而不是文件的管理，靠近知识管理更近一些，不太适应数字资产管理的需要。

MyDMS、owl

这两个是一系列类似系统中稍微好一些的了，特点是侧重于文件的管理，甚至作的和资源管理器一样。其实我要是想自己建目录管理文件，还费劲上什么DMS啊？另外对仓库中的文件都进行了重命名，不便于脱离DMS在文件系统中直接查询，也只能放弃了。

至于其他flickr、yupoo等在线图片管理网站就不说了，只能管理图片，不能管理其他类型的文件。

今天的搜索就到此为止了，还是没有找到最合适的，以后有时间我会继续查找，补充在这里。或许，闲得无聊的时候我会自己写一个？

Related posts

• No related posts.

现在的web服务器和开发工具虽然不会再出现像asp的%81那样明显的漏洞了，但是由于开发人员的疏忽和各种语言特性组合造成的一些奇异的漏洞仍然会存在。今天偶然读到的XSS Woes，就详细讲述了和$_SERVER['PHP_SELF']相关的一个危险漏洞。

$_SERVER['PHP_SELF']在开发的时候常会用到，一般用来引用当前网页地址，并且它是系统自动生成的全局变量，也会有什么问题么？让我们先看看下面的代码吧：

	<form action="<?php echo $_SERVER['PHP_SELF']; ?>">
	<input type="submit" name="submit" value="submit" />
	</form>

这段代码非常简单，我们想用$_SERVER['PHP_SELF']来让网页提交时提交到它自己，假设代码文件名为test.php，在执行的时候就一定会得到我们期望的地址么？首先试试地址http://.../test.php，结果当然是没有问题的啦，别着急，你再访问一下http://.../test.php/a=1，将会得到如下客户端代码：

	<form action="/fwolf/temp/test.php/a=1">
	<input type="submit" name="submit" value="submit" />
	</form>

显然，这已经超出了我们的期望，web服务器居然没有产生诸如404之类的错误，页面正常执行了，并且在生成的html代码中居然有用户可以输入的部分，恐怖的地方就在这里。别小看那个“a=1”，如果把它换成一段js代码，就显得更危险了，比如这么调用：

http://.../test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo

是不是看到了js的alert函数执行的效果？检查一下生成的html源代码找找原因吧。

通过这种嵌入js代码的方式，攻击者能夠获得512～4k的代码空间，甚至还可以连接外部网站的js代码或者通过image调用来伪装js代码的方式，那样js代码的长度就不受限制了，然后通过js，他们可以轻松的获取用户的cookie，或者更改当前页面的任何内容，比如更改表单提交的目的地，更改显示的内容（比如给一个<a>链接地址增加一个onclick=…的属性，这样用户点击的时候就会执行攻击者指定的代码，甚至连接到并非此链接地址本身的网站），甚至作出一个ajax效果来也不一定，总之，不要忽视js的威力。

那么，再来看看这个漏洞产生的原理，首先test.php/....这种调用是web服务器允许的，很多cms系统，比如我以前用过的plog，好像也是采用这种方式，在服务器不支持rewrite的情况下实现诸如http://…/index.php/archive/999这样的固定网址的（我以前还以为是对404错误页下的手），所以带“/”的地址无法从web服务器上禁止。然后再看看php中对$_SERVER['PHP_SELF']的识别，他就是一个包含当前网址值的全局变量，天知道用户会输入什么样的网站，在上面的例子中是恶意的，可是在wikipedia这样的网站上，却又是可以正常使用这种方式的地址的。所以，最终的结论要落在开发人员身上了，没有很好的处理与用户交互的数据。

从安全角度来讲，在开发应用尤其是web应用的时候，所有用户提交的数据都是不安全的，这是基本原则，所以我们才不厌其烦的又是客户端验证又是服务端验证。从上面说的这个安全漏洞来讲，不安全的内容中又要增加“网址”一条了。要解决$_SERVER['PHP_SELF']的安全隐患，主要有以下2种方式：

1、htmlentities 用htmlentities($_SERVER['PHP_SELF'])来替代简单的$_SERVER['PHP_SELF']，这样即使网址中包含恶意代码，也会被“转换”为用于显示的html代码，而不是被直接嵌入html代码中执行，简单一点说，就是“<”会变成“&lt;”，变成无害的了。

2、REQUEST_URI 用$_SERVER['REQUEST_URI']来替代$_SERVER['PHP_SELF']，在phpinfo()中可以看到这两个变量的区别：

_SERVER["REQUEST_URI"] /fwolf/temp/test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo
_SERVER["PHP_SELF"] /fwolf/temp/test.php/"><script>alert('xss')</script><foo

$_SERVER['REQUEST_URI']会原封不动的反映网址本身，网址中如果有%3C，那么你得到的也将会是%3C，而$_SERVER['PHP_SELF']会对网址进行一次urldecode操作，网址中的%3C将会变成字符“<”，所以就产生了漏洞。需要注意的是，在很多情况下，浏览器会对用户输入要提交给web服务器的内容进行encode，然后服务器端程序会自动进行decode，得到相应的原指，在我们进行post或者get操作的时候都是这样。

另外还有两点需要指出，第一是<form action="">这种写法虽然没有直接用到$_SERVER['PHP_SELF']，但实际效果却是一样的，只是发生的时间错后到了用户提交之后的下一个页面，所以，form的action还是不要留空的好。第二点，除了PHP_SELF之外，其他的$_SERVER变量也许也会有类似的漏洞，比如SCRIPT_URI, SCRIPT_URL, QUERY_STRING, PATH_INFO, PATH_TRANSLATED等等，在使用他们之前一定要先作htmlentities之类的转换。

最后，提供一个地址，里面有很多XSS的例子，可以作为反面教材或者测试工具： XSS (Cross Site Scripting) Cheat Sheet

Update @ 2007-07-31

SCRIPT_URI在cgi方式下或者在某些虚拟主机上无法使用：

Notice: Undefined index: SCRIPT_URI in ......

所以就只能用REQUEST_URI了：

((isset($_SERVER["HTTPS"]) && 'on' == $_SERVER["HTTPS"]) ? 'https://' : 'http://') . $_SERVER["HTTP_HOST"] . $_SERVER['REQUEST_URI'];

Related posts

• 配置安全的共享web服务器（抛砖引玉） (4)
• 由一个错误学到的一些php安全配置问题 (4)
• 选择Eclipse PHP Development Tools(PDT)作为PHP开发工具 (8)
• 让phpmailer支持中文名称的附件 (5)
• 终于能够通过phpmailer使用gmail账号发送邮件了 (50)

还在使用工具压缩 js 和 css 文件么？已经有些落伍啦，其实 web 服务器本身就具备压缩功能，可以把客户端所需要的内容压缩后再传输。当然这需要客户端浏览器支持压缩（通常是 gzip 方式），不过现在的主流浏览器比如 ie、firefox、opera、safari 都是支持滴。

首先可以用 Real-Time Compression Check 检查一下你现有的网站是否启用了压缩输出，如果没有，而且你使用的是 iis 系列 web 服务器的话，可以购买商业软件比如 ZipEnable 来实现；如果使用的是 apache 服务器，那你有福了，使用 mod_deflate 就可以了。

mod_deflate 的前身是 mod_gunzip 和 mod_gzip，他们大多用于 Apache 1.3分支，现在的 Apache 2.x系列中，就被 mod_deflate 替代了，并且功能更加丰富。mod_gunzip 和 mod_gzip 的区别在于：

mod_gunzip 需要服务器上的文件本身就是压缩存储的，如果浏览器不支持压缩的话，再由 web 服务器解压后传输给客户端，否则直接读取压缩文件传给客户端。这样作的好处就是不占用 cpu，并且大多数浏览器支持压缩，需要 web 服务器解压的不大。不过，碰到不支持压缩的机器人的话可就不好半喽。另外现在网站的内容大多是由程序动态生成的，在这种情况下 mod_gunzip 就没有用武之地了。

mod_gzip 则不需要文件预先压缩存储，而是在浏览器支持压缩的情况下，把数据压缩之后再传给客户端。这样会牺牲一些 cpu 代价，但是适用于网站内容由程序动态生成的情况，并且 gzip 的速度也是非常得快，每次 web 请求的数据量也都不大，所以实际的 cpu 占用并不会太多。并且如果文件本身就是压缩了的，比如 index.html.gz，那么这些文件会被直接输出，不用再压缩了（这样并不代表有了 index.html.gz，就能替代 index.html 作为目录索引页）。所以 mod_gzip 实际上覆盖和超越了 mod_gunzip 的功能。

mod_deflate 的启用在 ubuntu 中很简单，a2enmod deflate 就可以了，其他系统可以在 httpd.conf 中添加：

LoadModule deflate_module /usr/lib/apache2/modules/mod_deflate.so

mod_deflate 还需要配置一下，比如在 httpd.conf 中：

<ifmodule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php application/x-javascript text/css
</ifmodule>

指定对 html、txt、xml、php、js、css 等 mime 类型的文件进行压缩，application/x-httpd-php 和 application/x-javascript 是我加上的，不知道能否起作用。也可以按照文件扩展名或者浏览器类型进行压缩,还有更复杂的配置，可以查询官方的手册。

参考：

• Compressed delivery
• *.gz files shouldn’t get “Content-Encoding: gzip” header
• How To Save Traffic With Apache2′s mod_deflate
• Apache Module mod_deflate

Update @ 2008-03-31

今天在 apache 2.2.4 下看到还需要增加以下辅助配置：

AddEncoding x-gzip .gz	
AddType text/html .gz

主要是让 apache 能够正确设置和处理 .gz 文件，至于 MultiViews 选项我看设不设没什么影响，参考：The nGzip File Compressor

Related posts

• 防止垃圾评论的另类方法 (6)
• 配置安全的共享web服务器（抛砖引玉） (4)
• 配置Apache的ssl安全连接 (3)
• 由一个错误学到的一些php安全配置问题 (4)
• 生成用于web服务器的openssl证书 (1)

近期网通在大规模调整ip地址，从原来的218地址调整到121地址，原因据说是优化服务，不知真正的居心何在。我这里使用的是cisco 2621的路由器，原先已经由别人配置好了，我虽然是个路由器菜鸟，但是更改一下ip地址还是可以的，顺便把要用到的几个命令记录在这里。

通过控制端口连接上路由器之后，默认的是

提示符，这个状态下只能查看，不能进行配置，输入命令“en“就进入管理模式了，提示符也会有相应改变：

然后就可以配置了，首先是配置ip地址，就像这样：

解释一下： 首先“conf t“到底是什么我也不太清楚，或许t是配置的名称，或许是某个命令的简写，反正这么配就是了:)； 然后用interface命令指定要配置的网卡，选定之后ip address命令就是设定网卡地址，如果设置2个地址的话，掩码后面要跟上个secondary； ip地址设定完之后用exit退出网卡设置的“子过程”，继续配置静态路由，先用“no ip route“清除以前的路由表，然后再用”ip route“设置新的； 最后exit退出设置，“sh run“这个命令也许是运行配置，也许是检查配置，反正执行一下就是了，你会看到所有的配置情况，检查其中的ip地址设置、nat设置、访问权限设置、路由设置等等。 没有什么问题的话应该就可以生效了，但测试成功之后别忘记把配置保存起来，不然路由器一重启配置就恢复成原来的了：

有的时候配置完不生效，需要重启一下光电转换器，或者切换一下光电转换器的模式然后再换回来，只要配置好了能够正常ping上端路由器的互联地址，应该就是没有问题的。不过我配置的时候总是怪怪的，明明配置好了，路由转发就是不成功，后来实在没办法打到网通光纤机房请教，居然是个女孩子在值夜班，服务态度当然是A+了，她那边检查一下居然什么问题都没有了，残念。。。

Related posts

• No related posts.