偏执态度：您对网络安全问题的看法是什么？

Question

这个问题可能与主观问题有关，但这不是真正的问题。

当您开发网站时，您必须知道几点：XSS攻击，SQL注入等。 可能非常非常困难（并且需要很长时间才能编码）来保护所有潜在的攻击。<​​/ p>

我总是试图保护我的申请，但我不知道何时停止。

让我们举个相同的例子：像Facebook这样的社交网络。 （因为银行网站必须保护其所有数据。）

我看到了一些方法：

1. 不保护XSS，SQL注入......当您信任您的用户时，这可以真正完成：私有企业的后端。但是你确保这种类型的申请安全吗？

2. 仅在用户尝试访问非自有数据时才进行安全攻击：这对我来说是最好的方法。

3. 保护所有，所有，全部：保护所有数据（所有者与否）：用户无法破坏自己的数据和其他用户数据：这是很长的事情，它是否非常有用？< / p>

4. 保护常见攻击，但不会保护非常严重的攻击（因为与被黑客攻击的机会相比，代码太长了。）

好吧，我真的不知道该做什么...对我来说，我尝试做1,2,4，但我不知道这是不是很好的选择。

不保证所有数据安全是否存在可接受的风险？我可以保护所有数据但是我需要两倍的时间来编写代码吗？风险和“时间就是金钱”之间的企业方法是什么？

感谢您分享这个，因为我认为很多开发人员都不知道什么是好的限制。

编辑：我看到很多回复谈论XSS和SQL注入，但这不是唯一需要注意的事情。

我们来一个论坛吧。一个帖子可以写在我们是主持人的论坛中。因此，当您将数据发送到客户端视图时，您可以添加或删除此论坛的“添加”按钮。但是当用户尝试在服务器端保存线程时，您必须检查该用户是否有权点对它（您不能信任客户端视图安全性）。

这是一个非常简单的例子，但在我的一些应用程序中，我有一个权限层次结构，这可能非常难以检查（需要大量的SQL查询......）但另一方面，它是真的很难找到hack（数据在客户端视图中是伪加密的，有很多数据需要修改以使黑客运行，黑客需要很好地理解我的应用程序规则才能进行黑客攻击）：在这种情况下，我可以只查看表面安全漏洞（非常容易入侵）或者我可以查看非常严格的安全漏洞（但这会降低我对所有用户的性能，并且需要很长时间才能开发）。

第二个问题是：我们可以在客户端视图中“信任”（不开发一个降低性能的硬代码和长代码）以进行非常难的攻击吗？

这是另一篇关于这种黑客的帖子:(休眠和集合检查）Security question: how to secure Hibernate collections coming back from client to server?

Answer 1

我认为你应该尽力保护你所能做到的一切，花在这上面的时间与解决你利用某个漏洞的人所造成的混乱所需的时间相比毫无意义。

大多数事情都很容易解决：

• sql注入实际上与sql无关，它只是字符串操作，所以如果你觉得不舒服，只需使用带有绑定参数的预处理语句而忘记问题
• 在将每个不受信任的数据作为输出发送出去之前，通过转义（具有htmlentities左右）很容易否定跨站点利用 - 当然这应该与广泛的数据过滤相结合，但这是一个良好的开端
• 凭据窃取：永远不会存储可以提供对受保护区域的永久访问的数据 - 而是在cookie中保存用户名的哈希版本并为会话设置时间限制：这样一来，攻击者可能碰巧偷了这个数据将具有有限的访问权限而非永久性
• 从不认为仅仅因为用户登录然后他就可以信任 - 将安全规则应用于每个人
• 将您从外部获得的所有内容视为具有潜在危险：即使您从中获取数据的受信任站点也可能受到损害，您也不希望堕落 - 即使您自己的数据库也可能受到损害（特别是如果您是在共享环境上）所以不要相信它的数据

当然还有更多，比如会话劫持攻击，但这些是你应该看的第一件事。

关于您的修改的编辑：

我不确定我是否完全理解您的示例，尤其是“对客户端安全的信任”。当然，所有访问受限的页面都必须先检查用户是否有权查看内容，也可以选择是否（或她）拥有正确的权限级别：所有用户都可以使用某些操作，有些其他只适用于更受限制的群体（如论坛中的版主）。所有这些控件都必须在服务器端完成，因为你可以永远信任客户端发送给你的东西，通过GET，POST甚至COOKIES来获取数据。这些都不是可选的。

Answer 2

“破解数据”不是授权用户或任何其他人应该做到的。我会在“用户输入的验证和卫生”下提交此文件，这是您必须经常做的事情。如果用户“破坏您的数据”的可能性很快就会发生，那么您需要验证应用中的所有输入。转义SQL查询也属于这一类，这既是安全问题，也是数据卫生问题。

您的应用中的一般安全性应该是合理的。如果您有用户管理系统，它应该正常工作。即不应该访问某些内容的用户不应该访问它。

另一个问题，直接XSS攻击，与“打破数据”无关，但与未经授权的数据访问有关。这取决于应用程序，但如果你知道XSS攻击如何工作以及如何避免它们，那么 不 是否有任何理由？

总结：

• SQL注入，输入验证和卫生是齐头并进的，无论如何都是必须的
• XSS攻击可以通过最佳实践和一点意识来避免，你不应该为它做额外的工作
• 除此之外的任何事情，例如“主动”暴力攻击过滤器或此类事情，确实会导致额外的工作，取决于应用程序

简单地养成坚持最佳实践的习惯在制作安全的应用程序方面有很长的路要走，为什么不呢？ ：）

---

您需要将Web应用视为服务器 - 客户端架构。客户端可以提出问题，服务器会给出答案。问题只是一个URL，有时会附加一些POST数据。

  

我可以请/forum/view_thread/12345/吗？   我可以将此$data张贴到/forum/new_thread/吗？   我可以请/forum/admin/delete_all_users/吗？

您的安全性不能仅依赖于客户端而不是提出正确的问题。从来没有。
服务器始终需要在必要时评估问题并回答No。

Answer 3

所有应用程序都应具有一定程度的安全性。您通常不会在Intranet网站上请求SSL，但您需要处理SQL / XSS攻击。

您的用户输入您的应用程序的所有数据都应由您负责。您必须确保没有人未经授权访问它。有时，“不重要”的信息可能会带来很大的安全问题，因为我们都是懒惰的人。

前段时间，一位朋友曾经经营一家游戏网站。用户创建他们的个人资料，论坛，所有这些东西。然后，有一天，有人在某处发现了SQL注入。该攻击者获取所有用户和密码信息。

没什么大不了的，是吧？我的意思是，谁关心网站中的玩家账号？但是大多数用户使用相同的用户/密码来进行MSN，反恐精英等等。所以很快就会成为一个大问题。

底线是：所有应用程序都应该有一些安全问题。您应该查看STRIDE以了解您的攻击媒介并采取最佳行动。

Answer 4

我个人更喜欢随时保护所有内容。这可能是一种偏执的方法，但是当我在互联网上看到大量的网站时，它们容易受到SQL注入甚至更简单的攻击，并且在有人“攻击”它们并窃取他们的宝贵数据之前，他们并不打算修复它。让我非常害怕。我真的不想成为泄密密码或其他用户信息的负责人。

只需询问有黑客经验的人查看您的应用程序/网站即可。它应该让你清楚地知道什么是错的，什么应该更新。

您希望拥有强大的API端ACL。几天前，我看到一个问题，一个人已经确保了每个UI，但该网站通过AJAX易受攻击，只是因为他的API（他发送请求的地方）只是信任每个要检查的请求。我基本上可以通过这个bug拉出整个数据库。

Answer 5

我认为区分防止代码注入和普通数据授权是有帮助的。

在我看来，完全消除SQL注入需要一些良好的编码习惯。根本没有任何借口。

XSS注入有点不同 - 我认为它总是可以防止，但如果您的应用程序具有用户生成的内容，则可能并非易事。我只是说，与SQL注入相比，保护您的应用程序对抗XSS可能并不简单。所以我并不是说允许XSS是可以的 - 我仍然认为没有理由允许它，如果你的应用程序围绕用户生成的内容，那么比SQL注入更难防止。

因此，SQL注入和XSS纯粹是技术问题 - 下一级是授权：一个屏蔽访问数据的程度如何，这与当前用户无关。在这里，我认为它确实取决于应用程序，我可以想象区分：“用户X可能看不到用户Y的任何内容”与“用户Y的数据不打扰用户X将提高可用性和制作”是有意义的应用程序使用起来更方便“。