Wordpress deleted file info "UPDATE wp_options SET option_value" - wordpress

I am working on a forensics course, with which I have been looking into an attack on a blog server. I have found a number of deleted Wordpress files, and I have managed to figure out which ones contained blog posts.
The one file I cannot figure out contains information beginning with the following:
wordpress#UPDATE wp_options SET option_value = 'O:9:\"MagpieRSS\":19:{s:6:\"parser\";i:0;s:12:\"current_item\";a:0:{}s:5:\"items\";a:10:{i:0;a:9:{s:5:\"title\";s:37:\"India Vs Pakistan: Now Cyber Terror? \";s:6:\"author\";s:8:\"chinchak\";s:4:\"link\";s:59:\"http://feeds09.technorati.com/~r/trarticles/~3/sxlCqi2M9aE/\";s:4:\"guid\";s:74:\"http://technorati.com/politics/article/india-vs-pakistan-now-cyber-terror/\";s:11:\"description\";s:182:\"The India-Pakistan relations could very well be termed the greatest mystery ever of mankind.\";s:7:\"pubdate\";s:31:\"Tue, 21 Aug 2012 00:03:41 +0000\";s:8:\"category\";s:51:\"PoliticsAssam ViolenceCyber TerrorIndia Vs Pakistan\";s:10:\"feedburner\";a:1:{s:8:\"origlink\";s:74:\"http://technorati.com/politics/article/india-vs-pakistan-now-cyber-terror/\";}
It continues in this way for a while, but I haven't had too much luck trying to use Google to tell me what the "wp_options" means. It looks like someone was trying to spam the blog with commments but I can't be sure without a source which can confirm my view is correct. Can anybody help please?

The wp_option table stores key-value information in the columns option_name and option_value. When storing arrays they get serialized, to decode them you can use PHP's unserialize function. It looks like you're dealing with an SQL injection that tries to mess with Wordpress' user options. The purpose is not obvious, because they are rarely displayed. Just used internally. If there's a where clause somewhere in that SQL statement that tells you which option name it's trying to edit you could perhaps match it using this list:
http://codex.wordpress.org/Option_Reference

Related

Track of structure changes in a Progress database

I am asked to automate the tracking of changes in the structure of the database: Any modification, addition or removal of tables, fields, indexes, etc.
I have searched the audit but only found that it can track changes in the "Database schema", which is something else.
Do you know if it is possible to do that?
We use 11.6.3.
One wonders how those magical changes in the schema (I think you clarified that it was actually schema changes you wanted to automate) occur. Optionally it could be up to those making the changes to also keep track of them. Usually (hopefully) the database is updated using "delta df-files". Those df-files if kept are a changelog of the database.
Another option is to daily/hourly/weekly dump the data definitions:
CREATE ALIAS DICTDB FOR DATABASE sports.
DISPLAY LDBNAME("DICTDB").
RUN prodict/dump_df.p ("ALL",
"c:/temp/sports.df",
"").
DELETE ALIAS DICTDB. /* Optional */
Taken from this entry in the knowledge base: https://community.progress.com/s/article/15884
Then you can diff that df-file using your favorite tool or keep as it is.
If you actually mean structure (that's more how the data is stored in different files on disc) you can use the prostrct command to save a new st-file to disc:
prostrct list sports
This will save a file called sports.st. Handle it as above and you will have a changelog of the database structure.

Wordpress admin suddenly not an admin

I have installed a template that I bought, and this template came with a SQL script to run. After I ran it everything works fine, except that the admin user now doesn't have permission to delete articles, media, and other stuff.
I have complete access to the server along with knowledge of PHP and SQL. How can I fix this?
Check the wp_user_level value in the wp_usermeta table of your database. It should probably be 10.
Found the solution.
The original WordPress installation used a prefix for all table names. Apparently, fields in wp_users, wp_options and wp_usermeta whose names begin with "wp_" are supposed to begin with the full prefix.
I changed the table names in the script, but not the actual field names.
Setting the names to the full prefix solved this.
example:
if the prefix is wp_f3refs then wp_user-settings should be wp_f3refs_user-settings.
Thanks everyone for your help.

How to remove traces of Fields that belonged to a module content type?

I am trying to learn how to create a custom content type programmatically from within my module.
However, after uninstalling and reinstalling my module I was getting an error stating that one or more of the fields I was trying to create could not be created because they already exist.
So I went hacking through my databse, removing the content type and all tables that belonged to it.
Same result -- field already exists.
Next I went to the Drupal API website looking for ways to delete fields and field instances, and came across
field_delete_field()
and
field_delete_instance()
I made a php page to try to delete the fields that I had created, only to get an error stating that the table I was trying to delete does not exist.
So I'm kinda stuck -- I can't create the fields because they already exist, and I can't delete them because they don't exist!
BTW the code I was modeling my module after is the code found in the "node_example" section of the Drupal examples module.
Ouch, deleting the database tables manually is never a good idea - Drupal's not that forgiving :)
Just to address the code in your install/enable hook, wrap the field creation in:
if (!field_info_field('field_name')) {
field_create_field(...
}
That will stop the problem happening again. Or if you don't want to do that, make sure the field is deleted in the uninstall/disable hook. Obviously that method would potentially result in data loss.
To address the current problem, follow this process:
Completely uninstall (not just disable) your custom module. If it's in an inconsistent state, just delete its row in the system table.
Delete all traces of the field from the field_config and field_config_instance tables.
Truncate all the cache tables manually (any table beginning with cache_).
Not strictly necessary but clear up any lingering content:
$nids = db_query('SELECT nid FROM {node} WHERE type = :type', array(':type' => 'type'))->fetchCol();
node_delete_multiple($nids);
That ought to do it.
Any time you delete a field, through the UI or programatically you'll need to either run cron or call field_purge_batch() to 'hard' delete the fields as they're only marked for deletion in the first instance.

Beginning ASP.NET. using login name as sql parameter

Does anyone have some code or a link as to how to create the user login name as a parameter during a sql query in ASP.NET?
Basically I want to use the default membership structure with a new field ClubID, then I want to add a new table called aspnet_Clubs which contains things such as Club Name, stadium name, Balance etc etc... and then use a relationship between ClubID and a field in the aspnet_Clubs table to tie things together.
Then when each user logs in they should see the clubs information specific to their loginID.
I know the syntax to use for the query, its getting the loginname parameter and being able to use/assign it as part of the search that is causing me the problem.
In general it is not recommended to break the default schema of the aspnetdb where the Membership data is stored. It can bring you to unexpected consequences in the future.
I had a similar question a couple of days ago, please check it here, may be you will be able to adopt something from the discussion to your situation.

Wordpress wp_options option question?

Hello
Can anyone explain me what this mean :
a:2:{s:8:"scSlider";s:8:"featured";s:8:"npSlider";s:1:"4";}
How should I read these values?Tnx
Those are serialized options. When you use add_option() or update_option() with an array or object instead of a scalar value, WordPress serializes the data with serialize() before it puts it in the database. It's incredibly handy when you don't want to have to create a lot of different options in the database to save some values. This way you just put them all into an array and just save the array.
When you retrieve the data with get_option() WordPress will automatically unserialize the data into an array or object as well.
That looks familiar: it looks like a plugin option. As Pekka suggests, they use serialised arrays to pack multiple variables into a single database entry. (Use unserialize.)
I'm guessing you found it whilst doing something like:
SELECT *
FROM `wp_options`
WHERE 1
LIMIT 0 , 30
Unfortunately, without some idea of which plugin you have installed (I'm guessing it's a slider widget of some sort) it's unlikely that anyone will be able to tell you what the values mean.
Could I also suggest making use of the excellent Wordpress Stackexchange site?

Resources