当前位置: 首页>>技术解读>>正文

什么是WordPress插件和主题的安全最佳实践？

webfans 技术解读 , , , 去评论

问题描述

As suggested in this question，我正在添加这个主题作为一个新问题，关于best-practices插件/主题安全的社区讨论/投票。

这是基于我当前(work-in-progress)设置/数据安全检查表的起始检查表，用于审查主题(插件的原则应该与主题不同)。

如果您想查看带有安全和solidly-coded主题设置页面的主题，请查看以下主题：http://wordpress.org/extend/themes/coraline

最佳解决方法

使用Nonce(不使用Settings API时)

如果不使用Settings API，插件和主题应明确提供Settings-page nonce检查：

次佳解决方法

清理，验证和转义数据

清理任何可以进出(！)数据库的前端和后端的东西！

插件和主题应该执行正确的数据验证：

  1. 在将数据输入数据库之前，验证并清理所有不受信任的数据

  2. 在“设置”表单字段中输出之前，请转义所有不受信任的数据

  3. 在主题模板文件中输出之前，转义所有不受信任的数据

插件和主题应使用esc_attr()进行文本输入，将esc_html()或esc_textarea()用于文本区域。

WordPress API也提供esc_url()，esc_url_raw()，esc_js()和wp_filter_kses()。

不好的例子：

<?php $url = 'javascript:pwnd()'; ?>
<a href="<?php echo $url; ?>">anchor</a>

好例子：

<a href="<?php echo esc_url($url); ?>">anchor</a>

这是Mark Jaquith的精彩视频，解释了逃逸功能的用法：

第三种解决方法

只有在更好的API不可用时才仔细使用$ _GET /$ _POST /$ _REQUEST

插件和主题应使用Settings API来获取和保存表单输入数据，而不是直接依赖$_POST和$_REQUEST数据。

第四种方法

使用$wpdb->prepare

通过$wpdb对象构建自定义查询时，始终使用$wpdb->prepare来为占位符填充值，而不是使用与SQL代码混合的数据编写查询，因为mysql_*系列函数错误地教会了每个人。

第五种方法

请注意可能用于运行恶意代码的PHP函数

对于任何编写PHP的人来说都很好读：StackOverflow上的Exploitable PHP functions。

使用Theme Modification API

主题应该使用set_theme_mod()和相关功能而不是自己发明的名称方案。 theme_mod API是设置API的专用层;它保证了唯一的名称，将所有选项推送到一个数组中 – 从我的经验来看 – 更容易处理。此外，它还为插件提供标准化过滤器 – 这有利于互操作性。

避免启用register_globals

不要依赖register_globals = on。我上一个客户购买的专业主题正是这样做的。我可以在5分钟内使用这个主题破解任何网站…… ThimbThumb也这样做了(现在仍然这样做了)。

不要创建具有不必要的宽访问权限的文件

不要创建具有过于自由的访问权限的文件。

在可用的地方使用SSL

将您的分享指向Twitter /Facebook /任何指向HTTPS URI的链接(如果有)。读者的安全也很重要。

第六种方法

将数据保存在单个数组中

插件和主题应该将选项保存在单个阵列中，而不是为设置页面创建多个选项。使用Settings API可以解决这个问题。

第七种方法

添加和输出设置页面时检查适当的功能

插件应使用适当的功能(例如manage_options)来添加设置页面。

主题应使用edit_theme_options作为添加设置页面的适当功能。

第八种方法

使用up-to-date教程和信息

插件&主题应该故意实现选项和设置页面，而不是依赖过时的copy-and-paste网站教程，不包括正确的数据安全性，如下面列出的那些。

什么不该做的例子：

第九种方法

使用设置API

插件和主题应该使用Settings API，它更易于使用，更安全，并且可以处理设置页面的大量繁重工作：

有关使用Settings API的好教程，请参阅：

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/2710.html，转载请务必附带本地址声明。