• I have previously requested Anti-Hacking Checksums.

    Now – just to keep everybody busy – I would like to ask for automated database integrity checks. The following background has been added to my blog post on the subject:

    The database has a table, wp_postmeta, which tracks attachments. One record in this table has the values: meta_id=8474, post_id=2181, meta_key = ‘_wp_attached_file’, meta_value=’/services1/webpages/p/r/prefblog.com
    /public//../../../../../../../../../../../../../../../../../tmp/10bum.txt’

    There is also: meta_id=8472, post_id=2180, meta_key = ‘__wp_attached_file’, meta_value = ‘/services1/webpages/p/r/prefblog.com
    /public//../../../../../../../../../../../../../../../../../tmp/2newbum.txt’

    These records have been removed.

    I have also deleted some entries in the wp_posts table. As far as I can make out from the WordPress codex the value of ‘post_parent’ should reference a ‘post_id’ in the same table, which are all positive integers.

    After noting some odd entries, I queried the database: ‘select * from wp_posts where post_parent < 0’ and came up with seven records. Two have post_parent set to numbers that are large and negative; the ‘guid’ field indicates that this is stuff that I did, in fact, upload but somehow screwed up.

    The remaining 5 records all have post_parent set to -1, with ‘guid’ having a variety of values: the first one, with ‘post_modifed’ = ‘2008-03-25 05:26:58’ has ‘guid’ = ‘http://www.prefblog.com
    //../../../../../../../../../../../../../../../../../tmp/3rbsmag.txt’. The other entries are similar, with filenames 10bum.txt (three times) and 2newbum.txt.

    All these records have been deleted. Note that with these long field values, I have added a HTML line-break to make the full field look nice on this post.

    I note that the first of these highly suspicious entries occurred within a week of my WP 2.3.3 installation!

    It seems to me to be clear that a negative value for post_parent is simply wrong. A suite of functions whereby I could automatically validate the database for such things would be very useful.

Viewing 1 replies (of 1 total)
  • Suggest it as an enchancement on the tracker.

    However, I think such things are best as part of an optional plugin. I have no interest in checking for data validity when the site is working, and I wouldn’t want to sacrifice site performance for the sake of having such checks ran on any kind of regular basis.

    What you seem to be describing is occurences where your installation has been hacked and spurious data inserted. Whilst it’s good to be able to find such things, I’m not convinced that it’s best to be doing it from inside the (potentially) hacked application.

Viewing 1 replies (of 1 total)
  • The topic ‘Database integrity checks’ is closed to new replies.