php实现和工作原理（PHP应用程序安全设计指北）PHP教程 / PHP会话管理...

前言2018 年将至，一般程序员（特别是 Web 开发程序员）应当抛弃过去开发PHP程序的很多不好的习惯和观念了虽然部分人不以为意，但是这确实是事实这个指南应该以重点部分作为 PHP: The Right Way 安全章节的补充，而不是以一般的 PHP 编程话题。

正文PHP 版本请在 2018 年使用 PHP 7.2, 并且计划 2019 年初切换到 PHP 7.3PHP 7.2 已于 2017 年 11 月 30 日发布写这篇文章的时候，只有 7.1 和 7.2 版本还在被 PHP 官方积极维护，而 5.6 和 7.0 只在大概1年内提供安全补丁更新。

对于其他官方不维护的 PHP 版本，虽然某些操作系统会提供长期支持和维护，但这其实通常是有害的尤其是他们提供安全支持补丁却没有版本号，这使得很难解释系统的安全性（仅仅知道 PHP 版本）因此，无论其他供应商提出了什么承诺，如果可以，你就应该在任何时候都坚决地使用官方提供支持的 PHP 版本。

这样，尽管最终是一个短暂的安全版本，但一个不断致力于升级的版本，总会让你收获一些意外的惊喜依赖管理人生苦短，我用 Composer在 PHP 生态中，Composer 是最先进的依赖管理方案我们推荐 PHP: The Right Way 中关于依赖管理的完整章节。

如果你没有使用 Composer 来管理应用的依赖，最终（hopefully later but most likely sooner）会导致应用里某个依赖会严重过时，然后老旧版本中的漏洞会被利用于计算机犯罪。

重要： 开发软件时，时常记得保持依赖的更新幸运地，这只需一行命令：composer update 如果你正在使用某些专业的，需要使用 PHP 扩展（C 语言编写），那你不能使用 Composer 管理，而需要 PECL 。

推荐扩展不管你正在编写什么，你总会受益于这些依赖这是除了大多数 PHP 程序员的推荐（PHPUnit, PHP-CS-Fixer, ...）外的补充roave/security-advisoriesRoaves security-advisories 使用 Friends of PHP repository 确保你的项目没有依赖一些已知易受攻击的依赖。

composer require roave/security-advisories:dev-master 或者，你可以上传你的composer.lock文件到 Sensio Labs ，作为例行自动化漏洞评估工作流的一部分，以提醒发现任何过时的软件包。

vimeo/psalmPsalm 是一个帮助你识别代码里可能存在 bugs 的静态分析工具还有其他很好的静态分析工具（例如 Phan 和 PHPStan 都很棒），但当你发现你需要支持 PHP 5，Psalm 将是 PHP 5.4+ 的首选。

使用 Psalm 挺简单：# Version 1 doesnt exist yet, but it will one day: composer require --dev vimeo/psalm:^0 # Only do this once: vendor/bin/psalm --init # Do this as often as you need: vendor/bin/psalm

如果你是第一次在现有代码库运行，可能会看到很多红色错误但除非你在构建像 WordPress 那么大的程序，否则努力通过所有测试绝不是艰巨的无论使用哪种静态分析工具，我们都推荐你能将他加入到持续集成工作流（Continuous Integration workflow）中，以便在每次更改代码中运行。

HTTPS 和浏览器安全HTTPS, which should be tested, and security headers .2018 年，不安全的 HTTP 网站将不再被接受幸运的是，由于 ACME 协议 和 Lets Encrypt certificate authority，免费的 TLS 证书成为了可能。

将 ACME 集成到你的服务器，小菜一碟Caddy: 自动加入Apache: 很快作为mod_md可用在此之前，网上很多高质量教程Nginx: 相对简单你也许会想，“好，我已经有 TLS 证书了，为了网站变得安全和快速，得花些时间折腾配置信息。

”不！Mozilla做了件好事情！你可以根据网站的目标受众，使用配置生成器生成推荐套件如果你希望网站安全，HTTPS ( HTTP over TLS ) 是绝对不能妥协的使用 HTTPS 立刻就能消除多种攻击（中间人攻击、窃听、重放攻击以及若干允许用户模仿的会话形式的攻击）。

安全头在服务器使用 HTTPS 确实为用户提供了许多安全性和性能方面的好处，但也还能通过利用某些浏览器的安全功能来进一步提升安全性而这大部分会涉及到响应内容的安全头Content-Security-Policy你需要该 Header ，因为它提供了对于浏览器是否允许加载内部和外部资源的细化控制，从而为跨域脚本攻击漏洞提供了有效防御层。

参阅 CSP-Builder，以便快速简便地部署/管理内容安全策略（Content Security Policies）为了更加深入的分析， Scott Helmes introduction to Content-Security-Policy headers，会是一个很好的引导。

Expect-CT你需要该 Header ，因为它能通过强制某些不良行为者将其错误证书的证据颁发到可公开验证的仅可追加的数据结构，从而针对流氓/受损的证书颁发机构增加一层防护优先设置为enforce,max-age=30。

只要你有足够的自信该 Header 不会造成服务中断，增加max-age吧Referrer-Policy你需要该 Header ，因为它允许你控制用户的行为信息是否泄露给第三方同样地，Scott Helme 提供了一篇关于Referrer-Policy Header 介绍好文。

除非有理由允许更加宽松的设置，否则请设置为same-origin或no-referrerStrict-Transport-Security你需要该 Header ，因为它告诉浏览器通过 HTTPS 而不是不安全的 HTTP ，将 future requests 设为同源。

在第一次部署时，将其设置为max-age = 30，然后当你确信没有任何内容会中断时，将此值增加到某个较大的值（例如 31536000）X-Content-Type-Options你需要该 Header ，因为 MIME 类型的混淆可能会导致不可预知的结果，包括奇怪的允许 XSS 漏洞的边缘情况。

这最好伴随着一个标准的 Content-Type Header 除非需要默认的行为（例如文件的下载），否则请设置为nosniffX-Frame-Options你需要该 Header ，因为它允许你防止点击劫持。

设置为DENY (或者SAMEORIGIN, 但仅仅当你使用元素的时候)X-XSS-Protection你需要该 Header ，因为它启用了一些默认情况下未启用的浏览器反 XSS 功能设置为1; mode=block。

同样，如果你使用 PHP 的内置会话管理功能（建议使用），则可能需要这样调用session_start()： true, cookie_secure => true ]);

这会强制你的应用在发送会话标识符时使用 HTTP-Only 和 Secure 标志，从而防止 XSS 攻击窃取用户的 Cookie ，并强制它们分别通过 HTTPS 发送 我们之前在 2015 年的博客文章中介绍了安全的 PHP 会话。

子资源完整性在将来的某个时候，你也许会使用 CDN 来加载网站的公共 JavaScript/CSS 库安全工程师已经遇见了这存在一个明显的风险，如果很多网站使用 CDN 提供内容，Hack 和替换 CDN（获得了 CDN 的控制权）就可以注入（恶意）代码到成千上万的网站。

查阅子资源完整性吧子资源完整性（SRI，Subresource integrity）允许你将希望 CDN 服务的文件的内容进行哈希处理目前实行的 SRI 只允许使用安全的密码散列函数，这意味着攻击者不可能生成与原始文件哈希相同的恶意版本资源。

一个真实例子: Bootstrap v4-alpha uses SRI in their CDN example snippet

文档关系Web 开发人员经常在超链接上设置目标属性（例如，target ="_ blank"在新窗口中打开链接）但是，如果你没有传递rel ="noopener"标签，则可以允许目标页面控制当前页面不要这样做：

Click here 这会让http://example.com页面能控制当前页面而应该这样做：Click here 。

通过这样在新窗口打开https://example.com，当前窗口的控制权也不会授予可能的恶意第三方可以更加深入研究开发安全的 PHP 程序如果应用程序安全性对你来说是一个新话题，请从应用程序安全性简介开始吧。

大多数安全专家指出，开发者可以使用 OWASP Top 10 等资源开始着手但是，大多数常见的漏洞也可以是相同高等级的安全问题（例如代码和数据没有完全分离、逻辑不严谨和健全、操作环境不安全或是可破译的密码协议等）。

我们的假设是，应该授予安全新手知道一些更简单、基础的安全知识和问题，并如何解决这些问题，应该是一个更好的、长远的安全工程因此，我们避免推荐十大或二十大安全清单数据库注入避免 PHP 程序存在 SQL 注入。

如果你是自己编写 SQL 代码，请确保使用prepared语句，并且从网络或文件系统提供的信息都作为参数传递，而不是字符串拼接的形式此外，确保你没有使用模拟的prepared语句为了达到好的效果，可以使用 EasyDB 。

不要这样做：query("SELECT * FROM users WHERE username = " . $_GET[username] . "");

应该这样做：row("SELECT * FROM users WHERE username = ?", $_GET[username]);

还有其他数据库抽象层提供了相同的安全性（EasyDB实际上是在使用 PDO ，但在实际的prepare语句前避免了prepared语句模拟） 只要用户输入不会影响查询的结构，就很安全（包括存储过程）文件上传

深入：如何安全地允许用户上传文件？接受文件上传是一个冒险的提议，但只要采取一些基本的预防措施，是能保证安全的也就是说，允许文件直接上传的话，这些文件可能会被意外的允许执行或解释上传的文件应该是只读（read-only）或读写（read-write）的，永远不应该可执行（executable）。

如果你的网站根目录是/var/www/example.com，请不要保存上传文件在/var/www/example.com/uploaded_files而应该保存到一个不能直接访问的目录（例如：/var/www/example.com-uploaded/），以免意外地将其作为服务器端脚本执行，并获得执行远程代码的后门。

一个更加简洁的方法是将网站根目录往下移动一个层级（即：/var/www/example.com/public）如何安全地下载这些上传文件也是一个问题直接访问 SVG 图像类型时，将在用户浏览器执行 JavaScript 代码。

尽管它的MIME类型中的image/前缀具有误导性，但是这是正确的正如前面提及的，MIME 类型嗅探可能导致类型混淆攻击请参阅X-Content-Type-Options如果你放弃前面关于如何安全地存储上传文件的建议，攻击者就会通过上传 .php 或 .phtml 文件，直接在浏览器中访问文件来执行任意代码，从而完全控制服务器。

跨站脚本关于 PHP 中的跨站脚本攻击，你想知道的都在这里同样地，预防 XSS 和 SQL 注入是一样简单的我们有简单而易用的 API 来分离文档结构（structure of a document）和填充的数据。

然而，实际上还有很多 Web 开发程序员仍是通过生成一大串 HTML 代码作为响应的形式开发并且，这不是 PHP 独有的现实，这是所有 Web 开发程序员都应该重视的减少 XSS 漏洞不失为一个好方法总之，前面谈及的浏览器安全的章节就显得十分相关了。

简言之：尽量避免输出和输入（Always escape on output, never on input）如果你把已清洗的数据（sanitized data）保存在数据库，然后在其它地方被发现了 SQL 注入漏洞，攻击者将通过恶意程序污染这些受信任的已清洗数据（trusted-to-be-sanitized record），从而绕开 XSS 保护。

如果你的框架有一个提供自动上下文过滤的模板引擎，那就使用它吧这些工作可由框架安全地做到echo htmlentities（$ string，ENT_QUOTES | ENT_HTML5，UTF-8） 是一种安全、有效的方法阻止UTF-8编码的网页上的所有 XSS 攻击，但不是任何 HTML 都有效。

如果你的环境要求你使用 Markdown 而不是 HTML ，那就不要使用 HTML 了如果你需要使用原生 HTML（没有使用模板引擎），参阅第一点，并且使用 HTML Purifier 吧HTML Purifier 不适合转义为 HTML 属性上下文（HTML attribute context）。

跨站请求伪造跨站请求伪造（CSRF）是一种混淆的代理攻击，通过诱导用户的浏览器代表攻击者执行恶意的 HTTP 请求（使用的是该用户的权限）这在一般情况下是很容易解决的，只需两步：使用 HTTPS 这是先决条件。

没有 HTTPS 的话，任何保护措施都是脆弱的，虽然 HTTPS 本身并不防御 CSRF 增加基本的 Challenge-response authentication为每个表单添加一个隐藏的表单属性填充一个密码安全的随机值（称为令牌）。

验证是否提供了隐藏的表单属性，以及是否匹配上期望值我们写了一个名为 Anti-CSRF 的库，并且：你可以使每个令牌只能使用一次，以防止重放攻击多个令牌存储在后端一旦令牌获取完，令牌会循环使用每个令牌可以绑定特定的 URL 。

如果某个令牌泄露了，它不能在不同的上下文使用令牌可以绑定特定的 IP 地址v2.1 后，令牌可以重复使用（例如供 Ajax 使用）如果你没有使用防止 CSRF 漏洞的框架，请将 Anti-CSRF 放在一边。

在不久的将来，SameSite cookies将允许我们更简单地避免CSRF攻击XML 攻击 (XXE, XPath Injection)在处理大量 XML 的应用程序中存在两个主要的漏洞：XML External Entities (XXE)

XPath 注入除此之外， XXE 攻击可用作包含攻击代码的本地/远程文件的启动器早期版本的 Google Docs 被着名于 XXE ，但除了在很大程度上使用 XML 的商业应用程序之外，基本闻所未闻。

针对 XXE 袭击的主要缓解措施: