Securing $_POST

[SRB]

Since the OP asked about security and then posted code for INPUT into the database, you can only assume your post was in relation, no?

[rockwood]

Surely you did not write that. And did you bother to check if it adapts to current mccode without changing all the CODE? Or bother to adapt the class to fit in mccode?

1. The MCC db class not looking enough as per my view so i added as suggestion.

2. for use have to recode every query and lots of changes. and i tested this is working 100% perfectly

[HauntedDawg]

1. The MCC db class not looking enough as per my view so i added as suggestion.

2. for use have to recode every query and lots of changes. and i tested this is working 100% perfectly

Sorry, but i doubt your website is working 100% perfectly using that class.

Also, whats the point of recoding the entire engine, when the class could be recoded to suit? I believe Nyna awhile back done this, and prevented 80% of hacks without touching mccodes core code!

[jcvenom]

Sorry, but i doubt your website is working 100% perfectly using that class.

Also, whats the point of recoding the entire engine, when the class could be recoded to suit? I believe Nyna awhile back done this, and prevented 80% of hacks without touching mccodes core code!

well said there is no need of changing the as haunted dawg said all i would do is secure the header and globals or build the two into eachother simple

[rockwood]

well said there is no need of changing the as haunted dawg said all i would do is secure the header and globals or build the two into eachother simple

are you sure about this ??

Sorry, but i doubt your website is working 100% perfectly using that class.

Also, whats the point of recoding the entire engine, when the class could be recoded to suit? I believe Nyna awhile back done this, and prevented 80% of hacks without touching mccodes core code!

please Compare both db classes

[Dominion]

Sorry, but i doubt your website is working 100% perfectly using that class.

Also, whats the point of recoding the entire engine, when the class could be recoded to suit? I believe Nyna awhile back done this, and prevented 80% of hacks without touching mccodes core code!

Are you talking about the non-mccodes class file here?

I could be wrong on this because I don't remember the exact class you're talking about, however... I doubt this is true. There are a lot of exploits (way more then 20% even more so when you consider the problems the original had) that have nothing to do with anything that would pass through the DB class.

 

well said there is no need of changing the as haunted dawg said all i would do is secure the header and globals or build the two into eachother simple

Securing a few files won't fix every problem. I would highly suggest you look over the source if that's all you have done.

[HauntedDawg]

Are you talking about the non-mccodes class file here?

I could be wrong on this because I don't remember the exact class you're talking about, however... I doubt this is true. There are a lot of exploits (way more then 20% even more so when you consider the problems the original had) that have nothing to do with anything that would pass through the DB class.

No, Nyna had modified the original mysql class file (some where here is a thread about it), and managed to prevent 80% of sql injections. While the other 20% were (if i remember correctly), different injections than the known sql exploits out there.

[HauntedDawg]

please Compare both db classes

Why should I? Considering the OP has MCCode in his opening message, he is looking for securing $_POST data in MCCode!

I'll put this as simple as I can. Don't tell people:

 

Mccodes db class is old (also not escaping values properly by Old MCC) so i think it is bit better

when the file is not even for MCCodes.

And again, let me point this out to you!

MCCodes:

 

$db->query("INSERT INTO hoes VALUES('', $userid, '{$_POST['hname']}', '{$_POST['hage']}', 0, 1, '{$_POST['hspec']}', '{$_POST['hcolor']}')");

 

In your class:

 

public function Query($sql)

 

Nuf said?

 

 

-

 

 

 

 

If not, it will fail, unless you rewrite the entire engine to use $db->Query, instead of $db->query. Or alternatively rewrite the class. But you didn't answer my question.

Did you bother checking the class file to see if it matches MCCode? NO

Did you bother rewriting the class file to match MCCodes? NO - much simpler route

By the seems of things, you went and changed every query in your code to suit that class. Which is redundant, because that class still uses plain old mysql.

Now why go through 100 files to change $db->query to $db->Query? when you could of rewrote the class file to function query($sql), and the other functions.

You get my point now?

[rockwood]

yes, you have a valid point and i am agree with your comments.

as per my view a change is required in old db class something like new update.

it is not very hard to do

Edited July 26, 2013 by rockwood

[Dominion]

No, Nyna had modified the original mysql class file (some where here is a thread about it), and managed to prevent 80% of sql injections. While the other 20% were (if i remember correctly), different injections than the known sql exploits out there.

I'm reading that differently to how I first did... In any case I've never seen such a file, and wouldn't recommend a quick fix using the class on the current version since you don't know what's being done to it before hand so problems will pop up(e.g. mres, and then the query() doing mres again...). Maybe changing over to something like NWE has to allow it to check what's being passed through, however that wouldn't fix the major issues left in the current source.

 

yes, you have a valid point and i am agree with your comments.

as per my view a change is required in old db class something like new update.

it is not very hard to do

Not hard to do, but sure is time consuming. If you're doing it this way why would yours (or who ever the file is from...) be better then the others out there? Your original post sold it as a simple replacement... that is not longer what you're saying.

Edited July 26, 2013 by Dominion

[Djkanna]

I've been told to use htmlentities then when removing the data from database use html_entity_decode(), just saying.

That's counter-productive.

If you're using htmlentities on input, then decoding on output, why bother at all? Defeats the purpose in the first place.

Format on output rather than input, as has been said. :)

Maybe give this (Author has articles on the subject too ) a read through, if you get a chance.

Edited July 26, 2013 by Djkanna

[Script47]

That's counter-productive.

If you're using htmlentities on input, then decoding on output, why bother at all? Defeats the purpose in the first place.

Format on output rather than input, as has been said. :)

Maybe give this (Author has articles on the subject too ) a read through, if you get a chance.

Thanks DJK, like I said it's just what I've been told, so I did it, and I will definitely check them links out mate.

[Barrikor]

Format on output rather than input, as has been said. :)

I prefer formatting everything on input so that I know everything I've got is safe.

"Hëllo, WoⓇld!" goes into my database as "H[euml]llo[#44] Wo[#9415]ld[#33]"

Takes more storage space but converting+whitelisting the data as soon as you get it makes life much easier.

[rockwood]

bind your values best way

[Coly010]

As my question is somewhat related I thought it would be better to append it to this question.

If I have a textarea or input box where a user enters text or a message, how can I have it where I can secure the $_POST['message'] whilst allowing my users to put say apostrophes (single quote) or even a double quote into the message?

Is there a function that I can use, because when I test it with stripslases() and htmlentities() it wont insert the value into the database.

[Guest]

As my question is somewhat related I thought it would be better to append it to this question.

If I have a textarea or input box where a user enters text or a message, how can I have it where I can secure the $_POST['message'] whilst allowing my users to put say apostrophes (single quote) or even a double quote into the message?

Is there a function that I can use, because when I test it with stripslases() and htmlentities() it wont insert the value into the database.

Inserting the you use real_escape_string, on output you would use htmlentities().

[Coly010]

ah thank you :)

[rockwood]

you can use this too htmlspecialchars()

Edited July 28, 2013 by rockwood

[HazardBoy]

If you have more than 3 keys to verify is good to use a loop to avoid messy code.

If you know the keys you can define at first an array and loop the post with verification of in_array and is empty.

You can also sanitize your post without knowing the keys.

here I'll write some example:

 

function sanitizer( $postData, $recursive = true )
{
  $sanitized =array();

  foreach($postData as $key => $value)
  {
      if($recursive && is_object($value))
      {
           $sanitized[$key] = sanitizer($value, $recursive);
      }
      else
     {
      // YOUR CLEAN-UP METHODS HERE
      // example: $sanitized[$key] = escapeshellarg(escapeshellcmd(mysql_real_escape_string(addslashes(strip_tags($value)))));
      //
     }
  }

  return $sanitized;
}


$clearPost = sanitize($_POST); // sanitize($_SESSION); // sanitize($_FILE);

 

Same technique different utility

 

function IsValid( $postData, $checkArray)
{
  foreach($postData as $value)
  {
      if(!in_array($value))
      {
           return false; 
           break;
      }
      else if(empty($value))
      {
           return false;
           break;
      }
  }

  return true;
}

$allowOnly= array('Name','Email','Password');

if(IsValid($_POST,$allowOnly))
{
// code run
}

 

Cheers!

Edited April 1, 2014 by HazardBoy

[Zettieee]

Don't revive the dead.

[Djkanna]

Don't revive the dead.

It's okay if the information is useful.

Whilst I don't agree one should sanitize globally let alone do before validating.

If you really had to there's built in functionality that makes it easier to do the examples HazardBoy gave:

array_walk array_map.

The only issue, not every input has to be sanitized nor does every input have to be sanitized the same way.

Seems just a waste to sanitize a stage marker or a similar input ( anyone seen: _GET['ajax] before? or _POST['submit'] or users.php?addUser ) ?

[john.]

Personally I would use a Validation library to make sure the data is valid (according to my rules). Filtering/Escaping the User(s) data is just common sense. If you enter data in database, you would use prepared statement. When outputting data you escape it properly with i.e. htmlspecialchars.