Guest Anonymous Posted August 24, 2008 Share Posted August 24, 2008 Re: learning mysql_real_escape_string just need to verify. Actually I have posted the answer -- several times, but people are just too lazy to read the posts and the relevant sections in the manual, and assume that their 4 microseconds PHP knowledge is good enough for them to think up a different solution which will be rock stable under any circumstance. I'm prepared to help people, but only if they help themselves. Quote Link to comment Share on other sites More sharing options...
Zero-Affect Posted August 24, 2008 Share Posted August 24, 2008 Re: learning mysql_real_escape_string just need to verify. yeah like i said Nyna i ment no offense Quote Link to comment Share on other sites More sharing options...
Guest Anonymous Posted August 24, 2008 Share Posted August 24, 2008 Re: learning mysql_real_escape_string just need to verify. None taken -- What you have to understand with security is *why* we do something, not just how. Every single aspect has to be looked at - from your php source, the actual php source itself, the web server, it's source, the operating system and indeed its source. Then you have to look at the interaction between each of them in great detail. That's *why* it's often pointless just saying "do this", as we have no idea of what sort of platform how up-to-date it is, what extensions have been added that may compromise the system etc. That's why, all my web-based applications run on servers I've built (if not pyhsically, at least logically - ie. rebuild the *entire* operating system) -- Then I know that no outside influences may have affected the system and it's down to me and only me to ensure the safety of the application. Quote Link to comment Share on other sites More sharing options...
Zero-Affect Posted August 24, 2008 Share Posted August 24, 2008 Re: learning mysql_real_escape_string just need to verify. and you do that very well has from what i hear Quote Link to comment Share on other sites More sharing options...
Haunted Dawg Posted August 27, 2008 Share Posted August 27, 2008 Re: learning mysql_real_escape_string just need to verify. This is how i would do it... if($_POST['name']) { $name = mysql_real_escape_string(htmlentities($_POST['name'])); mysql_query("INSERT INTO db VALUES(NULL,'$name')") or die(mysql_error()); echo $name.' has been inserted into the database.'; exit; } echo '<form action="'.$_SERVER['PHP_SELF'].'" method="post"> Name: <input type="text" name="name"> <input type="submit" value="Submit"> </form>'; Quote Link to comment Share on other sites More sharing options...
Magictallguy Posted September 1, 2008 Share Posted September 1, 2008 Re: learning mysql_real_escape_string just need to verify. Looks good to me Killah :) Quote Link to comment Share on other sites More sharing options...
AlabamaHit Posted October 26, 2008 Share Posted October 26, 2008 Re: learning mysql_real_escape_string just need to verify. what about something like this? $db->query("UPDATE users SET crystals=crystals-250,cbank=0 WHERE userid=$userid"); Would this be best way? $open = sprintf("UPDATE users SET crystals = crystals - %d , cbank = %d WHERE userid = %d ", @intval(250), @intval(0), @intval($userid)); $mysql_query($open); Or this? $open = sprintf("UPDATE users SET crystals = crystals - %d , cbank = %d WHERE ((crystals >= %d) AND (userid = %d) ", @intval(250), @intval(0), @intval(250), @intval($userid)); $mysql_query($open); I used "%d" cause its a signed decimal....Is that the better way? or unsigned? with %u for numbers? Also.. its %s for strings (Words) right? Quote Link to comment Share on other sites More sharing options...
Floydian Posted October 26, 2008 Share Posted October 26, 2008 Re: learning mysql_real_escape_string just need to verify. A couple things: @intval(250), Why are you using so many error suppression operators? Read about error suppression here, if you don't know what that is -> http://us3.php.net/manual/en/language.operators.errorcontrol.php Seems unnecessary to me to use it before intval(). Why use intval at all on an integer constant? Since "250" is hard coded, it can never change, and it's already an integer. That shouldn't need any formatting. sprintf() is all about formatting a string and there's nothing to format with the "250" so plug it right into the string as is. I.e. -> $blah = sprintf('update users set money = money + %d', @intval(250) ); That is redundant in at least two ways. $blah = sprintf('update users set money = money + %d', 250 ); That is better... $blah = 'update users set money = money + 250'; And that is the best in that situation. You don't even need a sprintf function because nothing is being formatted. It's all hard coded. ------------- As for the question of whether or not to use %d instead of %u and vice versa it completely depends on the code at hand. I normally use %d. Reason being, my code almost always checks for negative numbers before I get ready to do a query. For instance, if a user types in -20000000 into a form which is intended for use in sending money from one user to another, instead of converting that number to +20000000 or 20000000 without warning to the user, it is better to relay a message to the user letting them know their "input" was out of the allowable range. You can't do that if you're using %u as the only means of dealing with negative numbers. And since I've filtered them out already by the time a query runs, I almost always use %d. I know some folks like to punish users that type in negatives by converting them to positive hoping that the user that probably attempted to find a loop hole in your program will screw themselves. However, being that we're above such useless tactics, we forgo the "punishment" approach and go for all out user friendliness instead. (That is how the big companies do things) Try sending a negative amount of cash through pay pal and see what happens. I guarantee you that they don't just convert it to positive in the hopes that it screws you up. In reference to the "punishment" A*N*A*L-ysis above, that's not directed to anyone in particular, but I think the whole idea of converting negs to positives silently is at least to a small extent motivated by the "punishment" mentality and probably also by lack of understanding in how the better way to do things works. Note: the bad word filter doesn't like A*N*A*L, so A*N*A*L-ysis is adversly affected by the filter and thus I had to compensate. ;) Quote Link to comment Share on other sites More sharing options...
AlabamaHit Posted October 26, 2008 Share Posted October 26, 2008 Re: learning mysql_real_escape_string just need to verify. Ok, so if its hard coded you dont need to use the @intval... If its a POST or GET is where i would need to use the @intval Is that basically what your saying? Quote Link to comment Share on other sites More sharing options...
Karlos Posted December 9, 2008 Share Posted December 9, 2008 Re: learning mysql_real_escape_string just need to verify. I believe he is, this post has helped me :) Thansk everyone Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.