CSRF Token - Security - Are we vulnerable?

[Aventro]

I have been scanning quickly through Ezrpg folder and could not find any token or anything that hint me on the security against CSRF. Does this mean EZRPG Project is vulnerable to CSRF?

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

[Spudinski]

Not really.

It's been some time since I've worked with ezRPG, but as far as I can remember, there's no need to protect against it with ezRPG.

The web has changed a lot since CSRF was a "big thing", and tactics used with CSRF attacks are becoming outdated.

I personally don't protect against CSRF, mainly because I don't use blatantly insecure methods of authentication.

I don't think ezRPG has flaws such as that either.

[Aventro]

Not really.

It's been some time since I've worked with ezRPG, but as far as I can remember, there's no need to protect against it with ezRPG.

The web has changed a lot since CSRF was a "big thing", and tactics used with CSRF attacks are becoming outdated.

I personally don't protect against CSRF, mainly because I don't use blatantly insecure methods of authentication.

I don't think ezRPG has flaws such as that either.

You don't make any sense. Just because the vulnerability is not a "big thing" doesn't mean it's not being used any more. They may be "out dated" but they are still possible to do. I mean If there is no big thingy how come CodeIgniter, cakephp, invisionpower and all other 'bigger' projects do take this under consideration?

I would like you to consider having a look at the following articles:

http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/miscellaneous-articles/protecting-against-csrf-attacks-r749

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html

http://shiflett.org/articles/cross-site-request-forgeries

[Spudinski]

You don't make any sense. Just because the vulnerability is not a "big thing" doesn't mean it's not being used any more. They may be "out dated" but they are still possible to do. I mean If there is no big thingy how come CodeIgniter, cakephp, invisionpower and all other 'bigger' projects do take this under consideration?

I would like you to consider having a look at the following articles:

http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/miscellaneous-articles/protecting-against-csrf-attacks-r749

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html

http://shiflett.org/articles/cross-site-request-forgeries

Your articles, while amusing that you would post them, are not of importance to me.

Furthermore, the "frameworks" (with the exception being IP.x) are all just that, frameworks.

They are built to suit most, if not every, scenario possible. It would be rather annoying not to have the functionality when needed.

CSRF has many aspects to it, and doesn't just fall at risk on the application layer.

That being said, one would wonder why protocols on the session layer wouldn't fall under suspicion to this as well.

Actually they do as well, it's just different methods employed. But, some protocols are designed "around" this.

Applications can also be designed "around" this issue - a simple example is to use only SESSIONs, with a minor alteration or two to PHP's configuration file.

I'm confident that you understand the concepts of CSRF, but how it is carried out requires deeper knowledge about the relationship between multiple applications on a system.

I'd be more than willing to explain further, if need be.

[bluegman991]

There are 2 reasons I can think of for a someone to do a csrf attack on text rpg game. One is to bot their account. The other is to trick another user into requesting a page on your site (from another site) while they are logged in. (e.g. to withdrawl and send all money to someone, attack stronger player, etc...)

If they are smart enough to make a bot then they are smart enough to get around a csrf key plainly put in the html. So this will not protect against someone botting their self.

Leaving you very vulnerable to the 2nd reason. You can check the "$_SERVER['HTTP_REFERRER']" variable as a quick replacement. However this value is set in the header and can easily be changed.

Unless you are using another method to check for csrf's, then you are leaving anyone who uses your site vulnerable including players and staff. And when your users are vulnerable then so is your site. But the last thing you would wan't is the person doing the csrf attack to get wind of the link to make their self staff.

Edited May 18, 2012 by bluegman991

[Aventro]

Your articles, while amusing that you would post them, are not of importance to me.

Furthermore, the "frameworks" (with the exception being IP.x) are all just that, frameworks.

They are built to suit most, if not every, scenario possible. It would be rather annoying not to have the functionality when needed.

CSRF has many aspects to it, and doesn't just fall at risk on the application layer.

That being said, one would wonder why protocols on the session layer wouldn't fall under suspicion to this as well.

Actually they do as well, it's just different methods employed. But, some protocols are designed "around" this.

Applications can also be designed "around" this issue - a simple example is to use only SESSIONs, with a minor alteration or two to PHP's configuration file.

I'm confident that you understand the concepts of CSRF, but how it is carried out requires deeper knowledge about the relationship between multiple applications on a system.

I'd be more than willing to explain further, if need be.

I guess you have a point. However I would not rely on designing around the issue but instead just deal with it. The implementation isn't really hard. I am rather depending on a solution on the problem that have been deeply discussed around and is well used. But we all do it in different ways, if you are happy with your solution around the problem and it is prevented well then there's nothing to argue about.

 

I believe CSRF checks (in html) is a rather weak layer of security because they key lies right in the html and only needs to be parsed out.

Please develop your answer, I am not quite sure what you mean.

[rulerofzu]

Whilst i love a discussion. The answer your looking for is no.

[JakeB]

We actually did have plans to implement a CSRF key into ezRPG, but honestly we never got around to it. I could make an update with one if it is a wanted 'feature'.

[Spudinski]

We actually did have plans to implement a CSRF key into ezRPG, but honestly we never got around to it. I could make an update with one if it is a wanted 'feature'.

As I've said, there's no need for it in ezRPG.

[Aventro]

I would actually not mind a CSRF token, as I can see there are no disadvantages having it, it's no big deal to implement it, and it does improve the security to your site.

[sniko]

I wise man once said "Better be safe than sorry."

Does that apply in this situation....?

[sniko]

*Puts on johnny*

I think it may. Step back, I'm going in boys!

Oh, you do make me chuckle!

[sniko]

And that was "Going in, boys" and not technically going into boys :o

Mhmmm, sure it does :D

[JakeB]

As I've said, there's no need for it in ezRPG.

I completely agree, I suppose it would be more of a peace of mind thing for game owners knowing that there is a little extra security in place.

[Spudinski]

I completely agree, I suppose it would be more of a peace of mind thing for game owners knowing that there is a little extra security in place.

Yea, but that's like replacing all the windows in a house with solid blocks of steel, just for "extra" security.

[Aventro]

Yea, but that's like replacing all the windows in a house with solid blocks of steel, just for "extra" security.

It would make more sense If you did your comparison when both the House and your site have "guests". With your logic, I believe you can see a lot of more problems with not for example locking in some valuable things when your hosting a party with people you don't know attending.

[Spudinski]

It would make more sense If you did your comparison when both the House and your site have "guests". With your logic, I believe you can see a lot of more problems with not for example locking in some valuable things when your hosting a party with people you don't know attending.

Well, ok. It's like having a Prison then.

You lock up the whole place, but the thing you don't bargain for is the guests.

You put up bars and cells up to keep certain people at bay, but they all still get fucked.

And that's all people that you do know.

[Aventro]

Well, ok. It's like having a Prison then.

You lock up the whole place, but the thing you don't bargain for is the guests.

You put up bars and cells up to keep certain people at bay, but they all still get fucked.

And that's all people that you do know.

Lol. xD

 

I can see we are rolling of the topic.

[JakeB]

Well, ok. It's like having a Prison then.

You lock up the whole place, but the thing you don't bargain for is the guests.

You put up bars and cells up to keep certain people at bay, but they all still get fucked.

And that's all people that you do know.

But in all reality, is adding an extra small string to the end of certain urls going to really affect people that badly? It's not like they have to actually type it out every time they want to visit that page

[Spudinski]

But in all reality, is adding an extra small string to the end of certain urls going to really affect people that badly? It's not like they have to actually type it out every time they want to visit that page

Depends weather you're talking about the PHPSESID...

If so, yes, it is really going to affect everyone.

A stupid example is when they bookmark that page, when they reload the website from that bookmark with the SESID appended, it would force a re-login(depending on what one has implemented).

If you do CSRF, it needs to be done communally.

Here's an example in lay man's terms(just because I'm lazy):

The user visits the site,

- A session_id is generated

- The session_id is stored via use of a hashing algorithm along with an identifiable ID of the user.

The user visits again,

- The cookie previously generated is now retrieved.

- PHP's session relating to that user is compared the the hash generated before.

+ If it matches, create a new session ID.

+ If not, automatically delete the data and initiate a new session.

Now, if user B tries to use user A's session:

- The cookie is validated to the session_id PHP holds for this user.

+ If it matches, it's deemed that everything is in order.

+ If not, it's deemed that this is not the same user as before.

* This can also mean the user has had 15 minutes(depending on session.max_lifetime) of inactivity, and would need to re-login.

Note: the above is an example, do not actually use/build a system based on this.

It's a very basic example, but it set sight to my point if I'm correct.

[Aventro]

Why would you place the token in the url when you simply can place it in a hidden-input field on the form?