Skip to content

[翻译]防御性编程的艺术

原文The Art of Defensive Programming
(译文发布在伯乐在线,感谢刘唱校稿)

为什么开发者不编写安全的代码?我们在这并不是要再一次讨论「整洁代码」。我们要从纯粹的实用观点出发,讨论其他东西——软件的安全性和保密性。是的,因为一个不安全的软件是无用的。我们来看看什么是不安全的软件。

  • 欧洲航天局的 Ariane 5 Flight 501 在起飞后 40 秒毁坏(1996年6月4日)。价值 10 亿美金的原型火箭因为搭载的导航软件里的一个 bug 而自毁。

  • 20 世纪 80 年代,在 Therac-25 radiation 医疗机器的控制代码里的一个 bug 使得 X光强度过大,直接导致至少 5 名病人死亡。

  • MIM-104 Patriot(爱国者)里的一个软件错误使它的系统每一百小时有三分之一秒的时钟偏移——导致定位拦截入侵导弹失败。伊拉克导弹飞入在达兰(沙特阿拉伯东北部城市)的一个军营(1991年2月25日),杀害了28名美国人。

这应该能够说明编写安全软件的重要性了,尤其在特定的环境中。当然也包括其他用例中,我们也应该意识到我们的软件 bug 会导致什么。

防御式编程初窥

为什么我认为在特定种类工程中,防御式编程是解决这些问题好的方式。

抵御那些不可能的事,因为看似不可能的事也会发生。

防御式编程中有很多防御方式,这也取决于你的软件项目所需的「安全」的级别和资源级别。

防御式编程是防御式设计的一种形式,用来确保软件在未预料的环境中能继续运行。防御式编程的实践往往用于需要高可靠性、安全性、保密性的地方。——Wikipedia

我个人相信这种实现适合很多人调用的大型、长期的项目。例如,一个需要大量维护的开源项目。

我们来探索一下我提出的关键点,来完成一个防御式编程的实现。

##永远不要相信用户输入

设想你总是将获取到你不期待的东西。这将使你成为防御式程序员,针对用户输入或传入你的系统的一般东西。因为我们说过我们期待异常情况。试着尽可能严谨。断言输入值是你所期待的。

进攻是最好的防守

设置白名单而不是黑名单。举个例子,当你验证图像扩展名时,不要检查非法的类型,而是检查合法的类型并排除其他类型。在 PHP 有无数的开源校验库让你的工作变得简单。

进攻是最好的防守。共勉

使用数据库抽象

OWASP Top 10 Security Vulnerabilities 排首位的是注入攻击。这意味着有些人(很多人)还没有使用安全的工具来查询数据库。请使用数据库抽象包或库。在 PHP 里你可以使用 PDO确保防御基本注入

不要重复发明轮子

你不用框架(或微框架)吗?好吧你喜欢毫无理由地做额外的工作。这并不仅仅有关框架,也意味着你可以方便的使用已经存在的、测试过的、受万千开发者信任的、稳定的新特性,而不是你自己仅为了从中受益而制作的东西。你自己创建东西的唯一原因是你需要的东西不存在,或存在但不符合你的需求(性能差、缺失特性等等)。

这就是所谓的智能代码重用。拥抱它吧。

不要相信开发者

防御式编程与防御驱动相关联。在防御驱动中,我们假设我们周围的每个人都可能犯错。所以我们要注意别人的行为。相同观念也适用于防御式编程,我们作为开发者不要相信其他开发者的代码。我们同样也不要相信我们的代码。

在很多人调用的大型项目中,我们有许多方式编写并组织代码。这也导致混乱甚至更多的 bug。这也是为什么我们需要规范代码风格并做代码检查,让生活更轻松。

##编写符合 SOLID 原则的代码

这是(防御式)编程最困难的部分——编写不糟糕的代码。这也是很多人知道并讨论的,但没有人关心或注意并致力于实现符合 SOLID 原则的代码。

让我们看一些糟糕的例子

避免:未初始化的属性

<?php

class BankAccount
{
    protected $currency = null;
    public function setCurrency($currency) { ... }
    public function payTo(Account $to, $amount)
    {
        // sorry for this silly example
        $this->transaction->process($to, $amount, $this->currency);
    }
}

// I forgot to call $bankAccount->setCurrency('GBP');
$bankAccount->payTo($joe, 100);

在这个例子中,我们需要牢记签发付款前要先调用 setCurrency。这是很糟糕的事情,一个像这样的改变状态的操作(签发付款)不应该分两步,使用两个公开的方法。我们可以拥有许多方法付款,但我们必须只有一个公开的方法来改变状态(类不应该存在不一致的状态)。

在这个例子中,我们把它改进,将未初始化的属性封装进 Money 类。

<?php

class BankAccount
{
    public function payTo(Account $to, Money $money) { ... }
}

$bankAccount->payTo($joe, new Money(100, new Currency('GBP')));

它变得极其简单和安全。不要使用未初始化的对象属性。

避免:类的作用域外泄露状态

<?php

class Message
{
    protected $content;
    public function setContent($content)
    {
        $this->content = $content;
    }
}

class Mailer
{
    protected $message;
    public function __construct(Message $message)
    {
        $this->message = $message;
    }
    public function sendMessage(
    {
        var_dump($this->message);
    }
}

$message = new Message();
$message->setContent("bob message");
$joeMailer = new Mailer($message);

$message->setContent("joe message");
$bobMailer = new Mailer($message);

$joeMailer->sendMessage();
$bobMailer->sendMessage();

在上述代码中,Message 通过引用传递“joe message”到每个例子中。一个解决方案是克隆 message 对象到 Mailer 构造函数。但是我们应该做的是试着使用(不变的)值对象,而不是简单易变的 Message 对象。尽可能使用不变的对象。

<?php

class Message
{
    protected $content;
    public function __construct($content)
    {
        $this->content = $content;
    }
}

class Mailer 
{
    protected $message;
    public function __construct(Message $message)
    {
        $this->message = $message;
    }
    public function sendMessage()
    {
        var_dump($this->message);
    }
}

$joeMailer = new Mailer(new Message("bob message"));
$bobMailer = new Mailer(new Message("joe message"));

$joeMailer->sendMessage();
$bobMailer->sendMessage();

编写测试

这点我们很还需要再说吗?编写单元测试可以帮助你秉承一般的原则,比如高内聚、单一职责、低耦合和正确的对象组合。它帮助你不仅仅测试小的单元用例,也测试你组织对象方式。确实,当测试你的小功能时,你会清晰的看到你需要测试多少情况和需要模拟多少对象,来达到 100% 的覆盖率。

结论

希望你喜欢这篇文章。记住这些仅仅是建议,由你决定何时、何处以及是否应用它们。

感谢阅读!

Published inTranslate

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注