不要因为实现不好而责怪模型,相反地,要从他人的错误中吸取教训。
这是我的(简短)意见,但我相信会有更好的答案 :)
(附注:使用Post方式并不会增加任何安全性)
无论您使用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 /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
POST请求并不比RESTful请求更安全,而RESTful请求也不比GET请求更安全。
有许多措施可以增加应用程序的安全性,这里无法一一列举。维基百科上有很多方法和预防措施。
这里举个例子:不应该使用GET请求进行重要操作,例如提取银行账户,因为如果您已经登录到银行账户中,某人可以设置一个源为http://yourbank.com/actions/withdraw/300USD的假图片,然后URL将被加载,从您的银行账户中提取资金。这可以通过使用POST请求轻松解决。
此外,我们还需要考虑一些进一步的安全问题来处理这个POST请求,因为它也可能被欺骗。
将POST用于安全措施而不是GET只是一种“安全通过模糊性”的使用。实际上,它并不比任何人都可以伪造POST请求的情况更安全。
使用会话ID而不是用户ID也只是另一种模糊安全漏洞的方法,它并没有真正解决问题,因为会话ID也可能被劫持。
在这种特定情况下,通过更改URL使安全漏洞变得极易利用,并不意味着REST的使用是安全问题的原因。
正如其他人所提到的,每当您需要保护REST服务时,HTTPS是开始寻找的地方。
我认为REST和所有Web应用程序安全问题非常相似。
在问题陈述中提到的问题被认为是“学校”错误 - 有经验的Web开发人员不会犯这种错误。因此,如果您了解Web应用程序安全性 - 您也将了解REST安全性。
因此,如果您没有任何经验丰富的Web开发人员,请将其添加到您的团队中 - 他将帮助您处理REST。
https://
和 POST
,永远不要使用 http://
和 GET
。https://
并稍后切换到 http://
的错误,这曾经是“事实上的标准”,直到几个月前有人发布了一个明显的工具)