10

这是一个困扰我一段时间的问题，因此我正在寻找意见和解决方案，以遏制该应用程序存在安全风险的可能性。

我用 jQuery 做很多事情，但主要是用它来处理 jQuery 对话窗口。很多时候需要从表单上的字段中获取一个值，将该信息与 .serialize() 命令连接起来，然后将其传递给 jQuery ajax 调用，以便转到 PHP 文件进行数据库交互。

我的问题来了（最后），

'猜测' PHP 处理的 url 看起来像什么不是很容易吗？
您可以在现代浏览器中打开源代码并单击链接以查看包含 ajax 调用的完整 JavaScript 文件。

我可能会缩小 JavaScript 文件以进行混淆，但这不是一种可以依赖的安全形式。

我正在使用 PDP 进行数据库访问，并使用准备好的语句进行 SQL 注入攻击，但是如果有人花时间查看，他们不能只是形成一个有效的 url 将其发送到数据库并插入他们想要的内容吗？

我不是在谈论将数据库黑客攻击到钢铁信息，我更多的是在谈论插入恶意信息，就好像数据是从应用程序本身添加的一样。考虑将 50 美元的东西添加到您的购物车，只需 25 美元。

如果它就像将 ajax 请求从 GET 转换为 POST 并更改我的 PHP 文件一样简单？

编辑：此人已登录并经过正确身份验证。

只是想知道那里的其他人在做什么。

谢谢！

4

6 回答 6

13

你说得很对，任何稍微懂技术的人都可以识别任何 web 应用程序的公共服务器端点。他们甚至不需要看代码。他们可以只使用他们的 webkit/firebug 来跟踪请求，或者使用像 Charles 这样的程序来监控网络活动。

这就是您需要在服务器端代码中进行 身份验证和授权处理的原因。

身份验证通常由用户名和密码处理；这是验证用户是谁的行为。

授权可以由服务器上的角色处理，并且是检查以确保用户可以做他们想做的事情。

这两种机制到位，即使用户知道一个url，他们仍然需要“登录”并有权做他们想做的事。

想想看。如果您在线查看您的银行账户信息，您可以轻松识别加载您的账户信息的请求。如果没有这些机制，是什么阻止您简单地更改您传递给服务器的帐户 ID 以尝试获取其他人的帐户信息？通过身份验证/授权，服务器知道即使它收到加载某些数据的请求，它也可以检查用户的详细信息以查看他们是否有权获取该数据，并拒绝该请求。

于 2012-04-26T12:30:30.617 回答
9

即使您从 GET 切换到 POST，任何有兴趣的人仍然可以很容易地查看（和更改）任何传递到您的服务器的参数。但关键在于：即使您根本不使用 AJAX，而是使用普通的旧表单，仍然非常容易查看和编辑传递给服务器的任何参数。

在危急情况下，您永远不能完全依赖从客户那里收到的信息。

例如，如果您要向购物车中添加商品，只需将商品的 ID 和数量传递给您的服务器。不要从您的客户那里获取价格详细信息，而是从您的数据库中获取。如果有人试图破解您并编辑要发送的商品 ID 或数量，最糟糕的情况是他们最终购买了他们不想要的东西；完全是他们的问题。（但出于同样的原因，如果它是有限的报价，您将需要验证您收到的数量不大于您允许任何一位客户购买的数量，例如）。

因此，在一天结束时，您始终是开发人员必须决定您希望用户控制哪些值，并在您的服务器端验证您没有收到任何超出用户应有范围的请求能够做到。

于 2012-04-26T12:32:04.510 回答
3

您永远不能依赖来自客户端的任何操作或数据，不仅与 jQuery 有关。

您必须处理服务器端的各种安全问题。始终仔细检查来自用户的数据（一个在客户端用于减少性能请求的数量；另一个在服务器端用于实际确认）。

请求类型（GET 或 POST）其实并不重要，可以很容易地模拟出来。在用户尝试以 25 美元的价格添加 50 美元的商品后，您应该检查您的数据库并确认商品的实际价格。

于 2012-04-26T12:33:44.663 回答
2

是的，您需要服务器端安全性来验证每个数据都发送到您的服务器。例如，您在 javascript/jquery 中验证数据：

if($(this).val() != ""){
   // post to my server page (mypage.cfm/php/asp)
}

但是如果你不保护你的服务器页面，我可以很容易地将空数据发布到你的服务器并避免使用 javascript，所以你需要使用另一个验证脚本来保护服务器页面，例如：

<cfif val is "">
  //dont post to my server ...
</cfif>

有时它是双重工作，但我们有时都会面对它......

于 2013-05-27T04:54:46.857 回答
2

您永远不应该以这种方式编写代码，价格是从客户端单独传输的，因为任何人都可以发送价格 = 0 或 0.01 的数据以获取任何数量的商品/服务或其他任何东西。

更笼统地说：永远不要相信客户数据。

于 2012-04-26T12:35:13.010 回答
2

数据库的风险通常是：恶意数据、SQL 注入、CSRF。

缩小/丑化你的 javascript 会有所帮助。但是无论您做什么，您的用户都可以轻松捕获他们自己的请求数据。并且没有明确的方法可以防止用户浏览这些乱七八糟的代码。

只有当用户知道您的所有源代码和配置，但仍无法破解您时，安全才是真正的。

没有简单的安全解决方案。以下是在大多数情况下避免出现问题的一些一般做法：

使用 HTTPS 和 POST 请求。 通过 HTTPS 的 POST 请求，请求数据被加密。URL 已公开，但通常没问题。这可以防止中间人攻击并大大减少隐私问题（例如密码/信用泄露）。如果您使用 GET 请求，您的所有数据都将作为 URL 中的查询字符串传递。这意味着为第三方更改您的数据的好机会。

服务器端验证 始终在服务器端验证数据。用户可能是恶意的，并且客户端可能存在错误。例如，计算服务器端的总价格，而不是客户端。否则，用户可能会在此处放置 0。

访问权限控制 AKA Authorization 对允许的操作设置限制，并限制其有效范围。例如，不允许用户代他人下订单。并且不要让他们删除他们的行动历史。

生成令牌以防止 CSRF 一些库可以防止 CSRF。或者你可以实现你自己的。主要概念是生成一个随机令牌并请求客户端将其传回。这可以防止其他网站触发对您服务器的请求（使用您的客户端凭据）

正确备份和 登录 定期备份您的数据库将有助于从灾难中恢复（是的，它们会发生）并通过日志模块跟踪用户所做的事情。

于 2019-03-14T08:11:41.697 回答