[Dev] Forcing A Download For Files On Web Pages

Something interesting happened today. I was working on a project for a client and the requirement was a file upload and downloadable system (with login of course :) ).. I had completed most of the stuff like login, uploading docs and the right click “save as” worked like a charm. BUT with the latest browsers like chrome and IE9\10, on clicking the link to the document, the files were getting opened either using Google Document Viewer or inside the browser itself – which was a no no for my client..

After trying to pick my brain for couple of hours I figured it could be a server thing and all I had to do was to make sure that I pass the correct header for the respective files (could be .zip, .doc or .pdf or . anything else).

Then it flashed!

I figured it out… The problem was a server problem. Since I was using the WordPress framework to build the site, the header was automatically passed for content and hence the files would open-up inside the browsers. I had to add a small code – just 4 lines in order to make this happen. Here’s what I wrote in order to force the data download:

<FilesMatch “\.(?i:pdf|doc|docx|xls|xlsx|txt|zip)$”>
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

And that was it! All those hours of brain picking finally paid off :)

I added the above code to the .htaccess file and the rest was taken care by my server :) Let me explain the above code:

 

  • FilesMatch: Simply tells the apache server for the document types. Here I only need to make .doc, .pdf, .zip etc as downloadable.
  • ForceType application/octet-stream: This told apache that the file types listed above is a generic content (MIME) type. So the browser should try to will always show the “open with” or “save as” download dialog if a server sends a file with such a MIME type.
  • Header set Content-Disposition attachment: Then I set the header of the webpage manually and woah! We’re done and that’s it!

For anyone having similar trouble.. Hope this helps!

Deleting Multiple Pending Posts and Post Revisions Instantly from WordPress Using MYSQL Scripts

Have you ever tried deleting multiple posts (more than 500posts) from the WordPress admin panel before? If you’ve tried you’ll know that it fails! Yes it fails hopelessly.

I know that there are lots of Bulk delete WordPress plugins out there in the WordPress repository that can do the job. But how do you delete multiple pending posts, post revisions if there are way too many posts? (Say more than 2000 posts)

I’m not exaggerating things here guys. I had this exact problem myself and some of my friends who had guest posts enabled in WordPress faced the same issue too. So HOW do you delete multiple posts instantly in WordPress? The bulk delete plugin timed out on me and I was left wondering how else can I get the deletion work done easily?

Then I realized it ‘MySQL’! Yes, MySQL can do this for me and within no time at all. It took me less than 5 minutes to delete all the pending (spam) posts from WordPress. So this is me contributing to the WordPress ecosystem by sharing how I achieved what I needed!

>> Login to your MYSQL and select the SQL tab from the MYSQL window.

 

Step1 – Searching and deleting all Pending Posts in Bulk:

SELECT * FROM `wp_posts` WHERE `post_status` LIKE 'pending'

This fetches all the posts that are NOT yet published and which are in the pending state.

DELETE FROM `wp_posts` WHERE `post_status` LIKE 'pending';

This SQL query removes all the posts that are currently in pending state.

SELECT * FROM `wp_posts` WHERE `post_status` LIKE 'pending';

Now run the select statement again to see if the deletion of pending posts worked.

Once you’ve removed all the pending posts from WordPress. You would need to check the revisions made on those posts. These still do exist in WordPress and would consume some space.

Step2 – Searching and deleting all Post Revisions Posts in Bulk:


Thanks bacsoftwareconsultine for the image

Select * FROM wp_posts WHERE post_type = "revision";

Fetches all the posts that are currently under revisions state.

DELETE FROM wp_posts WHERE post_type = "revision";

Deletes all the post revisions.

Select * FROM wp_posts WHERE post_type = "revision";

Running the select statement to see if it worked!

Warning: To be tried only if you know a little bit of SQL (Structured Query Language) or you might end up screwing up your WordPress setup..

Need help? or Have you faced any other similar issues in bulk deletion of content from WordPress? Share your comments below!

Fix The Thumb.php or Timthumb.php WordPress Vulnerability

One of the WordPress site that I manage was recently hacked. Yes hacked! I’m going to explain the main reason on how my site was easily defenseless against the attacker.

I used the Woo Canvas theme and had already taken all the WordPress security measures to protect my site but still the hacker was successful in hacking the main page. How did this happen? Is WordPress safe? How do I avoid it? Is it going to happen again? What if it happens again? How do I prevent it from happening again? Tons of questions started in my mind.

Also, being a vivid Web Dev Geek myself, the other part of my brain started asking questions like how did he break in? I need to meet this guy, what technique did the hacker use?

So here’s what I did:

-          Looked at the server logs

-          Found out where more requests were coming from

-          Found the vulnerability in my theme file

-          Find and remove any suspicious files

#1. Look at the server logs

This is the most common thing anyone should do when the site gets hacked or hijacked. Where do you find it you ask? Simple, it should be available in the control panel. Or if you are using an FTP client, simple search for a file called error_log and open with notepad

When I looked at the logs I found out there were many unnecessary requests made to the thumb.php file from a particular IP. Since the hack happened a few minutes ago, I was able to easily identify who the real culprit was by seeing the logs.

#2. Found a pattern

Multiple accesses to my /wp-content/themes/headlines/thumb.php file. I wasn’t really sure why there were so many requests to the same file but was really surprised.

Then I looked the file access time. This time coincidentally matched the same time when the site was hacked. SO I Googled my find “thumb.php exploit” to find About 1,360,000 results. When I read through the list, I got to know that I wasn’t the first one to be exploited. It was already done – A lot of times, to a lot of websites.

#3 Concluded that My old theme file was screwing me

Yes an old theme file I had was used to screw me over. I was under the impression that the user was using the latest woo canvas theme’s thumb.php file but it wasn’t the case. The hacker somehow managed to find the inactive but still available in the wp-contact/themes folder theme.

#4 Finding any left over files by the hacker

Hackers usually do leave some piece of code behind, so that can whop the sites again. So make sure to compare your WordPress installation files code with the real file. (http://phpxref.ftwr.co.uk/wordpress was extremely helpful)… Looked into the cache folder to find 2 weird files – 1. externl_28ajssjlaax.php and 2.wsob.php file. Deleted it.

How to fix it and make sure this never happens again?

There are 3 main things that need to be done here.

-          Update the Thumb.php or Timthumb.php file

-          Remove the sites from thumb.php

-          Add a .htaccess file to your cache directory

#1 Update the file

The original source repository for thumb.php is located on the code.google.com website.Visit the site and update\replace the thumb.php or timthumb.php file with the new one.

 

#2. Remove sites

//external domains that are allowed to be displayed on your website
$allowedSites = array();

These are used to fetch and cache images from external sites.

 

#3. Add an .htaccess to the cache directory

Now that we’ve updated and patched the thumb.php or timthumb.php file we’d probably need to forbid anyone ever from accessing or stashing something in your cache folder.

Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi

Upload a new .htaccess file to the cache directory with the following code

 

Oh and the hacker claims himself to be “Hmei7” – would love to meet him though :) . I’m probably going to send an email out to all my WordPress clients to let them know to update their thumb.php files and follow the same steps I used. Being cautious is better than being hacked cautiously ;) Hail WordPress!

Thanks Mark!