Intranet的application需要注意CSRF吗

kr2000

今天同事说我写的ajax code有问题：

我的ajax代码call了一个这样的地址xxxx/deleteabc?abc_id=80.在deleteabc这个controller里面有个权限检查，看用户能不能做这个action。自认为是够安全了，因为只有login的用户才能访问这个地址，而且有权限删除这个abc_id的用户才能delete。

同事说有CSRF的问题。 其他网站可能会包含一个这样的html代码”<img src="xxxx/deleteabc?abc_id=80" />“，我们的用户如果访问了就可能把这个abc删除了。

，有这个必要吗？
什么情况下会有人用CSRF来黑你？

CSRF:Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF ("sea-surf"[1]) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

[ 本帖最后由 kr2000 于 2011-1-10 13:47 编辑 ]

乱码

原帖由 kr2000 于 2011-1-10 13:45 发表
今天同事说我写的ajax code有问题：

我的ajax代码call了一个这样的地址xxxx/deleteabc?abc_id=80.在deleteabc这个controller里面有个权限检查，看用户能不能做这个action。自认为是够安全了，因为只有login的用户才能访问 ...

你同事是对的。

http get只能用在retrieval的情况下，其他的update/delete/create必须用http post，作pre-authentication,或者做一次，用session存了结果，为以后用。还可以进一步验证referrer，

N久之前有这种病毒，侵入一个cms，用http get删了很多records.

classic asp developer很喜欢用action，好像足迹也喜欢这么做，但注意做非read其他操作的时候，要验证身份，这比较重要。

bulaohu

原帖由 kr2000 于 2011-1-10 13:45 发表
今天同事说我写的ajax code有问题：

我的ajax代码call了一个这样的地址xxxx/deleteabc?abc_id=80.在deleteabc这个controller里面有个权限检查，看用户能不能做这个action。自认为是够安全了，因为只有login的用户才能访问 ...

理论上是有可能的。CSRF的案例比XSS少得多，但杀伤力大。有些著名的案例是Internet Banking的早期，有人就这样被人把钱从银行转走了。

CSRF的执行人往往看不到执行结果，因为结果是被送到用户的browser那里去的，带CSRF的exploit的网站不能看到，所以一般用来执行破坏性的行为，比如删除用户ID

你这个例子里这个风险很小，实在有必要的话加一个动态的session id就解决了

kr2000

原帖由 乱码 于 2011-1-10 14:00 发表


你同事是对的。

http get只能用在retrieval的情况下，其他的update/delete/create必须用http post，作pre-authentication,或者做一次，用session存了结果，为以后用。还可以进一步验证referrer，

N久之前有这种病毒，侵入一 ...

我刚跟他说，能用post不？人家说别人照样可以用javascript来执行你的action。
我知道他说的是对的，但一般的用于内部的系统，非网站需要这么注意吗？象老布说的，风险非常小。
解决起来也不是太容易，至少我一下子想不到有什么快捷的方法

乱码

原帖由 kr2000 于 2011-1-10 14:26 发表

我刚跟他说，能用post不？人家说别人照样可以用javascript来执行你的action。
我知道他说的是对的，但一般的用于内部的系统，非网站需要这么注意吗？象老布说的，风险非常小。
解决起来也不是太容易，至少我一下子想不到有什么快 ...

只要你del/update操作的url需要authentication，你就是安全的，至于他们login之后想做什么，那是他们自己问题，不是你的问题。

注意把这些行为和credential log一下，为以后找人算账有根据。

典

Assume my webpage doesn't have external links, How to cross-site forgery?

Users login websiteA (mywebsite) with valid user_name / password,
Didn't close down the webpage, goes to another website B,
Website B runs some actions (xxxx/deleteabc?abc_id=80) to mywebsite

If this is the only scenario,
Firstly, it's unlikely, --- website B must know my actions,  
Secondly, we can check the referrer HttpRequest.UrlReferrer
And thirdly, of couse, set the session to expire (10 mins?)


Back to LZ's question
Our internal website was required to pass the penetration test (including CSRF)--conducted by a security company.
What we done is: check the HttpRequest.UrlReferrer, set the login session to expire. The risk may be still there but the risk level is very low.

[ 本帖最后由 典 于 2011-1-10 14:25 编辑 ]

典

原帖由 乱码 于 2011-1-10 13:40 发表


只要你del/update操作的url需要authentication，你就是安全的，至于他们login之后想做什么，那是他们自己问题，不是你的问题。

注意把这些行为和credential log一下，为以后找人算账有根据。 ...

Not really...
The issue is: some other pages can "borrow (or steal or ...)" the credntial to do leagal actions. How do we know the credential is a real credential?

[ 本帖最后由 典 于 2011-1-10 14:30 编辑 ]

乱码

原帖由 典 于 2011-1-10 15:28 发表


Not really...
The issue is: some other pages can "borrow (or steal or ...)" the credntial to do leagal actions. How do we know the credential is a real credential?

if we don't believe credential, what else should we believe

典

原帖由 乱码 于 2011-1-10 14:44 发表


if we don't believe credential, what else should we believe

As you mentioned ealier,.. with referrer....Only trust credential from my website....

乱码

原帖由 典 于 2011-1-10 16:06 发表


As you mentioned ealier,.. with referrer....Only trust credential from my website....

OK, that's a good one too, yes, referrer is valid. but I have scenarios that referrer is not always available(null instead), but if it is, it's normally regarded as good one.