Question

几天前，我遇到news关于黑客如何通过更改URL中的数字来偷走200,000多个花旗帐户。似乎开发人员因为RESTful而损害了安全性，并且也没有费心去保持会话ID代替userId。我也正在开发一个安全性是主要问题的产品，所以我想知道在这种情况下我们是否应该避免使用REST并在任何地方使用发布请求？或者我错过了一些关于REST的重要内容？

Answer 1

不要因为执行不力而责怪模型，而是要从别人的错误中吸取教训。

这是我的（简短）意见，但我确信会增加更好的答案：）

（P.S。 - 使用Post不会以任何方式增加安全性）

Answer 2

问题中提到的安全问题与REST，SOAP或Web无关。它与设计应用程序的方式有关。

这是另一个常见的例子。比如说，电子商务应用程序中有一个屏幕显示订单的详细信息。对于登录用户，URL可能如下所示：

http://example.com/site/orders?orderId=1234

假设订单是全局唯一的（跨该系统的所有用户），可以轻松地将该orderId替换为不属于该用户的其他有效OrderId并查看详细信息。保护它的简单方法是确保底层查询（SQL等）还将用户的Id添加为连接（在SQL的WHERE子句中为AND）。

在这种特定情况下，良好的应用程序设计可确保使用关联的经过身份验证的会话验证URL中的帐户ID。

Answer 3

无论您使用GET还是POST，相同的数据都会通过网络传输。下面是一个示例GET请求，它是提交表单[取出User-Agent值因为它很长]的结果：

GET /Testing/?foo=bar&submit=submit HTTP/1.1
Host: localhost
User-Agent: ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/Testing/demoform.html

现在这是与POST相同的请求：

POST /Testing/ HTTP/1.1
Host: localhost
User-Agent: ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/Testing/demoform.html
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
foo=bar&submit=submit

请注意，这是服务器在您提交请求时看到的内容，或者是中间人攻击者在拦截请求时可能看到的内容。

在GET中，我们在请求的第一行看到foo = bar和submit = submit。在POST中我们必须看最后一行才能看到......嘿！ foo = bar和submit = submit。一样。

在浏览器级别，差异在地址栏中显示。第一个请求显示?foo=bar&submit=submit字符串，第二个请求不显示。想要拦截此数据的恶意用户并不关心浏览器地址栏中显示的内容。主要的危险是因为任何人都可以从地址栏中复制一个URL并传递它，从而泄露参数;事实上，人们常常这样做。

让恶意人员看不到这些类型的请求的唯一方法是在将其发送到服务器之前对其进行加密。服务器提供使用的公钥（通过https协议和SSL / TLS）。浏览器使用密钥加密请求，服务器使用私钥解密。客户端仍然存在一个问题，即从服务器收到的密钥是否实际上属于运行服务器的人员。这必须通过一些带外信任系统进行验证，如第三方验证或指纹比较等。

这一切与REST完全正交。无论您如何操作，如果您使用HTTP通过线路传递信息，您将遇到此问题，并且您将需要加密请求/响应以防止恶意用户看到它们。

Answer 4

POST请求并不比RESTful请求更安全，RESTful请求并不比GET请求更安全。

有一系列措施可以提高应用程序的安全性，但不能在此处列出。维基百科有很多它们和防止它们的方法。

以下是一个示例：GET请求不应用于撤销银行帐户等关键操作，因为如果您登录银行帐户，则有人可以将源代码设置为http://yourbank.com/actions/withdraw/300USD ，并将加载该网址，从您的银行帐户中提取资金。使用POST请求可以很容易地解决这个问题。

然后，我们还有一些进一步的安全考虑因素来处理这个帖子请求，因为它可能会被欺骗。

Answer 5

使用POST代替GET作为安全措施只是使用“通过默默无闻的安全性”。实际上它并不安全，因为任何具有少量HTTP知识的人都可以伪造POST请求。

使用会话ID而不是用户ID也只是掩盖安全漏洞的另一种方式，它并没有真正解决问题，因为会话ID也可能被劫持。

在这种特殊情况下，通过更改URL非常容易利用安全漏洞这一事实并不会使REST成为安全问题的原因。

正如其他人所提到的，每当您需要保护REST服务时，HTTPS就是开始寻找的地方。

Answer 6

我会认为REST和所有Web应用程序的安全问题非常相似。

问题中陈述的问题被认为是“学校”错误 - 经验丰富的Web开发人员不会这样做。因此，如果您了解Web应用程序安全性 - 您也将了解REST安全性。

如果您没有任何经验丰富的Web开发人员，请将其添加到您的团队中 - 他会帮助您使用REST。

Answer 7

如果安全是主要问题，请专门使用https://和POST，绝不使用http://和GET。

这将避免你描述的攻击以及许多其他攻击，例如会话劫持，以及简单的线路窃听。

（...并且，不要错误地使用https://进行身份验证并稍后切换到http://，这是“事实上的标准”，直到几个月前有人发布了一个工具，做了显而易见的）

REST与安全性

7 个答案: