Penetration Testing Content Management Systems
Today, I want to discuss how we do penetration tests of Content Management Systems (CMS) like Wordpress or more specialized CMS used for managing intranets and knowledge bases. Our approach to testing is quite familiar to our regular readers. Let’s review the basics of the approach:
- Create a Threat Profile for the CMS
- Create the Test Plan
- Perform the Tests
- Prepare the Report
A “Threat” is the goal of an adversary, it’s what the bad guys want to achieve. A “Threat Profile” is the list of all threats to an application. [For more about Threat Profiles, please read “Why We Love Threat Profiles”].
The Threat Profile is central to our testing methodology. For a Content Management System, the threat profile would include threats like:
- … publishes content on a site he is not authorized to
- … deletes published content from a site
- … modifies templates without authorization
- … adds editors and publishers without authorization
- … modifies the scheduled publishing date for an article
- … views the list of documents scheduled for publication
- … steals the passwords of other users
Notice these are the things an adversary might be interested in. Logically, that’s where we should start from.
It takes about half-a-day to two days to create the threat profile - that depends on the complexity of the CMS. We study the CMS, prepare a draft threat profile and then get your feedback. Our generic Threat Profile Repository helps accelerate this step. This repository is a collection of common threats we see many applications.
Once the Threat Profile is ready, we create the Test Plan for the CMS - the specific tests to perform for checking each threat. This is the intensely technical part of our test, when we visualize in the mind’s eye the various possibilities for attack.
The Test Plan connects each threat in the Threat Profile to specific pages on the CMS. For example, consider the threat, “The adversary publishes content on a site he is not authorized to”. The “Publish Content” page and the “Schedule for Future Date” page are the relevant pages for the threat. An adversary might try to exploit flaws in these pages to publish content without permissions.
Once we identify the right pages, then we identify all the attacks to try on those pages to realize that specific threat. For example, on the “Publish Content” page, we might decide to try a Variable Manipulation attack and a SQL Injection attack to publish content by escalating privileges. The Test Plan is thus prepared for all the Threats to the application. To assist our engineers, we have a master reference checklist of all attacks - they pick attacks for the Test Plan from that checklist.
Once the Test Plan is prepared, it’s reviewed and approved by a senior. The actual testing begins only after that. The tests are a combination of manual and automated checks. The penetration tester adheres to the original Test Plan. The test plan is updated when he gets new ideas during the test.
When an attack succeeds, we capture the screenshots of the attack. Our final report explains the attack step-by-step using these screen shots.
Any large application penetration test involves hundreds of test cases, so it’s important that we focus on the right set of test cases. We should, for instance, focus on whether a the terms of a plan can be modified than on generating error messages by tampering unimportant variables. The Threat Profile to Test Plan approach helps us focus our testing on the threats specific to CMS.
Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.Add yours.closed for this post.
- June 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- April 2007
- March 2007
- February 2007
- January 2007
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
You can read full entries of Palisade Blog using an RSS reader. Use this link —