Spudinski

Mind using ereg on system level? Vs. PHP's ctype_x? PHP has made an implementation of regex into their application, and under PHP regex is not yet complete. You are testing things that are beyond PHP intended capabilities of regex, you are filtering about a Gb of data. If I could, I would suggest that you port the regex code to shell(ereg) for valid inquiry of actual regex results.

Well that we know... :P

I'm sorry, but that statement makes no sense to me. Once a programmer knows how to use Regex, they can take that knowledge and apply it mostly anywhere. Also, it's much quicker. On a system's standpoint, I can find a single string in a thousand files in an instant. On a developers standpoint, I can limit, reform and validate any datatype with less than three lines of code.

Is it better to use native PHP functions? No, Regex is much more powerful than any of those functions mentioned. What you can do however, is prepare functions that switches between the data type you want to filter. Which you can then implement as an abstract class, and only use when needed. Native PHP functions, like htmlentities(), are good, but they don't offer much flexibility towards what you want to filter.

Well, even though security is a complex field, it's good to keep it as simple as possible. XSS is one of the easiest things to secure a website from, but the techniques that you mention are lengthy and not needed at all. You say you only want to allow integers? Yet, you are attempting to convert mixed data types to integers. If you only want to ALLOW integers from input into processing, I'd suggest you filter out the rest of the data types. I prefer pattern matching. Here's a simple Regex pattern that only allows for integers(note that it does NOT allow for floats): An implementation of regex matching into a standard PHP web-form: <?php if (!empty($_POST['submit'])) { $error = array(); if (empty($_POST['data'])) $error[] = 'Fill in all fields'; elseif (count(preg_match('^[0-9]$', $_POST['data'], $matches)) <= 1) $error[] = 'Invalid data type'; else { $data = $matches[0]; // valid data, integer { ... use data ... } } ?> The problem is with you methods is that although it is secure, it's neither optimized or usable. A user may just accidentally type a character, and their input is nullified to 1(any string converted to int equals 1).

From the login page.

It's commercially licensed, so I can't say.

You guys are getting off-topic. Programming is vague, but many languages conform to a set of rules. I'd suggest general boards created towards the theory of programming, like implementations, security, design, etc. And when I say theory, I mean discussion of topics, eg. Implementing a security mechanism to detect weak passwords. Much like theoretical physics, or not.

Maybe not crucial, but a bug none the less. While logging in, when you come to the page that redirects you: {1} was always the username.

Finally man... Congrats.

True, but each script has to be evaluated for it's input and output, and optionally it's processing functions. The server is another part in my opinion, one person might just install an IDS and say it's secure enough for a web-server while others may consider all applications individually(Such as the OP with PHP). With PHP however, one can never reach pure authenticity since the "web"-applications used are public.

I don't see why everyone is so diligent to raise attention to the price, because it's not a lot. It's a moderate price. Let's take for instance any other job: [(scripts to be secured * 0.25) * flat hour rate]. Assuming a developer takes an average +- 15 minutes per script, and doesn't go over the DB, etc. A basic hourly rate is 40-120 for someone capable of doing this, so let's take the minimum of 40USD. P = (scripts to be secured * 0.25) * flat hour rate P = (50 * 0.25) * 40 P = 12.5 * 40 P = 500

runthis recently posted a mod about this, I'm sure he could do it.

Ok, ok, calm down. I'm just interested in how it's accomplished, but I will wait.

@Octarine: Crippling the server is a strong word. I've not seen a bug in MCCodes Lite -> 2.0 that is that severe on a factory setup server. Exploiting mysql queries to gain entrance into the database or extract data, sure, but it's not exactly crippling a server.   And if you knew anything about the history of Linux you would know why.

PHP isn't high level security.

Not really. I've made my share of money from MCCode mods, although it is nothing compared to actual web development work, it's still something. For young programmers it's an excellent way to gain experience in the "i give this, you do that" market which is web development. Just don't expect to make a lot. There are huge gaps in this MCCodes market, the biggest being security. But I wouldn't advise anyone to go into it, unless you are very experienced and want to waste your time on the simpler things in life.

MCCodes officially started back in early 2006. Created by a kid aged 15, and going by the alias of Dabomstew. The early stages of development were quick paced, and popularity hit sky-high by the time version 2 of the product came into being. Many people have different ways from which they became aware of MCCodes, and many people have different experiences with it. I would like for people to share their stories of their experience with MCCodes, for future generations and prospective owners. Whether you love, or hate, MCCodes I want to you share your opinion on Amplicate. Just keep it moderately clean and simple. [TABLE=width: 500, align: center] [TR] [TD=align: center]I [ATTACH=CONFIG]231[/ATTACH] MCCodes[/TD] [TD=align: center]I [ATTACH=CONFIG]230[/ATTACH] MCCodes[/TD] [/TR] [/TABLE] I'd love to see everyone's opinions, S.

Sure, but there's just one problem... Everybody is already making theirs.

Yes. it is.

This is a suggestion I have. MySQL, as we all know, isn't the only DBMS out there. I would like to see a section called "Databases", which would include MariaDB and SQLite, among others. I see no reason why they aren't there... they all have their perks.

Well, you need to find out where the second request is being sent from. My suspicion would be an ajax request being sent to a wrong location, a.k.a. the current page. Have a look at your javascript, and try using Bug[something]er which is a Firefox plugin. An alternative is Opera's Dragonfly, which is in my opinion just as good. Chrome has a javascript console as well.

@Paul, it is over - you lost. But whether you can continue with securing MCC is another part of it. I know you are a very talented programmer, I've seen your work before. I don't agree with people critisiing the way they do, but as Octarine said, there is no other way to communicate with the MCC developers. I myself have tried to contact ColdBlooded on a few occasions, and the only time he ever replied was when it was about something entirely different than the code. They aren't very responsive, and a approach towards fixing that aspect of MCCodes will benefit them. Octa made a good suggestion for a solution, a bug tracker.

You are just ignorant. @Paul: If this was because of your work, then you are to blame. And then stop being full of yourself and just admit defeat this once. Other websites with your code is also at risk then, and it could come down to you if they get hacked. Find the problem, and fix it man.

I mean the table schema. It is possible that the mysql service is having conflict whilst converting data types, but with that amount of users it shouldn't slow down at all. Try passing the timestamp and user id as integers to the database, rather than strings(as they are being sent currently).