怎样打造安全的API（part1）

API驱动的天下
毫无疑问，跟着光阴的推移，咱们所生涯的天下正在变得愈来愈慎密。新的办事正在呈现，目的是使咱们的生涯更简略，更高兴。在一切这些变更的面前，这些办事的组合是一种真正进入自己的技巧：API驱动架构。这些API容许办事在法式级别互相通讯，并供给别的办事可以或许以自己有效的方法花费和应用的可猜测的相应功效。
假如你在曩昔七，八年内不停在停止着任何情势的开辟，那末你可以或许会碰到某种情势或前卫的API。大概你为你的公司创立了一个API，或许你是一个守业公司，而API 便是你的产物。这几天有个笑话是，假如你没有API，那末你的办事久曾经落后于时代。
但是，伴跟着API的创立也会发生一些迟疑。开辟职员在前端，面向客户的开辟和功效方面加倍温馨，在深刻懂得API的进程中，可以或许会感到到其构建的深度。固然根基的常识仍旧存在（如HTTP哀求/相应和输出处置），但它们的实现方法存在分歧的成绩。表现层被完整删除，重点放在被同享的数据上，而不是它的表面。你的义务是订定一些功效和实用性，使其具备更好的演示性和用户体验。
这里有一个简短的阐明 - 本文将重点先容REST API，而不是SOAP（或RPC）。REST在API范畴曾经显著地抢先，假如你筹划实行新的API，那这确定是你抉择的偏向。
假如一个开辟职员对付API的天下来讲是绝对陌生的，那末很天然的偏向便是做出“只是事情”的器械 - 在特定的端点上接管数据哀求，并答复所哀求的婚配。固然这是终极的目的，然则在创立API时也有个事情异样紧张：做出抉择并做好充足掩护的事情。这很容易理解，因为它是一个API，只要别的的“机械”会措辞，它的安全性可以或许比面向客户的应用法式加倍宽松。明显，没有甚么可以或许从真相中更进一步。然则，在确保面向客户的对象中不必要的API时，就必要斟酌到这些成绩。让咱们先来看一下这些观点和斟酌身分，
观点
起首，让咱们来谈谈无关掩护API的一些根基常识。要开端这个话题，我会在这里先说一件事 - 稍后将先容掩护API的方法并非独一的方法。这只是一个方法，我曾经放在一路阐明了一些API的根本安全观点。有一个环球性的API掩护筹划，他们应当在你确定以前停止评价。我将展现的方法对付一个盼望安全的API来讲非常棒，然则不盼望别的体系可以或许带来许多开支。
咱们将应用的方法是应用“同享密钥”体系，此中API和客户端都具备用于认证和发送新闻的机密信息（在这类环境下为令牌）。我看到一些相似体系的体系实现，并应用一个体系，每一个哀求应用一个动态标志。然则，假如攻击者发明了这个令牌，这可以或许会招致严重的成绩。攻击者可以或许模仿用户的新闻并潜伏地绕过验证机制。
我这里说的不是一个繁多的令牌体系，我曾经抉择了一个多重令牌，可撤消的体系，让用户创立他们想要的令牌，描写他们的应用，另一个紧张的利益 - 随时撤消它们。假如你是GitHub用户，那末你可以或许认识它的令牌体系。它以相似的方法事情，只必要增加更多元数据。
假如你认识OAuth v2的处置进程，那末这个设置听起来久很认识。与OAuth事件有一个相似的机密令牌和先后切换，但这里会涉及到更多的器械。别的请记着，计划OAuth并非紧张用于身份验证。其紧张目的是受权。比方，斟酌在网站上看到的一切“应用Twitter登录”功效。当你点击该按钮时，应用法式会将你返回到Twitter站点并请求得到受权同意。你点击“容许”按钮，流程就会继承。这便是OAuth，它正在处置幕后的事情。应用该流程，你就曾经受权应用法式应用你的Twitter信息来辨认你。但是，到Twitter可以或许登录你的帐户时，另一个应用法式实在不晓得你能否真的是你所说的 - 他们曾经接管了危险，并将这一决议移交给了Twitter。
在这里有一个如许的正告：在应用像如许的基于令牌的体系时，请确保所哀求的URL中不因此令牌停止的。默许环境下，URL哀求会记载到Web办事器日记中。假如你的URL中的令牌（特别是性命周期比拟长的）被攻击者得到，一切的攻击者必需做的是找到你的日记存储的地位，并拜访他们想要的一切令牌。
在咱们将要创立的体系中，还将有另一个方面的令牌来赞助进步他们的安全性 - 限定他们的有效光阴。我在这里评论辩论的令牌是认证后的哀求中所应用的令牌，而不是用于身份验证的令牌。经由进程限定这些令牌“存活”的光阴，咱们可以或许削减攻击者被拦阻和从新应用的可以或许性。在咱们的体系中，会将token的有效光阴限定为1小时。这个光阴内平日足以让用户可以或许应用API胜利运转，但仍旧必要为哀求供给充足的掩护。
适时牌过时时，客户端将被发送一个对于认证失败的新闻，他们只必要哀求一个新的令牌。在OAuth的天下里，他们发送一个“刷新令牌”，它专门用于这类令牌“refetch”哀求，然则因为咱们在这里搞了一个更简略，更轻的版本，以是咱们只必要保持手动请求得到新的令牌就行了。
根本流程
我曾经描写了这个API的运作进程，然则让我花一些光阴来遍历失常会话的流程，包含身份验证和残剩的哀求。
1.令牌创立
咱们将会把用户进入应用法式的治理部门当成次进程的开端，并天生用于身份验证进程的新令牌。该令牌是一个随机的字符串，数字和标记，在认证哀求时代（而且仅用于）应用。
2.认证
一旦咱们拥有了令牌，用户将向API上的端点收回一个POST哀求及其凭证：用户名和“暗码”的令牌。如后面所述，你不盼望将此哀求应用GET方法，因为这会将凭证信息表现在办事器日记中...这是一件不好的事情。
对令牌和所供给的用户名停止查找，并确保婚配。假如统统都很好，那末相应将包含咱们随机天生的有光阴限定的令牌，用于以后会话。该令牌用作如下哀求中的标识符，并确保正在发送的新闻未被窜改。假如用户在该令牌仍旧有效的光阴内履行另一个认证哀求，则每次都邑赐与新的令牌，以进一步低落潜伏攻击者的令牌拦阻和重用的危险。
3.追随哀求
有了这个令牌，客户端就可以或许向API中的别的端点收回哀求。咱们的体系今朝不会强迫履行任何权限，只要曾经认证的网关。在一个真正的API中，必要有一个更繁杂的体系来赞助掩护各个端点，并确保只要应用它们的用户能力拜访。

要收回哀求，客户端必需履行几个义务：
1.在名为“X-Token”的header中发送认证发生的令牌
2.创立要发送的新闻的内容的HMAC散列，并将其包含为X-Token-Hash头
应用PHP，第二步可以或许很容易的应用hash_hmac方法实现：
$body = json_encode(['foo' => 'bar']);
$messageHash = hash_hmac('SHA512', $body, $hash.time());
?>
在上面的代码中，咱们正在创立$body内容的SHA512 HMAC散列，并应用$hash身份验证哀求和以后光阴（以秒为单位）作为key。当新闻回到办事器时，这个哈希值是依据雷同的信息从新创立的，而且与X-Token-Hash  header中发送的值停止比拟。假如体系发明不婚配，那末体系就晓得新闻的内容已被变动，并可以或许完整回绝。
夺目的读者可以或许曾经注意到这个哀求处置的一个小成绩 –必要在几秒钟内应用以后光阴。在曩昔一段光阴，我曾经在事情顶用到了许多API，这切实其实成为了一个成绩，因为他们的用户遍及天下各地，有时候他们的体系上的时钟没有准确的同步。因此，不管发送甚么，哀求均会呈现“Bad Request”的新闻。为了赞助办理这类环境，你可以或许将被应用的光阴值改动的“稍长一点”，应用分钟级的光阴而不是秒级的光阴。包含光阴的要点是供给一些随机性来天生HMAC哈希值，因此每一个哀求都不异样。假如把它设置为秒级别的光阴会形成许多成绩，
$body = json_encode(['foo' => 'bar']);
$time = date('ymdHi');
$messageHash = hash_hmac('SHA512', $body, $hash.$time);
?>
你根本上只必要在哀求的+59秒内增加。这不太安全，但假如这意味着更多的用户哀求正在经由进程，那末这是一个绝对公道的衡量。只要记着将其标志为你身旁的被接管的危险，如许就不会被忘记。
对象
固然这里提出的观点可以或许适用于你可以或许抉择的任何语言和任何框架，然则我必需抉择一个作为开端。因为我将重点存眷在了本系列中的PHP示例，以是我决议开辟一个简略的PHP框架，我熟知的框架是Slim框架。这个框架在技巧上是一个“微框架”，旨在为开辟职员供给最少的功效，用于制造Web应用法式。在其根基上，它只是一个简略的前端控制器，并附加路由器和哀求/相应处置。它没有太多的别的器械。有几个长处捆绑在了一路，但假如你正在探求一个框架，你可以或许去探求一个能为你供给统统的一个框架， Slim并非最好的抉择。
但是，这类简洁的方法使其非常得当咱们的例子，特别是当API更多的只是哀乞降相应周期比具备前端的Web应用法式。Slim供给了咱们必要设置的一些根本道路并将其链接到咱们的API的功效部件的统统。
只要给出一个咱们评论辩论的内容的简略设法主意，一旦经由进程Composer装置，相应一切这些都必要的索引页面哀求的应用法式是：
require_once 'vendor/autoload.php';
 
$app = new \Slim\App();
$app->get('/', function() {
    echo 'Hello world!';
});
$app->run();
这便是一切代码...在这个简化的布局中，咱们将构建咱们的API并集成别的几个部门，以赞助掩护它及其要掩护的数据。谈到别的部门，让咱们来看看下一个在咱们的哀求/相应周期中给咱们供给一些可重用的逻辑：中间件。
假如你不认识中间件的观点，实在这是一个非常简略的观点。我一样平常是一个视觉学习者，以是我发明这个图（从Slim框架借来的）很有效：

中间件阐明
如图所示，中间件的根本思惟是环抱你的应用法式的紧张部门停止“包装”。它旨在供给以哀乞降相应处置为中心的附加功效。固然，它也可以或许做别的的事情，然则大多数中间件在全部HTTP哀求中处置数据流方面表现精彩。该哀求进入应用法式，经由进程中间件层，一旦外部处置实现，它将以相同的次序返回到雷同的中间件层。
这个中间件层是咱们在示例应用法式中履行某些受权逻辑的处所。因为必要在每一个哀求上反省API拜访级别，以是将其包装在中间件中是很有意义的，并反省所需数据的传入哀求。这类方法还容许咱们在控制器和外部的逻辑呈现受权成绩时，踢掉客户端。
接下来是咱们将在API示例中应用数据库的两个软件包：Laravel Enloquent数据库层和Phinx迁徙对象。假如你是PHP开辟职员，那末你可以或许会听说过Laravel框架。这个框架在曩昔几年中人气大涨，因为其易用性和“简略”的感到，曾经得到了许多人的追捧。固然框架自己具备许多功效，但咱们这里的这些示例中Eloquent包仅用于处置数据库。
荣幸的是，这个包可以或许在紧张的Laravel框架以外应用，因为“胶囊”这类特征。有了这个，咱们可以或许将Eloquent及其功效引入咱们基于Slim的应用法式，并像Laravel应用法式异样应用它。你可以或许检查“Eloquent”手册懂得更多信息，如下是应用它的示例：
$links = Link::all();
$users = User::where(['active' => 1])->get();
$userLinks = User::find(1)->links;
它不只容许间接提取记载，还可以或许搜刮数据库信息并在模子之间树立干系，从而使你更易在PHP中穿插援用数据，而不会对SQL形成困扰。
Phinx对象使咱们可以或许停止可重用的数据库迁徙。迁徙根本上是一种主动履行SQL敕令的方法。当你斟酌开辟职员面对的一些罕见的数据库成绩时，迁徙的真正利益就非常显著了：初始数据库设置的一致性，并保持全部团队的同步性。Phinx是一个基于PHP的对象，可以或许让你创立迁徙，也可以或许用PHP编写，让你界说迁徙的“up”和“down”逻辑：当新增数据时履行“up“，当必要移除数据时履行“down“。Phinx对象还可以或许跟踪哪些迁徙曾经运转，假如变动后有意想不到的效果，则可以或许回滚。
如下是创立表的Phinx迁徙的示例：
 
use Phinx\Migration\AbstractMigration;

 

 
class CreateSources extends AbstractMigration
{
    public function change()
    {
        $table = $this->table('sources');
        $table->addColumn('name', 'string')
            ->addColumn('type', 'string')
            ->addColumn('user_id', 'string')
            ->addColumn('source', 'string')
            ->addColumn('last_update', 'datetime', ['default' => 'CURRENT_TIMESTAMP'])
            ->addColumn('created_at', 'datetime')
            ->addcolumn('updated_at', 'datetime')
            ->create();
    }
}
在这类环境下，咱们创立一个sources表，此中包含用户援用的列，范例，称号和源值。你会注意到，在这个例子中没有一个详细的up或许down方法。跟着更新版本的Phinx，该对象曾经应用一些邪术实现了change方法。当你写一个change方法时，Phinx会努力找出，并依据正在履行的操纵（应用或回滚）断定若何处置迁徙。在这个例子的环境下，它比拟简略：履行up，表将被创立，而且履行down，表将被删除。
另有一些别的随机的功效将被包含在随机数天生函数和自界说非常处置的方法，但不要担忧，这些都将被实时笼罩。
下集预报
这是本系列文章的第一部门的开头。我向你描写了API生态体系的以后状况，描写了应用法式的根本流程，并列出了咱们将在本系列中应用的一些对象来实现把戏方法。在本系列的下一部门中，咱们将花费一些光阴经由进程筹划咱们的一些根本API功效来设置和通讯。