Understanding sseq-lib log file

Freitag, Juli 23rd, 2010 | blind patch, Dokumentation, PHP, Sicherheit, sseq-lib, Uncategorized | Keine Kommentare

To understand what kind of attacks have been blocked by sseq-lib you should occasionally take a look into the log file you find under „sseq-lib/seq_log/log.txt“. Each blocked attack is logged here with an explication of why it has been blocked.

 !  Do not open „log.txt“ with your web browser! You could execute some of the malicious code that has been written into the log file!

Each line of the log file represents an attack or the detection of a possible attack which is triggered by the integrated, lightweight IDS (intrusion detection system).

Understanding Log data

Splitting every log line by the comma (,) will result in the following data:

1. date[BR]
2. time[BR]
3. IP of attacking client[BR]
4. where the attack string has been found[BR]

  • [_GET] : $_GET
  • [_POS] : $_POST
  • [_COO] : $_COOKIE
  • [_SES] : $_SESSION
  • [_REQ] : $_REQUEST
  • [_GLO] : $GLOBALS

5. explanation of what happened. If the variable name which carried the payload is known it will be named.[BR]
6. attack payload[BR]
7. used method: GET, POST[BR]
8. the file which was used for the attack[BR]
9. User Agent of the attacking client[BR]
10. referer

Here some examples of blocked attacks against a WordPress installation and their corresponding log line.

XSS (Cross Site Scripting)

Example from log file:
12.03.2010, 06:16:42,, [_GET], p: INT param not INT, 99″>, GET, /index.php, Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2),

So here slice by slice:
1. 12.03.2010 (explanation: date)
2. 06:16:42 (explanation: time)
3. (IP) (explanation: some typical IP)
4. [_GET] (explanation: attack string was found in super global $_GET)
5. p: INT param not INT (explanation: variable „p“ was not an integer/number)
6. 99″> (explanation: attack payload – create an iframe)
7. GET (explanation: attack was performed through a GET request)
8. /index.php (explanation: attack was initiated on this file)
9. Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2) (explanation: user agent of client)
10. EMPTY (explanation: no referer)

Relative Path Traversal.

Example from log file:
29.03.2010, 22:16:38,, [_GET], p: INT param not INT, ../../../../../../../../../../../../../../../../../../../../../../../etc/passwd , GET, /index.php, DataCha0s/2.0,

Here the attack payload.


SQL Injection

Example from log file:
08:03:28,, [_GET], page_id: INT param not INT, 133 and 1=0 Union Select 0x787878756E696F6E787878–, GET, /index.php, ,

Here the attack payload.

133 and 1=0 Union Select 0x787878756E696F6E787878–

Code Injection

Example from log file:
23.07.2010, 04:12:41,, [_GET], p: INT param not INT, 446 //index.php?get=, GET, /index.php, Mozilla/5.0,

Here the attack payload.

446 //index.php?get=

Globals Overwrite

Example from log file:
19.07.2010, 09:27:19,, [_GET], p: INT param not INT, 26 ///?_SERVER[DOCUMENT_ROOT]=, GET, /index.php, Mozilla/5.0,

Here the attack payload.


WordPress security under pressure

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,, [_GET], Global VAR overwrite detected, _SERVERDOCUMENT_ROOT, GET, /index.php, libwww-perl/5.79,

06.09.2009, 18:04:58,, [_GET], p: INT param not INT, 446//index.php?str=, 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„).
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

SSEQ-LIB installation

Create two additional folders on your web server: sseq-lib and sseq-filter.

Put the content of the filter ZIP („“ or similar) into the folder: sseq-filter

UnZIP the SSEQ-LIB 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:



On your web server the SSEQ-LIB structure should look like this:

|- sseq-lib
| |
| |- seq_lib
| |- seq_log
| |- seq_dump
|- sseq-filter
|- wp-includes

You’re done!

Testing SSEQ-LIB installation

Now go to your blog and try something like: „“ 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.

Tags: ,

Gegen Cross-Site-Request-Forgery absichern

Montag, Juli 20th, 2009 | Dokumentation, PHP, Sicherheit, sseq-lib | 17 Kommentare

CSRF, der schlafende Gigant tritt immer mehr in Erscheinung, mehr als Analyse und weniger in Form einfach anzuwendender Lösungen für Jedermann.

Die Sicherheitsbibliothek SSEQ-LIB stellt zum Schutz gegen CSRF Tokens bereit, die in Links und Formulare eingebaut und bei der Ausführung überprüft werden. Die Tokens tragen Namen, sodass ihre Gültigkeit für bestimmte Bereiche der Webapplikation eingeschränkt werden kann und können außerdem eine einmalige Gültigkeit aufweisen, z.B. bei der Verwendung in Login-Masken.

Beispiele der Verwendung in eine Webapplikation:

‚ . SEQ_FTOKEN(‚kontaktformular‘) . ‚

// Erzeugt z.B.:

// Setzen eines Link-Tokens
$formular = ‚LISTE

// Erzeugt z.B.:


Dort, wo die entsprechend vorbereiteten Formulare oder Links ausgeführt werden, werden die Tokens geprüft:



Je nach Einstellung reagiert SSEQ-LIB auf fehlende, falsche und abgelaufene Tokens mit einer Umleitung, Logout des Nutzers oder einer Antwortverzögerung. Diese können auch kombiniert werden. Zusätzlich – wenn in der Config eingeschaltet – muss der verwendete Browser der selbe sein, der bei der Erzeugung des Tokens verwendet wurde.


Zu finden unter: SERVERPFAD/sseq-lib/seq_lib.php

Tokens gültig nur vom selber Webbrowser aus

Maximale Lebenszeit eines Tokens
$_SEQ_TOKENLIFETIME = 7200; /* zwei Stunden */

Reaktion bei ungültigen Tokens
ANMERKUNG: Gilt für alle Prüfungen der SSEQ-LIB!
$_SEQ_IDS_ONATTACK_ACTION = ‚logout redirect delay‘;

Tags: ,