东拉西扯

浅谈个人博客网站or屌丝vps服务器暴露真实IP的危险性

经常关注张戈博客的朋友应该注意到,张戈在以往的文章中多次提到要隐藏我们网站服务器的真实IP,比如最近分享的《阿里云盾网站安全防御(WAF)的正确使用方法》,肯定有不少人心怀疑问,这是为什么呢? 一、为啥隐藏真实IP? 今天,抛出这样一个话题,也是为了提醒那些还懵懵懂懂,毫无设防的屌丝站长们!我们是小网站,我们用的也是屌丝服务器,不像腾讯、网易那些大站用的是价格昂贵、性能卓越的高性能、高可用集群。我们这种屌丝服务器一旦被人恶意攻击基本玩完! 也许,大部分人和我有一样的想法:这有啥,开启高防CDN啊!比如百度云加速、360网站卫士以及安全宝等。确实,使用国内免费的高防CDN是我们这种屌丝服务器的最佳选择。 当我们使用了高防CDN之后,用户访问路径如下: 用户请求-->高防CDN节点-->源服务器 攻击请求就落到分布式大带宽的CDN节点,如果合理设置好缓存项目,我们的服务器几乎不会受到影响。 看到这,你是否对今天这个话题嗤之以鼻?心里想着暴露真实IP有什么问题?我开启百度云加速不就好了嘛! 不错,这应该就是大部分人的想法了,当然肯定还有大部分人对暴露真实IP无动于衷,不知道有什么危害。 好吧,再往下看你是否依然淡定。 一旦真实IP暴露,攻击者只要在攻击时用类似于hosts手段指定IP去攻击,那就神马CDN都是浮云了!因为攻击请求已绕过了CDN节点,直捣黄龙!而DDoS更甚,可以直接大流量攻击真实IP,非高防服务器会立马死翘翘! 当攻击者通过hosts强行指定源服务器IP来进行攻击时,请求途径如下: 攻击请求-->hosts解析-->源服务器 直接绕过高防CDN节点,落到了源服务器!小带宽,低配置的屌丝服务器,对于大批量的不同IP请求,几乎毫无防御能力!每个IP都是正常的请求,根本无法辨别黑白,那么同时l来1000个,看你死不死? 因此,保护好真实IP不暴露到公网,对于小服务器来说是重中之重!虽然你是新站,暂时没被人盯上,一旦有一点起色就很可能招来各种苍蝇的攻击骚扰。这些苍蝇不一定是因为你的网站挡了他的财路,很可能就因为在你网站留言一些推广被拉黑,也有可能是因为和你换友链被拒绝等等,都可能带来嫉恨似的攻击骚扰!直接原因无它,只因CC攻击成本太低而已! 二、如何隐藏真实IP? 上面也已经说了,目前隐藏真实IP的做法主要是利用国内外一些免费的CDN加速服务。比如国内的百度云加速、加速乐、360网站卫士以及安全宝,国外的CloudFlare。不管有没有备案,都能选择一款适合你的免费产品。 当然,如果你不需要加速功能,也可以考虑入住阿里云或腾讯云,然后使用免费的WAF防御服务,也能使用cname解析,起到改变网站IP的效果。 实际上,如此设置之后,在隐藏真实IP的同时,也杜绝了网络上那些到处扫描端口、扫描漏洞的行为。 三、个人经验分享 那用这些高防CDN隐藏真实IP之后,是否百分百可靠呢?且继续看。 不久前,张戈博客被一大波苍蝇攻击,1核CPU配置下的 load average 直接达到10+!我挺奇怪的,因为张戈博客早已实现了纯静态化,被攻击不应该产生这么高的CPU负载才对,因为都是 html 页面。 网站已经龟速,容不得我细究。我立刻将网站迁移到百度云加速,设置为完全缓存,结果发现网站打开速度变快了,但是CPU负载还是没有明显的改善,这是为什么? 当我查看 nginx 的 access.log 才恍然大悟,原来是 postviews 插件的 ajax 统计!就算你是纯静态html,被打开的时候,还是会产生一个 ajax 动态请求来记录浏览数,从而导致了cpu的狂飙,被请求的路径是: https://zhang.ge/wp-admin/admin-ajax.php 我最开始想到的解决方法是,直接将 admin-ajax.php 重命名,让请求变成404状态,CPU瞬间恢复正常! 重命名之后,在WP后台操作的时候发现一个问题,后台很多操作都不能生效了,比如我点击批准了一个评论,刷新后评论又变成待审核了。看来后台的很多操作也是ajax请求了这个文件! 既然不能重命名了,那只好想其他办法了!在页面里面看到这个 postviews 的 ajax 请求代码如下: 因此,我想到的临时解决办法是修改 admin-ajax.php 这个文件,在<?php 后面加入如下内容: 保存后,CPU 压力立马消失无影无踪!因为我让浏览统计临时失效了。浏览统计这种不痛不痒的功能,影响不大。等攻击消停之后再改回来就是。 从这个案例,我们可以看出,百度云加速等高防CDN并不是百分百有效的。当攻击者用数以万计的不同IP来请求的时候,只要你页面中存在一个动态请求,负载就上去了! 最后分享一个小经验,我2个网站的360网站卫士和百度云加速解析记录与各种设置都是以前就设置好了的,一旦被攻击,我只要立刻将NS记录指向云加速或360的NS服务器即可,方便又快捷!这就叫运筹帷幄,未雨绸缪,不管有没有攻击都要留好紧急恢复后路,避免不必要的损失。 好了,磨叽叭嗦的就说到这里,希望我这篇文章能起到正能量的作用,而不是给那些苍蝇们提供了一个无视高防CDN的攻击途径!当然,张戈在这里也奉劝那些整天没事喜欢CC攻击小网站的朋友,这点攻击手段真的很菜鸟,很逗逼,很没技术含量,你真要有本事,敢不敢去做一个白帽子造福互联网?
阅读全文
WEB应用

阿里云盾网站安全防御(WAF)的正确使用方法

将2个网站搬到阿里云,一个是因为阿里云稳定,另一个就是牛逼轰轰的云盾了。之前在博客联盟群里模拟CC攻击过搭建在阿里云ECS上的博客,结果云盾毫无反应,而网站已经挂了。 这次特意细看了一下云盾上的CC防护功能,发现有部分朋友估计并未正确使用WAF。所以,我在本文就简单的分享一下阿里云盾-WAF网站防御的正确使用方法。 一、域名解析 大部分朋友,只是开启了云盾就不管了,这也就是很多朋友受到CC攻击后,云盾却毫无反应的原因了。实际上WAF防御必须配合域名解析来使用。 阿里云的WAF网站防御实际上相当于没有缓存机制的百度云加速或360网站卫士,不过只能用cname接入方式,后续是否会结合万网解析,新增NS接入方式就不得而知了: 如上图所示,要开启WAF网站防御,就必须在域名解析那,将主机记录cname到云盾生成的CNAME地址。这时用户访问网站是这样一个情况: 用户浏览器 → 域名解析 →cname到云盾服务器 → 源服务器 当受到攻击时,流量会经过云盾节点,并触发清洗机制,起到CC/DDoS防护作用。 当然,也有部分朋友知道WAF使用方法,但可能是出于SEO考虑,这些朋友也只会在网站受到攻击的时候才会修改为CNAME解析,因为CNAME解析到阿里云WAF域名后,IP并不是固定的,这点和云加速之类的是一致的,不过遗憾的是WAF并没有搜索引擎自动回源机制,所以使用cname之后,IP的频繁变更会对SEO造成不良影响! 如下图所示,使用WAF之后,网站IP也就变成了云盾节点IP了: 那该如何解决这个问题呢?想必看过张戈博客上一篇文章的朋友已经了然于心了吧?没错!和备案不影响SEO的做法一样:将默认线路cname到阿里云WAF地址,然后再新增一条搜索引擎线路,指定到源服务器IP即可!这样就可以长期开启云盾WAF防御,而不影响SEO了! 本想,百度自家的云加速解析,对搜索引擎线路的判断应该是最靠谱的(对于做百度流量的网站来说),毕竟是自家的产品,有哪些蜘蛛IP,都一清二楚,不会搞错!但实际测试发现,百度云加速目前并不支持cname默认线路的同时,新增搜索引擎线路,会提示该记录已存在! Ps:尝鲜版的百度云加速倒是支持,地址是 http://next.su.baidu.com,感兴趣的可以自行测试下。 后来仔细一想,百度虽然对自己的蜘蛛了解透彻,但是对其他几家呢?比如搜狗,比如360?估计是个半吊子。处于完整性考虑,我推荐使用DNSPOD解析,原因无它,看图: DNSPOD和百度有过合作,所以有一个百度专属线路,额外的还有搜索引擎线路,想必比百度云加速收集的蜘蛛IP更加完善吧! 所以,正确的解析如下所示: 这样解析不但可以放心使用阿里云WAF防御,还可以隐藏你的网站真实IP,避免发生源站被攻击只能换IP的尴尬(通过hosts本地解析进行攻击,啥CDN防护都没了作用!) 二、防护设置 可能开启了云盾,也正确解析了域名,但是被CC攻击时,云盾还是毫无反应?!实际上还要设置下DDoS防护高级设置,因为云盾默认的DDoS防护阈值还是太高,如下所示: 清洗触发值: 每秒请求流量:180M 每秒报文数量:30000 每秒HTTP请求数:1000 我们这种搭建在阿里云的小博客,大部分带宽都只有1~2M,别人2M请求流量或100+并发就已经把你的网站打出了翔咯!所以很多朋友就算正确开启了WAF防御,被攻击的时候还是非常卡! 因此,我们必须根据自己网站的流量设置下阈值。 看了下,最低的请求流量是10Mbps,也就是10M带宽,所以一般ECS服务器根本不够看,因为水管太小了。。因此,我们需要设置另一个阈值:http并发请求。 对于我这种1M带宽的ECS,相信100并发已经卡出了翔。所以,我们考虑设置在50以下: Ps:当然做好了CDN动静分离的网站可以设置到100+,比如用了七牛CDN的朋友,总之得根据实际情况而定。 阈值只是触发的前提,下面还有一个触发之后的清洗限制,也就是发现并发超过阈值时,云盾对来访的单IP做连接数限制,超过了这个限制就返回503: 原则上,触发清洗阈值之后,单一IP连接数限制得越小越好,但是又不能将正常的访问阻挡在门外。所以这个限制该如何定义还得看实际情况!当然,你可以通过模拟攻击去测试出一个合理的限制值,但是也得考虑一些局域网公用一个公网IP上网的情况(得看网站的受众人群)。 看到这,相信不少用阿里云服务器的朋友已经有所收获吧?再我看来,使用阿里云WAF的作用主要有2个,一个是基础DDoS防护,另一就是隐藏网站真实IP。当你的网站经常被攻击,而云盾都无法完全清洗时,我们还可以在本文的基础上再套上一层百度云加速,平常不被攻击时,百度云加速设置回源,关闭加速即可,具体做法我就不多说了,看图即懂: 这种方案的网站访问模式如下: 用户浏览器 → 域名解析  →  百度云加速节点(缓存开启时) → 阿里云盾节点 → 源服务器 当然,这个方案只适用于百度云加速3.0尝鲜版,地址:http://next.su.baidu.com/ ,感兴趣的自己去研究下吧!就写这么多,洗洗睡。 最新补充:提了好几次工单,才弄清楚云盾中的DDoS和WAF是2个不同的功能,看来是我理解错了!最后纠正下,DDoS中的DD/CC防护和WAF设置并无关系,也就是你不设置WAF的CNAME也没关系,只要开启了DDoS防护就可以了!所以本文中的部分描述是不到位的,但是必须说明的是,参考本文开启WAF之后,确实可以实现隐藏真实IP的妙用!强烈建议使用!
阅读全文
网站建设

WordPress评论ajax动态加载,解决静态缓存下评论不更新问题

这是一个历史遗留问题,自从博客部署了PHP纯静态缓存之后,所有页面都是html静态内容了,而且在七牛CDN静态分离之后,速度更是达到极致! 不过也带来不少疑难问题,在之前写的《启用WP Super Cache纯代码版本之后的一些优化措施》一文中已经总结一些解决办法。其中为了解决用户无法看到最新回复的问题,我也想了多个办法,比如成功提交评论就会删除该页缓存、右下角集成清理缓存按钮等。在我多次改进之后,已经趋向于完美,而且这个php缓存优化也是张戈博客有偿服务最受欢迎的项目之一。 前不久,有朋友拿我的网站练手,用大量代理IP对我的博客进行DDos攻击,无奈之下博客临时转入到百度云加速。转入之后,如果把云加速的页面缓存也打开,那么就有了2层缓存:【CDN节点的html缓存】和【服务器的html缓存】。那么我之前写的ajax清理缓存以及评论删除缓存失去了效果,因为只能删除本地的html缓存,而CDN节点的缓存百度并未提供API控制接口,所以用户看到的还是缓存内容! 当然,不是强迫症的话,直接关闭百度的页面缓存就可以了!但这只是逃避问题,而没有解决问题!所以,本文就分享一下,强迫症是如何解决这个非必须问题的。 一、自动动态加载评论 这是我最初想到的、而且是老早就想实现一种方案:当静态的html页面加载时,评论部分实时从数据库动态拉取数据,由于是纯静态下的html页面,所以这个功能需要JS+Ajax来实现。 ①、php评论动态拉取接口代码 Ps:代码的原理就不赘述了,主要用到wp_list_comments内置函数,感兴趣的可以自行了解下。 以上代码保存为php文件,比如ajax-comments.php,保存到网站根目录,备用。 ②、Ajax评论请求代码 以上代码可以直接贴到网站的footer.php当中。如果你要添加到js文件中,请除去首尾的script标签,而且post_id值需要在外部通过php动态定义(搞不清的还是直接贴footer吧)! 特别说明下,2段代码中的【.commentlist】是指评论列表的class,比如知更鸟主题的评论列表的是<ol class="commentlist">评论列表</ol>,实际上请根据主题的评论列表class或ID来自行修改! 部署无误之后,每次页面加载都会动态去拉取一次最新的评论,并呈现给用户。 优点:每次打开页面用户都能看到最新评论; 缺点:每次打开页面都会动态拉取评论,降低了纯静态效果,拉取的评论分页有点误差(影响不大)。 二、手动动态刷新评论 这个方法灵感源自网络上流行的评论分页Ajax加载:点击评论的下一页,不会刷新整个页面,而是通过ajax拉取被点击那个分页的全部内容,然后找到评论部分并加载。 简单解释下原理: 比如,张戈博客的留言板,有100页评论,那么第99页的评论地址应该是:https://zhang.ge/liuyan/comment-page-99/,当点击【99】这个分页链接时,将触发ajax函数,先隐藏当前分页的所有评论,然后ajax拉取第99页的内容,然后将评论部分加载出来,实现不刷新页面来加载评论。 分析了这个过程,我们可以发现一个特征关键字,那就是分页地址后面的 comment-page-xx !这是个好东西,因为我可以在云加速和本地的缓存中排除这个关键词的缓存即可!也就说,浏览器直接访问带comment-page-xx这类关键词的地址,就略过缓存,加载动态内容! 因此,当我们部署了ajax评论分页,点击其他分页将会显示非缓存内容!但是这还不是我需要的,因为我想要当前页面也实现动态评论。也许聪明人会说,你点到其他评论分页,再点回来不就好了嘛? 确实,实现ajax评论分页后,我点到其他评论分页,然后再点回来,确实可以实现评论刷新,但是却用了2次点击! 好,下面我们换个角度,既然 comment-page-xx 是动态页面,那么comment-page-1肯定也是动态页面咯! 于是就有2种情况:第一种,文章评论数量还不够生成分页,那这时候只要拉取comment-page-1就可以了;第二种,评论已经存在分页,那么只要拉取这个comment-page-【页码】即可,所以ajax拉取之前,我们只要通过js判断来决定要拉取的目标地址即可。 那么,js如何判断评论是否有分页了呢?很简单,先分析下网页代码: 可以发现分页是有分页对应的class的,那么js只要判断这个class是否存在就好啦!而且我还可以发现当前的分页和其他分页的class还是不一样的:当前分页的class是【page-numbers current】,而 其他分页则是【page-numbers】,如以此来,我们还可以用js代码 $('.page-numbers.current').html() 获得当前分页的页码!!! 那问题就好解决了,我们只要先判断是否存在分页,然后根据不同情况抓取不同的目标地址即可! 下面开始分享代码: 使用方法很简单,把这个代码添加到主题已有的js中,然后在任意位置新增一个ID为refresh的html元素即可,比如: Ps:这个代码参考修改自:《WordPress Ajax 评论分页 | Kayo's Melody》,因此如果没看懂ajax评论分页,本文分享的也会看得稀里糊涂的,尤其是代码中的ID元素,不同主题是不一样的。 本文分享的方法和思路,如果不是真正需要,我想会看得很痛苦,因为我写的也很痛苦!很多地方不好解释,因为你没有需求,就可能看不懂!!但是,只要是我用心折腾过的功能,我都想分享出来,网络这个林子那么大,不可能就没有同样需求的人吧?!有时候,【解决思路】真心比【实现代码】来的更加难得! 这种看似很复杂的文章,实际上,光看文章是很费解的,个人建议结合自己的需求,然后对比张戈博客的页面源代码去参考,会更容易理解一些。 好了,废话说了够多了,还是那句话,文章是分享给真正有需要的人,没有需求,又说不出个甲乙丙丁的人,建议不要在本文浪费口水,说三道四比较好!
阅读全文
WEB应用

PHP彩蛋还是漏洞?expose_php彩蛋的触发和屏蔽方法

最近在折腾网站XSS漏洞修复的时候,当我把XSS漏洞和谐成功之后,360扫描送来了一个"彩蛋": 本以为又是360误报,结果点击看了下,还真能打开PHPinfo: PHP彩蛋我也是第一次听说,貌似老一辈的程序员们都知道,因为PHP是由黑客语言发展而来,所以各方面都透露着放荡不羁的极客精神! 一、如何触发PHP彩蛋? 我们只要在运行PHP的服务器上,在域名后面输入下面的字符参数,就能返回一些意想不到的信息。当然有些服务器是把菜单屏蔽了的。彩蛋只有这4个,PHP是开放源代码的,所以不必担心还有其他。 我2个网站目前都已屏蔽了PHP彩蛋,所以我们一起来看下腾讯的招聘网站: 原网站是这样的 点击跳转 加上“彩蛋之后”是这样: 1). PHP信息列表 点击跳转 2). PHP的LOGO 点击跳转 3). Zend LOGO 点击跳转 4). PHP LOGO 蓝色大象  点击跳转 二、如何看待PHP彩蛋? 如果你在自己的博客上也发现了这个问题,请不要惊慌,也莫要想着必须马上去解决他。其实这不算是漏洞。只是开源团队开的一个玩笑,全世界都认可的玩笑。没必要上纲上线,将它列为PHP的漏洞,连360都戏称为。 三、如何屏蔽PHP彩蛋? 方法①、我们可以通过apache或者nginx的伪静态规则去屏蔽,比如apache的服务器,我们可以在 .htaccess 里面加入以下2条规则即可拦截此类访问: 方法②、 直接编辑PHP的配置文件php.ini,找到expose_php,将值改为Off,然后重启或重载PHP服务即可: 我是懒得去想nginx规则该如何写了,直接修改php.ini来屏蔽的。屏蔽后,再去触发彩蛋发现已经无效了。再用360检测已经没有任何问题了: 如果你也发现你的网站有这个问题,也不必太在意。当然,强迫症还是去折腾修复下,免得坐立不安,哈哈!
阅读全文
网站建设

PHP跨站脚本攻击(XSS)漏洞修复思路(二)

上一篇文章《PHP跨站脚本攻击(XSS)漏洞修复方法(一)》写到了360修复XSS漏洞的插件并不完善的问题,那么这篇文章就来分享一下自己如何写代码修补这个漏洞。 从上一篇文章看出,部署了360出的XSS修复插件之后,至少还存在iframe无法过滤缺憾,是否还有其他纰漏目前还不得而知。 分析一下中国博客联盟和张戈博客已开放的数据入口: ①、中国博客联盟,主要有搜索、后台博客提交等; ②、张戈博客(WordPress),主要是用户评论提交; 所以,本文就已这2个入口为例子,来分享XSS漏洞修复的简单思路。 一、完全过滤 问题①,我可以找到站内搜索和博客提交这2个开放入口的数据处理php,然后对数据过滤即可。 比如站内搜索,中国博客联盟取得搜索关键词是这样一行代码: 考虑到中国博客联盟的站内搜索,只能搜索博客名称、域名、类型及描述这四种,而这四种均不需要出现html代码!如果有人提交搜索了html代码,绝非善意! 那对于这种情况,我只需要完全过滤掉html内容即可!所以可以用到strip_tags()函数,具体运用如下: 在数据外套上 strip_tags 进行html完全过滤即可!那么系统后台得到的数据就是不含任何html代码的。 比如,依然搜索360爆出的“88888<iframe src=http://xxooxxoo.js>”: 从搜索结果可以看出,系统已自动过滤了后面的iframe恶意内容,问题得到解决。 因此,对于XSS漏洞的第一种修复方法就是使用 strip_tags 函数来完全过滤html内容。 二、代码转义 问题②,WordPress的评论并不能如此暴力的过滤,因为很多用户确实是想提交一些html代码,来进行交流。 对于这种情况,有3种思路: ajax方式的评论都会用到主题下的comment-ajax.php文件,所以我们编辑这个文件,搜索$comment_type = '',然后在这行后面添加以下三种方法中,你所中意的代码: A. 直接过滤,允许提交 效果截图: B. 提出警告,禁止提交 效果截图: C. 内容转义,允许提交 效果截图: 其中过滤列表只写了iframe和script2种,如果你需要过滤其他你不喜欢的内容,比如某些人评论总是带上链接,这些都是可以过滤的!反正方法我已经分享了,具体就看你自行发挥了! Ps:其实WordPress本身已屏蔽了XSS漏洞,评论是不允许一些html代码的, 比如font字体标签等。本文也只是为了探讨修复XSS漏洞的一个简单思路,临时关闭了HTML过滤。为了安全起见,非特殊情况,还是不要禁止WordPress自带的HTML过滤为好! 最后,再去用360扫一扫,已经是“满意100”了: 好了,关于XSS漏洞的简单修复思路的探讨,就暂告一段落,后续有新的见解再来补充完善。
阅读全文
网站建设

PHP跨站脚本攻击(XSS)漏洞修复方法(一)

今天又做了一回奥特曼(out man),居然才发现360的综合搜索变成了好搜!前几天,其实看到过一次好搜,但是以为又是DNS劫持出现的流氓搜索。 今天细看了下,居然是360综合搜索改头换面后的独立品牌:好搜(怎么读都有点山寨)。 一、惊现漏洞 好了,暂且不研究这名称到底咋样,顺手site了一下我2个网站:张戈博客和中国博客联盟。 结果,site中国博客联盟的结果吓我一跳: 很久没理过360搜索了,一看还真吓一跳!急忙进去看了下,y原来是XSS跨站攻击漏洞!之前听无主题的博主小武提到过一次,当时是WordPress开启颜色评论后造成的XSS漏洞,因为我懒得折腾就放弃了带颜色评论的功能,避免出现XSS漏洞。没想到,中国博客联盟居然出现这么多! 二、现身说法 什么叫XSS跨站攻击漏洞?专业理论性的解释我也懒得说,自己去百度。我就举个实际的例子来说明这玩意的危害好了! 就拿之前WordPress留言来举例好了。 默认状态下,WordPress是不允许带颜色评论的,但是我们可以通过在functions.php里面插入这2行代码,强行允许评论开放所有HTML代码: 这样修改之后,WordPress确实可以留言带颜色了,比如<font color="red">红色</font>。 但是,XSS漏洞也随机而来!最简单的演示就是在博客如下带上代码留言: 留言生效后,页面一加载就会自动跳到百度首页了! 这只是XSS漏洞的一个最简单的攻击例子之一而已,上次中国博客联盟就被一个小人挂过一次黑链!看了上面的例子,你应该很猜出是怎么挂的了吧?他注册了中国博客联盟的会员,然后在提交博客时额外提交了一段js代码,后台审核时,这个js就会操作我的数据库,在首页加入对方的友链。 这种SQL注入就更加危险了!所以,如果你的网站有XSS漏洞,最好还是修复一下,避免被小人利用! 三、修复方案 好了,下面说一下简单修复方法。 先来看下360给出的修复方案: 方案一:避免XSS的方法之一主要是将用户所提供的内容输入输出进行过滤,许多语言都有提供对HTML的过滤: 可以利用下面这些函数对出现xss漏洞的参数进行过滤 PHP的htmlentities()或是htmlspecialchars()。 Python 的 cgi.escape()。 ASP 的 Server.HTMLEncode()。 ASP.NET 的 Server.HtmlEncode() 或功能更强的 Microsoft Anti-Cross Site Scripting Library Java 的 xssprotect(Open Source Library)。 Node.js 的 node-validator。 方案二:使用开源的漏洞修复插件。( 需要站长懂得编程并且能够修改服务器代码 ) 具体可以参考:http://webscan.360.cn/group/topic/tid/4571 之前小武就提到过,可以写代码过滤。能写代码当然好,但是自己写代码不但很麻烦,而且一个人能想到的正则过滤也可能会存在漏掉的风险,毕竟一个人考虑问题总是不会那么的全面和完善。既然360安全团队已经推出了修复插件,那不妨先试试。 我下载并部署了360写的PHP插件,感觉不错!而且WordPress颜色代码又可以安全的打开了,现在来分享一下,建议所有PHP网站都部署一下,有备无患! 四、部署方法 ①、下载插件 360提供的是专站专用的插件,插件代码会有和网站对应的KEY,所以下载前请修改下面的域名部分: 将上面下载地址中的yourdomain.com改为你的域名,然后浏览器访问即可下载专用插件: ②、上传插件 解压后,得到360safe文件夹,并上传至服务器根目录: ③、部署插件 按照360的部署教程,是要在网站的一个公用文件(如数据库的连接文件)中加入代码: 所以,WordPress网站可以选择添加到网站根目录下的index.php或数据库连接文件wp-config.php当中: 但是,玩WordPress的朋友都知道,这玩意更新频繁,每次版本更新,index.php这个文件十有八九是会替换的!所以最靠谱的方法是将以上代码添加到wp-config.php文件的第一个<?php 之后: 而且,任意建站程序都建议加到数据库连接文件当中,可谓一夫当关,万夫莫开! 五、最后验证 部署完插件了,咱们就来试试效果吧! ①、最简单的验证方法 直接在WordPress原生搜索带XSS特性的代码,比如搜索: 就会出现如下拦截页面: ②、带XSS攻击特征留言验证 依然和本文开头提到的那样,来测试留言: 结果显然可以猜到: 更令人欣慰的是,带颜色是可以评论的: 六、发现缺憾 本以为能全部修复了,结果再次扫描了下中国博客联盟,360自己打脸的现象出现了: 点进去看了下,发现已不是原来的攻击特征了: 特意试了下WordPress的评论是否会拦截,结果依然失望:   看来360写的正则过滤也不全面啊!最终还得靠自己! 七、下篇预告 在测试360的XSS防护插件存在缺憾之后,只能感叹360也就这样,真是失望哟! 于是,我决定自己写代码解决。几经折腾测试,最终搞定了这个问题! 先来2张效果预览: 鉴于本文篇幅已经过长,所以打算另开一篇文章,来分享一下最终XSS修复方法! 对XSS漏洞修复感兴趣的童鞋,敬请期待!
阅读全文