关于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应该都还不错,否则也不会有人去用了(哈哈,我其实对于这两个真的一点都不了解~~)

Deepseath Modified from Green Hope Theme · Proudly powered by WordPress · 津ICP备09005418号-1  津公网安备 12010302001005号