常见的未知PHP安全陷阱

Question

我知道这样的问题已经被问了上百次了，但我的有点不同。

我知道所有常见的和广为人知的安全问题，如SQL注入、XSS等。但是，那些经常出现但大多数时候没有被识别或没有被判断为漏洞的问题呢？有吗？

Answer 1

有一件事我见过很多，它被开发成一个特性，直到为时已晚才被视为安全漏洞，那就是状态更改GET请求。这些很容易导致cross-site request forgery。例如，您的应用程序可能有一个指向http://mysite.com/logout的链接，用于注销用户。但是第三方站点可以添加这样的代码：

<!-- on evil.com site -->
<img src="http://mysite.com/logout">

然后，当用户在evil.com上加载页面时，他们将从mysite.com中注销！

最糟糕的问题发生在站点使用状态更改的GET请求实现API时。例如，如果我运行一个具有类似site.com/addfriend、site.com/sendmessage等urls的社交网站，并将这些urls分发给要为我的网站制作应用程序的开发人员，那么当发现安全漏洞时，开发人员将不得不处理API更改。

Answer 2

1. 使用$_REQUEST而不是$_GET或$_POST，这不是一个好主意，因为$_REQUEST也包含cookie，而且它为适用于所有解释型语言的visibility of .svn/.CVS directories

打开了大门。

Answer 3

以下是我做过的一些工作：

• 在DB
  • 中以明文形式存储密码如果您的站点遭到黑客攻击，黑客可以访问您所有用户的密码和电子邮件。考虑有多少用户的电子邮件和site.

密码相同

​

• 将电子邮件存储在与您的用户相同的表中
  • 如果SQL注入攻击允许黑客访问您的用户表，则电子邮件地址是唯一有价值的信息之一。
  • 如果你不打算给用户发电子邮件，只存储他们的电子邮件的哈希:黑客可以将用户的电子邮件卖给spammers.

​

• 即使您有一个受密码保护的站点，也要计算一下密码的安全性。我有一个朋友，他的网站使用一个简单的5位数字作为密码。
• 如果你正在发送有价值的通信(例如:你正在执行一个使用大量资源的操作: cpu，内存等)，总是需要来自用户的带有时间戳的令牌。
  • 如果黑客发现你有一个每次攻击都要花费你0.0001美元的操作，他们可以租出一个僵尸网络来在你的name.
  • Require上收取费用。用户发送散列(用户的唯一ID，时间戳和秘密盐)以及明文时间戳。明文时间戳允许您验证上周二您没有授予他们权限，散列中的时间戳允许您验证has是否属于该消息，has中的UID确保黑客没有窃取来自其他人的请求，散列中的秘密盐确保他们不会在自己的own.

上生成请求

​

• 如果您正在为应用程序编写插件系统，则要小心存储在私有变量中的内容。看看我写的这篇关于如何使用lock it down.

的文章

这只是我处理过的一些想法和事情。希望它能帮上忙！