Need a coder who is good at securing

[Play Mobo Entertainment]

I need a good coder who can secure around 50 files from Mccodes V2.5 please inbox with price per file and est delivery date.

I need to secure the POST/GET to stop sql injections and such.

[Zettieee]

Wouldn't it more beneficial to learn how to secure them yourself?

If it's a number var then this will do just fine:

$number = abs(intval($_POST['number']));

Otherwise this will do just fine:

$something = mysql_real_escape_string($something);

This is VERY basic but should work for the most part.

GL

[Play Mobo Entertainment]

I know how to secure my self but i can not secure all files as quick by myself. Therefore i need 50 files done and the rest i am doing them. The game is live and therefore needs to be secured asap without having to take the game down.

[Alan]

If it's a number var then this will do just fine:

$number = abs(intval($_POST['number']));

I can't help but wonder what part of that is related to security (outside of the possible information disclosure exploit). Not only is it bad practice, it is making a number of key errors which are easy to circumvent with careful programming.

if (!array_key_exists('number', $_POST) || !ctype_digit($_POST['number'])) {
// Assuming you had a form with an <input name="number" ...> field,
// then reaching here means that somebody has bypassed the usual
// submission method.

// Respond with a 400 but no clues.
header('HTTP/1.1 400 Bad Request');
exit;
}

// At this point abs() is pointless as the value contains ONLY 0-9

// Question.. is this safe? (The answer btw is no)
$value = intval($_POST['number']);

// Or how about this?
$value = (int)$value;

// But do you actually need it to be an integer? After all, MySQL
// as with HTTP operates with strings.

[lucky3809]

I can't help but wonder what part of that is related to security (outside of the possible information disclosure exploit). Not only is it bad practice, it is making a number of key errors which are easy to circumvent with careful programming.

if (!array_key_exists('number', $_POST) || !ctype_digit($_POST['number'])) {
// Assuming you had a form with an <input name="number" ...> field,
// then reaching here means that somebody has bypassed the usual
// submission method.

// Respond with a 400 but no clues.
header('HTTP/1.1 400 Bad Request');
exit;
}

// At this point abs() is pointless as the value contains ONLY 0-9

// Question.. is this safe? (The answer btw is no)
$value = intval($_POST['number']);

// Or how about this?
$value = (int)$value;

// But do you actually need it to be an integer? After all, MySQL
// as with HTTP operates with strings.

So with your logic you can hack abs(intval()) ??? If so please go further it stating how so...Your bringing unnecessary security measure to life here... Your making it sound harder than what it basically is, there is numerous ways to secure a script, but their is simpler form such abs(intval()) that does the job as well as those longer security functions...

Also managing your database correctly is a key part in security, such using the correct integer types...This forum has argued over and over about security, the point is NOTHING is secured 100% maybe 99.9% but never 100!!

[Alan]

I don't believe I used the word "hack", I pointed out that failure to correctly identify the type of an incoming variable results in an information disclosure exploit - which were you to use something like phpIDS would be quickly spotted.

I also stated that converting to an integer is not safe using a typecast or explicit conversion function. By not safe as surely somebody with your skills would attest to, it is not architecture agnostic, nor can it handle large numbers. I don't see either of those points as being unnecessarily harder than what it is required.

Seems to me that any sensible programmer would look at the above and write some sort of small wrapper to encapsulate all the different types of data with range checking that they are liable to encounter resulting in an altogether more efficient, architecture agnostic and secure mechanism. Of course, if you look back to before even your time here, you will find those very points alongside stable working code however if you wish to belabour the point that abs(intval(..)) is superior, that is of course within your rights.

If these forums are meant to assist people with lightweight projects from gaming onwards, then isn't it better to occasionally think outside the McCodes ""security"" modal, and try to improve peoples skills rather than waste time defending outdated methods that would or at least should earn a slap around the head for carelessness?

[SRB]

So with your logic you can hack abs(intval()) ??? If so please go further it stating how so...Your bringing unnecessary security measure to life here... Your making it sound harder than what it basically is, there is numerous ways to secure a script, but their is simpler form such abs(intval()) that does the job as well as those longer security functions...

Also managing your database correctly is a key part in security, such using the correct integer types...This forum has argued over and over about security, the point is NOTHING is secured 100% maybe 99.9% but never 100!!

Seriously? Just because you don't understand it and believe the logic behind your own creation is nothing less than the holy grail of code, doesn't mean you are right.

For MC code, your logic probably slides right in and wouldn't be noticed.

But this isn't a crime scene and we don't really want to just slip in and out without notice, do we?

I can only assume by your... flawed... argument, that you have no experience in commercial development? Good luck with your mc-code-style-code that you apparently love.

One day, I wish you success in moving forward away from what you know, to better logic, understanding and skill.

[KyleMassacre]

I don't want to start a war up on me but why not something like this:

$numberVar = $_POST['number'] + 0;

anything other than an integer or float would return "0".

Maybe the OP needs negative numbers or a float so if the value is less than/equal to 0 then something went wrong

[Alan]

anything other than an integer or float would return "0".

Sure about that?

No war needed; it's a legitimate question.

Assume if you will that $_POST['number'] is a string; with basic checks your expression returns either the number, or 0 (zero is not really ideal here, however that complexity is probably left for elsewhere).

But what happens if some enterprising "hacker" (for want of a better term) injects an array here...?

PHP Fatal error:  Unsupported operand types in /var/www/vhosts/alantest/httpdocs/test.php on line #

*THAT* is a perfect bit of information disclosure; from that I know the path to the document root, I have a good idea that the local username is (in this case) alantest though that is hosting dependent etc. It also gives me a clue to the version of PHP in use and indeed to the type of server setup.

The point here is that you *need* to check the type of data coming in from GET/POST/COOKIE structures before considering that they actually contain otherwise it is possible to give a vital clues out that can eventually compromise your system.

Think "well I can't bothered to do that"? Fair enough, go the old fashioned way, forget at type checking, range checking etc. But if you ask me for assistance, the answer will be no. There are people here who are perfectly capable of helping you out but I'm not one of them; I'm simply not interested. The so called pen-testers that occasionally pop-up here seldom spot things like this as they often rely on programs written by people with no understanding of the language or the protocol itself. Those how profess to understand the problem, seldom understand it when it is rephrased; for example (and referencing this particular problem) intval/cast to int fails differently on 32/64 bit machines; which may seem obvious, but there are remarkably a large number of functions that perform differently between the two. This has major headaches between development and production systems and has been known to cause problems when people run code in distributed cloud systems - something thankfully I suspect is above the bar for most here, but nevertheless something that should be taken into consideration.

However if you think "okay, I think I can make that work but can you check"? I'll be more than happy to run through it with you and point out any omissions. That's not to say that what I write is perfect; far from it; however unlike far too many people here I've actually read the manual, I understand the protocol itself and I take the time to try and improve upon it as the language itself grows. Long gone (hopefully) are the days of such posts as the hilarious "How to secure your script from all known exploits", yet people still fail to understand the basics of the language.

Look at the protocol definition; it essentially declares that all GET/POST (and COOKIE) data is string, however PHP mangles this in certain cases to produce arrays; given everything that is coming in through those vectors is therefore a string or an array, how do you go about ensuring that the data is what you expected?

[lucky3809]

Where does it state any where that abs(intval()) is an mccode security?

abs(intval()) can be used on ANY script not just mccodes, and for your info I do not use mccodes.

However I rather use basics that get the job done just as well as other functions that are longer in coding... It's really simple to secure a page... I still have yet had anyone hack the website successfully, that I have done for others, so that tells me that I am doing it correctly, despite your opinion on abs(intval()) or mysqli_real_escape_string() ... They work.

[Seker]

something thankfully I suspect is above the bar for most here

The pretension you exude garners a similar feeling to "cooties."