关于SQL注入的监测

网站被挂马,有一个方式就是对某个帐号进行提权操作,比如针对非管理用户提权至最高管理员的权限。

事后可以发现被提权的用户帐号,但检查经由哪个文件注入的是个麻烦的事情,特别是针对开源的文件结构比较复杂的程序来说。

以前有个思路,一直未实现,今天处理了一个,是针对Discuz!5.5(很老的一个版本了^^)的,处理思路就是事后诸葛亮。

更多 »

MySQL报错Errcode: 28

在对大数据进行查询操作(比如,排序操作)时候,有时候会有类似:Error writing file ‘x:/tmp/xxxx.tmp’ (Errcode: 28)的错误提示。 更多 »

PHP的命令行执行方式

最近喜欢上了用PHP的命令行方式执行一些操作。

PHP的命令行方式详情可以看一下手册内容,写得很详细的。这里只说说自己在应用时的一些情况。 更多 »

PHP的Snoopy.class.php

使用PHP读取HTTP页面基本使用Snoopy,使用简单方便易用。

最近在使用过程中发现一些问题,读取某些服务器的时候会发现获取不到页面内容。

留意Snoopy的Header请求头的时候发现,对于HOST请求是类似
HOST: hostname:port
看代码,只要端口存在,就使用该方式发送请求。

但观察浏览器请求时发现如果端口为80的时候,会省略掉端口号。

按这个方式改造一下Snoopy的代码,加入判断端口号,如果端口号为80的情况下,则直接使用
HOST: hostname
否则使用
HOST: hostname:port

这样改写代码后上面的问题就解决了。

问题的原因不太清楚,呵呵,对于HTTP协议始终就是模棱两可一知半解,实用至上主义,问题解决就不管了。

另外,还有一个问题就是,自官方下载到的Snoopy.class.php的编码问题,这个文件使用的是“阿拉伯语(Windows)”进行编码的,至少在这个编码下查看没有乱码。
为了方便日后改写代码,我是利用阿拉伯语(Windows)打开,然后Copy无乱码的代码另存为UTF-8编码,方便日后更改处理。

分享一下近期在开发过程中用到的一些PHP库类

手里的项目进展还算顺利,即将进入一个新阶段,越来越感觉运营中的那句话“先开枪后瞄准”的确是进行一个商业计划(特别是比较新颖的)时,需要考虑的。技术人员不能眼里只有纯粹的技术,如若想要尽快的实现盈利,一些非关键性的功能和技术方面可以放到后面去考虑,目的是要尽快的确保项目能够稳定的运行且尽快的抢占市场赢得一些商机。

一直以来开发的程序都没有用过现成的框架,由于对面向对象开发还是有一些障碍(心理接受以及性能方面考虑等),但由于一些长期的运营项目涉及未来扩展和开发问题(面向过程开发在这方面还是很弱的),所以自己弄了一个面向过程开发的一个“框架”(只能算是一个雏形吧),虽然不能解决大问题,但最起码可以让新开发中减少很多重复性的操作。
更多 »

几款比较实用的PHP库

整理资料的时候看到的,不知道出处了。放博客上备忘一下^_^都是比较实用的。

更多 »

(转)基于jQuery的上下无缝滚动应用(单行或多行)

有时候能用得着,自己懒的写(估计写也不是很好,嘿嘿),看到一个插件。 更多 »

域名转移注册商操作完毕

2010年7月22日申请了eXinQing.net的域名转移注册商(http://www.deepseath.com/?p=731)

当日已经顺利进行确认信确认。

直到7月26日中午,突然发现域名DNS无法解析,询问后得知只能是等待,这状况一直持续到7月28日早上8点左右,发现域名已经完全转移完毕,且可以在新的注册商处进行管理。

只是仍旧无法进行DNS设置解析。联系客服后终于在11点的时候可以进行修改了。

经过设置后,根据网友的报告,大概在12点半左右国内已经陆续可以正常解析访问了。

通过本次域名转移注册商得到几个经验就是:

1.注册域名最好选择一些知名的有品牌的注册商,要考虑到日后维护、缴费、迁移等等问题的方便性以及代价(比如,我这个域名就交给之前注册商500元的手续费,TMD)

2.做域名迁移前一定要做好预案,万一无法解析的时候应该通过一些手段来避免用户无法访问。因为有时候域名迁移DNS会中断的,当然如果幸运其实整个过程DNS都是可以正常解析的。

原本其实还有备用域名的,可惜早先没想过这样的问题,只是将备用域名做了一个永久转向。

现在看来,得想个方式在未来能够尽量避免这样的问题。

始终对于多域名访问有一个困惑:

我想实现一种方式,平时只用一个域名访问(当然也包括这个域名的二级域名),其他域名只是转向。如果万一这个域名无法解析的时候,只要通过一些轻微(记住是轻微)的更改就可以轻易的切换到两个域名同时可以访问的状态。

自己琢磨了几个方案发现都不行:(原因是因为,几个栏目之间的应用其实还有一些内部通讯,如果要更换域名的代价太大了,操作非常多——特别是栏目和应用特别多的情况下。

不知道大家都有什么好办法?给个建议哦~~

由服务器想到的……

昨天夜里到今天上午,服务器由于第二块硬盘无法找到而停止运行。搞得心神不宁的……

服务器已经3年多了,头一两年基本比较稳定,自从去年来,频繁死机,先是更换过内存条,然后春节前有更换了主板,虽然最近一个多月温度稍微高一些(CPU温度一般在55到59度之间),但也算比较稳定的运行了40天,前天正庆幸机器争气,结果昨天就出现了意外——第二块硬盘偶尔就找不到了:(由于数据库以及一些系统日志文件都写到了第二块硬盘,因此非常害怕出问题,经过检查发现,似乎硬盘没什么问题,很有可能是数据线或者接口的问题。凌晨的时候机房没人,所以到今天早上给机房打电话帮忙查看一下,因为机房也没有备用的数据线,所以只是更换了一个插口,恢复开机后,发现运行稳定,暂时处于观察期,但也不敢大意,先把数据库进行了备份,然后将系统日志都转移到主硬盘上了,数据库还是留在那块上,期望减少对这块硬盘的请求降低它的负载,期望不会再有问题了。唉,每次服务器有问题都会搞得头痛,类似那种偏头痛的感觉,睡觉也不踏实,神经衰弱……

经过这个事情,目前考虑了一个新的架构。主要是针对投入有限的情况而且有期望性能有所提高的。

之前架构服务器的时候,为了节省资金获得最高的性价比,因此只用一台服务器进行架构,web+database,从数据库读写性能角度考虑,把数据库放到了第二块硬盘上,web服务和文件放在第一块硬盘(主硬盘) ,系统运行日志也放到第二块上了。其实这种架构应该说是最节省也是相对获得最大的性价比的方式,毕竟再花万把块钱实在是捉襟见肘了。不过,这次感觉这样的架构还是有点麻烦,数据库和系统日志都是频繁进行读写的,增加了系统的不稳定性,现在硬盘价格已经很便宜了,因此,考虑如果只用一台服务器架构web的话:

可以考虑将主硬盘只做操作系统、软件环境、然后单独划出一个分区作为整个系统的日志区,

第二块硬盘,作为web程序文件存放区,除此之外不再放其他文件。

第三块硬盘,作为数据库储存区,只放数据库文件。数据库日志不在此处,单独放到主硬盘的日志区内。

如果,还有可能的话,可以再加一块硬盘,单独作为备份盘使用,平时不做任何读写操作,纯粹做为数据库备份之用。

这样的架构,可以最大的降低磁盘磁头的读写频率,提高I/O性能,从而保护磁盘寿命。

PS:纯粹只是一台机器用的,如果有很多money,基本不太考虑这个了……穷啊……而且,这个服务器上的网站纯粹只是个人爱好而已,没有获得什么收入, 每年运行的费用虽然不多,可也不是个小数了……

关于验证码实现的另一个思路

最近在做一个项目。在涉及到关于忘记密码找回功能时,从用户体验角度去考虑,在申请找回密码表单中只有两个元素——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应该都还不错,否则也不会有人去用了(哈哈,我其实对于这两个真的一点都不了解~~)

页面嵌入JavaScript脚本的URL“and”符号

在HTML页面中嵌入JavaScript脚本代码,如果代码内包含一些URL中的“and”符号(&),或者包含HTML元符号(用于输出结构的),如果不对javascript代码区进行注释声明处理,那么就不符合W3C标准当然也就不能通过w3c检测。
比如:
<script type="text/javascript">
var test='http://www.foudang.com/tag/?tag=%E5%81%87%E8%B4%A7&p=2';
</script>

是不可以的,但如果将 & 替换为 &amp; 是可以通过w3c验证的,不过,由于javascript处理URL会将&认为是变量的间隔符,如果改为 &amp; 那么实际上面的URL将会被处理为tag=xxx 和 amp;p=2。

这个时候可以使用注释声明:
<script type="text/javascript">
/* <![CDATA[ */
var test='http://www.foudang.com/tag/?tag=%E5%81%87%E8%B4%A7&p=2';
/* ]]> */
</script>

或者:
<script type="text/javascript">
//<![CDATA[
var test='http://www.foudang.com/tag/?tag=%E5%81%87%E8%B4%A7&p=2';
//]]>
</script>

都可以。

PS:事实上,我之前也有过“另类”的一种解决方法,对于HTML标签字符,我写到外部的js文件内;对于URL我就使用一个函数去构造,用起来也倒很方便,但现在看来有点弱智,呵呵。因为很早之前刚接触W3C的时候一味追求通过验证,根本没仔细研究过,为了标准而标准来着,这是很不好的一个方式……

建议所有的程序开发者一起来保护MySQL——《拯救MySQL》

对于其他程序不甚了解,但就PHP开发来说,估计99%的人都选择MySQL作为数据库,因为MySQL给大家的印象是轻巧、易用并且最重要的是它有一个免费的社区版本,这个版本同它收费版本是完全一样的区别仅在于它的商业版本提供技术服务而已。

作为一个PHPer来说,我自2000年接触PHP,因为没有任何程序语言基础,所以学习起来挺费劲,一直使用文本储存数据,但真的觉得既麻烦又不安全,然后2001年年初的时候第一次开始接触MySQL,对于我无任何数据库语言概念的人来说上手的确有一点点困难,但我清晰的记得,看完了几个例子以后,我便轻松的了解了MySQL知道了它的强大、易用,而且最主要的是它不像Orlce和SQL Server,它是免费的!!

自那个时候起,我慢慢开始了解了这世上还有一些人,在维护着PHP、维护着MySQL、维护着Apache,我知道了一个名词“开源社区”,知道了还有一个免费的操作系统Linux ,知道这世界上还有一群具有创新、共享精神的人……

到现在,熟练使用并在自己项目上应用部署MySQL已经有接近8年的时间了,从MySQL4.0用到MySQL5.1,这个过程是很奇妙的,我从未担心过什么,因为我知道MySQL精神会继续着 ……

突然有一天,我知道了那个卖得很贵的数据库Orcal的东家甲骨文开始“惦记”着MySQL了 ,就我个人的感觉来说,这不是什么好事,如果这个公司或者其他别有用心的公司去收购MySQL,那么可能会带来的两种情况就是:1.为了维护其自身收费的数据库产品,势必会打压MySQL的开发,致使MySQL慢慢落后于其他数据库,导致它的淘汰;2.将MySQL也变成一个完全收费的产品。我个人可能更容易想到第一种情况,如果是那样,那真的是一个灾难……

为此,包括MySQL的创始人Michael Widenius在内的一些人组织了一个《拯救MySQL》的活动,请求所有MySQL的支持者支持和保护MySQL。

刚刚也在上面签名了,做为能力有限的支持者来说,我也许只能做到这些了。

希望支持MySQL的朋友们,一起来救救MySQL,点击进入这个链接填写表单就可以了:http://www.helpmysql.org/cn/petition

不要害怕E文,呵呵,是多语言的,我给的连接是中文版的^_^

拯救MySQL

拯救MySQL

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