Jump to content
MakeWebGames

MCCodes Vulnerabilities, fixed yet?


Melkrow

Recommended Posts

Basically the issue is the following:

Some actions are pure URL based, whatever it is, like a login / logout or whatever. You could actually do more simply by passing an URL (yet as I don't know fully McCodes nor I do care about it, I didn't checked exactly what you can and what you cannot just via URL).

So imagine that you can sell something, or attack a monster or whatever just via an url like: mygame.com/attack.php?monster=10

So far, nothing dramatic, yet, if you can trigger other players to do actions they would not want to do, like drop items, reset account or whatever, you could simply "tinify" the culpit url such that instead of having mygame.com/attack.php?monster=10 you would see tinyurl.com/kjhsd

Yet post somewhere this tinyurl with some message like: check what did my cat yesterday, and here you are people will check it... without noticing it may do some harm. Doesn't matter if the url will be directly clickable or not, it could also be posted somewhere else, on another forum, or even sent via email, so you can't control the "diffusion" of this tinyurl, nor people can know what exactly will be the action of the url.

Now if you believe your site is secure because you added some hidden fields on some of the strategic pages, I'm pretty sure you can still trigger annoying things, also, even POST actions are not secure as you could simply go through some middle site to trigger it.

Link to comment
Share on other sites

Basically the issue is the following:

Some actions are pure URL based, whatever it is, like a login / logout or whatever. You could actually do more simply by passing an URL (yet as I don't know fully McCodes nor I do care about it, I didn't checked exactly what you can and what you cannot just via URL).

So imagine that you can sell something, or attack a monster or whatever just via an url like: mygame.com/attack.php?monster=10

So far, nothing dramatic, yet, if you can trigger other players to do actions they would not want to do, like drop items, reset account or whatever, you could simply "tinify" the culpit url such that instead of having mygame.com/attack.php?monster=10 you would see tinyurl.com/kjhsd

Yet post somewhere this tinyurl with some message like: check what did my cat yesterday, and here you are people will check it... without noticing it may do some harm. Doesn't matter if the url will be directly clickable or not, it could also be posted somewhere else, on another forum, or even sent via email, so you can't control the "diffusion" of this tinyurl, nor people can know what exactly will be the action of the url.

Now if you believe your site is secure because you added some hidden fields on some of the strategic pages, I'm pretty sure you can still trigger annoying things, also, even POST actions are not secure as you could simply go through some middle site to trigger it.

Perhaps use some sort of token before such actions are taken. Pardon the lingo, but isn't this a case of csrf?

Link to comment
Share on other sites

RFC2616 makes it pretty simple in suggesting that a GET operation should be considered ""safe"" in that it does not change data whereas a POST operation may change data. Bearing that in mind, the fix should be apparent without resorting to ugly-assed urls which are often difficult to bookmark and/or remember.
Link to comment
Share on other sites

RFC2616 makes it pretty simple in suggesting that a GET operation should be considered ""safe"" in that it does not change data whereas a POST operation may change data. Bearing that in mind, the fix should be apparent without resorting to ugly-assed urls which are often difficult to bookmark and/or remember.

With them being difficult to bookmark and/or remember shouldn't make a difference in game, in my opinion, as you have the links to click in game, as it's part of the game.

Link to comment
Share on other sites

And octarine, you can as well trigger the same issues with a POST, you simply need a middle page with a small form and some hidden fields, a single line of JS and here you are the browser will jump on this page, post the values you want to the game, as the game authentication works via cookies (session or other) the cookie will be sent and for the game it will react as a normal user wish... which is not. So unless you add an hidden field on each forms with the token you will have exactly the same security issue and as far as I'm aware only some forms are protected (inside McCodes), not all, way not all.

Link to comment
Share on other sites

And octarine, you can as well trigger the same issues with a POST, you simply need a middle page with a small form and some hidden fields, a single line of JS and here you are the browser will jump on this page, post the values you want to the game, as the game authentication works via cookies (session or other) the cookie will be sent and for the game it will react as a normal user wish... which is not. So unless you add an hidden field on each forms with the token you will have exactly the same security issue and as far as I'm aware only some forms are protected (inside McCodes), not all, way not all.

Hardly any, I could count them on one hand.

Link to comment
Share on other sites

Shows that what I reported is not so useless ;)

BTW... oddly enough today CB said in the chat that he forget to publish a patch... odd I had to make such a theater for it, and yet I will count the days before we really see any patch... as I'm still waiting in my mailbox his "extremely easy to code" fix.

Link to comment
Share on other sites

How is it you dont publish a patch for your own software.

I know they have little interest in the Mcc project clearly by their lack of action and involvement in the community but to fix a major security flaw and then just not release it is not only lazy but disrespectful to those that have paid licence fees.

Thats IF they have fixed it...or its just a hahahah yes fixed that sorry forgot to release it (best go see if i can fix it quick)

Link to comment
Share on other sites

Octarine: never said it's difficult, beside it's a bit harder to make it so that the ENGINE itself does it alone and not the programmer on each and every form and page. I simply stated that in the current state you can't really say McCodes is safe and as you are the first one to point out security issues, I wonder why you cover them somehow for such issue.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...