Ajax的post请求安全安全、Ajax、post

2023-09-10 19:57:36 作者:即使百毒不侵也會萬劍穿心

我正在开发使用PhoneGap的移动应用程序,它会通过Ajax请求的服务器(PHP)进行通信。

在服务器端(PHP) 像 https://example.com/retrieveData.php 将通过 $获得用户ID _ POST ['USER_ID'] 键,返回有关用户以JSON一些敏感信息。

和在客户端(PhoneGap的JavaScript的) 该JSON输出将被解析并在应用将被使用。

我担心的是,如果有人偷了这个网址( https://example.com/retrieveData.php),他可以手动发送伪造的POST请求,并可以窃取返回的用户信息?

我如何能确保这一沟通?

解决方案   

我担心的是,如果有人偷了这个网址( https://example.com/retrieveData.php),他可以手动发送伪造的POST请求,并可以窃取返回的用户信息?

ajax的get和post请求,js Ajax get和post请求

您的权利予以关注。任何人都可以发送邮件到该网址,并得到结果的除非你检查的 批准 请求。

例如,您可以的验证的检查的要求来自用户,然后基于该想法,用户应该可以访问该信息授权该请求。

另外,你可以授权基础上的东西,只有一个有效的请求都知道通过的共享的秘密的并依靠这个URL prevent共享秘密成为公开的 HTTPS 部分。你给了秘密可信赖的合作伙伴,而当你产生通过PHP Web表单(也通过HTTPS保护的),您有包含共享秘密隐藏的输入。这是怎么 XSRF 保护典型作品。

您应该考虑以下几点:

谁应该合法地能达到这一页?已登录用户通过您的手机应用程序进行交互,合作伙伴谁可以保护一个秘密,网络API用户? 在什么凭证做他们使用你的服务器的其他部分?登入的饼干? XSRF令牌?合作伙伴的令牌? 仅发送哪些部分您的应用程序通过安全渠道,如 HTTPS

如果所有(1)由(2)和那些凭据永远只能发送(3),那么你只需要检查(2)在你的页面的凭据某个子集满足。否则,你需要返工您的应用程序的架构,直到那是真的。

OWASP有指南授权可能会派上用场,他们也有一个对审查批准code,但大部分的例子不是PHP具体页数。

I am developing a mobile application using PhoneGap which will communicate with a server(PHP) via ajax requests.

On the server side(PHP) Something like https://example.com/retrieveData.php will get the user id via $_POST['user_id'] and return some sensitive information about the user as JSON.

And on the client side(PhoneGap-Javascript) that JSON output will be parsed and will be used in the application.

My concern is that if someone steals this url ( https://example.com/retrieveData.php ), he can manually send fake post requests and can steal the returned user information?

How can I secure this communication?

解决方案

My concern is that if someone steals this url ( https://example.com/retrieveData.php ), he can manually send fake post requests and can steal the returned user information?

You are right to be concerned. Anybody can send a message to that URL, and get the result unless you check some part of the request that authorizes the request.

For example, you could authenticate to check that the request comes from the user and then authorize the request based on the idea that the user should have access to that info.

Alternatively, you can authorize based on something that only a valid requestor would know via a shared secret and rely on the https part of that URL to prevent shared secrets from becoming public. You give out the secret to trusted partners, and when you generate a web form via PHP (also protected via HTTPS), you include a hidden input containing the shared secret. This is how XSRF protection typically works.

You should think about the following:

Who should legitimately be able to reach this page? Logged-in users interacting via your phone app, partners who can protect a secret, web API users? What credentials do they have for using other parts of your server? Log-in cookies? XSRF tokens? Partner tokens? What parts of your app are sent only over secure channels like https?

If all of (1) is satisfied by some subset of credentials in (2) and those credentials are only ever sent over (3) then you just need to check (2) in your page. Otherwise, you need to rework your application architecture until that is true.

OWASP has a Guide to Authorization that might come in handy and they also have a number of pages on reviewing authorization code but most of the examples are not PHP specific.