带有jQuery前端的REST Web服务安全性 [英] REST Web Service Security with jQuery Front-End

查看:125
本文介绍了带有jQuery前端的REST Web服务安全性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

感谢阅读.

我想开发一个安全的Web应用程序,以jQuery作为前端,以.NET MVC作为服务器端,并在RESTful Web服务中表达其功能.在这一点上,我正在尝试设想将要使用的安全性方案,但我希望获得有关最佳实践的一些建议(显然,我将使用https/ssl,但当然还有更多的建议).

I would like to develop a secure web application with jQuery as the front-end and .NET MVC as the server-side with its functionality expressed in RESTful web services. At this point I'm trying to envision the security scheme that I will use but I wanted some advice on best practices (obviously I will use https/ssl, but there's more to it than that of course).

我一直是秘密方法的拥护者,所以我绞尽脑汁想弄清楚如何在这种类型的Web应用程序体系结构中使用它,但是我很茫然.基本上,将生成一个秘密密钥,并将其放置在服务器上以及将其提供给客户端(因此该密钥永远不会通过网络发送),并且每个客户端请求都必须使用此密钥进行数字签名".这是您通常在网络应用程序中通常看到的典型用户名/密码/会话ID结构的补充.

I have always been a fan of the secret-key approach so I was racking my brain trying to figure out how to employ it in this type of web application architecture but I'm at a loss. Basically, a secret key would be generated and placed both on the server as well as given to the client (so the key is never sent across the wire), and each client request must be digitally "signed" with this key. This would be in addition to the typical username/password/session-id structure you usually see in web apps.

我的问题是客户端上密钥的实际存储.由于jQuery文件只是服务器上的.html文件,因此无法访问虚拟Web目录外部目录中的密钥文件.而且,将密钥文件放置在公共网站上并不会成为一个秘密. :)

My problem is the actual storage of the secret key on the client. Since the jQuery file is just .html sitting on the server, there is no way for it to access a secret key file in a directory outside of the virtual web directory. And placing the secret key file on a public web site wouldn't make it too much of a secret. :)

这是我喜欢工作的方式:

  1. 每隔一定间隔(5-15分钟),后端进程将生成一个密钥,并将其放置在后端数据库以及Web服务器上非公开位置的文件中
  2. 当客户端发出请求时,它将从密钥文件中读取,然后使用秘密密钥对请求进行数字签名.
  3. 服务器接收到请求并使用密钥对其进行解码.

但是显然#2是问题所在,因为无法通过javascript访问秘密"(即非公开)文件.

But obviously #2 is the problem, because there's no way to access a "secret" (i.e. non-public) file via javascript.

我太偏执吗?秘密密钥方法很好,因为它在用户名/密码之外还具有更高的安全级别(攻击者需要密钥和有效的用户名/密码),如果我每隔5分钟重新生成一次密钥,则可以降低风险.秘密密钥将泄漏.这也可以确保所有请求均来自经过认证的"客户端.但是我看不到使用未编译的代码(例如html/jQuery)是怎么可能的.

Am I being too paranoid? The secret key approach is nice because it has another level of security above and beyond username/password (the attacker would need the secret key AND a valid username/password), and if I regenerate the key every 5 minutes the risk is mitigated if a secret key would leak. This also ensures that all requests are made from a "certified" client. But I don't see how it is possible using non-compiled code such as html/jQuery.

有人对RESTful Web服务安全性方法有任何建议或文章吗?

Does anyone have any suggestions or articles on RESTful web service security methods?

谢谢:)

文斯

推荐答案

如果您还没有,我建议您阅读 OAuth 1.0 2.0 .它们都被一些较大的API使用,例如Facebook,Netflix,Twitter等. 2.0仍在起草中,但是并没有阻止任何人实现和使用它,因为客户端使用起来更简单.听起来您想要更复杂,更安全的东西,所以您可能希望专注于1.0.

If you haven't already, I'd recommend some reading on OAuth 1.0 and 2.0. They are both used by some of the bigger API, such as Facebook, Netflix, Twitter, and more. 2.0 is still in draft, but that hasn't stopped anyone from implementing it and using it as it is more simple for a client to use. It sounds like you want something more complicated and more secure, so you might want to focus on 1.0.

我总是发现Netflix的身份验证概述是对客户的很好解释.

I always found Netflix's Authentication Overview to be a good explanation for clients.

然后快速谷歌搜索发布了这篇文章:如何做:使用JavaScript保护OAuth

And a quick Googling gives this post: How-to: Secure OAuth in JavaScript

这篇关于带有jQuery前端的REST Web服务安全性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆