+ Reply to Thread
Results 1 to 7 of 7
  1. #1
    Join Date
    May 2010
    Posts
    6

    UPDATE of the great CMS articles::Read before posting about ERRORS::

    Ok hi there... I will refer this to mainly the 'not-so-experienced- php users etc, as more able users often debug and find the culprits in their systems.

    Right... As you know, the articles were written years ago in outdated versions; thus much of it will fail now (especially login which agin is due to verification etc).

    Right.... so... what is going wrong... about 5-6 issues. They all are pretty much due to deprecated methods.

    So first we are going to get the variable system up to date:

    extract all source files provided by articles and always overwrite the earlier article source files with the later (5 -> 4> 3>..1). In SystemComponents.php :

    you set the value (so on the right hand side of the = sign), YOUR particular fileds.
    for the siteRoot... I guess you can use the one which will be the base folder which could be a sub-folder as such in your site.
    Eg. If you have CMS under /var/www/ , you set this to /var/www/CMS/
    (I haven't experimented with that yet so can not say for 100% if the last slash should be appended).

    Anyway, that is not so important.

    Now, in ALL the files, do a search + replace for :
    A. HTTP_GET_VARS is replaced with _GET
    B. HTTP_GET_POST is replaced by _POST

    With that done, one has got rid of the deprecated variables.

    2. As someone else pointed out, if you are using a higher than 4.1 mysql, PASSWORD will now be in the form of 41 char long. (YOU can check this by seeing in your database if there is an asterisk at the beginning (*). In that case, you need to update these files.

    to do this use this table instead say for users (someone asked about cyrillic etc. in validator, I havent looked into that yet, this is for latin standard alphanumeric alphabet).

    CREATE TABLE IF NOT EXISTS `cmsusers` (
    `ID` int(4) unsigned NOT NULL AUTO_INCREMENT,
    `user` varchar(20) DEFAULT NULL,
    `pass` char(41) CHARACTER SET utf8 DEFAULT NULL,
    `thegroup` int(4) DEFAULT '10',
    `firstname` varchar(20) DEFAULT NULL,
    `surname` varchar(20) DEFAULT NULL,
    `e-mail` varchar(40) DEFAULT NULL,
    `enabled` int(1) DEFAULT '1',
    PRIMARY KEY (`ID`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;

    Comments on table: I have added e-mail and one has to change the pass to 41 chars.

    NOW comes two IMPORTANT parts. To understand the code, and to figure out issues, the following is both essential and/or useful for you to understand what is going on.

    A. (must do)... I noticed that when in welcome.php , i.e. the pages one wishes to protect, it no longer is ok to write

    if (!$theSentry->checkLogin(2) ){ header("Location: login.php"); // to protect page @ level 2

    The FIRST entry of checkLogin parameters will be set to 2, which is user.
    So you can do two things: Either change the parameter list in checkLogin (which might lead to other errors , OR [which I did] replace
    if (!$theSentry->checkLogin(2) ){ header("Location: login.php");
    with
    if (!$theSentry->checkLogin('','',2) ){ header("Location: login.php");

    This way, $group is set to 2 as desired, rather than the value in eg. login.php (which should be set to 9)

    Ok, so hopefully you understand that.

    Now comes the FINAL IMPORTANT thing. Even if all that works now, you still will probably be unable to log in as VALIDATOR.php is the real culprit left.

    Ok... so a lil pre-amble: We just want to make the log in functioning first right, and validator is to avoid hacks in the passwords and names etc... since we are debugging our own system, just comment out ALL the IF statements which call functions inside validator.php in the Sentry.php file, which regard $pass!!!
    eg.

    if (!$validate->validateTextOnly($_SESSION['pass'])){;return false;}
    if (!$validate->validateTextOnly($pass)){;return false;} //these two are also faulting your program. The ones with 'user' is still fine as e-reg still exists as a function).

    HINT: to follow the flow in your files:
    add this to each code you wish to examine
    echo "whatever values you wish to add here or just a line";die;
    the program will stop due to die after yoru last echo. if you never reach your echo , means the logic has gone elsewhere. (also empty values can give you a hint).


    NoW YOU CAN TRY various user names and setting the level for entry.. (play around with the old way of checkLogin(2) vs. checkLogin ('','',2) for a user less than 2 and one over 2... you will see how user=2 and group =2 in the two cases.

    Ok..have you managed now to get your log in to work? and found with the echo statements all the problems? Ok , now we finally can attack validation.php and get all the if statements back!

    NOTE: Validation in all honesty, is the one you should through practice, develop and rewrite to your needs and to your understanding of security. (eg. should passwords be a min length? max length? which characters can be included.. if not, then exclude them? (strict parsing vs. lenient), spaces allowed? etc etc.

    Validator.php:

    in validator.php, e-grep is used, which was a long serving regexp function. However, that is deprecated. Also, each time the function ValidateTextOnly is called for the 'hashed' password, it will fail (due to the new password function with a *).

    validateTextOnly($theinput,$description = ''){

    $result = ereg ("^[A-Za-z0-9\ ]+$", $theinput );// causes fail on hashed function

    So what does one do? Well look up preg for example (I think this is the successor), and one needs to write a pattern for the hash:
    Add to Validator.php:

    (Ok, let me edit and update you on this.. I just am going to make sure my regexp is correct before I continue) (for now, just keep the if lines commented out in sentry.php :
    //if (!$validate->validateTextOnly($_SESSION['pass'])){;return false;}
    etc.


    I will come back and give you the regexp unless osmeone else in themeanwhile gives it to you and sorry for the english, lame grammar and all... I am not much of a guy who bothers giving 'tutorials' so when I do, I just throw everything down in haste

    but hopefully this will aid you in solving your problems (as I said, when I got the final regexp, I will also show you how to enable validation for password as the last final part).

  2. #2
    Join Date
    May 2010
    Posts
    6
    Hmmm , ok too late to edit. Right.. Apologies for the previous mess as I intended to rewrite the post and present it more properly. Even so, let it be...

    Going back to the part about the validator.php (remember, all files are case sensitive, also in apache2)

    ereg is deprecated and instead we will use preg_match()... also, since we are using (hopefully) now a 41 char password which starts with a *... we need to update the pattern to 'starts with a * followed by 40 alphanumeric values). In my case, the letters are all capitalised so I left out the optional lowercase... I will leave that as an exercise if someone needs to expand on that.

    Either way : in Sentry.php where you are passing on the $_SESSION['pass'] to Validator.php (ie. the hashed password), we need to change this from the function validateTextOnly, to a new one

    which I called ValidatePassHash...

    ok so in Validator.php create a new function:

    function ValidatePassHash($theinput,$description = ''){

    $result = preg_match("/^\*.*(?=.{8,})(?=.*\d)(?=.*[A-Z]).*$/", $theinput);



    if ($result){

    return true;

    }else{

    $this->errors[] = $description;

    return false;

    }

    }

    like so....

    and in sentry where the session pass is asked to be validated , one does :

    if(!$validate->ValidatePassHash($_SESSION['pass'])){return false;}


    thats it... hmmm, I also did some other logic .. but don't know if I can upload the 'finished' source files... either way, this should help most along if they found the sources of the article useful.

    lak

  3. #3
    Join Date
    May 2010
    Posts
    6
    $result = preg_match("/^(\*){1,1}[A-Z0-9]{40,40}$/", $password) {

    sorry use that for the preg match.. I KNEW i would screw it up ..

    There is probably better way than to overload min,max but ok, I haven't been doing these things for 6-8 yrs.

    Right explanation: Starts with 1 and only 1 '*' (asterisk has to be escaped), followed by exactly 40 occurences of the two ranges inside the brackets.. A-Z0-9 (if you want lower case, all you do is add a-z somewhere with the other two ranges and that's it). $ means that the end of the string has to match preceding pattern and the ^ that the start of the string, meaning it must be * + 41 capitalised alphanumeric string.

    enjoy

    oh: $result = preg_match("/^(\*){1,1}[A-Z0-9]{40,40}$/", $password) can be rewritten like so I think:
    $result = preg_match("/^(\*){1}[A-Z0-9]{40}$/", $password)
    Last edited by lakmilis; 06-10-2010 at 03:37 PM.

  4. #4
    Join Date
    Jun 2010
    Posts
    2
    Shouldn't that be HTTP_POST_VARS, not HTTP_GET_POST?

    Also, a comment about the original tutorial: You use the MySQL PASSWORD() function to encrypt user passwords. In the MySQL documentation, it specifically says that you should not use it in your own applications (it is the way MySQL passwords are hashed) and suggests using MD5() or SHA1().

  5. #5
    Join Date
    May 2010
    Posts
    6
    Hi.. about the HTTP stuff, I am sure you can figure it out. Those variables are deprecated.. use $_POST and $_GET.

    About the mysql password function however. Good point and yes.. I don't do it myself, I simply hmm responded to it as it wasa problem for people and I just showed how it could be done. Yes it is BAD practice but the questions on how to use this was posted by beginners absolutely.

    Yes.. IF you use sha1 or mda5 , do NOT do it without a salt.. and also make sure your salt is rather long (make sure your salt + min user passsword length is 15 chars) + and use non alphanumeric symbols in your salt. Why? (look up sql insertion attacks, compromised passwords, md5 cracking.sha1 with rainbow tables). You will understand why from there.

    sha2 or so seems good but for now, what I am doing myself is something like this: (I 'm not sure about if the double runs help a lot but I do it nonetheless):

    define("SALT1","SOME@#$THING65!");
    define("SALT2","$OMETHING@#$ELSE65!ff");

    ...


    //sanitize your userinput then ->
    passfield = md5(username + passinput + SALT1);
    passfield = sha1(username + passfield + SALT2); // say.. not sure if this was entirely correct, just giving you the idea

    I add something like the username AND a salt to make it solid.

    anyway.. when you wish to check if valid password input:
    //sanitize
    input as above ... check vs value in DB.

    (md5 is cracked in matter of seconds these days wihtout a salt), sha1 is also compromised I believe.

    (PS. I actually do a double run of md5 , not sha1 but I am not the best to answer this topic.. I'm sure there are better ways, but this will hold for normal users).
    Last edited by lakmilis; 06-10-2010 at 03:43 PM. Reason: additional info

  6. #6
    Join Date
    Jun 2010
    Posts
    2
    Good post.

    In my last project I used a combination of sha1 and md5, and the salt was also different for every user, meaning that new rainbow tables would have to be made for each individual user if they wanted tog et the passwords. I'm no expert in security though, so...

  7. #7
    Join Date
    May 2010
    Posts
    6
    that's a start.. make sure to keep it 15 chars , passy + salt + user bla bla. If you read a bit, you see what I meant.

    As you can also see and probably know.. many of the questions posted to this outdated script are by people who want something right up and don't know too well issues with security, thus my implementation was merely a little help to update them to ucrrent php and well using lazy mysql passy, but it was a good thing you brought it up !

    Enjoy scripting.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts



Latest Headlines from Datamation