Montag, September 7th, 2009 | Dokumentation, PHP, Sicherheit, sseq-lib | 3 Kommentare
So there it is: a popular Wordpress installation got hacked. Obviously it was an old version which has some security flaws. And yes, there was an update available for Wordpress which unfortunately was omitted.
Running Wordpress? You're toast!
Now there is a question in my mind: is Wordpress kind of notoriously unsecure as some may think? And what is the solution for these security flaws coming now and then? It seems everybody agrees that there is no 100% secure software. So we must live with the risk of getting hacked? I definitively don't feel good with this.
Besides, there is alt least one Wordpress plugin out there to identify infected blogs (Did I said a plugin to hinder infection? Certainly not.) Plugin solutions may come in handy but they also must be updated and installed on every new Wordpress and - as we've learned - this may be the common point of failure. So what to do now? Never ever again feel safe with Wordpress?
Wordpress out-of-the-box security!
What if Wordpress would come with security out of the box? There is a method of filtering incoming data by checking type and length against expected definitions. Only what passes the filter will be let through to the internal code (which may have security flaws). This very blog of mine is running such a filter. Want to see what kind of attacks it catches? Some log file lines:
SSEQ-LIB log file
06.09.2009, 15:46:24, 204.xx.xxx.xxx, [_GET], Global VAR overwrite detected, _SERVERDOCUMENT_ROOT, GET, /index.php, libwww-perl/5.79,
06.09.2009, 18:04:58, 91.xxx.xx.xx, [_GET], p: INT param not INT, 446//index.php?str=http://www.trxxxxxxx.eu/roxx.jpg???, GET, /index.php, libwww-perl/5.803,
All these attacks do not pass the filter, get deleted and cannot harm the Wordpress installation. Having a set of those filters being delivered with every Wordpress installation, will make sure that even if there is a bug inside the code, attacks will not go that deep but be stopped at the gates.
What is filtering with SSEQ-LIB all about?
Catching the attack before it reaches the application is already implemented in SSEQ-LIB security library. Including the filter into your Wordpress installation is as easy as inserting 2 lines of code into "wp-load.php" (see below)
The filter file contains line by line a filter definition which is to be read this way:
Check a variable name ("cat"), coming from "p"ost and "g"et, which has to be an "INT"eger between the interval of "1" and "9999999", encode against XSS ("true"), escape against SQL-Injection ("true").
// VARIABLE NAME # SOURCE # TYPE # MIN # MAX # XSS # SQL &
cat # pg # INT # 1 # 9999999 # true # true &
p # pg # INT # 1 # 9999999 # true # true &
page_id # pg # INT # 1 # 9999999 # true # true &
m # pg # INT # 1 # 9999999 # true # true &
attachment_id # pg # INT # 1 # 9999999 # true # true &
feed # pg # STR # 1 # 50 # true # true &
I don't know if you will sleep better after having SSEQ-LIB running on your blog. I do. You may download SSEQ-LIB from here and secure your Wordpress blog too. There is also a configured filter file which you should use by default. You may add more filter to improve security. If you do so, send me a copy of it to share it with others.
Download SSEQ-LIB security library+ Wordpress filter definition
Create two additional folders on your web server: sseq-lib and sseq-filter.
Put the content of the filter ZIP ("wordpress_2.6.x_filter_v.0.3.zip" or similar) into the folder: sseq-filter
UnZIP the SSEQ-LIB ZIP ("sseq-lib_0.7.1.zip" or similar) and read the "readme.txt". After that copy the folder sseq-lib out of the ZIP to your web server.
Open the Wordpress file "wp-load.php" and include 2 lines of code. After that the file should look like this:
/** Define ABSPATH as this files directory */
define( 'ABSPATH', dirname(__FILE__) . '/' );
error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE);
// including SSEQ-LIB
include_once(ABSPATH . 'sseq-lib/seq_lib.php');
// loading and using filter data
On your web server the SSEQ-LIB structure should look like this:
| |- seq_lib
| |- seq_log
| |- seq_dump
Testing SSEQ-LIB installation
Now go to your blog and try something like: "http://www.erich-kachel.de/?p=2ATTACK" and you'll be redirected to your start page. Now go check the log file on your web server: "sseq-lib/seq_log/log.txt". You have to do this with your FTP connection because this file should not be reachable through HTTP.
Too much work?
Give Wordpress a hint about this security solution. They may think about including SSEQ-LIB by default to guarantee security for longer time than just until the next security release.
Freitag, August 21st, 2009 | PHP, Sicherheit, sseq-lib | Keine Kommentare
I am so sorry!
While redesigning the CSRF-tokens check routines I made a mistake in SSEQ-LIB version 0.6.2. I checked the name of the token but I forgot to check its value. This means that knowing the name of a token is enough to pass the CSRF protection. Fortunately there are still other protection mechanisms like absolute lifetime of a token or its binding to the users-agent which keep the shields up for a while.
Anyway in the new version 0.6.3 (and 0.6.3.1) the bug is fixed. Besides, the difference between 0.6.3 and 0.6.3.1 is minor and located only in the config file.
Credit for finding the bug goes to Andreas Mauf.
Samstag, Juli 4th, 2009 | PHP, Sicherheit, sseq-lib | 1 Kommentar
So here it is, 3 steps to dramatically increase security in your xt:Commerce 3.04 SP2.1 (or xtc:Modified 1.01) online shop. The security pack is based on the PHP Application and Website Defense Library (SSEQ-LIB) and consists of:
- Current version of SSEQ-LIB, the PHP Application and Website Defense Library.
- Some slightly modified xt:Commerce/xtc:Modified files to prevent Cross Site Request Forgery.
What the security pack is supposed to do
Having the SSEQ-LIB included instantly fortifies the xt:Commerce session and cookie. Your online shop then is secured against:
With the SSEQ-LIB filter mechanism (aka. Web Application Firewall) and a customized filter definition for xt:Commerce/xtc:Modified even unknown or not patched security flaws in your installation are closed. The filter additionally secures against:
- Cross Site Scripting
The security pack also comes with some slightly modified files from the original xt:Commerce/xtc:Modified shop. The changes consist in fact of two well placed functions which make sure your shop is secured against:
- Cross Site Request Forgery
You may want your shop be secure in minutes. You'll be happy to read the installation instruction. But first I really encourage you to make a backup of your shop - you'll maybe need it.
- Download xt:Commerce/xtc:Modified Security Pack Version 0.1.
- Make a copy of your files - just in case.
- Unzip the Security Pack in your fresh xt:Commerce/xtc:Modified installation and override any files.
- You are done now.
Not having an original xt:Commerce at hand, I took xtc:Modified 1.01 (http://www.xtc-modified.org) which is in fact xt:Commerce 3.04 SP2.1 with some extra. So using the Security Pack may work well for you, elsewhere restore your shop with the files you have saved before installing the Security Pack.
- November 2013
- Juli 2010
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- September 2008
- August 2008
- Juli 2008
- Juni 2008
- Mai 2008
- April 2008
- März 2008
- Januar 2008
- Dezember 2007
- Oktober 2007
- September 2007
- März 2007
- sirdarckcat: A couple of unicode issues on PHP and Firefox
- HTTP Parameter Pollution
- Our Favorite XSS Filters/IDS and how to Attack Them
- 1 Raindrop: Don't Cede the Cloud
- Top 10 Web Vulnerability Scanners
- Torsten Keil - www.torsten-keil.net
- Als attackierend gemeldete Website!
- [WEB SECURITY] Web Application Scanners Comparison
- TSJ-2009-01-winter.pdf (application/pdf-Objekt)