Skip navigation

All posts tagged with "PHPAskIt"

PHPAskIt is insecure!1!1!zomg!11

I came across a couple of websites discouraging the use of PHPAskIt because it uses a database and therefore absolutely must be insecure.

One such example states:

PHPAskIt isn't completely secure, either. It uses a database so I woulda thought that was more INsecure than the flat file of Waks Ask & Answer script.

Another says:

PHPAskit is just as insecure [as Wak's Ask&Answer] only people think it's secure because it's not flat file.

And so on, and so forth.

For the record, there is no difference in security in using one method or another, as long as they are both done properly. Wak's Ask&Answer and CuteNews (flat file scripts) aren't. PHPFanBase and SimpleDir (MySQL scripts) aren't either. Jem's Bella~ series and FlatPress however, are flat file scripts and they are fine. Similarly, WordPress and PHPAskIt are MySQL scripts and they are absolutely fine.

Yes, it's true that hackers discover more and more vulnerabilities in scripts and programming languages all the time, so those scripts may not always be secure in their current versions so it is very important to keep your scripts up to date. But to say a script is insecure because of the method of storage that they use is stupid and shows complete ignorance. If you are going to say a script is insecure, don't just back it up with "well I looked it up online and it said it was insecure". People seem to like publishing fake reports of insecurities (probably where all this is coming from, actually... PHPAskIt had a nice security hoax published about it - and in case you're still living in the dark ages it was wrong) so "looking it up online" isn't always the answer.

If in doubt, ask someone who knows what they're talking about. :)

PHPAskIt Security Vulnerability

It has been brought to my attention that there is a serious security vulnerability within all versions of PHPAskIt, which states that the conversion scripts for Wak's Ask&Answer and the classic Ask&Answer can be hacked through the directory variables.

The security vulnerability is a hoax. The import files CANNOT be hacked through the $qadir and $dir variables even with register_globals on.

I find it such a shame that the person who discovered this has gone round telling everyone who will listen that my script's insecure (and every major security site there is) but 1) won't inform me (I found out through a Google search) and 2) makes things up. I've contacted them several times but each time the mail has bounced back. *Rolls eyes* How mature.

CodeGrrl scripts: security flaw

Regarding these scripts and ONLY THESE SCRIPTS:

FA-PHPHosting, PHPCalendar, PHPClique, PHPCurrently, PHPFanBase and PHPQuotes

There is a serious vulnerability that can and has been exploited by hackers if left unsecured. Read below for more details on what you can do.

This does NOT, repeat NOT affect my script, PHPAskIt. Please do not keep contacting me asking which file to replace - PHPAskIt, although a CodeGrrl script, is not based on PHPFanBase like the scripts mentioned above and is therefore not vulnerable to the attack.

Spread the word!

Edit: Ok, so all affected scripts have been removed from CG. As I said above, PHPAskIt is not affected by the recent hackings and security vulnerabilities and, just to make doubly sure, I've even updated it slightly. Once CG give me the go ahead, I'll put it up again.

If you're using ANY of the scripts mentioned at the top of this post, do this immediately:

  1. Open up protection.php and add this code to the very top (but underneath the opening <? ):

    if ('protection.php' == basename($_SERVER['SCRIPT_FILENAME']))
    die ('Please do not load this page directly. Thank you.');

  2. Find this line AND DELETE IT:

    $logout_page = "$siteurl";

  3. Find these lines:

    setcookie("logincookie[user]","",time() - 86400);

  4. Change them to look like this:

    setcookie("logincookie[user]","",time() - 86400);

The official fix didn't work for me, which is why I suggest you use this one - it stops hackers from getting to the protection.php file directly, and takes the ability to include any site as $siteurl away. Apply some sort of fix as soon as possible.