Archives for February 2015

Next 30 day challenge: social media/news cleanse

For January 2015, I tried to declutter around the house for 15 minutes a day. We now have a couple rooms that are much cleaner, and I gave away a bunch of magazines.

For February 2015, my 30 day challenge was to go on daily 15 minute walks with my wife. That was nice.

Lately I’ve been spending more time than I’d like on social media and reading news sites. So for March 2015, I’m going to do a social media and news cleanse. I’ve done a social media cleanse several times before and it’s usually quite helpful for getting re-centered.

Here’s the steps that I’m taking:
– I’m using the StayFocusd Chrome extension to limit myself to 15 minutes a day of Google News, Twitter, Google+, Hacker News, Techmeme, Nuzzel, Reddit, and Imgur.
– On my R7000 home router I’m using the “block site” functionality for several of these sites. It looks like the R7000 can block HTTP sites, but not HTTPS.
– On my phone, I’m removing the new tab thumbnails for these sites. I’m also removing some social media apps from my home screen.

I figure that either I’ll get some good stuff done, read a lot of books, or die of boredom. I may (rarely) drop a link on social media, but if you see me just hanging out, please remind me to close my tab and move on. 🙂

Fixing “full path disclosure” issues

Whether you’re running a web service or a blog, you should always keep your software fully patched to prevent attacks and minimize your attack surface. Another smart step is to prevent full path disclosures. For example, if your blog or service throws an error like

“Warning: require(ABSPATHwp-includes/load.php) [function.require]: failed to open stream: No such file or directory in /home/horace/public_html/wp-settings.php on line 21”

then by noting the full pathname from that error, an attacker could reasonably infer that your username is “horace” and use that try to guess your password. It’s not the end of the world if your attacker has that information, but why not make an attack as hard as possible?

For WordPress, here’s a couple ways to prevent full path disclosure vulnerabilities:
– In a php.ini file, you can add a line like “display_errors = off” (without the quotes).
– In an .htaccess file, you can add a line that says “php_flag display_errors off” (without the quotes).

It sounds like the php.ini approach might be slightly better, because some web hosts run PHP in CGI mode which might not allow php_flag or php_value directives in .htaccess files.

After you’ve made this change, php errors shouldn’t be shown to web clients. If you’re developing live code on a PHP installation, that can make debugging slightly less easy. But if you’re running (say) a blog, it’s probably better to turn off display errors for a little extra protection against attacking hackers.

css.php