关于SQL注入的监测
网站被挂马，有一个方式就是对某个帐号进行提权操作，比如针对非管理用户提权至最高管理员的权限。
事后可以发现被提权的用户帐号，但检查经由哪个文件注入的是个麻烦的事情，特别是针对开源的文件结构比较复杂的程序来说。
以前有个思路，一直未实现，今天处理了一个，是针对Discuz!5.5（很老的一个版本了^^）的，处理思路就是事后诸葛亮。
点评类网站寻求突围路径
转自《中国经营网》http://www.cb.com.cn/1634427/20101008/155057.html
觉得里面说得还不错，对于项目运营方向有一些参考意义。以下是全文转载。 更多 »
关于用户邮箱验证的一个思路
当下很多运营或者应用都会引导用户激活验证注册的Email地址，为了确保获得更可靠的用户（虽然可靠性不是很高），同时也为了避免地址不被滥用，尽力获取更优化的用户资源等等，好处是很多的。
一般在验证流程上都很简单，无非是：根据用户登记的Email发送一个验证邮件，用户收到邮件后，访问一个特定的处理链接，系统接收后，便会确认此人Email通过验证激活。
这个方式简单容易，设计也很方便。
但有一个“问题”，某个用户起初登记了一个A地址，然后通过了验证，过了一阵他又将Email改成了B地址，也通过了验证，可过了一阵又因为某种原因他又将Email改回了A地址，可系统仍旧提示未通过验证，这个挺囧的——当然其实也不是什么大不了的问题，不过个人始终觉得这是一个人性化的考虑。已经通过验证了的邮箱为什么还要再次验证呢？
近期在一个项目上也有类似的处理，因为基于该异想天开的想法，我特意费时巴拉的用了一个新的机制，虽然没人能够看到，但我相信多多少少会让用户觉得有点人味的^_^
具体流程其实很简单，无非是增加一个数据表，用来储存经过验证的Email地址，且每个Email对应一个用户id。
当用户通过验证的时候记录下他的id和Email，以及其他信息（比如验证时间等等）
当用户修改Email的时候，先去到这个数据表内查询该记录是否存在（uid和email同时满足），存在了就表面该用户已经通过验证了，不需要再次发送验证邮件。
uid与Email是作为一个唯一性索引键（UNIQUE）存在的。这样可以确保别人冒用这个Email地址的情况也被认为是通过验证的。 也就是说，只有其本人曾经用过的Email地址才会采用跳过验证的机制。
简单说：
用户A曾经验证通过了a、b、c三个Email地址。 那么日后他无论将Email地址修改变换为这三个任意一个的时候，系统都不会提醒他再次去验证。
如果另一个用户B登记了a地址，那么系统还是要提醒他进行验证的，因为数据表记录下验证通过a地址的用户是A而不是B。
以上就是我在项目中关于用户Email地址验证的一个机制（当然实际操作过程中，还要加入一个验证的条件限制等条件，避免用户频繁的请求，关于这部分处理，相信所有的验证机制都会考虑的。），不一定有什么特别重大的作用，不过觉得还是挺有意思的，记录下来分享一下吧。
（转）成功演讲的10个技巧（要点）
偶然读到这篇文章，觉得挺有意义的，转过来备忘一下，也许，也许有用得着的时候^_^
来自：http://www.zishu.cn/10/928.html
一、讲前准备
1、在讲前30-60分钟，要检察所有相关的设备，如电脑、投影仪、麦克风，确保设备正常；如果不正常，自已不家足够的时间去准备；
2、在讲前30分钟，再把要讲的PPT全部过一遍，这个是非常有用的；
3、在讲前10分钟，下次和听几个听众聊聊天，了解一下他们想听到些什么？为什么来等？另外，可以混个脸熟，在讲的过程中，对着这几个人，最起码不会紧张；
4、在讲前2分钟，反复反复反复在说自已的开场，或前30秒；因为前30秒是最危险的，这30秒过了，基本就不紧张了； 更多 »
关于验证码实现的另一个思路
最近在做一个项目。在涉及到关于忘记密码找回功能时，从用户体验角度去考虑，在申请找回密码表单中只有两个元素——Email输入文本框和一个提交按钮。应该说会很方便。
但在接下来测试的时候，突然发现，虽然方便一些，同时也有关于恶意动作的阻止策略，但某些意外因素仍旧无法避免。
因此考虑加上一个验证码，避免一些纯粹攻击性恶意申请动作（此类动作其实也可以用一个方式进行阻止，不过，因为某些原因在此不方便实现）。
原本验证码打算用一些比较成熟的开源的代码来实现（比如：Discuz!中的验证码类——/include/seccode.class.php就是一个不错的例子），但其实发现类似这些显示出的效果仍旧会出现“人”难识别的情况。
对于机器识别验证码图片字符的机理说实话了解不多，以我的知识，我觉得可能是利用图片色彩加上字库方式去分辨的。既然是这两个因素，那么图片色彩上如果过于复杂显然对于“人”也同样难以识别，这个因素可以大略不去考虑，从字库来说，我觉得如果验证码字符利用非常规字库去显示或许效果会很好——但我不清楚机器将什么字库作为“非常规”，因此，我决定利用图片组合的方式进行构建。
简单说，就是将事先做好的字符图片拼凑起来，字符图片可以使用多套然后随机选取，字符图片上的“字符”利用自己“个性设计”——比如，将常规的字库图形利用图片编辑软件加以变形、缩放等等。考虑到，字符涉及较多，因此设计遵循两个原则：一是要将某些模棱两可的字符排除掉（比如：L、1、i、0、O等），二是根据CSS Sprite的原理，将同类型的字符放到一个图片中——我自己称之为“字符库图片”。
经过设计，得到若干组的 字符库图片，然后再设计多种类型的“背景图片”，作为验证码的背景，略微增加一些识别干扰。设计的原则最重要的就是——易于人类识别。
由于字符是特定个数的（经过我的筛选剩余24个）字母和数字，因此很容易放到一个小的数组里，利用array_rand()函数以及shuffle()函数，很容易生成一个漂亮的随机字符串。利用字符串单元字符的特定“位置(其实与数组的键值是对应的)”可以很方便的在“字符库图片”中找到它的位置。利用imagecopymerge()函数轻松的将它们拼凑在一起。
这样最终就形成了一个验证码的显示。
配合验证码的验证，可以利用私有的加密函数将字符串原形加密后保存在cookie内，对用户提交后进行快速验证。
由于涉及到的数组、图片的数量都不大，因此对于压力负载情况很好。
组合图片不是这个思路的难处，难点在于如何设计“人类”能看懂的字符图形:)另外，对于字符图片的相对位置控制也是一个比较费思量的课题，好在通过一些位置上的计算也可以进行不规则的变化。
思路很简单，写了一个简单的应用类，设计了大概6组“字符库图片”和4组“背景图片”，加上测试也花了整整一个下午的时间，效果自认为还不错。
代码就不上了，其实代码很简单，每个人的算法都可能不一样，主要的难点在于“字符库图片”的设计和排序问题。
谁订阅了我的博客，有兴趣看代码的可以直接朝我要，不贴在这里了^_^
PS：最近做项目用最多的是jQuery，这个框架太爽了。通过这个了解到框架做事的确很轻松，可惜，接触PHP有年头了，某些观念和意识基本已经根深蒂固了，所以到现在还无法使用任何PHP的框架。同时对于面向对象的开发，我个人真的是不入门，我倒觉得面向过程也并非是网上说的一无是处——比如性能、比如理解力等等还是略胜上风的。呵呵，题外话，个人不喜欢（或不上路）并非宣传大家也不要用，事实上，我最近看到开源站最多的比如：ThinkPHP、CakePHP应该都还不错，否则也不会有人去用了（哈哈，我其实对于这两个真的一点都不了解~~）
