April 2009 Archives

Most MySQL server installations floating around on the Internet are blindly using the default server configuration.  Even more shocking, you'd be surprised to find out how many of these MySQL server installations are left wide open, completely vulnerable to attacks.  In this post, I'll provide a few simple tips you can use to better secure your MySQL server.  Note that these tips should be used as a basic starting point; they are not an end-all-be-all MySQL security solution.  You still need to know what you're doing, and if you're unsure, find a consultant or friend who can help you lock down your server.

Continue reading for the HOWTO ...
Here's another quick tip; I fought through this issue today at work.  In PHP, you might have a need to parse some JSON that contains a field/member name with one or more hyphens.  Here's an example:

{
"field-one" : 1,
"field-two" : 2,
"field-three" : [ 1, 2, 3 ]
}

Most JSON libraries should convert this JSON string into a native object with ease.  However, in PHP when you try to access $obj->field-one directly, PHP will complain given the hyphen in the member name.  The solution to this simple problem, is to wrap the name in curly braces, like so:

$obj->{'field-one'}

Here's a more complete example using Services_JSON in PHP:

<?php

require_once("JSON.php");
$json = new Services_JSON();

$string = "{\"field-one\":1,\"field-two\":2," .
"\"field-three\":[1,2,3]}";

$obj = $json->decode( $string );

// Will FAIL
//echo $obj->field-one;

// WORKS
echo $obj->{'field-one'};

?>

For your download convenience, you can find the latest Services_JSON library here (as of 4/22/09).  The official PEAR CVS repository for Services_JSON can be found here.  Enjoy.
Every once in a while, I find myself stuck on the most mundane and boring coding problems.  Take this one, for example: use Java to capitalize the first letter of each word in a sentence.  Amazingly, I actually had a need today to write some Java code that does just that.  Sounds trivial; I actually ended up spending almost half-an-hour on this (I know, you can laugh at me, but I just couldn't wrap my head around this one).  My first reaction was to use a regular expression, but I realized that, unlike Perl, Java doesn't support \u which can come in handy when capitalizing letters in a regex.  From what I read online, there are quite a few back references and other escape sequences built into Perl regular expressions that Java doesn't support.

I finally bit the bullet, and solved this the introduction-to-programming way, which is to loop through each character in the String, and capitalize the letters that sit at the start of a word-boundary.  It makes me shudder when I have to "loop through" letters in a String, but I guess there are some problems that simply cannot be solved without doing just that.

Here's the code:

public static String capitalizeFirstLetters ( String s ) {

for (int i = 0; i < s.length(); i++) {

if (i == 0) {
// Capitalize the first letter of the string.
s = String.format( "%s%s",
Character.toUpperCase(s.charAt(0)),
s.substring(1) );
}

// Is this character a non-letter or non-digit? If so
// then this is probably a word boundary so let's capitalize
// the next character in the sequence.
if (!Character.isLetterOrDigit(s.charAt(i))) {
if (i + 1 < s.length()) {
s = String.format( "%s%s%s",
s.subSequence(0, i+1),
Character.toUpperCase(s.charAt(i + 1)),
s.substring(i+2) );
}
}

}

return s;

}

Note that another solution might involve using a StringTokenizer, like so:

public static String capitalizeFirstLettersTokenizer ( String s ) {

final StringTokenizer st = new StringTokenizer( s, " ", true );
final StringBuilder sb = new StringBuilder();

while ( st.hasMoreTokens() ) {
String token = st.nextToken();
token = String.format( "%s%s",
Character.toUpperCase(token.charAt(0)),
token.substring(1) );
sb.append( token );
}

return sb.toString();

}

Enjoy.
Here's a relatively quick tip you can use to harden the security of your LAMP stack.

In a default Apache/PHP configuration, PHP likes to insert its own HTTP header advertising the fact that you are using PHP on your server.  The "X-Powered-By" response header displays the version of PHP you are running, and in some cases, even the PHP patch level.  This can be troublesome, because intelligent hackers often look for this information in your response headers as a way to verify the version of PHP you are using.  For example, if a hacker discovers you are running PHP 4, there is a possibility that they will attempt to exploit known PHP 4 vulnerabilities.

Luckily, you can set the expose_php variable to "Off" in your global php.ini configuration file to hide this "X-Powered-By" header.  Depending on your distro, php.ini is usually found at /etc/php.ini or /etc/php5/apache2/php.ini.  Here's a snapshot of my php.ini file, showing the expose_php config variable set to Off:

; Misc
;
; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header). It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.

expose_php = Off

Using HttpFox, an HTTP header analyzer extension for Firefox, I verified that PHP is no longer adding the "X-Powered-By" header to my responses (click for larger view):

expose-php-before-after.png

If you enjoyed this tip, you might also enjoy my post on HOWTO: Hide your Apache Server Version in Your HTTP Response Headers.
solar-shield-tw.jpgAt home, my den faces to the west.  This unfortunately means that I have to deal with the late afternoon sun pounding on my office window.  Not surprisingly, this often turns my den into a complete sweat box.  Since it's spring, and the weather is starting to heat up, I decided to get creative.  I have a set of outdoor hanging blinds over the window to keep the sun out, but that only helps so much.  I needed something much more impenetrable; meet my homemade aluminum foil solar shield!
My girlfriend recently asked me "so what is the most popular page on your blog?"  That was an interesting question, and to be honest, I had no idea.  I regularly monitor my Apache logs, so I had a rough idea of what's popular but I never actually dug into into my access logs to find out.  Using a few handy commands (awk, grep, sort, uniq) I determined that the most popular page on kolich.com is my post on Microsoft's IE8 Boondoggle: The IE8 Beta Incompatibility List.

My complete most popular list can be found here.

The command chain I used to analyze my access logs is as follows:

cat /var/log/httpd/mark.koli.ch-access_log* | awk '{print $7}' | \
grep html | grep -v "mt-static" | grep -v tracker | \
sort | uniq -c | sort --reverse -n | tee ~/popular.txt

This command produces a text file that looks something like this:

42 /2008/10/first-post.html
41 /2008/12/initial-implementation-of-gagawa-in-php-now-available.html
37 /2009/01/follow-up-four-more-reasons-why-i-dislike-facebook-and-myspace.html
36 /2008/10/obamas-prime-time-ad-skips-over-budget-realities.html
34 /2008/12/howto-recursively-delete-directories-on-windows.html
33 /2009/01/jpandmeghancom-a-work-of-css-art.html

I then wrote this PHP script which uses Gagawa to read the text file output and create a nice HTML template of the results.  Enjoy.
mt-logo.pngWhile reading Jean-Baptiste Jung's 10 awesome .htaccess hacks for WordPress I was inspired to write my own version of the 10 awesome hacks post, but for Movable Type.  Because I use Movable Type instead of WordPress, I decided to take Jean-Baptiste's post and tweak it for MT.  Many of the concepts are the same, just with a slightly different twist.  I've also added my own tweaks to the mix as well; some of the hacks below are not specific to WordPress or Movable Type and can be easily integrated into any blogging platform running on Apache.

  1. Redirect Movable Type RSS Feeds to FeedBurner
  2. Encourage Browser Caching For a Faster Load Time
  3. Use Apache's mod_deflate To Gzip Compress Static Data
  4. Combat/Block Trackback Spam
  5. Redirect Visitors to a Maintenance Page
  6. Prevent Hot-Linking of Your Images on Other Sites
  7. Control Access to mt*.cgi Movable Type Core Scripts
  8. Deny Access to Your Blog by IP Address
  9. Deny Access to Rogue Bots and Other Invalid User-Agents
  10. Combat HTTP Referrer Spam

Continue reading for the details ...
tweetmeme-logo.pngThis post is an attempt to officially document the Tweetmeme bot's invalid User-Agent string.  Maybe someone from Tweetmeme will see this, and configure their bot to use a more appropriate User-Agent string.  I've already alerted Tweetmeme of the concern via Twitter, but no one has responded.

Here's the problem.  The Tweetmeme bot claims it's Firefox 3.0.6 as shown here:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) \
Gecko/2009011913 Firefox/3.0.6 TweetmemeBot

Unless the TweetmemeBot is actually a Firefox web-browser (which I doubt it is), this is an inappropriate and invalid User-Agent string.
Thumbnail image for google-dominant.jpgA few weeks ago, I found myself sitting waist deep in blog regret.  You know, that feeling you get when you post something you probably shouldn't have, and then you realize a month later that it was a bad idea.  Long story short, as an HP employee, I posted some (neutral?) comments on HP's recent pay cuts.  Some folks didn't think it was very neutral, and said some pretty nasty things about me on another blog.  I found out about this (the hard way), and decided to remove the post from kolich.com all together.

The removal process went fine (thank you Movable Type), but after analyzing my server logs a bit, I noticed that some clever folks were using Google to look up a cached copy of the post in question.  Unfortunately, there was nothing I could do about cached copies of the post floating out there on the web.  The "damage" (if you would call it that) was already done.

Here's a quick Java tip.  If you're using ant, and you want the java compiler (javac) to share more information about various compilation warnings, you can integrate javac's -Xlint:unchecked option into your build script.

During your compilations, you might see warnings like this:

[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

To pass the -Xlint:unchecked option to javac within ant, user the compilerarg element like so:

<javac srcdir="${src.dir}"
       destdir="${classes.dir}"
       classpathref="libraries">
  <compilerarg value="-Xlint"/>
</javac>

For more granular control over the compiler warning output (-Xlint:unchecked, -Xlint:serial, etc.), see the Non-Standard Options section of the javac man-page.  If you want a real-world example, check out the Gagawa build script on Google Code.
After setting up my first mobile blog portal (http://kolich.mobi), I started looking for ways to improve the content delivery speed of kolich.mobi to mobile devices.  On the server-side, I'm fairly sure I implemented just about every hack imaginable to squeeze every bit of performance I could from the PHP engine.  At this point, my only bottleneck was the actual content delivery chain.  I can't control how fast my data is transferred over a wireless (2G/3G?) network because of factors outside of my control, but I can help grease the skid.  To do so, I activated Apache's mod_deflate extension which compresses the content of an HTTP response before its delivered to the client.

The mod_deflate extension (err, module) uses gzip to deflate the HTTP response body.  Obviously, since the response is compressed, that means there's less data to transfer.  Hence, it takes less "cycles" (packets, octets, whatever) to get the data to the client.  In short, using compression within the confines of HTTP can often dramatically improve the "speed" of your site or mobile portal on a wireless network.  Of course, not only wireless clients benefit from the performance improvement, but typically wireless devices see more of an improvement than an average broadband user.
kolich-mobi-iphone.pngYou can now access a mobile device ready version of my blog at http://kolich.mobi.  I spent a few cycles today coding up some PHP that reads my blog's RSS feed XML, parses it, and prepares a version of the content suitable for a mobile device (PDA, smart phone, plain phone, etc.).  Unfortunately, I don't have an iPhone or smart phone, so I can't really test http://kolich.mobi as much as I would like.  Regardless, I adhered to as many mobile web standards as I could, so it should look presentable.

In fact, the W3C Validation Service confirms that http://kolich.mobi is XHTML 1.0 Transitional.  Enjoy.

Twitter (@markkolich)

Translate

About this Archive

This page is an archive of entries from April 2009 listed from newest to oldest.

March 2009 is the previous archive.

May 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.