php安全性怎么样（2019 PHP 安全指南）

Php教程

2019 年, 大多数的科技工作者—尤其是 Web 开发者—必须摈弃掉关于开发安全 PHP 应用的老一套. 这对那些不相信能够开发出安全的 PHP 应用的人来说尤其重要.这篇指南应该作为 P资源HP: The Right Way 这本电子书强调安全部分的补充, 而不是作为代码风格一样的普通主题.

PHP 版本长话短说:：除非你没有办法， 2018年你在最好使用 PHP 7.2 ， 同时在201资源9年早些时候计划切换到7.3PHP 7.2 已经于2017年11月30号发布.在撰写本文时，只有PHP 7.1和7.2会得到了PHP语言开发人员的积极支持，而PHP 5.6和7.0只会在大约一年的时间资源内获得安全补丁。

虽然一些操作系统为不受支持的PHP版本提供长期支持，但是这种做法普遍被认为是有害的特别在于，他们会在不升级版本号的情况下提供安全补丁，这个坏习惯会使得仅通过PHP版本来判断系统的安全性资源变得非常困难综上，无论其他供应商做出什么样的承诺，只要你能够做到，都应该在任何时间内只运行

获得积极支持的PHP版本这样，即使使用了一段时间的安全版本，持续不断的升级工作也会让你的生活免于不愉快的意外依资源赖管理简而言之：使用 Composer .Composer 是对于PHP生态系统最先进的依赖管理方案, 我们强烈推荐的 。

PHP: The Right Way 里有专门一整节用于如何开始使用 Comp资源oser .如果你不使用 Composer 来管理你的依赖项, 你最终会 (希望延迟但可能事情很快发生) 出现这样一种情况, 你所依赖的库变得过时，旧版本的漏洞被黑客利用.

重点: 始终记得在开发软件时资源更新依赖项 . 幸运的是, 这是一条命令:composer update如果你正在做一些特别需要使用PHP扩展（用C语言编写）的东西, 你就不能用 Composer 安装它们. 您还需要 PECL.

推资源荐的包无论您正在构建什么，您几乎肯定会从这些依赖项中获益这是大多数PHP开发人员推荐的（比如：PHPUnit、PHP-CS-fixer）roave/security-advisoriesRoave的安资源全报告 使用了名叫Friends of PHP 的包来保证。

你的项目不会依赖任何已知的非健壮的包composer require roave/security-advisories:dev-maste资源r    或者，你可以 上传你的 composer.lock 文件到Sensio Labs 作为常规自动漏洞评估工作的一部分，它会把所有使用的过期的包告知你。

vimeo/psalmPsalm是一个静态资源分析工具，可以帮助识别你代码中的bug虽然还有其他很好的静态分析工具（例如： Phan and PHPStan ，它们都很好），如果您发现自己需要支持php 5，没问题，psalm是支持php 5.4资源+的。

Psalm是很容易上手的：# 目前还没有Version 1 ,但是让我们拭目以待:composer require --dev vimeo/psalm:^0# 仅需这样操作:vendor/bin资源/psalm

--init# 一如惯例的操作:vendor/bin/psalm如果你是第一次在现有的代码库上运行，可能会看到很多红色提示这是正常的，除非你创造了一个如同Wordpress一样强大的应用程资源序，否则不太可能使全部测试通过以满足符合Herculean的要求。

无论您使用哪种静态分析工具，我们建议您将运用到持续集成工作流（如果适用），以便在每次代码更改后运行它HTTPS和浏览器安全简而言之: 资源HTTPS, which should be tested, and security headers.。

在2018年，通过不安全的HTTP访问网站将不再被接受幸运的是，得益于ACME协议和 Lets资源 Encrypt certificate authority的存在，我们可以免费获取TLS证书并自动更新它们。

将Acme集成到Web服务器中简直就是小菜一碟Caddy: 自动生成.Apache: 不久资源将以mod_-md.的形式提供, 这里有高质量的教程 在互联网上提供Nginx: 相对简单.你也许会想，“好吧，我有一个TLS证书。

现在，我必须花几个小时来处理配置，然后才能保证它的安全和快速”Nop资源e! Mozilla支持. 您可以使用配置生成器根据预期的访问群体构建推荐的密码套件 HTTPS (HTTP over TLS) 是绝对不可协商。

如果您希望您的网站是安全的使用HTTPS可以立即消除对资源用户的几类攻击（中间建注入、窃听、重复攻击和多种形式的会话操作，否则将允许用户模拟）安全Headers虽然将HTTPS连接到服务器上确实为用户增加了安全性和性能优势，但你可以通过利用其他浏览器安全功能资源更进一步的扩大这些优势。

其中大多数都涉及在内容里发送HTTP响应头Content-Security-Policy你需要这个header，因为它可以对浏览器允许加载的内部和外部资源进行精度控制，从而为跨资源站点脚本漏洞提供强大的防御层。

请参阅CSP-Builder，以便快速轻松地部署/管理内容安全策略要进行更深入的分析，Scott Helme的Content-Security-Policy标题简介是一个资源很好的起点Expect-CT你需要这个header，因为它通过强制将不良居心的人的证书的证据发布到可公开验证的数据结构，从而为恶意/受损的证书颁发机构添加了一层保护。

了解更多关于“Expect-CT”资源的信息首先将这个header设置为enforce，max-age = 30，并增加max-age，如此操作让服务更稳定Referrer-Policy你需要这个header，因为它允许您控制是否将有关用资源户行为的信息泄露给第三方。

再次深入了解 Scott Helme 深入探讨了 `Referrer-Policy` headers将header设置为“same-origin”或“no-referrer”资源，除非您有理由允许更宽松的设置。

Strict-Transport-Security你需要这个header，因为它告诉浏览器通过HTTPS强制所有将来的请求到同一个来源而不是不安全的HTTP首次部署时将资源其设置为“max-age = 30”，然后当您确信没有任何内容会中断时，将此值增加到某个较大的值（例如“31536000”）。

X-Content-Type-Options你需要这个header，因为M资源IME类型混淆可能导致不可预测的结果，包括允许XSS漏洞的奇怪边缘情况最好伴随标准的Content-Type 标题设置为nosniff。

，除非您需要默认行为（例如，用于文件下载）X-Frame-Opt资源ions你需要这个header，因为它可以防止点击劫持设置为DENY（或SAMEORIGIN，但仅当你使用元素时）X-XSS-Protection。

你需要这个header，因为它启用了默认情况下未启用资源的某些浏览器Anti-XSS功能设为1; mode=block同样，如果你使用PHP的内置会话管理功能（推荐使用），你可能想要调用session_start（）。

，如下所示：session_start资源([cookie_httponly => true,cookie_secure => true]);这会强制你的应用在发送会话标识符cookie时使用仅HTTP和安全标记，阻止成功的XSS攻击窃取用户资源的cookie并强制它们分别仅通过HTTPS发送。

我们之前已经在2015年的博文中介绍了安全PHP会话子资源一致性攻击（Subresource Integrity）在将来的某个时候，你可能会使用CDN资源将常用的Javascript / CSS框架和库放到一个集中的地方。

负责安全的工程师对这种操作表示有很明显的安全隐患：那就是，许多网站使用CDN来提供内容，那么攻击CDN并替换内容注入这些代码到成千上资源万数千的网站输入subresource integrity.Subresource integrity (SRI)允许你固定你希望CDN提供的文件内容的哈希值。

当前实现的SRI仅允许使用安全加密散列函资源数，这意味着攻击者生成与原始文件产生相同散列的相同资源的恶意版本是不可行的真实的案例: Bootstrap v4-alpha在他们的CDN示例片段中使用SRI.<

linkrel="stylesheet资源"href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/css/bootstrap.min.css"

integrity="sha3资源84-rwoIResjU2yc3z8GV/NPeZWAv56rSmLldC3R/AZzGRnGxQQKnKkoFVhFQhNUwEyJ"crossorigin="anonymous"

/>

crossor资源igin="anonymous">文档关联Web开发人员经常在超链接上设置target 属性（例如：target="_blank"）实现在新窗口中打开链接但是，如果您没有传递 rel="noopene资源r"标记，则可能允许目标页面控制原始页面。

不要这样做Click here这让example.com可以控制当前的网页替换成这样

target="_blank"rel="noopener noreferr资源er">Click here这将在一个新窗口中打开example.com，但不会将当前窗口的控制权交给可能怀有恶意的第三方。

延伸阅读开发安全的PHP软件如果应用程序安全性是一个新主题，请从应用安全性详资源解开始.许多安全领域的专家都会向开发人员提供诸如 OWASP Top 10 之类的资源.但是，大多数常见漏洞可以归类为同一类的安全问题（代码/数据没有完全分离，逻辑不健全，操作环境不安全或加密协议缺陷资源）。

给新手们说明安全问题是一个很简单的，容易实现的事情，但是如何解决这些安全问题将是更长远的安全工程因此, 我们只推荐类前10名或前25名安全检查清单.数据库交互深入了解： PHP防止SQL注入如果您资源自己编写SQL查询，请确保您使用的是。

预备表达式，并且将网络或文件系统提供的任何信息都作为参数传递，而不是拼接查询字符串此外，确保你没有使用模拟的预备表达式.为达到最佳效果, 使用 EasyDB.*不资源要这样做：/* 不安全代码： */$query = $pdo->query(。

"SELECT * FROM users WHERE username = " . $_GET[username] . "资源");替换成这样：/* 防止SQL注入： */$results = $easydb->row(

"SELECT * FROM users WHERE username = ?", $_GET[usern资源ame]);还有其他一些数据库抽象层提供了同等的安全性（EasyDB实际上在底层使用PDO，但是为了防止安全隐患，它特意禁用准备好的语句模拟，而使用实际的准备好的语句）。

只要用户输入不能影响查询的结构资源，您就是安全的（这包括存储过程）文件上传深入了解: 如何安全地允许用户上传文件接受文件上传是一个冒险的主张，但只要采取一些基本的预防措施，就可以安全地执行此操作也就是说，应当阻止意外地允许执行或解释上资源传文件的方式直接访问上传文件.。

上传的文件应该是只读的或读写的，永远不能被执行.如果你的站点根目录是 /var/www/example.com, 你不应该存贮上传文件在 /var/www/exampl资源e.com/uploaded_files

.相反，你应该将上传文件存储在无法通过浏览器直接访问的单独目录中(例如， /var/www/example.com-uploaded/),以免它们意外地作为服务资源器端脚本执行，打开远程代码执行的漏洞更简单的解决方案是将站点根目录向下移动一级 (例如，移动到：。

/var/www/example.com/public)文件上传的另一个问题是安全地 下载文件 直接访资源问SVG图像将在用户的浏览器中执行JavaScript代码 这是真的,尽管SVG图像的MIME类型是以`image`为前缀.。

MIME类型嗅探可能导致类型混淆攻击详情见前文安全Headers对X-Co资源ntent-Type-Options响应头的介绍如果你不采纳前面关于如何安全存贮上传文件的建议,攻击者可能设法上传.php或者.phtml

的文件， 通过直接在浏览器中访问上传文件执行任意代码, 从而获资源得对服务器的完全控制请安全地玩你的服务器跨站脚本 ( XSS )深入阅读: 关于防止 PHP 中的跨站点脚本漏洞，您需要了解的所有内容在理想的情况下， XSS 和 SQL 注入一样容易预防。

我们有简单资源易用的 API ，用于将查询语句和数据进行分离不幸的是，大多数 web 开发人员的实际工作会涉及到将生成的一长串 HTML 文本并通过 HTTP 协议响应这不是 PHP 独有的功能，它只是 web 开资源发的基本工作方式。

减少 XSS 漏洞并不是那么难做但是，浏览器安全 的所有内容是至关重要简而言之：经常对输出转义，而不是对输入转义 如果你在数据库中存储已过滤的数据，然后在一些地方发现 SQL 注入漏资源洞，那么攻击者可以通过恶意代码篡改可信的数据记录，从而完全绕过 XSS 保护。

如果你的框架中有一个提供自动上下文过滤的模板引擎，那可以使用它它将会给你的框架的功能的安全性提供保障echo htmlen资源tities($string, ENT_QUOTES | ENT_HTML5, UTF-8);。

是一种安全有效的方式，它可以阻止对 UTF-8 编码的 web 页面的 XSS 攻击，但它不允许任何 H资源TML 标签内容输出如果你的需求是允许你使用 Markdown 替代 HTML，不要使用 HTML 。

如果你需要允许一些 HTML 并且没有使用模板引擎（请参见#1），那么就使用 HTML 净化器 H资源TML 净化器不适用于将内容转义成 HTML 标签属性的场景对于用户提供的 URLs ，你应该只允许使用 `http:` 和 `https:` 协议模式；不要用 。

javascript: 此外，使用 资源URL 编码方式编码用户的所有输入跨站请求伪造 (CSRF)跨站请求伪造是一种混乱的代理攻击，通过这种攻击，你可以利用用户的权限，欺骗用户的浏览器执行恶意的 HTTP 请求来实现攻击者的目的。

这在一般资源情况下可通过两个简单步骤解决：使用 HTTPS，这是前置条件没有 HTTPS，任何防御都会变得脆弱，然而单纯的 HTTPS 并不能阻止 CSRF添加基本的请求-响应的身份验证在所有表单中添加一个隐藏的资源表单值。

用安全的随机加密字符串来填充这个值（称为令牌）验证表单中是否含有这个隐藏的值，并且校验是否与设置的一致我们编写了一个名为 Anti-CSRF 的库来更进一步了解如何防范 CSRF为了防止重复攻资源击，每个令牌只能使用一次。

多个令牌都存储在后端令牌轮换一旦达到上限，优先使用最老的每个令牌都可以绑定到指定的资源地址（URI）一旦令牌泄露，那么它也不能用于其他资源请求令牌可以选择绑定到指定的 IP 资源地址从 v2.1 版本开始，令牌可以重复使用（即 AJAX 调用）。

如果你没有使用一个能够帮你解决 CSRF 的框架，那么 Anti-CSRF 能够帮到你在将来，使用 cookie 的 SameSit资源e 属性能够更加简单地防范 CSRF译者注：截至2016年4月，Chrome 51、Opera 39、火狐60已实现了cookie 的 Same-Site 属性。

XML 攻击 (XML外部实体注入, 资源XPath 注入)对于那些过多依赖XML数据结构来处理繁重的业务逻辑的程序而言，这里有两个比较容易被攻击的点XML外部实体注入 (XXE)XPath 注入XXE攻击会利用服务器执行本地或远端的的恶意外资源部文件， 或者执行其他恶意的行为.。

在早期版本的谷歌安全文档中就有显著的提及XXE攻击, 但对于大多数的大量执行XML操作的非商业应用来说对XXE的防范意识是薄弱的其实最简单的减轻XXE攻击影响的方式资源就是：libxml_disable_entity_loader(。

true);XPath 注入 和SQL注入的原理一样，只不过是把攻击对象换成了XML文档比较幸运的是，PHP 对XPath操作方法的查资源询参数是很比较特殊和形式固定的另一方面呢，PHP对于XPath注入没有提供简单有效的防御手段（参数过滤）。

对于XPath查询参数过滤，你的最佳方案就是使用白名单策略匹配过滤