Zeggy

Can you post your globals.php? You could also try optimizing your database so queries run faster.

Seanybob: int() and +0 both have the same effect. Not sure about performance-wise but it should be negligible.   Note that somebody could add the &mailbox=1 flag to any url and your header code will interpret that. This could lead to a vulnerability. I'd recommend leaving out the regex for strings, and let that be used on a page by page basis instead. Or rather than using a whitelist of characters, use a blacklist of characters instead. Then you can filter out the characters/strings that you are sure you do not want on ANY page. On certain pages that might need more security for strings, you can simply add to the blacklist.

sprintf can be extremely useful, as The_Past has been saying. It can be used to enforce data types when you want to concatenate variables to a string such as in queries.

No, there's no problem with redefining it, except unnecessary repetition:   $_GET['digits'] = ( ctype_digit($_GET['digits']) AND isset($_GET['digits']) ) ? $_GET['digits'] : '' ; //skip down 100+ lines function func() { global $var1, $var2 $_GET['digits'] = ( ctype_digit($_GET['digits']) AND isset($_GET['digits']) ) ? $_GET['digits'] : '' ; $ql->query("UPDATE `table` SET `column` = {$_GET['digits']} WHERE `column1` = $var1"); }   (and depending on how you sanitize the variable, it could change the contents - eg. addslashes done once in global scope and once in each function could have very annoying consequences)

Yes of course, it is not practical to secure variables like that in a real application. Every sql injection is specific to the exact query format. Every xss attack is specific to how values are filtered. And every variable is used differently on every page. If you could secure get/post variables from a global header, then your website would have to follow a very rigid structure in using url parameters and form values. Sure, it's possible, but probably not for mc codes. If you want to be able to do this, you'd need to start doing this from the very beginning of coding the website. There is nothing wrong with securing each get/post manually, in fact it's probably better. There's just no use doing it over and over again in each function you define. I've made a simple test program showing that changing $_GET inside a function makes no difference as changing it outside of a function, eg. at the top of the page: <?php //original value echo $_GET['var'], ' '; //Change $_GET in global scope $_GET['var'] = 'changed'; echo $_GET['var'], ' '; //Change $_GET in function function change() { $_GET['var'] = 'changed again!'; } change(); //call function echo $_GET['var'], ' '; ?>   If like you said, there are still sql injections happening on your page, then I'm guessing it's because the attacker is using some attack vector that you haven't considered, or you are not correctly securing the variables/queries.

I don't use mc codes so I can't really relate to your example. If it's what I think it is, then yes, you could define your get/post variables in a header file. (Although that would restrict your website in a couple of ways) What I'm saying isn't an opinion, it's a documented behaviour of PHP: http://php.net/manual/en/language.variables.superglobals.php

bluegman991: Yes, to use variables outside a function's scope you need to redefine it, pass it through as a parameter or define it with global. BUT, $_GET is a superglobal, you do not need to define that anywhere, ever. It is given a value at page load, once you change it with abs or int functions, it will STAY changed no matter the scope. What immortal described is NOT intended behaviour in PHP.   Oh, and to select specific columns in an SQL statement: SELECT `id`, `username`, `any_more_columns` FROM `players`;

Well, the mail you send needs to be sent through a mail server. You'll need to enter the mail server you want to use, and the port, etc. in php.ini. If you don't have a mail server that you can use, you could use gmail's if you've got a gmail account. I'm not sure how to set that up though. You could google it.

Did you setup your php.ini to use your SMTP server settings?

$places_to_be_secured = array('ID', 'viewforum', 'viewtopic', 'reply'); $limit = count($places_to_be_secured); for ($x = 0; $x < $limit; $x++) { $_GET[$places_to_be_secured[$x]] = abs(@intval($_GET[$places_to_be_secured[$x]])); }   Fixed that for you. I can't comment on how secure it is. As far as I can tell, it's only useful if you need these fields to be positive integers.

Dabomstew is right. Maybe what ImmortalThug did was use $_GET = abs(int($_GET)); (from seeing his last post, but maybe he just didn't bother to finish the example), in which case it would fail because $_GET is an array. Just wondering, why is sprintf useless?

Well, what do you mean, you find some things inefficient? I find that it's nice to use once you're learned how to use it properly. I do find some things annoying, like all the keyboard shortcuts. You have to be very careful what you press when you're in a terminal or curses program if you don't know what every key does yet. I've given myself many headaches by accidentally pressing Break instead of Backspace too (Break is just above backspace on my keyboard) :(

Linux is not a magical OS that helps you instantly code better or faster :) Linux just has more powerful tools for development, and these tools can speed up certain development processes, or reduce work in certain areas. But to be able to gain the benefits from these tools, you need to learn how to use them first. If you're switching from windows, it will probably seem confusing or complicated. It will take some time (or a lot of time) to learn to use these tools, so you're not likely to notice a dramatic speedup at first. As for these wonderful tools I speak of, everybody has their own preferences so I can't really tell you which ones to learn. For example, text editors. There are many powerful text editors, but they are each different in their own way. Some people prefer emacs, some prefer vim and some stick to a gui-based editor. Or IDE like eclipse. Or source code revision management for example. Central repository, or distributed? SVN or CVS? Git or Mercurial? But it all comes down to your preferences. Trying to argue emacs or vim is the better one is just starting a religious debate. :P I'd recommend you give everything a try, and take some time to learn to use them and see which ones you like. If things still don't work out you can always switch back to windows or mac. Another benefit is being able to use the terminal. Although some would call it a downside :)

Nope, now it's wrong. Stick with your original code, it's much better and it works :P

Yep, it is. md5 and sha1 are both functions that return strings... meaning that you can pass the result into the functions again, however many times you want, in whatever combinations you want.

So design your site so it fits :) There is some javascript code that you can use to stop the scrolling behaviour, and automatically have the iframe resize to the content size, making it look and behave exactly like an FBML app. (It's on the fb dev wiki if you want to read more about it)

Why not facebook iframe? FBML is far too limited, especially javascript. An iframe gives you far more control over every aspect of your fb app.

Yeah, what crimgame said. Since your image only needs to pass validation the first time you use it, you can host a valid image on your own server and use it. Once it's passed validation, you can replace the file and change the mimetype so it still executes as a php file. This is why linking to remote images is not easy to secure. It's better if you let users upload images instead. That way you can control the content of the images, and display the images in a more secure environment. It is also possible to add php code within an image file which will execute in the browser. This is usually used when images are uploaded to a server. Also, the getimagesize function is useful in most cases, but it is possible to have a valid image and also have executable code embedded, which is why checking file extensions isn't useless.

Try replacing $HTTP_POST_VARS with $_POST instead. It's deprecated in PHP 5. Also... don't store username/password in cookies.

We were both correct. You found a solution, but you still don't understand what the problem was. The problem is quite clear in the error message: "headers already sent (output started..)". From the way you fixed it, that means you already started a session and was trying to start another one, which we both said. We just couldn't give a more specific solution because we didn't have all the code to view, we only had your error message to work with. :)

It means you've already sent output before starting the session. Looking at your code, the error's probably in functions.php. Check if you're echo/printing anything, if you've already started a session, if there anything before the PHP opening tag or after, etc. Even whitespace.

The point of using hashes is so you don't need the original data. If you're storing both the hash and the plaintext, then there's no point in storing the hash. You are not gaining any security out of it.

I'm sorry for my last post, it was a stupid post.   You know what, this is something I agree with. Yes, it is not needed if you really don't want it and you think your site is secure enough. I listed using a different salt per user as just one of a number of ways to make password storing safer. Like I said in a much earlier post from this thread, there are so many ways of storing passwords in a safer way. You could very well be using a 10 character salt and be just fine with it. But there is so little to stop you from using a random salt with each user. Time spent generating the hash is negligible, and disk space usage is too, until you get huge amounts of players in which case you can certainly afford more disk space. In the end, how far you want to go with this issue depends on how willing you are to provide the best and beyond for your players. If player passwords are easily cracked, then it is your players that suffer in the first place. Of course, if your game admin control panel is using the same security techniques then your game will suffer too, in a much more direct way :P

No, stop jumping to conclusions and read the rest of that post. You know, the part before that line. All I meant by that line was, I didn't realize that was all you were arguing. Now it is clear for me what you are arguing about. And I still disagree. EDIT: Silly me.

Ouch, that hurts. I don't see any reason to reply to this comment. How about we stay on topic?  Okay, I don't use MC so I wouldn't know.  Yes, let's stop storing data because we'll be wasting disk space.  SHA512 gives a hash of 512 bits... In your scenario, the storage used for saving passwords is half a gigabyte. The salt is only a little over twice that amount of storage, assuming a fixed-width 8 bit character set encoding. With 1 million users, you can certainly afford 1.2gb diskspace.  And why not inside register.php? Are we to assume that your source code and file system as well as your database are all insecure in this hypothetical situation? In that case, I doubt any amount of hashing or salting or security could save that website. EDIT: Sorry, I wrote the above assuming there would be one hash. Of course, if you were to have a separate hash with each user, then it would be best to store them in a separate file/folder.   See, this single line has cleared up my confusion from the past two posts. All you needed was this sentence in the first post and I would know what you were arguing about.  Yes.