Help Securing

[eboy23]

Im learning to code and ive read that mccodes isnt secure so i was wondering if i could get a list of things that need to be secured and maybe links if there is already posts about it. This would really help me alot.

[CJ - Twitch]

First things first is secure your header.php. Then if your using MCC V2 secure the forums. :) You may also wan't to secure crystal market, item market and I would personally secure mailbox. I have forgotten how many mails I have had that have made me change some user in to a admin.

[Analog]

Secure every file!

[CJ - Twitch]

You don't need to secure explore.php. :P

[Guest Drizzle]

Depends how your explore is set up. Some custom ones need securing.

[Zero-Affect]

i'd say on generic your best editing all 126 files but 50 minimum is moderate security.

[mp]17[/mp]

[CJ - Twitch]

TBH those 127 files could be turned into 80ish.

[Zero-Affect]

ah wow your correct 127 not 126 and yes it could be dropped down to about 80.

[eboy23]

im talking about like what things should i secure like what hacks and stuff??

[seanybob]

For the record, I disagree with those above.

You should be securing about 3 files. Header.php, register.php, and login.php. I'd probably secure mailboxes and forums separately, so that may bring the total up to 5.

You're all doing it the hard way. ;)

[Jordan Palmer]

For the record, I disagree with those above.

You should be securing about 3 files. Header.php, register.php, and login.php. I'd probably secure mailboxes and forums separately, so that may bring the total up to 5.

You're all doing it the hard way. ;)

No, were doing it a way which make's sure that everything on every page is secured, I don't care how your way work's but all i'll say is, securing every page in my eyes is needed

[Lithium]

No, were doing it a way which make's sure that everything on every page is secured, I don't care how your way work's but all i'll say is, securing every page in my eyes is needed

Register... avoiding malicious input from start!

Login... avoiding malicious input from getting into sessions, ingame.

Header... the file is called upon every single request making it main way to lock every single down call...

What else can you secure that hasn't been already checked?

[Zero-Affect]

I'm sure not even header will fully secure global variables i mean yes super globals could be secured but not always the best solutions work via sanitising them in header. This maybe my personal persona though but even stuff like display picture or forum avatar use different ways of sanitising.

[Joshua]

I'm sure not even header will fully secure global variables i mean yes super globals could be secured but not always the best solutions work via sanitising them in header. This maybe my personal persona though but even stuff like display picture or forum avatar use different ways of sanitising.

^

 

agreed

I would just love to see how to secure the output on viewuser and player_report using just header.php ^_-

Not to mention, if you "did" secure via header alone, you would have to go through every file anywho and get Every single $_POST/$_GET variable of diff varieties as some need diff securing

simply using abs((int) or ctype digit will bug those that are strings and vice versa, even using a foreach type arguement some "output" need to be differant and vice versa.

it's better to secure the files the "hard" way as it's the "proper" way and you can rest a little safer.

I'd never suggest just securing header/register.php

As for login..why? Secure authenticate leave login alone, it's has no globals or anything included on the majority of games, it all goes via authenticate :p

[seanybob]

I'm sure not even header will fully secure global variables i mean yes super globals could be secured but not always the best solutions work via sanitising them in header. This maybe my personal persona though but even stuff like display picture or forum avatar use different ways of sanitising.

And, for those <10 inputs in game that require a different method of sanitizing, you could set a flag on that page. Simple. These include, as I started mentioning before but didn't make a full list, profile signatures, mailboxes, and forums.

 

I would just love to see how to secure the output on viewuser and player_report using just header.php ^_-

That is actually quite easy. The output was already secured. Why? Because we secured the INPUT, when it was received, as it should have been - which can easily be done through header.

 

Not to mention, if you "did" secure via header alone, you would have to go through every file anywho and get Every single $_POST/$_GET variable of diff varieties as some need diff securing

Actually, no. In McCodes, there are three types of input. Numbers, strings consisting of just a-zA-Z0-9, and more complex strings - and the more complex strings I mentioned above (forums, mailboxes, etc.).

 

simply using abs((int) or ctype digit will bug those that are strings and vice versa, even using a foreach type arguement some "output" need to be differant and vice versa.

Yes, using many of the securing methods you guys use on here would cause problems if you used them in header. You'd have to be a bit more creative.

 

it's better to secure the files the "hard" way as it's the "proper" way and you can rest a little safer.

If you have an excessive amount of time on your hands, and are getting paid based on how 'hard' your project is, then yes, you're absolutely correct. However, if you're looking to advance your understanding in the Computer Sciences in general (and specifically algorithms) I disagree entirely. If I were to do a binary search on 100 numbers, I could go through and make 100 if statements, checking to see if the number I'm searching for is a specific number, 1-100. Or... I could use a while loop with 1 if/else statement, and get the job done in about 3 lines of coding.

 

I'd never suggest just securing header/register.php

As for login..why? Secure authenticate leave login alone, it's has no globals or anything included on the majority of games, it all goes via authenticate :p

Actually, you are correct here. I forgot that the default McCodes separates login and authenticate - in that case, yes, it would be authenticate.

 

All in all, you guys are decent programmers. You know more than a lot of the people I work with do. Except, having learned from and never (ok, rarely - there are a few) seeming to move beyond McCodes programming, you all fail at algorithms, and prefer to 'brute force' program instead.

 

(Also, I'd just like to note that here I'm talking about securing inputs in general. Making sure people don't access information that is not theirs [i.e. changing the message ID on mailbox to view someone else's messages] is something I'd just assume people would do in their code. I have to wonder if you guys secure that sort of thing too when you go through the 126 [or however many] files of McCodes.)

[Joshua]

Not to beat a dead horse...

Ok you secure all input on preferances and use header security to check the following

that it's a .gif.png.jpg image

 

So they use htaccess to change .gif to .php

Now how would you secure that in header?

it's the viewuser output.

The only way i've seen to secure it Other than "the best way simply upload links not offsite urls" is to use getimagesize which is slow to say the least

 

As for moving off away from mccodes, i'm actually venturing into the GL engine as it's nice.

[seanybob]

Not to beat a dead horse...

Ok you secure all input on preferances

Ok.

use header security to check the following

that it's a .gif.png.jpg image

Indeed, if it's hosted on another server (say, their server) you'd have to worry about that.

However, you'll notice all major sites immediately upload the image to their own servers. You may say that's just because they have the space to - but I'd say the focus is more on the fact that they would prefer not to rely on ANY other site but their own to maintain security.

That is what I would do. I'd verify that the file was an image, and store a local copy of it on my server. I would consider setting up some complex regex to allow 'possibly' one off-site image storing service like photobucket (which would get rid of your htaccess problem).

Uploading images to your server though would have it's own special security in place, and I would not take care of that in header.php, but would do that separately.

 

As for moving off away from mccodes, i'm actually venturing into the GL engine as it's nice.

Good to hear! I'd also suggest (if you haven't already) getting deeply involved in javascript (and specifically jquery and ajax). That, combined with php, is where the future of the web is at.

[Joshua]

Good to hear! I'd also suggest (if you haven't already) getting deeply involved in javascript (and specifically jquery and ajax). That, combined with php, is where the future of the web is at.

 

I'm reading up on all 3 although it takes time

 

My goal is in the next 2 years have Ajax, Jquery, PHP, Javascript down Pat.

Then I'll spend the rest of my life perfecting what I know

I'd like to keep my areas focused on a few languages and master them rather than know several and just be "decent" if that makes sense.

 

As for uploading an image aye, that's what I was referring to when I said "other than uploading images"

But again, you wouldnt secure that through header either way :p

So which ever way you choose you would avoid header security.

it's just personal preferance to secure individual files I suppose, there's always someone out there better looking for loopholes and if you dedicate the time on each file and "make sure" the chances are a lot less likely they will find one rather than just slapping in some header protection :P

[Zero-Affect]

So they use htaccess to change .gif to .php

wonder who brought that to peoples attentions... lol

 

it's just personal preferance to secure individual files I suppose, there's always someone out there better looking for loopholes and if you dedicate the time on each file and "make sure" the chances are a lot less likely they will find one rather than just slapping in some header protection

You do have a point there.

 

Good to hear! I'd also suggest (if you haven't already) getting deeply involved in javascript (and specifically jquery and ajax). That, combined with php, is where the future of the web is at.

you do have a valid point there JS/Ajax is the future.

[Nicholas]

ah wow your correct 127 not 126 and yes it could be dropped down to about 80.

actually you can make all 127 files into like 10 lol

index.php?action=jail

index.php?action=hospital

index.php?action=explore

so on... just put all the information into a function lol.

[Zero-Affect]

i find it best to use a include when doing something like that which leaves the files there but makes it look like it's all in one file (think alot of people will agree it's better). index?function=mail would be mailbox.php really simple i will be using something along them lines on CrimGame

[Joshua]

I will agree there, it makes it a lot cleaner.

[Guest Drizzle]

Shouldnt we be teaching how to secure in general, instead of just mccodes?

[Zero-Affect]

give us a example...

[Jordan Palmer]

All in all, you guys are decent programmers. You know more than a lot of the people I work with do. Except, having learned from and never (ok, rarely - there are a few) seeming to move beyond McCodes programming, you all fail at algorithms, and prefer to 'brute force' program instead.

What make's you think that we don't move beyond MCCodes?

 

I've worked with alot off engine's. I do like working with mccodes but I've worked with quite a lot off engine's, Including Horizon. I don't there is many ''decent'' programmers which base there life on MCCodes anymore to be quite frank