WordPress插件和主题的最佳安全性最佳做法是什么?[关闭]


22

正如该问题中所建议的那样,我将该主题添加为一个新问题,以供社区讨论/投票有关插件/主题安全的最佳实践。

这是一个初始检查表,基于我当前用于审阅主题的(正在进行的)设置/数据安全检查表(插件的原理应与主题相同)。

如果要使用安全且经过严格编码的主题设置页面检出主题,请检出此主题:http :
//wordpress.org/extend/themes/coraline


如果拥有适当特权的人不介意将其设置为社区Wiki?
Chip Bennett

要在Wiki模式下获取问题,国防部需要适当地标记问题,我已将其标记为国防部注意,这只是时间问题。.:)
t31os 2011年

珊瑚素有何特别之处?Imo仍然有进入的方法。我建议将anons A插入一个链接:wordpress.stackexchange.com/questions/13539/…–
kaiser

Coraline可能没有什么特别之处。它只是我们当前在审查主题时将主题开发人员指向的那个对象,因为这是Justin Tadlock给出的示例,他做了许多初始的特定于安全性的主题审查。我也提供Oenology作为一个很好的例子,但是我不想尝试拉皮条自己的主题。:)
Chip Bennett

Answers:



12

消毒,验证和转义数据

清理可能会从前端和后端进出数据库的所有内容!

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

  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的精彩视频,解释了转义功能的用法:


3
进场时进行

9

仅在没有更好的API时小心使用$ _GET / $ _POST / $ _REQUEST

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


3
始终将$ _POST,$ _ REQUEST和$ _GET视为不安全。对这些数组中的值进行清理和白名单,然后将它们放入您自己的变量中。切勿清理来自用户的值并将其放回$ _POST。
goldenapples

2
始终检查是否在适当的数组中设置了需要使用的密钥。isset()是您的朋友:)
mfields 2011年

9

使用 $wpdb->prepare

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


$wpdb->prepare一样的预处理语句。
hakre 2011年

8

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

对于任何编写PHP的人来说都是不错的读物:StackOverflow上的可利用PHP函数

使用主题修改API

主题应使用set_theme_mod()及其相关功能,而不是自行发明的名称方案。
theme_mod API是设置API的专用层;它可以保证唯一的名称,将所有选项组合成一个数组,并且-根据我的经验-更容易处理。此外,它还为插件提供了标准化的过滤器,这对互操作性很有帮助。

避免启用 register_globals

不要依靠register_globals = on。一个专业主题这我上次买的客户不正是这一点。我可以在5分钟之内破解使用该主题的任何网站……
ThimbThumb也是这样做的(现在还可以吗?)。

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

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

在可用的地方使用SSL

将您在Twitter / Facebook / Anything上共享指向HTTPS URI(如果可用)。读者的安全也很重要。


2
您能否详细说明一下set_theme_mod(),特别是如何将其与Settings API的用法结合使用?
Chip Bennett

@Chip Bennett我已经在回答中添加了一些信息。
fuxia

您能否以更小的更具体的答案细分此迷你列表?较小规模的社区Wiki更易于管理。TIA
Rarst,2011年

3
芯片:Theme mod系统与Settings API集成得不太好。我将写一篇文章解释如何在不久的将来做到这一点。
奥托

7

将数据保存在单个阵列中

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


6

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

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

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


1
小但重要的注意事项:edit_theme_options虽然您不能与设置API一起使用,但选项提交是硬编码的manage_options,以便提交更新。相关Trac票可在此处找到。
t31os 2011年

是的,但是1)仅会影响编辑者,而不会影响管理员;2)希望可以通过链接的Trac票证尽快解决。
Chip Bennett

总是有可能给自定义角色或常规角色设置edit_theme_options上限,我认为指出这一点的方便之处在于,处于当前状态的设置API仅可用于具有该manage_options功能的角色。
t31os 2011年

5

使用最新的教程和信息

插件和主题应该有意实现“选项”和“设置”页面,而不应依赖已过时且不包括适当数据安全性的复制粘贴网站教程,例如下面列出的那些。

不做什么的例子:


1
我在其中添加了一些强调的文字以指示链接是不做的示例,因为很容易浏览信息并单击链接而无需阅读前面的段落。当我在那里的时候,答案也变得更漂亮了;;)
t31os 2011年

2
这可以使用一些解释来说明示例教程在使用错误和/或旧方法时的确切作用。
罗斯特(Rarst)2011年

4

使用设置API

插件和主题应该使用设置API,该API更易于使用,更安全,并且可以处理设置页面的许多繁琐工作:

有关使用Settings API的良好教程,请参见:


关于设置API和主题选项,请参阅我对此答案的评论。
t31os 2011年

1

对于复选框和选择选项,插件和主题应该分别使用checked()selected()函数来输出checked="checked"selected="selected"


除非我缺少某些东西,否则这并不是真正的安全性。仍然非常方便且使用方便。:)
Rarst 2011年

好吧,也许也许不是。我已经看到了很多用于完成同一件事的自定义代码。更多的代码细面条=带来更多引入安全风险的机会。:)
Chip Bennett

Bennet-从几天前寄给toscho的邮件中-我想我可以为我们两个人说-最简单的功能比这些功能更容易阅读和理解。我没有失望,但也没有对此表示赞同。恕我直言,这不应该成为核心,因为它不会增加任何价值。
kaiser

2
我很好奇,你们想出了什么比checked( $theme_options['whatever_option'] )或容易checked( 'some_value' == $theme_options['whatever_option'] )。我不知道它比这更简洁吗?
Chip Bennett

1

前缀函数和变量名

插件应在所有选项,自定义函数,自定义变量和自定义常量之前加上plugin-slug。

主题应在所有选项,自定义函数,自定义变量和自定义常量之前加上theme-slug。


我将其扩展到所有类名称以及自定义对象(如post_types和分类法)的名称。
mfields 2011年


0

将设置页面添加到管理菜单的适当部分

插件应该使用该add_options_page()功能将“插件设置页面”添加到Settings菜单中,而不是add_menu_page()用于添加顶级菜单。

主题应使用该add_theme_page()功能将“主题设置”页面添加到Appearance菜单,而不是add_menu_page()用于添加顶级菜单。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.