I’ve been thinking about this one for over a couple of weeks. Should I share what happened to my daughter’s blog or should I bury it and pretend it didn’t happen? If I actually blog about then maybe it will happen again. On the other hand, it may not. In the meantime, I think what happened to my daughter’s blog re-opens the conversation about digital citizenship and when to start creating one’s own digital footprint.
Right before the Apple Leadership Summit, my husband called me from school and asked me if I had seen Maddie’s blog that day. This is a tame snippet of what I saw when I went to Maddie’s blog:
Context: Maddie is five and over the past year she has taken a strong interest in what we put on her blog. We talk about it at night just like we talk about what she did at school that day. She constantly says, “Mommy, let’s put the picture on my blog” or “Don’t put that on my blog!” She heads to school on Monday mornings and can’t wait to share what she did over the weekend with her classmates and with her teacher. How does she share? She goes to the computer and opens up her own blog. She’s five. This is her reality.
Maddie’s blog was hijacked by the Ghost of Iraqi Hackers – whoever they are. To this day, I have no idea how they hacked into her blog – it’s beyond everything tech that I know. I just know that I couldn’t log in to her blog and immediately went to my Twitter PLN and asked what to do. My wonderful PLN told me to call bluehost, which I did and they were able to restore Maddie’s blog right away. They are worth every single penny by the way!!!!!
Maddie’s blog means a lot to her and when this happened, it felt like a huge invasion of privacy. I am convinced though now more than ever that this is just another learning experience. I consider it my responsibility to teach Maddie about digital responsibility. What’s okay to talk about – what is not okay to talk about…. what do you do when something bad happends to you online? We are raising and teaching our children in a new world and we can’t protect them from its dangers by avoiding digital responsibility. This experience is one more feather in the hat for a lesson learned, but we will not hide and will continue to promote the goodness that can come from behaving responsibly online.
And that is my opinion.
———-
By the way: this is what bluehost sent me to make sure that this doesn’t happen again! But of course!! 
1. Set register_globals to OFF
2. Turn off Display Error/Warning Messages. set error_display to ZERO
3. Never run unescaped queries
4. Validate all user inputs. Items on Forms, in URLS and so on
5. Move Config and files containing Passwords to mysql to a Secure directory outside of the public_html folder
6. Access Control, U don’t want ya user to have access to Admin function or Clean up scripts
7. htaccess is your friend use it to deny people (we also have a easy deny manager too in the cpanel)
8. PHP can parse any valid script, whether it is called foo.php, very_long_name.php.php.php, or even willeymtard.bat. Using the default extension of “.php” means that before your hackers start you have already told them you are using PHP. As mentioned, you can use any filename for your scripts – if you are using PHP for every script on your server, consider using the “.html” extension for your scripts and making PHP parse HTML files you can change your file extension by adding this line to the htaccess or turn it on via the add type handler in the cpanel (AddType application/x-httpd-php .php)
9. To protect against SQL injection attacks Sometimes hackers will try to screw up you database by inserting SQL code into your form input fields. They can for example, insert code that could delete all the data in your database!To protect against this, you need to use this PHP function:
mysql_real_escape_string()
This function escapes (makes safe) any special characters in a string (programmers call text a ‘string’) for MySQL.
Example:
$name = $_REQUEST['name'];
$safe_name = mysql_real_escape_string($name);
Now you know the variable $safe_name, is safe to use with your SQL code.10. Keep the PHP code to yourself. If anyone can see it they can expliot vulnerabilities. You should take care to store your PHP files and the necessary passwords to access your MySQL databases in protected files or folders. The easy way to do this is to put the database access passwords in a file with a .inc.php extension (such as config.inc.php), and then place this file in a directory which is above the server’s document root (and thus not accessible to surfers of your site), and refer to the file in your PHP code with a require_once command. By doing things this way, your PHP code can read the included file easily but hackers will find it almost impossible to hack your site.
