有关 API 的 Web 安全问题
我正在构建一个没有服务器端身份验证的 API。将为会话生成一个唯一的密钥（假设该密钥很长且无法猜测），但不会在客户端设置 cookie。客户端可以是使用 AJAX 的 Web 浏览器、使用 CURL 的 PHP 脚本或桌面应用程序。我想象的正常交易过程将是：
初始遇到
- 客户端发出初始请求，调用 start_session 方法
- 服务器生成一个密钥并将其与一些初始数据一起返回
- 客户端存储该密钥以供以后使用（例如 JavaScript 设置一个密钥） cookie 和密钥）
下一个请求
- 客户端再次请求服务器，调用一些 set_data 方法，提供原始会话密钥，以及大量私人数据，例如信用卡号、有关法律案件的信息等。
- 服务器响应，并返回成功消息
另一个请求
- 客户端再次请求服务器，提供原始会话密钥，并调用某些 get_data 方法
- 服务器以某种格式（例如 XML、JSON 等）响应所有私有数据
会话密钥如果未使用，将在 20 分钟后过期，并且所有 API URI 都将需要 SSL。
我关心/问题是：我是否需要担心客户端是否泄露了会话密钥。如果没有身份验证，我相信原始请求者会将会话密钥保密。这是常见/安全的做法吗？
I'm building an API with no server-side authentication. A unique key (assume the key is very long and impossible to guess) will be generated for the session, but no cookie will be set on the client. The client could be a web browser with AJAX, a PHP script using CURL, or a desktop application. The normal transaction process I'm imagining will be:
Initial encounter
- The client makes an initial request, calling a start_session method
- The server generates a key and returns it along with some initial data
- The client stores the key for later use (e.g. JavaScript sets a cookie with the key)
Next request
- The client requests the server again, calling some set_data method, providing the original session key, as well as loads of private data such as a credit card number, information about legal cases, etc.
- The server responds, and the responds with a success message
Another request
- The client requests the server again, providing the original session key, and calling some get_data method
- The server responds with all of the private data in some format (e.g. XML, JSON, etc)
A session key expires, if not used, in a 20 minutes, and all API URIs will require SSL.
My concern / question is: Do I need to be worried about whether the client has leaked the session key. Without authentication, I'm trusting that the original requester to keep the session key private. Is this common / safe practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非您自始至终都使用 HTTPS，否则您很容易受到 HTTP 嗅探的攻击，a la Firesheep。
Eve，如果您确实使用 SSL，如果客户端页面不是 SSL 或包含任何非 SSL Javascript（或同一域中的非 SSL 框架），您仍然容易受到攻击（并且对此您无能为力）
要回答您提出的问题，完全取决于您的情况。
编辑：您应该在文档页面中警告您的客户（开发人员）正确处理密钥。
除此之外，这取决于客户的平均技能水平。
您可能应该有某种免责声明（我不是律师）。
可能没问题。
Unless you use HTTPS throughout, you're vulnerable to HTTP sniffing, a la Firesheep.
Eve, if you do use SSL, if the client page isn't SSL or contains any non-SSL Javascript (or non-SSL frames in the same domain), you're still vulnerable (and there's nothing you can do about it)
To answer your stated question, it completely depends on your situation.
EDIT: You should warn your clients (developers) in the documentation page to handle the key correctly.
Beyond that, it depends on the average skill level of the clients.
You should probably have a disclaimer of some sort (I am not a lawyer).
It's probably OK.