怎么把网站去除安全风险

1、后台备份数据，备份成功后打包整个网站数据，下载到本地电脑。切记！

2、安装全新的dedecms系统，安装完成后，登录后台。

3、上传备份数据文件夹/data/backupdata，覆盖到相应的目录。

4、后台-恢复还原数据。到了这里，只是把数据恢复了。

5、上传模板templets、附件资源uploads文件夹，覆盖相应的目录。记得先检查这些文件夹里，有没有非dedecms原程序文件，比如0day木马文件等。

6、做安全设置，限制目录权限

7、删除没用的文件：

装程序后一定要删除install目录;

修改dedecms默认后台目录dede

这是肯定的，本身DedeCMS 织梦内容管理系统软件的被广泛应用普及跟广大用户的思维里面这个系统不收费有关，很多用户是冲着织梦的简单易上手、常见的问题可百度到解决方法、感觉它是免费的心理有关。

其一、9月26号织梦官方突然决定收费，并从2021年10月25号开始维权。对于一个已经在市面上出现10年之久积累了大批量用户的一个内容管理系统软件突然决定强制收费来讲，这个决定无疑让广大的站长和网站管理者感到突然。

其二、织梦官方对本次DedeCMS商业使用授权费高达5800元，这个费用对于中小用户或者业务DedeCMS 使用者是不太好接纳的，因为其他CMS 内容管理系统单个域名的授权费用大多为100-400元不等，5800元的单域名授权费用显然是相对较高的。同样作为一个软件和网站应用服务提供商我深知作为技术服务提供者需要支付人员办公等日常开支，应该需要用户支付一定的报酬，但是建议这个报酬应该在行业适中水平或者用户接受的范围内，这样显然能减少用户流失和怨声载道之声。

其三、很多织梦用户应该都遇到过网站被恶意挂马或者中毒的情况，虽然最终都得以解决，但是对于网站安全这一重中之重的问题站长们一定特别在意，因为有时数据本身比网站授权费更重要，之前可能大家还能接受，但是如果既需要缴纳相对高昂的授权费，还要随时准备着处理网站安全问题，很多站长可能就选在放弃织梦而投身其他CMS 管理系统了。

其四、现在已经不同于10几年之前，DedeCMS 作为老牌内容管理系统如今已经面临着很多CMS 管理系统的竞争，而且很多CMS 已经拥有了很多的应用开发者生态圈也获得了很好的口碑，这些CMS 或者免费或者相对仅需几百块的商业使用授权费。这样的局面显然对织梦的本次声讨版权付费造成用户流失到其他CMS 管理系统。

其五、很多有技术实力的网络公司或者技术从业者完全可以在完全保留网站数据的情况下，将网站的DedeCMS 织梦内容管理系统更换为其他的 CMS管理系统，这对于网站的使用和SEO排名营销推广完全也没啥影响。当然更有甚至对于网站数据不太注重的用户可以直接应用插件将网站的DedeCMS 织梦内容管理系统刚换掉。

以上是作为一个网站技术服务商对于DedeCMS 织梦内容管理系统开始商业授权问题的看法，欢迎广大的技术爱好者和服务商深入探讨，也欢迎有DedeCMS 织梦内容管理系统相关问题的用户和我们交流。

　　如何消除网站安全的七大风险

　　改善之前

　　第三方专业安全测试公司进行测试，其中的重点问题列表如下：

　　问题1：易受到SQL注入攻击

　　风险：攻击者可以通过应用程序发送数据库命令，这些命令将被服务器执行。这可以用来对数据库进行完全控制。这些SQL注入漏洞可以通过在其中一个区域插入“and 7 = 7 -”或“and 8 = 9 -”，并比较结果进行判断。

　　分析：SQL注入攻击是由于服务器对参数检查不够，而导致攻击者借此获得敏感信息。因此，需要使用参数化查询以确保攻击者无法操作数据库的SQL查询语句。例如，如果应用程序要求输入名称，那它应该只接受字母字符、空格和撇号，而不接受任何其他字符。也就是说，在应用程序中的所有输入域实施服务器端白名单技术。特别是所有用于SQL语句的输入域，需要空格的都应该用引号括起来。

　　改善：在程序中所有可接受外部参数的地方进行逐一识别，以过滤危险字符。如在全局函数中定义“禁止字符串列表”，该表中列出所要过滤出的SQL攻击代码可能包含的字符串。

　　and |exec |insert |select |delete |update |count |  |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|}

　　//当然可以根据网站的特点完善和修改本列表

　　接下来做如下处理：

　　问题2：易受到跨站点脚本攻击

　　风险：此漏洞可以被用来获取身份验证Cookie，攻击管理员账户，或使应用程序的用户攻击其他服务器和系统。该漏洞可以通过在某区域中插入“<script>alert(‘23389950’);</script>”来判断。

　　分析：这也需要在本网站的所有输入域实施服务器端白名单技术。如果需要特殊字符，应该转换为更安全的形式。如适用于各种语言的HTML转码：

　　&应转换为 &；

　　“应转换为”；

　　‘应转换为&39；

　　>应转换为>；

　　<应转换为<。

　　改善：除了这些标准的HTML转码之外，对于可疑字符串也要进行强化检查和转化，并进一步执行以下操作：（1）对各页面的输入参数进行强化检查；（2）对原来只在客户端判断的参数，在服务器端进一步强化检查;（3）最终提供了全局的转码和过滤的函数。当然这需要在性能和扩展性以及安全性方面的平衡综合考虑。

　　问题3：非安全的CrossDomainXML文件

　　风险：为解决Flash/Flex系统中的跨域问题，提出了crossdomainxml跨域策略文件。虽然可以解决跨域问题，但是也带来了恶意攻击的风险，如果该策略文件里允许访问任何域，就可能允许发起对网络服务器的跨站点请求伪造和跨站点脚本攻击。比如，不安全Flash应用程序可能会访问本地数据和用户保存的网页记录，甚至传播病毒和恶意代码。

　　分析：考虑如何确保只对提供安全资源的可信域开放允许。

　　改善：经过调查，发现在程序目录下的crossdomainxml文件里的配置如下：

　　<xml version=”10″>

　　<!DOCTYPE cross-domain-policy SYSTEM ”http://wwwmacromediacom/xml/dtds/cross-domain-policydtd”>

　　<cross-domain-policy>

　　<allow-access-from domain=”” />

　　</cross-domain-policy>

　　文件中的allow-access-from 实体设置为星号设置为允许任何域访问，将其修改为 <allow-access-from domain=”examplecom” />，表示只允许本域访问，该问题就解决了。

　　问题4：Flash参数AllowScript-Access 已设置为always

　　风险：当AllowScriptAccess为always时，表明嵌入的第三方Flash文件可以执行代码。攻击者此时就可以利用该缺陷嵌入任意第三方Flash文件而执行恶意

代码。

　　分析：AllowScriptAccess参数可以是“always”、”sameDomain”或“never”。三个可选值中，“always” 表示Flash文件可以与其嵌入到的 HTML 页进行通信，即使该Flash文件来自不同于HTML页的域也可以。当参数为“sameDomain”时，仅当Flash文件与其嵌入到的HTML页来自相同的域时，该Flash文件才能与该HTML页进行通信，此值是AllowScriptAccess 的默认值。而当AllowScriptAccess为 “never”时，Flash文件将无法与任何HTML页进行通信。

　　因此需要将AllowScriptAccess参数设置为“sameDomain”，可以防止一个域中的Flash文件访问另一个域的 HTML 页内的脚本。

　　改善

　　<param

　　name=”allowScriptAccess” value=”always” />

　　改为

　　<param

　　name=”allowScriptAccess” value=“sameDomain” />

　　问题5：网站后台管理通过不安全链接实施

　　风险：管理访问没有强制实施SSL，这可能允许攻击者监视并修改用户和服务器之间的发送的包括账户凭据在内的所有数据。如果攻击者通过代理或者路由软件拦截服务器和管理员间的通信，敏感数据可能被截获，进而管理员账户可能会受到危害。

　　分析：管理访问没有强制实施SSL，为防止数据拦截，管理访问应该强制执行HTTPS (SSL30)。

　　改善：运维对服务器进行了配置调整，单独配置支持了SSL30访问管理后台。

　　问题6：验证环节可以被绕过

　　风险：用户发布信息时，虽然有页面的验证码防止自动恶意发布，但仍可能被绕过进行自动提交。绕过的方式之一是使用过滤和识别软件，之二是可以利用Cookie或Session信息绕过验证码。

　　分析：图像失真机制本身不是特别强，可以很容易地使用公开的过滤和识别软件来识别。生成的也是可以预测的，因为使用的字符集很简单（只是数字），建议实现一个更强大的验证码系统。

　　Cookie或session信息处理有漏洞导致验证码被绕过, 确保每一个链接只能取得唯一的验证码，并确保每个请求产生并需要一个新的验证码。

　　改善：根据需要增加验证码的复杂度，而不只是单数字。

　　经过分析发现是因为验证码被存入了Session里，而开发人员忘记在提交之后清空Session中的验证码的值，导致验证码在过期时间内一直可用，从而可能被利用多次提交。因此在提交后追加了及时清空验证码的操作。

　　问题7：泄露敏感信息

　　风险：此信息只能用于协助利用其他漏洞，并不能直接用来破坏应用程序。网站的robotstxt文件里可以获得敏感目录的信息，这可能允许攻击者获得有关应用程序内部的其他信息，这些信息可能被用来攻击其他漏洞。

　　分析：robotstxt不应在提供管理界面的信息。如果robotstxt文件暴露了Web站点结构，则需要将敏感内容移至隔离位置，以避免搜索引擎机器人搜索到此内容。

　　改善：当然robotstxt要根据SEO的要求来处理，但也要同样注意安全性。如：disallow:/testadmin/，其中testadmin为管理后台，就被暴露了。可以根据实际情况是否必要决定删除robotstxt文件或者把敏感目录单独配置禁止搜索引擎搜索。

　　其他问题汇总

　　除此以外，还有很多其他危害性相对较低的问题，分析如下。

　　问题：可能通过登录页面枚举出用户名，因为根据账户是否存在的错误信息是不同的。

　　对策：修改错误信息使之不带有提示性，如“您输入的邮箱或密码不对!” 并且超过一定次数则对该IP进行锁定。

　　问题：检测到可能泄露敏感信息或被恶意利用的冗余文件，如测试文件、bak文件、临时文件。

　　对策：除去服务器中的相应文件。

　　问题：发现潜在机密信息，如名为order的文件很容易被联想到用户订单。

　　对策：避免在文件名中含有完整的敏感词汇或不要在容易猜测到的文件中保存敏感信息，或者限制对它们的访问。

　　问题：发现内部信息泄露。

　　对策：除去代码中漏删的内部IP地址，内部组织，人员相关信息等。

　　共性原因分析

　　在发现的问题中，71%是与应用程序相关的安全性问题。可以修改应用程序相关的安全性问题，因为它们是由应用程序代码中的缺陷造成的。29%是基础结构和平台安全性问题，可以由系统或网络管理员来修订“基础结构和平台安全性问题”，因为这些安全性问题是由第三方产品中的错误配置或缺陷造成的。

　　综合主要的原因包括但不限于以下三个方面。

　　程序方面

　　未对用户输入正确执行危险字符清理；

　　Cookie和Session使用时安全性考虑不足；

　　HTML注释中或Hidden form包含敏感信息；

　　提供给用户的错误信息包含敏感信息；

　　程序员在 Web 页面上的调试信息等没有及时删除。

　　Web 应用程序编程或配置不安全；

　　配置方面

　　在Web目录中留下的冗余文件没有及时清理；

　　Web服务器或应用程序服务器是以不安全的方式配置的。

　　安全规范文档不够完善，开发人员的培训不足；

　　开发人员的安全相关经验和安全意识不足。

　　对于这些问题的解决方法-——技术之外

　　对于安全问题本身的解决可能只能case by case ，但为了预防更多潜在问题的引入，技术之外方面的改善也不容忽视：

　　1 对于开发人员在项目初期即进行安全开发的培训，强化安全意识。

　　2 建立用于共享安全经验的平台，将经验形成Checklist作为安全指南文档。

　　3 将成熟的代码成果提炼出公共安全模块以备后用。

　　本次改善之后总结出一些常用基本安全原则供大家参考，见“非官方不完整网站开发安全原则”。

　　作者简介：晁晓娟，目前在互联网公司负责项目管理。InfoQ中文站SOA社区编辑，有多年的Web开发管理经验，关注项目管理、架构和产品。

　　(本文来自《程序员》杂志13年02期)

不知道你的问题是不是已经得到了解决。我觉得我来回答很有发言权。因为我前段时间也出现了这样的现象。

你看看你的主页的源代码是不是如下这样的，网站标题、关键词、描述都发生了变化，多了如图所示的代码在网站里面。这个就是病毒代码，但是删除之后，过段时间有出现了这样的情况。那是因为删除只是一时的，并没有解决网站漏洞的根本原因。

其实出现这种现象是网站被“跨站脚本攻击（XSS）”了。具体的跨站脚本攻击（XSS）的意思你百度就知道了，有这个漏洞的百科词条。我用的也是dedecms网站，那么具体解决方法就是防范跨站脚本攻击（XSS）漏洞。只有修复了漏洞，才会不再生成这样的病毒sj代码出来。

1、跨站脚本攻击（XSS）的防范方法，X-Frame-Options头设置，具体方法篇幅比较大，参考百度经验《X-Frame-Options头未设置,如何设置？》

2、跨站脚本攻击（XSS）的防范方法，Cookie没有HttpOnly标志，需要设置HttpOnly，参考百度经验《Cookie没有HttpOnly标志咋办？IIS设置HttpOnly》

3、跨站脚本攻击（XSS）的防范方法，dedecms版本升级，dedecms是免费的开源网站，用的用户多，存在的漏洞也多，要不断的打补丁，升级版本。

把以上三点都做好了，你的网站就不会出现跳转到别人网站去的现象了，因为防范了“跨站脚本攻击（XSS）”，别人就不会攻击你的网站，在你网站里面加病毒代码了。我是一个热爱分享的网站站长，可以关注我，跟我一起进步。

能。

网站被百度惩罚应从哪些方面分析，对于国内站长圈的朋友来说，辛辛苦苦运营的网站被百度惩罚似乎在这几年已经是司空见惯了，所以很多时候网站流量、排名或者是收录有小幅度波动时，站长都会认为网站又被惩罚了。其实，很多情况都只是站长自己太过于敏感了而已，下面给大家介绍一下网站被百度惩罚的分析思路，让你在面对惩罚时不显得方法不足。

我们将网站被百度惩罚分为4个方面来说：1不一定为惩罚;2确为惩罚;3被惩罚原因和解决方法;4惩罚后的心态，下面逐一来说一下。

不一定为惩罚

只要自然搜索流量、自然排名亦或是搜索引擎收录量变动不是很大，就不是被百度惩罚。不一定为惩罚主要有以下几个方面问题：

Asite首页不在第一位;

Bdomain首页不在第一位;

Csite结果数和索引量大幅度增减(只要带来流量的有效收录页面数量不变，其他变动都不必太过担心，可能是搜索引擎算法变动或抽风，注意观察一下其他网站即可);

D网站批量改动title、description、keyword、网页模板等引起网站搜索排名和流量小幅度变动(一些和排名有关的重要因素有变动，肯定会影响到搜索结果排名的);

E部分关键词排名下降，但网站整体搜索流量无大变动(搜索引擎rank算法不断在调整，所有网站数据也都在变化，网站关键词有升有降，只要幅度不是很大都是正常);

F首页快照停滞不动或更新缓慢(这方面一般和惩罚无直接关系，检查页面更新幅度和质量是否正常或太弱);

G首页快照倒退(参考百度官方对百度快照的介绍，或为根据查询条件显示不同版本快照，或为百度抽风);

H老内容收录排名正常，新内容只抓不收录(分析抓取日志是否正常，检查网站结构嗯哼程序是否出现bug，核对spider是否能够正常提取熬内容);

I无任何异常操作，搜索流量有一定幅度的变动(小幅度变动都是正常现象，并不是流量跌一点就是惩罚，升一点就是提权，SEOER不必过度给自己贴金，也不必盲目自责);

确为惩罚

网站确为百度惩罚的表现主要有以下几个方面：

A网站收录在，快照正常，但排名全无(一般会出现搜索流量或减半或接近全无的现象);

B页面被收录，但搜索包含特征关键词(如品牌词)的全title，无排名;

C被拔毛至只剩首页：i老站点确为惩罚;ii新站内容时收时删，可能为考核期，提升内容质量，持续正常运营即可;

D首页时而无快照：i确为惩罚;ii搜索引擎抽风;

E全站无快照：i老站点确为惩罚;ii新站内容时收时删，可能为考核期，提升内容质量，持续正常运营即可;

确为惩罚的原因及解决方法

当网站确为搜索引擎惩罚，一定要及时分析近期操作和综合数据，以前没事不代表现在没事，也有很多是因为作弊数据积累到一定量而被处理，及时分析原因并找到解决方法是最重要的。

A首先要仔细检查和静心思考，自己网站是不是主动或被动做了一些伤害用户体验的事情;

B在不确定真正原因之前，不要轻举妄动，可以先和大家交流一下，并持续观察一段时间，看是否会自动恢复;

C百度站长平台、Google webmaster完善****，及时获得网站异常提醒信息;

D站内问题：

i可以堆砌关键词过多而造成大量页面质量很低(不要过度关系“关键词密度”，关键词自然地出现就好，不要很突兀地硬性添加关键词);

ii页面中推荐无关联链接过多，页面信噪比过低而造成大量页面质量过低(推荐链接要相关和适量，尽量不要让附属体检的链接内容占比太大，站在普通用户角度审视页面质量和链接意义);

iii有TAG词作弊做了一些其他品牌官网之类的词(百度大力大家对象，无相关内容，不符合网站主题的词坚决不要;无能力把控页面质量坚决不做，不要因小失大);

iv泛域名解析作弊(百度大力打击对象，每个子域名只有一个单页面，页面内容质量不高，建议每个子域名下最好都配有一些有价值的页面);

v大量采集内容，大量低质量伪原创内容(该清理的都清理掉，没有欺骗搜索引擎的能力就不要浪费这个感情了);

vi含有大量指向作弊网站的链接(对导出链接严格把控，避免被人钻空子，友链要记得定期检查);

vii含有大量垃圾内容;

viii网站被黑客利用，包括：被挂黑链、被插入页面或被利用进行泛解析作弊、被动使用判断UA返回不同内容的功能、被恶意改动代码，在页面中插入大量垃圾内容(如菠菜、赌博、色情居多)、被挂马;

ixrobots或meta使用错误;

E站外问题：

i积累垃圾外链过多(主动、被动)，建议使用百度站长平台、Google webmaster拒绝链接工具;

ii大量购买垃圾链接，不要犯这种低级错误，使用拒绝链接工具;

iii垃圾站群嫌疑;

F实在找不到原因，就在平台进行投诉(选择网页搜索产品，非百度站长平台)，也许是被误伤了，被误伤的站可以尝试去买**了;

G如果作弊太过于严重，要懂得和舍得放弃;

被惩罚后的心态

A作弊要承担任何后果的心里准备;

B为什么以前没事，现在就不行了(搜索引擎也会有严打，很多作弊数据会随着时间推移而累计，超过搜索引擎的忍受度就要被处理了);

C为什么别人也这样做，但没有被处理呢这主要是因为很多细节上并不同，且反作弊算法为避免误伤，初期策略相对保守，后期会逐渐完善;

D为什么我向百度投诉了作弊站，百度却一直不处理呢(除非是严重影响搜索引擎结果质量的站，否则搜索引擎不可能对单个站进行处理的)

开学了，返校了，又在宿舍上网了，但现在的校园网安全吗暑假中，DeDeCMS系统曝出了严重的漏洞，这个系统在很多学校的校园网中存在，黑客利用该漏洞就可以控制校园网，进行挂马、嵌入病毒……不过校园网中不乏电脑高手，下面我们就来看看“红帽”同学对自己学校网站的开学安全检测。

我的网名叫“红帽”，我猜每一个大学校园里，都有像我这样的一号人，我们对电脑充分的了解，面对互联网海洋时，就如同游泳池中的菲尔普斯一样。无论你需要找到什么东西，只要它存在于互联网之中，或者在互联网中生活过一段时间，我都能够帮助你找到源头，或者帮你把你感兴趣的东西弄到手。你猜对了，我就是黑客，活跃在校园里面的黑客。

我自认为算是高手，帮同学从别的黑客手里**回被窃的账号，在网吧让一个讨厌鬼不停的更换电脑，也曾经尝试着入侵NASA的计算机网络。

这段日子正是开学的日子，我准备对我的学校网站进行了一次安全检测。或许你要问，为什么要对自己学校的网站进行安全检测我们学校用了DeDeCMS系统(中文名称是织梦内容管理系统)，这个系统在很多学校中被使用。

博弈主题：攻击DeDeCMS整站系统

技术难度：★★★★

重点知识：如何用新的DeDeCMS漏洞来入侵

DeDeCMS系统被很多学校使用并不能让我产生检测自己学校的网站的念头，真正让我产生这个念头的原因是这个系统最近曝出了严重的漏洞，不知道网管补上该漏洞没有，如果没有补上，大家回校后上校园网就危险了。

DeDeCMS身藏URL编码漏洞

这次DeDeCMS新出的漏洞是一个URL编解码漏洞，导致漏洞出现的原因是DeDeCMS的设计者在joblistphp、guestbook_adminphp等文件中对orderby参数未做过滤。黑客可以利用这些漏洞查询数据库的敏感信息，例如管理员密码、加密key等，一旦这些敏感资料被黑客掌握，要在校园网内挂马就是轻而易举的事情了，真危险。

小知识：编码是将源对象内容按照一种标准转换为一种标准格式内容。解码是和编码对应的，它使用和编码相同的标准将编码内容还原为最初的对象内容。编解码的目的最初是为了加密信息，经过加密的内容不知道编码标准的人很难识别。

实战入侵

既然知道了漏洞的成因，下面就来亲手检测一下。目前有两种方案可以实现DeDeCMS整站系统的入侵，一种是PHP脚本的入侵方案，采用这种方案，需要先在自己的本机调试好PHP解析环境，然后登录入侵的目标网站，在PHP环境中运行漏洞测试代码。不过这种方案实行起来相对复杂，因此我使用第二种进行检测，通过漏洞检测注入程序直接注入。

首先，登录学校的网站。然后打开《DeDeCMS漏洞注入检测程序》，点击“Target

Infomation”标签选项，在“URL”一项后面将寻找到的有DeDeCMS系统漏洞的网址复制粘贴到地址输入框，这里利用DeDeCMS的网站路径地址“/include/htmledit/indexphp”得到网站的物理路径。

在登录系统之后，复制浏览器地址栏中的网站路径，例如[url=http://wwwhackercom/dedecms5/include/htmledit/indexphpmodetype=basic&height[]=chinaren]http://wwwhackercom/dedecms5/include/htmledit/indexphpmodetype=basic&height[]=chinaren[/url]，然后复制粘贴提交测试，粘贴完成后点击“Check”按钮，测试网站是否符合条件