WordPress is the most popular blogging software written in PHP and   MySQL. Years ago we had played with the software when blogging was considered a hobby by the Internet savvy. Now a days, blogging is more and more accepted as a desirable online communication media for spreading and sharing ideas, news and opinions among groups of people within organizations.

A few years ago, we standardized on Wiki-based online commucation for our teams. We find wiki to be very suitable for project documentation: specifications, meeting notes, status reports, Q&A etc. However, recently we decided to give our teams a more informal idea sharing platform — a WordPress blog per team. We are very familiar with WordPress blog from the very beginning; in fact, our very first WordPress blog ran on a IBM thinkpad x600 for over a year before we shut it down. Our recent decision to provide each team with an internal WordPress had two-fold objectives:

• Deploy internal team blogs using WordPress
• Explore the WordPress code, plugin development as part of our R&D

 Pre-requisites for WordPress

WordPress uses MySQL database and therefore we created a new database called <team_evoknow_blog> for for each team blog and created appropriate grant privileges using the following sample GRANT statement:

GRANT ALL PRIVILEGES ON database_name.* 
   TO 'username'@'hostname' IDENTIFIED BY 'secret_passsword';

We ran FLUSH PRIVILEGES; command on the MySQL server to ensure that the new database can be readily accessible by the username from the hostname mentioned in the GRANT statement.

Getting Started

Next, we downloaded the latest stable version of the WordPress software from: http://wordpress.org/latest.tar.gz. We extracted the WordPress source code in the document root directory of the Web server using tar xvzf latest.tar.gz, which created a new directory in the Web site. We renamed the directory to reflect the team name. We also changed the file permissions to allow WordPress to read+write in the wp-contents sub directory.

Getting Started (cont.)

Next, we copied the sample wp-config-sample.php to wp-config.php. We also edited this file to modify the default database access information to allow WordPress installer to access our newly created empty database. The lines we changed are as follows:

define('DB_NAME', 'blog');           
define('DB_USER', 'blog_dba');       
define('DB_PASSWORD', 'yoursecret');

Finally, we were ready to install WordPress using the Web-based installer that can be run from http://server/<wordpress directory>/

Running WordPress Web Installer

The Web-based installer is very simple and therefore we will not discuss details here. Only one setting worth mentioning was that we unchecked the search option since we did not want the blog to be searchable from the Internet.

Changing Admin Password

Once logged in as the administrator using the generated password, we immediately changed the generated password to a new one.

 Allowing Self-registration for Users

The idea of an informal blog to allow users to access it easily and without needing approvals from anyone. Why manage user accounts and complicate admin’s life? Instead, let the user register and get started with blogging. Therefore, we choose to allow self-registration by users; and followed the instructions below:

• Clicked on Dashboard >> Settings >> General link on the Dashboard
• Checked “Anyone can register” in the Membership section
• Checked “Users must be registered and logged in to comment”
• Set “New User Default Role” to be “Author”

FYI, you can review this link to learn more about user roles and capabilities.

Check Point: What Have We Got So Far?

We have the blog up and running and anyone can register and start blogging. Now, we need to restrict access to the blog using IP adress and also throw in a highly restrictive robots.txt for peace of mind. The goal is to allow access to the blog from office LAN and forbid any Web spiders from indexing any page. We know that IP restriction will stop the spiders but there is nothing wrong with a two-line robots.txt to increase peace of mind. The robots.txt we installed in the blog directory had two lines:
User-agent: *
Disallow: /

Restricting Access to the Blog

To block all access to the blog from outside, we configured Apache to have the following directives:

# Use a redirect page to say sorry to users 
   # when they try to access the internal blog from outside
   ErrorDocument 403 http://server/sorry.html
   <Limit GET POST>
     Order Deny,Allow
     Deny from all
     # Add your office router IP address
     Allow from 1.2.3.4
   </Limit>

Our Web server that runs the blog site is on the Internet and thus the above-mentioned configuration is necessary. If yours is inside your LAN, this configured is not needed.

Check Point: Day After Blog in Announced

We annouced the availability of team blogs on our Wiki home page, which many of our users visit daily. Within a day, most of usual suspects with a voice signed up and started postings. A good mix of technical and non-technical posts started appearing daily — sharing has begun!

Counting Our Benefits

Many companies worry about making blogs available to employees becuase they fear sharing could lead to office politics, rumors, confusion and overall waste of paid time. We are not expert in corporate behavior trends and analysis; all we can report is that sharing works for us. It allows us to discover in-house talent that are often behind the scene and also improves writing skills — a rare jem among software engineers.

Next Step: Automated Posting via Email

We immediately realized that if we can automate postings from other tools that we use, we can inform everyone about birthdays, other events and highlight interesting stories from outside sorces.

To automate posts, we explored the email-to-blog capabilities of WordPress using the wp-mail.php as a POP3 mail box reader run via a cron job.

We were able to post simple messages by sending emails to the blog but we needed fancier capabilities like posting rich-media (HTML, image, audio, video) via email. Unfortunately, wp-mail.php did not handle rich-media at all. Google searches for plugins to do the same job resulted in finding plugins that do not work well and are written very poorly. We decided this is an area where we can devleop a plugin of our own. This plugin project have already started and will be made available to WordPress community when we are ready with an alpha version.

WordPress Look & Feel Customization
We wanted to change the look and feel of the default blog and found that WordPress theme concept is acceptable for most look and feel customization.
However, we did not quite like the fact that our UI designers needed to have full administrative access to change the theme CSS and other templates. If WordPress allowed a maintenance account role, we would have appreciated it more.
As a workaround, to avoid giving our UI designers access to the admin accout, we simply gave them sendbox blog where they perfected the look and feel with CSS and template changes. Once they were done, we replaced the template files using the Admin account.
Putting on PHP Developer Hat: Code Review
From the early days, we were not too excited about how WordPress uses the traditional “glue-PHP” concept in presentation and business logic separation. It was disappointing to see that WordPress in 2008 still uses embedded PHP scripts in presentation layer instead of using a template engine like Smarty or similar technologies. From developer’s point of view, we are not ready to give WordPress a five-star rating but from popularity and usability point of view it has alreay earned such rating throughout the world. We are now WordPress users.

I found CWE/SANS Top 25 Most Dangerous Programming Errors list, and actually it’s important, and deserves a wide audience, so I’m repeating it here with ‘Jeff Atwood‘ hand-edited summary of each error.

If you work on software in any capacity, at least skim this list. I encourage you to click through for greater detail on anything you’re not familiar with, or that piques your interest.

1. Improper Input Validation
   

   Ensure that your input is valid. If you’re expecting a number, it shouldn’t contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today’s most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.

2. Improper Encoding or Escaping of Output
   

   Insufficient output encoding is at the root of most injection-based attacks. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application – not to mention exposing the other components to exploits that the attacker would not be able to launch directly. When your program generates outputs to other components in the form of structured messages such as queries or requests, be sure to separate control information and metadata from the actual data.

3. Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
   

   If attackers can influence the SQL that you send to your database, they can modify the queries to steal, corrupt, or otherwise change your underlying data. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security.

4. Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
   

   Cross-site scripting (XSS) is a result of combining the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you’re not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you — because, after all, it did come from you! Suddenly, your web site is serving code that you didn’t write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man.

5. Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
   

   Your software acts as a bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, and you allow untrusted inputs to be fed into the command string, you are inviting attackers into your operating system.

6. Cleartext Transmission of Sensitive Information
   

   Information sent across a network crosses many different nodes in transit to its final destination. If your software sends sensitive, private data or authentication credentials, beware: attackers could sniff them right off the wire. All they need to do is control one node along the path to the final destination, any node within the same networks of those transit nodes, or plug into an available interface. Obfuscating traffic using schemes like Base64 and URL encoding offers no protection.

7. Cross-Site Request Forgery (CSRF)
   

   Cross-site request forgery is like accepting a package from a stranger — except the attacker tricks a user into activating a HTTP request “package” that goes to your site. The user might not even be aware that the request is being sent, but once the request gets to your server, it looks as if it came from the user — not the attacker. The attacker has masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application’s functionality.

8. Race Condition
   

   A race condition involves multiple processes in which the attacker has full control over one process; the attacker exploits the process to create chaos, collisions, or errors. Data corruption and denial of service are the norm. The impact can be local or global, depending on what the race condition affects – such as state variables or security logic – and whether it occurs within multiple threads, processes, or systems.

9. Error Message Information Leak
   

   Chatty error messages can disclose secrets to any attacker who misuses your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. They might seem like harmless secrets useful to your users and admins, such as the full installation path of your software — but even these little secrets can greatly simplify a more concerted attack.

10. Failure to Constrain Operations within the Bounds of a Memory Buffer
    

    The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. Attack and detection techniques continue to improve, and today’s buffer overflow variants aren’t always obvious at first or even second glance. You may think that you’re completely immune to buffer overflows because you write your code in higher-level languages instead of C. But what is your favorite “safe” language’s interpreter written in? What about the native code you call? What languages are the operating system API’s written in? How about the software that runs Internet infrastructure?

11. External Control of Critical State Data
    

    If you store user state data in a place where an attacker can modify it, this reduces the overhead for a successful compromise. Data could be stored in configuration files, profiles, cookies, hidden form fields, environment variables, registry keys, or other locations, all of which can be modified by an attacker. In stateless protocols such as HTTP, some form of user state information must be captured in each request, so it is exposed to an attacker out of necessity. If you perform any security-critical operations based on this data (such as stating that the user is an administrator), then you can bet that somebody will modify the data in order to trick your application.

12. External Control of File Name or Path
    

    When you use an outsider’s input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple “..” or similar sequences to cause the operating system to navigate out of the restricted directory. Other file-related attacks are simplified by external control of a filename, such as symbolic link following, which causes your application to read or modify files that the attacker can’t access directly. The same applies if your program is running with raised privileges and it accepts filenames as input. Similar rules apply to URLs and allowing an outsider to specify arbitrary URLs.

13. Untrusted Search Path
    

    Your software depends on you, or its environment, to provide a search path (or working path) to find critical resources like code libraries or configuration files. If the search path is under attacker control, then the attacker can modify it to point to resources of the attacker’s choosing.

14. Failure to Control Generation of Code (aka ‘Code Injection’)
    

    While it’s tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing. It becomes a serious vulnerability when your code is directly callable by unauthorized parties, if external inputs can affect which code gets executed, or if those inputs are fed directly into the code itself.

15. Download of Code Without Integrity Check
    

    If you download code and execute it, you’re trusting that the source of that code isn’t malicious. But attackers can modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs updates.

16. Improper Resource Shutdown or Release
    

    When your system resources have reached their end-of-life, you dispose of them: memory, files, cookies, data structures, sessions, communication pipes, and so on. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. Attackers may sift through the disposted items, looking for sensitive data. They could also potentially reuse those resources.

17. Improper Initialization
    

    If you don’t properly initialize your data and variables, an attacker might be able to do the initialization for you, or extract sensitive information that remains from previous sessions. If those variables are used in security-critical operations, such as making an authentication decision, they could be modified to bypass your security. This is most prevalent in obscure errors or conditions that cause your code to inadvertently skip initialization.

18. Incorrect Calculation
    

    When attackers have control over inputs to numeric calculations, math errors can have security consequences. It might cause you to allocate far more resources than you intended – or far fewer. It could violate business logic (a calculation that produces a negative price), or cause denial of service (a divide-by-zero that triggers a program crash).

19. Improper Access Control (Authorization)
    

    If you don’t ensure that your software’s users are only doing what they’re allowed to, then attackers will try to exploit your improper authorization and exercise that unauthorized functionality.

20. Use of a Broken or Risky Cryptographic Algorithm
    

    Grow-your-own cryptography is a welcome sight to attackers. Cryptography is hard. If brilliant mathematicians and computer scientists worldwide can’t get it right — and they’re regularly obsoleting their own techniques — then neither can you.

21. Hard-Coded Password
    

    Hard-coding a secret account and password into your software is extremely convenient — for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it’s hard-coded, it’s a huge pain to fix.

22. Insecure Permission Assignment for Critical Resource
    

    Beware critical programs, data stores, or configuration files with default world-readable permissions. While this issue might not be considered during implementation or design, it should be. Don’t require your customers to secure your software for you! Try to be secure by default, out of the box.

23. Use of Insufficiently Random Values
    

    You may depend on randomness without even knowing it, such as when generating session IDs or temporary filenames. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used, he can guess the next random number often enough to launch a successful attack after a relatively small number of tries.

24. Execution with Unnecessary Privileges
    

    Your software may need special privileges to perform certain operations; wielding those privileges longer than necessary is risky. When running with extra privileges, your application has access to resources that the application’s user can’t directly reach. Whenever you launch a separate program with elevated privileges, attackers can potentially exploit those privileges.

25. Client-Side Enforcement of Server-Side Security
    

    Don’t trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what your security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.