Kenvi的布拉格

浅谈产品经理的基础和能力

kenvi — Sun, 30 May 2010 23:27:39 +0800

入产品这行只有2年多，作为一个产品新人，一边学一边想，走了很多弯路和顿悟，本文以自身经历、角度来说说在我印象中产品经理的一些理解。

（1）概念理解：

1． PD和PM：正常来说，PD指的是产品设计，PM指的是产品经理，但在有的公司，产品经理统称PD，PM指的是项目管理。
2．产品和运营：有些公司产品和运营是区分开的，团队里有专门负责产品的产品人员，有专门负责运营的运营人员；也有的公司产品和运营不分家，通常产品经理，所以投简历时一定要注意该公司环境、该职位的工作职责——这份工作到底适不适合自己。
3．产品设计、产品规划、产品经理：不同的公司对于职称有不同的定义，看过很多产品相关的文章，发现自己只是做了产品经理的一部分工作，于是拿产品经理作为目标来鞭策自己
4．战略规划：菜鸟的终极目标是从需求的执行方，上升到产品战略规划，但现状产品的大方向都是老板规划好的，自己在小方面有全完的自主权，通过产品来实现老板的大产品生态圈。
5．产品经理的定义：
引用《人人都是产品经理》的一段话
只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态、维护这个产物，那么，你就是成品经理。

（2）产品经理需要的能力

1) 沟通是基础
很多人都会把沟通能力作为自己的亮点提出，其实沟通能力只是一个产品经理所必需的基础能力，可以说没这项能力，你就成为不了一个好的产品经理。包括：
1. 输入能力：作为产品需求的发起人、执行者，要具备良好的需求理解能力，从客户、老板、用户那边接到需求，正确理解用户需求；同时要把用户需求转化为产品需求。
2. 输出能力：作为一个跨部门协助的人，产品人员需要有良好的表达能力，在项目初期你要拿你的概念去忽悠老板，让老板同意立项。在产品的中期，要组织UI、开发、测试产品相关人，把自己的想法输出给他们，这主要体现在产品的评审会上，产品评审、UI评审、测试评审等， PRD文档以及后续的开发、测试跟进，确保开发出来的效果符合产品初衷。
3. 演示能力：产品上线前的产品介绍、产品培训，作为立项和演示用的产品规划PPT
2) 具备市场感觉
我见过的很多产品，其实根本没想好我们为什么要做，市场定位和产品核心价值都不明显，看别人都在做，于是跟风趋势。比如之前的SNS热和现在的微薄、团购门。
要做一个有天分的产品经理，其关键是必须要以市场为导向。要进行市场调查，做市场细分，这个市场大不大，有没有前景，做的人多不多，进入这个市场有没有堡垒，需不需要特定资源的优势。通盘考虑了这些，然后利用SWOT，做竞争对手分析，了解各自的强项和弱项，找到机会在哪里，威胁在哪里，并进行分析，我们来做合不合适，合适的话如何制订未来的战略。
3) 用户意识
所谓用户意识，并不仅仅是把用户拿在口头上，把用户体验作为说服老板和研发人员的武器。
产品设计最重要的是意识，了解和尊重用户的意识；策划最重要的是感觉。所谓感觉，特指你对用户的了解程度，越了解用户，感觉也就越准。这种感觉尤其体现在对特定用户群，在特定应用情景下的了解。
4) 文档能力
如果用时间刻度来衡量产品经理的工作，20%时间在思考，30%时间在沟通，50%时间在写文档。一般来说，产品人员所要求的专业技能，具体体现在产品所撰写的各类文档中。
说起文档，MRD市场需求文档我也没写过，听易趣的一个朋友说，MRD是市场部人员写的；PRD文档是写得最多的，一份PRD文档包括了项目背景、用户说明、业务流程和原型；竞品分析，狭义上的定义是理清好产品概念后，通常会去看看看市场上相对应的产品有哪些，有哪些功能和设计思路可以借鉴。广义上的竞品分析指的是针对竞争对手的情况做一个通盘的分析，包括市场、用户、团队、产品细节、运营手段等，然后形成一个报告，比如之前流传的《梦幻西游》；产品说明书指的是产品上线前、交付用的产品介绍说明书，用来做培训和销售卖点的特征。培训手册，用来给内部人员培训的，特别是给面对用户的客服人员，产品人员也是客服支持人员。
5) 技术能力
很多人都在讨论产品人员需不需要了解技术，正常来说，产品经理部需要去了解技术的实现手段，但是对于基础的技术原理一定要了解，比如基本的HTML/CSS知识，AJAX的原理、PHP的基础、用户规模对数据库的要求。
6) 团队的力量
一般来说，刚入社会，人与人的差别并不明显，学校里教的只是基础的东西。个人的力量是渺小的，这个时候需要借用团队的力量。产品经理很多时候都是在协调，协调资源和人员，这个时候更需要发挥团队的力量

（3）个人核心技能
如果说产品经理的核心能力，那一定是产品规划能力。
个人的核心技能是什么？据我理解，个人核心技能一定是独立的分析和解决问题的能力。在这里面可能涉及到已有实践工作的经验积累，工作方式和专业技能。时间管理、个人知识管理、等个人的方法和模式；以及学习能力，信息知识的获取和成长。

（四）激情、信仰
记得08年刚入门时，有个前辈跟我说过，我们是互联网的创造者，我们的工作，是在改变人类的生活。听之，并未记在心上。
09年，在和我们产品总监的一次聊天中，他提到了他以前的一个很成功的产品，他的激情让我很震撼，他提出的口号，让人类的生活更美好，我知道，并不仅仅是一种号召语，而是融入灵魂的一种信仰。
无独有偶，苏杰《人人都是产品经理》的副标题是“好产品改变世界”、王坚的《结网》的标题是“互联网产品经理改变世界”、QQ的产品理念是打造人类在线生活社区。
做产品2年多以来，我也发现了自己早已把产品习惯融入了生活中的很多细节，比如写文章之前总是喜欢先用MM画好结构图、做个详细的学习、工作计划 LIST，隔一段时间会迭代更新、喜欢规范和模板利用，不仅在工作中会运用到，生活中的学习模式、文件管理也如此。
所以，首先，找到你最喜欢的事（产品和行业），做你喜欢的事，你才能充满激情，告诉自己这是一份伟大的工作，相信我们所做的产品是在改变生活、改变世界，让我们一起努力。

No related posts.

nginx文件类型错误解析漏洞

kenvi — Mon, 24 May 2010 15:21:22 +0800

来源：80sec

漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。

漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以

location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问

将会得到一个URI

/80sec.jpg/80sec.php

经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为

/scripts/80sec.jpg

所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为

/scripts/80sec.jpg和80sec.php

最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。

http://www.80sec.com/80sec.jpg/80sec.php

POC：访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：

访问http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

访问访问http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。

漏洞厂商：http://www.nginx.org

解决方案：

我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失

关闭cgi.fix_pathinfo为0

或者

if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}

Nginx做负载均衡时X-Forwarded-For信息头的处理

Adobe CS5 全系列软件通用破解补丁

kenvi — Sat, 22 May 2010 23:25:50 +0800

这次的CS5通用破解补丁是由 MyCrack 大侠制作的，使用非常方便，理论上支持CS5所有程序和所有语言版本，是目前最佳的破解方法了，推荐大家使用。之前如果修改Hosts成功注册使用的朋友可以下载收藏以备日后使用……

Adobe CS5 通用破解补丁使用方法：

下面以安装 Photoshop CS5 为例：

第一步：下载 Photoshop CS5 简体中文版与 Adobe CS5 通用破解补丁
第二步：以试用方式安装 Adobe Photoshop CS5，不需要输入序列号
第三步：将破解补丁 amtlib.dll 文件复制到Photoshop CS5的安装目录，覆盖同名文件

PS：如果覆盖后还出现注册或者输入注册码的选项，选择以后注册和试用即可。其他软件破解步骤与 Photoshop CS5 没什么差别，最多就是 amtlib.dll 原文件位置不一样，大家可以用搜索软件 (推荐EveryThing) 找出来再覆盖。
PS2：使用64位系统的朋友请下载64位的补丁！
PS3：如果你安装多个软件，例如同时装了PS CS5和 DreamWeaver CS5，那么每个不同的软件需要覆盖一次amtlib.dll

下载地址

32位下载地址：http://www.rayfile.com/files/ded81dca-65b5-11df-b251-0015c55db73d/

64位下载地址：http://www.rayfile.com/files/156c2e80-65b6-11df-846e-0015c55db73d/

No related posts.

PAC-MAN 30th Anniversary

kenvi — Sat, 22 May 2010 00:12:10 +0800

纪念PAC-MAN诞生30周年。真是很极客，很“生活大爆炸”，让人觉得GOOGLE里面全是一群SHELDON。然后突然发现这个是能玩的首页，音效和红白机里的一样，真怀念啊！

No related posts.

腾讯微博邀请

kenvi — Tue, 18 May 2010 11:28:54 +0800

一有新的会及时发上来，今天先发三个

http://t.qq.com/invite/0962cfd22fb3d9fa2247
http://t.qq.com/invite/4764cac53ecdd3a3be49
http://t.qq.com/invite/7c8fa582500a83b3806b

先看到的先认领吧，我会定期更新

No related posts.

Nginx做负载均衡时X-Forwarded-For信息头的处理

kenvi — Wed, 12 May 2010 15:17:49 +0800

如今利用nginx做负载均衡的实例已经很多了，针对不同的应用场合，还有很多需要注意的地方，本文要说的就是在通过CDN 后到达nginx做负载均衡时请求头中的X-Forwarded-For项到底发生了什么变化。下图为简单的web架构图：

先来看一下X-Forwarded-For的定义：
X-Forwarded-For:简称XFF头，它代表客户端，也就是HTTP的请求端真实的IP，只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项。它不是RFC中定义的标准请求头信息，在squid缓存代理服务器开发文档中可以找到该项的详细介绍。
标准格式如下：
X-Forwarded-For: client1, proxy1, proxy2 从标准格式可以看出，X-Forwarded-For头信息可以有多个，中间用逗号分隔，第一项为真实的客户端ip，剩下的就是曾经经过的代理或负载均衡的ip地址，经过几个就会出现几个。

按照上图的Web架构图，可以很容易的看出，当用户请求经过CDN后到达Nginx负载均衡服务器时，其X-Forwarded-For头信息应该为 客户端IP,CDN的IP 但实际情况并非如此，一般情况下CDN服务商为了自身安全考虑会将这个信息做些改动，只保留客户端IP。我们可以通过php程序获得X-Forwarded-For信息或者通过Nginx的add header方法来设置返回头来查看。

下面来分析请求头到达Nginx负载均衡服务器的情况；在默认情况下，Nginx并不会对X-Forwarded-For头做任何的处理，除非用户使用proxy_set_header 参数设置：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

$proxy_add_x_forwarded_for变量包含客户端请求头中的”X-Forwarded-For”，与$remote_addr用逗号分开，如果没有”X-Forwarded-For” 请求头，则$proxy_add_x_forwarded_for等于$remote_addr。

$remote_addr变量的值是客户端的IP

当Nginx设置X-Forwarded-For等于$proxy_add_x_forwarded_for后会有两种情况发生

1、如果从CDN过来的请求没有设置X-Forwarded-For头（通常这种事情不会发生），而到了我们这里Nginx设置将其设置为$proxy_add_x_forwarded_for的话，X-Forwarded-For的信息应该为CDN的IP，因为相对于Nginx负载均衡来说客户端即为CDN，这样的话，后端的web程序时死活也获得不了真实用户的IP的。

2、CDN设置了X-Forwarded-For，我们这里又设置了一次，且值为$proxy_add_x_forwarded_for的话，那么X-Forwarded-For的内容变成 ”客户端IP,Nginx负载均衡服务器IP“如果是这种情况的话，那后端的程序通过X-Forwarded-For获得客户端IP，则取逗号分隔的第一项即可。

如上两点所说，如果我们知道了CDN设置了X-Forwarded-For信息，且只有客户端真实的IP的话，那么我们的Nginx负载均衡服务器可以不必理会该头，让它默认即可。

其实Nginx中还有一个$http_x_forwarded_for变量，这个变量中保存的内容就是请求中的X-Forwarded-For信息。如果后端获得X-Forwarded-For信息的程序兼容性不好的话（没有考虑到X-Forwarded-For含有多个IP的情况），最好就不要将X-Forwarded-For设置为 $proxy_add_x_forwarded_for。应该设置为$http_x_forwarded_for或者干脆不设置！

参考文章：http://salogs.com/qi

WAF(Web Application Firewall) and Code Review

kenvi — Thu, 06 May 2010 23:45:40 +0800

最近对于这两种方法的争论挺多的。

实际上，在我思想中，企业搞web安全，这是两个主攻方向了。(PCI标准也这么要求)

我习惯上把WAF归纳为过滤层，就是在应用的架构中有这么一个 filter-tier, 他起的作用是过滤和净化危险输入。在架构中的位置可以是多样化的：单独的硬件、apache mod、应用里面捕获输入；

WAF如果开启阻断功能的话，就可以起到虚拟补丁的功能。在这个意义上来说，可以减小程序员的工作量。

而WAF的最大阻力则是：
1. 误报
2. 对性能的影响
3. 稳定性

而AppSec这些公司推的WAF都属于硬件产品。包括mod-security等，他们都自己有一套漏洞规则，然后卖给甲方。这也是他们产品难推的原因，尽管你吹的天花乱坠，但实际上敢开启block模式的估计不会有多少，实际上jeremiah grossman自己也承认了，并引用了一段话

“When you know nothing, permit-all is the only option. When you know something, default-permit is what you can and should do. When you know everything, default-deny becomes possible, and only then.”

要了解所有的东西，就要从一开始就上WAF，对于很多半路出家搞安全的网站来说，这显然是很难接受的。

所以真正要实现好的WAF，只能是自己开发，自己部署，通过“学习模式”，来消除误报。而且自己的东西，是可控的，至少从心理上来说是可控的。

WAF的模式是有一定的作用，但不是万能的，也没厂商吹嘘的那么玄乎。这玩意治标不治本，无法带给你的网站安全；只有有人不断专业维护的WAF，才能从一定程度上说可以带给你安全。这就是我一直在强调的：安全是一个持续的过程。

与WAF对应的另外一个方向是code review。 code review也有很多方向，不是随便从网上抄个规范来就行的。同样的，code security review可以做为sdl中的一个核心过程，在软件工程中发扬光大。每个企业都需要找到自己代码的特色，从而定制出符合自己特色的代码规范，和代码漏洞扫描工具。这些思想也是我在《安全幻想曲2008》中曾经强调过的，可惜从CB的反馈看来，真正能看懂我那篇paper背后意思的人的恐怕不多。

code review 是一个治本的过程，也需要长期坚持。不过review code的成本会比较大，有人力也有时间的投入，还有更多的沟通成本。code review的方向应该是尽可能降低对个人经验的依赖，这就需要有优秀的规范和规则。

在应用安全里， WAF和code review应该是相辅相成的。但是我看现在不少厂商为了牟利，鼓吹WAF的优越性，让WAF走上了歪路，企业冤枉钱花了，却只是一个花架子的安全，一戳就破。如何正确应用，才是甲方安全人员需要思考的问题。

先瞎扯这么多，这两个话题可以讲很深，以后再慢慢一一侃来。

Web Application Firewall(WAF)入门

kenvi — Thu, 06 May 2010 23:40:02 +0800

Web Application Firewall又名WEB应用安全防火墙，简称WAF，07年底08年开始Web应用防火墙日趋流行，过去这些工具被很少数的大型项目垄断，但是，随着大量的低成本产品的面市以及可供选择的开源试用产品的出现，它们最终能被大多数人所使用。在这篇文章中，先向大家介绍Web应用防火墙能干什么，然后快速的概览一下Web应用防火墙最有用的一些特征。通过这篇文章的阅读，大家能清楚地了解web应用防火墙这个主题，掌握相关知识。

什么是web应用防火墙？

有趣的是，还没有人能真正知道web应用防火墙究竟是什么，或者确切的说，还没有一个大家认可的精确定义。从广义上来说，Web应用防火墙就是一些增强 Web应用安全性的工具。然而，如果我们要深究它精确的定义，就可能会得到更多的疑问。因为一些Web应用防火墙是硬件设备，一些则是应用软件；一些是基于网络的，另一些则是嵌入WEB服务器的。

国外市场上具有WEB应用防火墙功能的产品名称就有不同的几十种，更不用说是产品的形式和描述了。它难以界定的原因是这个名称包含的东西太多了。较低的网络层（Web应用防火墙被安置在第七层）被许多设备所覆盖，每一种设备都有它们独特的功能，比如路由器，交换机，防火墙，入侵检测系统，入侵防御系统等等。然而，在HTTP的世界里，所有这些功能都被融入在一个设备里：Web应用防火墙。

总体来说，Web应用防火墙的具有以下四个方面的功能：

1. 审计设备：用来截获所有HTTP数据或者仅仅满足某些规则的会话

2. 访问控制设备：用来控制对Web应用的访问，既包括主动安全模式也包括被动安全模式

3. 架构/网络设计工具：当运行在反向代理模式，他们被用来分配职能，集中控制，虚拟基础结构等。

4. WEB应用加固工具：这些功能增强被保护Web应用的安全性，它不仅能够屏蔽WEB应用固有弱点，而且能够保护WEB应用编程错误导致的安全隐患。

但是，需要指出的是，并非每种被称为Web应用防火墙的设备都同时具有以上四种功能。

由于WEB应用防火墙的多面性，拥有不同知识背景的人往往会关注它不同方面的特点。比如具有网络入侵检测背景的人更倾向于把它看作是运行在HTTP层上的 IDS设备；具有防火墙自身背景的人更趋向与把它看作一种防火墙的功能模块。还有一种理解来自于“深度检测防火墙”这个术语。他们认为深度检测防火墙是一种和Web应用防火墙功能相当的设备。然而，尽管两种设备有些相似之处，但是差异还是很大的。深度检测防火墙通常工作在的网络的第三层以及更高的层次，而 Web应用防火墙则在第七层处理HTTP服务并且很好地支持它。

直接更改WEB代码解决安全问题是否更好？这是毋庸置疑的，但也没那么容易（实现）。

因为，通过更改WEB应用代码是否一定就能增强系统安全性能，这本身就存在争论。而且现实也更加复杂：

    * 不可能确保100%的安全。人的能力有限，会不可避免地犯错误。
    * 绝大多数情况下，很少有人力求100%的安全。如今的现实生活中那些引领应用发展的人更多注重功能而不是安全。这种观念正在改变，只是有点缓慢。
    * 一个复杂的系统通常包含第三方产品（组件，函数库），它们的安全性能是不为人知的。如果这个产品的源代码是保密的，那么你必须依赖商品的厂商提供补丁。即使有些情况下源代码是公开的，你也不可能有精力去修正它们。
    * 我们不得不使用存在安全隐患的业务系统，尽管这些旧系统根本无法改进。

因此，为了获得最好的效果，我们需要双管齐下：一方面，必须提高管理者和开发者的安全意识；另一方面，尽可能提高应用系统的安全性。

Web应用防火墙的特点

Web应用防火墙的一些常见特点如下:

异常检测协议

如果阅读过各种RFC，就会发现一个被反复强调的主题。大多数RFC建议应用自己使用协议时要保守，而对于接受其他发送者的协议时可以自由些。Web服务器就是这样做的，但这样的行为也给所有的攻击者打开了大门。几乎所有的WAF对HTTP的请求执行某种异常检测，拒绝不符合Http标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些WAF还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

增强的输入验证

就频繁发生的Web安全问题而言，有些是源于对Web设计模型的误解，有些则来自于程序师认为浏览器是可信的。很多WEB程序员用JavaScript在浏览器上实现输入验证。而浏览器只是一个用户控制的简单工具，因此攻击者可以非常容易地绕过输入验证，直接将恶意代码输入到WEB应用服务器。

有一个解决上述问题的正确方法，就是在服务端进行输入验证。如果这个方法不能实现，还可以通过在客户和应用服务器之间增加代理，让代理去执行Web页面上嵌入的JavaScript，实现输入验证。

消极的安全模型VS积极的安全模型

曾经设置过防火墙规则的人，可能会碰到这样的建议：允许已知安全的流量，拒绝其他一切访问。这就是一种很好的积极安全模型。恰恰相反，消极安全模型则是默认允许一切访问，只拒绝一些已知危险的流量模式。

每种安全模型方式都存在各自的问题：

消极安全模型：什么是危险的？

积极安全模型：什么是安全的？

消极安全模式通常使用的更多。识别出一种危险的模式并且配置自己的系统禁止它。这个操作简单而有趣，却不十分安全。它依赖于人们对于危险的认识，如果问题存在，却没有被意识到（这种情况很常见），就会为攻击者留下可趁之机。

积极安全模式（又称为白名单模式）看上去是一种制定策略的更好方式,非常适于配置防火墙策略。在Web应用安全领域中，积极安全模式通常被概括成对应用中的每一个脚本的枚举。对枚举的每一个脚本，需要建立一个相应列表，表中内容如下所示：

    * 允许的请求方式（比如，GET/POST或者只POST）
    * 允许的Content-Type
    * 允许的Content-Length
    * 允许的参数
    * 指定参数和可选参数
    * 参数类型（比如，文本或整数）
    * 附加参数限制

上述列表仅仅是个例子，实际的积极安全模式通常包括更多的要素。它试图从外部完成程序员本应从内部完成的工作：为提交到Web应用的信息验证每一个比特。如果肯花时间的话，使用积极安全模式就是一个比较好的选择。这个模式的难点之一，在于应用模式会随着应用的发展而改变。每当应用中添加新脚本或更改旧脚本，就需要更新模式。但是，它适用于保护那些稳定的、无人维护的旧应用。

自动开发策略可以解决以上问题：

    * 一些WAF能够监视流量，并根据这些流量数据自动配置策略，有些产品可以实时进行这样的工作。
    * 通过白名单，可以标识特定的IP地址是可信的，然后，依据观察的流量，配置WAF，更新安全策略。
    * 如果通过一个全面的衰减测试，（仿真正确的行为，）来创建一个应用，并且在WAF处于监控状态时执行测试，那么WAF可以自动生成策略。

可见，没有哪个模式是完全令人满意的。消极安全模式适用于处理已知问题，而积极安全模式则适用于稳定的Web应用。理想的做法是，在现实生活中，将二者结合使用，取长补短。

及时补丁

积极安全模式理论上更好一些因为浏览器和WEB应用程序之间的通信协议通过HTML规范进行了很好的定义。现在的Web开发语言都可以处理带有多个参数的 HTTP请求。因为这些参数在Web应用防火墙中都是可见的，因此WEB应用防火墙可以分析这些参数判断是否存在允许该请求。，

当一个应用中的漏洞被发现时大多数情况下我们会尽可能在代码中修补它。受诸多因素的影响（如应用的规模，是否有开发人员，法律问题等等），开发补丁的过程可能需要几分钟，或者一直到无限长的是时间。这些时间正是攻击者发起攻击的好机会。

如果开发人员能够在非常短的时间内在代码中修补好漏洞，那你就不用担心了。但如果修补这个漏洞需要花费几天，甚至几周来修复呢？Web应用防火墙就是处理这个问题的理想工具：只要给一个安全专家不错的WAF和足够的漏洞信息，他就能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常完美的，并且没有安装对应的补丁就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。

及时补丁的原理可以更好的适用于基于XML的应用中，因为这些应用的通信协议都具规范性。

基于规则的保护和基于异常的保护

现在市场上大多数的产品是基于规则的WAF。其原理是每一个会话都要经过一系列的测试，每一项测试都由一个过多个检测规则组成，如果测试没通过，请求就会被认为非法并拒绝。

基于规则的WAFs很容易构建并且能有效的防范已知安全问题。当我们要制定自定义防御策略时使用它会更加便捷。但是因为它们必须要首先确认每一个威胁的特点，所以要由一个强大的规则数据库支持。WAF生产商维护这个数据库，并且他们要提供自动更新的工具。

这个方法不能有效保护自己开发的WEB应用或者零日漏洞（攻击者使用的没有公开的漏洞），这些威胁使用基于异常的WAF更加有效。

异常保护的基本观念是建立一个保护层，这个保护层能够根据检测合法应用数据建立统计模型，以此模型为依据判别实际通信数据是否是攻击。理论上，一但构建成功，这个基于异常的系统应该能够探测出任何的异常情况。拥有了它，我们不再需要规则数据库而且零日攻击也不再成问题了。但基于异常保护的系统很难构建，所以并不常见。因为用户不了解它的工作原理也不相信它，所以它也就不如基于规则的WAF应用广范。

状态管理

HTTP的无状态性对Web应用安全有很多负面影响。会话只能够在应用层上实现，但对许多应用来说这个附加的功能只能满足业务的需要而考虑不到安全因素了。Web应用防火墙则将重点放在会话保护上，它的特征包括：

强制登录页面。在大多数站点，你可以从任何你所知道的URL上访问站点，这通常方便了攻击者而给防御增加了困难。WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。

分别检测每一个用户会话。如果能够区分不同的会话，这就带来了无限的可能。比如，我们能够监视登陆请求的发送频率和用户的页面跳转。通过检测用户的整个操作行为我们可以更容易识别攻击。

对暴力攻击的识别和响应。通常的Web应用网络是没有检测暴力攻击的。有了状态管理模式，WAF能检测出异常事件（比如登陆失败），并且在达到极限值时进行处理。此时它可以增加更多的身份认证请求的时间，这个轻微的变化用户感觉不到，但对于足以对付自动攻击脚本了。如果一个认证脚本需要50毫秒完成，那它可以发出大约每秒20次的请求。如果你增加一点延时，比如说，一秒种的延迟，那会将请求降低至每秒不足一次。与此同时，发出进一步检测的警告，这将构成一个相当好的防御。

实现会话超时。超出默认时间会话将失效，并且用户将被要求重新认证。用户在长时间没有请求时将会自动退出登录。

会话劫持的检测和防御。许多情况下，会话劫持会改变IP地址和一些请求数据（HTTP请求的报头会不同）。状态监控工具能检测出这些异常并防止非法应用的发生。在这种情况下应该终止会话，要求用户重新认证，并且记录一个警告日志信息。

只允许包含在前一请求应答中的链接。一些WAF很严格，只允许用户访问前一次请求返回页面中的链接。这看上去是一个有趣的特点但很难得到实施。一个问题在于它不允许用户使用多个浏览器窗口，另一个问题是它令使用JavaScript自动建立连接的应用失效。

其他防护技术

WAF的另外一些安全增强的功能用来解决WEB程序员过分信任输入数据带来的问题。比如：

隐藏表单域保护。有时，内部应用数据通过隐藏表单变量实现，而它们并不是真的隐藏的。程序员通常用隐藏表单变量的方式来保存执行状态，给用户发送数据，以确保这些数据返回时未被修改。这是一个复杂繁琐的过程，WAF经常使用密码签名技术来处理。

Cookies保护。和隐藏表单相似的是，cookies经常用来传递用户个人的应用数据，而不一样的是，一些cookies可能含有敏感数据。WAFs 通常会将整个内容加密，或者是将整个cookies机制虚拟化。有了这种设置，终端用户只能够看到cookies令牌（如同会话令牌），从而保证 cookies在WAF中安全地存放

抗入侵规避技术。基于网络的IDS对付WEB攻击的问题就是攻击规避技术。改写HTTP输入请求数据（攻击数据）的方式太多，并且各种改写的请求能够逃避IDS探测。在这个方面如果能完全理解HTTP就是大幅度的改进。比如，WAF每次可以看到整个HTTP请求，就可以避免所有类型的HTTP请求分片的攻击。因为很好的了解HTTP协议，因此能够将动态请求和静态请求分别对待，就不用花大量时间保护不会被攻击的静态数据。这样WAF可以有足够的计算能力对付各种攻击规避技术，而这些功能由NIDSs完成是很耗时的。

响应监视和信息泄露保护。信息泄露防护是我们给监视HTTP输出数据的一个名称。从原理上来说它和请求监视是一样的，目的是监视可疑的输出，并防止可疑的 http输出数据到达用户。最有可能的应用模式是监视信用卡号和社会保险号。另外，这个技术的另一项应用是发现成功入侵的迹象。因为有经验攻击者总会给信息编码来防止监测，所以防止这样有决心并技术熟练的攻击者获取信息是很困难的。但是，在攻击者没有完全掌控服务器而仅仅尝试WEB应用的安全漏洞的情况下，这项技术可以起到防护效果

Ubuntu 服务器上安装 SSH Server

kenvi — Sat, 01 May 2010 15:13:20 +0800

因为我需要的服务器最终会被“抛弃”在实验室的某个角落，无论是后期设置还是维护的需要，都必须安装一个远程管理的工具。在 Linux 系统中，不二的选择就是 openssh 了。在 Ubuntu 中安装 openssh 实在是再简单不过的一件事情了，下面的内容也只是纯记录，给我这个菜鸟备个份。如果是高手直接绕过就好。

安装前的准备

Ubuntu 之所以好用，就是因为它继承了 debian 的 apt 系统，这一点相信您在昨天装系统的教程中已经感受到了。但是 apt 需要依赖网络，昨天我们装好的系统是暂时上不了网的，我们需要先设置一下。

首先，激活服务器的网卡，命令如下：

sudo nano /etc/network/interfaces

在 interfaces 中添加以下内容：

auto eth0
iface eth0 inet static
address 202.113.235.181
netmask 255.255.255.0
gateway 202.113.235.1

这其中，斜体部分标注的 IP 地址是我服务器的设置，您需要根据您的具体情况修改。当然，如果您的服务器使用的是 DHCP 来分配 IP 地址，只需要写上 iface eth0 inet dhcp 就可以了，无需设置 address/netmask/gateway。

然后，修改 resolv.conf 配置 DNS 服务器：

sudo nano /etc/resolv.conf

添加您的 DNS 服务器地址：

nameserver 202.113.16.10
nameserver 202.113.16.11

完成后，重新启动 networking 服务：

sudo /etc/init.d/networking restart

这样应该就可以连通网络了。如果您使用的是 ADSL，可能还需要装上 pppoe 之类的东西，考虑到服务器很少用这样的配置，这里就不讨论了，需要的话可以在网上查找。

安装和设置 OpenSSH Server

Ubuntu 下安装 OpenSSH Server 是无比轻松的一件事情，需要的命令只有一条：

sudo apt-get install openssh-server

随后，Ubuntu 会自动下载并安装 openssh server，并一并解决所有的依赖关系。当您完成这一操作后，您可以找另一台计算机，然后使用一个 SSH 客户端软件（强烈推荐 PuTTy），输入您服务器的 IP 地址。如果一切正常的话，等一会儿就可以连接上了。并且使用现有的用户名和密码应该就可以登录了。

事实上如果没什么特别需求，到这里 OpenSSH Server 就算安装好了。但是进一步设置一下，可以让 OpenSSH 登录时间更短，并且更加安全。这一切都是通过修改 openssh 的配置文件 sshd_config 实现的。

首先，您刚才实验远程登录的时候可能会发现，在输入完用户名后需要等很长一段时间才会提示输入密码。其实这是由于 sshd 需要反查客户端的 dns 信息导致的。我们可以通过禁用这个特性来大幅提高登录的速度。首先，打开 sshd_config 文件：

sudo nano /etc/ssh/sshd_config

找到 GSSAPI options 这一节，将下面两行注释掉：

#GSSAPIAuthentication yes
#GSSAPIDelegateCredentials no

然后重新启动 ssh 服务即可：

sudo /etc/init.d/ssh restart

再登录试试，应该非常快了吧

利用 PuTTy 通过证书认证登录服务器

SSH 服务中，所有的内容都是加密传输的，安全性基本有保证。但是如果能使用证书认证的话，安全性将会更上一层楼，而且经过一定的设置，还能实现证书认证自动登录的效果。

首先修改 sshd_config 文件，开启证书认证选项：

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

修改完成后重新启动 ssh 服务。

下一步我们需要为 SSH 用户建立私钥和公钥。首先要登录到需要建立密钥的账户下，这里注意退出 root 用户，需要的话用 su 命令切换到其它用户下。然后运行：

ssh-keygen

这里，我们将生成的 key 存放在默认目录下即可。建立的过程中会提示输入 passphrase，这相当于给证书加个密码，也是提高安全性的措施，这样即使证书不小心被人拷走也不怕了。当然如果这个留空的话，后面即可实现 PuTTy 通过证书认证的自动登录。

ssh-keygen 命令会生成两个密钥，首先我们需要将公钥改名留在服务器上：

cd ~/.ssh
mv id_rsa.pub authorized_keys

然后将私钥 id_rsa 从服务器上复制出来，并删除掉服务器上的 id_rsa 文件。

服务器上的设置就做完了，下面的步骤需要在客户端电脑上来做。首先，我们需要将 id_rsa 文件转化为 PuTTy 支持的格式。这里我们需要利用 PuTTyGEN 这个工具：

点击 PuTTyGen 界面中的 Load 按钮，选择 id_rsa 文件，输入 passphrase（如果有的话），然后再点击 Save PrivateKey 按钮，这样 PuTTy 接受的私钥就做好了。

打开 PuTTy，在 Session 中输入服务器的 IP 地址，在 Connection->SSH->Auth 下点击 Browse 按钮，选择刚才生成好的私钥。然后回到 Connection 选项，在 Auto-login username 中输入证书所属的用户名。回到 Session 选项卡，输入个名字点 Save 保存下这个 Session。点击底部的 Open 应该就可以通过证书认证登录到服务器了。如果有 passphrase 的话，登录过程中会要求输入 passphrase，否则将会直接登录到服务器上，非常的方便。

QQREADERF26AB3D62169C803

kenvi — Sun, 04 Apr 2010 17:48:44 +0800

QQREADERF26AB3D62169C803

Kenvi的布拉格

浅谈产品经理的基础和能力

nginx文件类型错误解析漏洞

Adobe CS5 全系列软件通用破解补丁

Adobe CS5 通用破解补丁使用方法：

下面以安装 Photoshop CS5 为例：

PAC-MAN 30th Anniversary

腾讯微博邀请

Nginx做负载均衡时X-Forwarded-For信息头的处理

WAF(Web Application Firewall) and Code Review

Web Application Firewall(WAF)入门

Ubuntu 服务器上安装 SSH Server

安装前的准备

安装和设置 OpenSSH Server

利用 PuTTy 通过证书认证登录服务器

QQREADERF26AB3D62169C803

随机日志