Tuesday, May 15, 2007

Blogs: What is Hot and What is Not

Although podcasting has surpassed the popularity of blogging, that doesn’t mean blogging is a dying art. If you take the time to browse around the Internet, you’ll see that blog hosting communities are still rapidly growing. If you’re not yet part of this crowd, check it out to experience the fun and excitement.

Pressing the Keys at applications. Newbies and advanced users will enjoy blogging at WordPress with the many features available for use such as entry previews, blog categories and blogrolls.

Thumbs-Ups: You can add plug-ins and customize your blog layout. WordPress also provides constant updates for their users.

Thumbs-Down: A bit of software knowledge is required to properly install WordPress. If you have enabled commenting in your site, don’t be surprised to find that more than a few spammers are developing a habit of dropping by your site. [Ed. Note: I've definitely found this to be the case. Having anti-spam filters like Akisimet in place is important to keep on top of the spam issue.]

Fire up at FeedBurner

Is your blog is worth broadcasting? If so, you should consider moving from your old blog community to FeedBurner. At FeedBurner, they help you create content and spread the word about your blog as well.

Thumbs-Ups: With the standard free package, FeedBurner allows you to set up the configuration for your blog for easy posting and even use an RSS subscription button to automatically update the readers of your blog. The Web site gives you information about the average number of visits your blog has per day along with other traffic statistics. You can earn money on the sideline from by adding Google Ads in your blog.

Thumbs-Down: The template editing section of FeedBurner isn't easy to master.

Everything in One at Multiply

If you wish to blog, upload photos, videos, music files, write reviews and post your social calendar with one Web site, all you have to do is sign up for an account at Multiply.

Thumbs-Ups: Photo uploading is virtually unlimited, images can be classified by albums and given captions. Skin choices are provided to give your blogs more color and life and RSS feeds are allowed.

Thumbs-Down: When writing reviews, Multiply doesn’t give users much freedom to customize content by font type or color. Layouts can be edited…but only if you have CSS knowledge and even with that, customization is still limited. The smiley list is woefully inadequate.

Live and Write Freely at LiveJournal

With a hip nickname such as “LJ,” LiveJournal is a Web site that’s designed for the fun-loving crowd on the go.

Thumbs-Ups: Bonds forged online are strengthened by LJ’s email notifications for commenting. If someone comments in your blog, an email will inform you of it. Additionally, an email will be sent to you if your comment on someone else’s LJ receives a reply ­ whether it’s from the blog owner or another blogger doesn’t matter.

Thumbs-Down: LJ isn't easy to customize. Some features offered for free by other blog hosts are only for LJ members with paid accounts.

Be In Vogue at Xanga

Teenagers seem to be enamored with Xanga. If you want a blogging process that’s easy and stylish at the same time, Xanga is the blog host for you.

Thumbs-Ups: Besides having community-based blogging, each post allows you to inform your readers what you’re reading, watching or playing. You can also upload photos, music and write categorized reviews. A guest book is automatically offered to users.

Thumbs-Downs: Although Xanga allows users to use RSS feeds; it takes time to properly integrate it in their blogs. The layout options are limited, the URL for members is a mouthful and commenting is reserved for Xanga members only.

Conclusion

Which blog hosting site do you plan to choose? Wherever you end up blogging, we wish you well! Blog on!

Security Techniques for PHP

With more and more personal information being stored on the Web—credit card data, social security numbers, maiden names, favorite pets—today's PHP developer cannot afford to be ignorant when it comes to security. Sadly, most beginning programmers fail to understand the truth about security: there is no such thing as "secure" or "insecure." The wise programmer knows that the real question is how secure a site is. Once any piece of data is stored in a database, in a text file, or on a Post-it note in your office, its security is compromised. The focus in this chapter is therefore how to make your applications more secure.

This chapter will begin by rehashing the fundamentals of secure PHP programming. These are the basic things that I hope/assume you're already doing. After that a quick example shows ways to validate different kinds of data that might come from an HTML form. The third topic is the new-to-PHP 5 PECL library called Filter. Its usage isn't very programmer-friendly, but the way it wraps all of the customary data filtering and sanitizing methods into one interface makes it worth knowing. After that, two different uses of the PEAR Auth package show an alternative way to implement authorization in your Web applications. The chapter will conclude with coverage of the MCrypt library, demonstrating how to encrypt and decrypt data.

Remembering the Basics

Before getting into demonstrations of more particular security techniques, I want to take a moment to go over the basics: those fundamental rules that every PHP programmer should abide by all of the time.

To ensure a basic level of security

  1. Do not rely upon register_globals.

    The advent of register_globals once made PHP so easy to use, while also making it less secure (convenience often weakens security). The recommendation is to program as if register_globals is off. This is particularly important because register_globals will likely disappear in future versions of PHP.

  2. Initialize variables prior to using them.

    If register_globals is still enabled—even if you aren't using them—a malicious user could use holes created by noninitialized variables to hack your system. For example:

    1if (condition) {
    2 $auth = TRUE;
    3}

    If $auth is not preset to FALSE prior to this code, then a user could easily make themselves authorized by passing $_GET['auth'], $_POST['auth'], or $_COOKIE['auth'] to this script.
  3. Verify and purify all incoming data.

    How you verify and purify the data depends greatly upon the type of data. You'll see many different techniques in this chapter and the book.

    Avoiding Mail Abuses

    A security concern exists in any Web application that uses the mail() function with form data. For starters, if someone enters their "to" email address as someone@example.com,someone.else@example.com, you'll now be sending two emails. If a malicious user enters 500 addresses (perhaps by creating their own form that submits to your same page), you're now sending out spam! You can avoid this by using regular expressions to guarantee that the submitted value contains just one address. Or you could search for a comma in the submitted email address, which wouldn't be allowed. But that won't solve the problem entirely.

    Although the mail() function takes separate arguments for the "to" address, "from" address (or other additional headers), subject, and body, all four values are put together to create the actual message. By submitting specifically formatted text through any of these inputs, bad people can still use your form to send their spam. To guard against this, you should watch for newline (\n) and carriage returns (\r) within the submitted data. Either don't send emails with these values or replace them with spaces to invalidate the intended message format. You should probably also make sure that you (or someone involved with the site) receives a copy of every email sent so that close tabs can be kept on this area of the server.

  4. Be careful if you use variables for included files.

    If your code does something like

    require($page);

    then you should either make sure that $page does not come from an outside source (like $_GET) or, if it does, that you've made certain that it has an appropriate value. See the technique in Chapter 2, "Developing Web Applications."

  5. Be extra, extra careful when using any function that runs commands on the server.

    This includes eval(), exec(), system(), passthru(), popen(), and the backticks (``). Because each of these runs commands on the server itself, they should never be used casually. And if you must use a variable as part of the command to execute, perform any and all security checks on that variable first. Also use the escapeshellarg() and escapeshellcmd() functions as an extra precaution.

  6. Consider changing the default session directory or using a database to store session data.

    An example as to how you would do this is discussed in Chapter 3, "Advanced Database Concepts."

  7. Do not use browser-supplied filenames for storing uploaded files on the server.

    When you move a file onto your server, rename it to something safe, preferably something not guessable.

  8. Watch for HTML (and more important, JavaScript) in submitted data if it will be redisplayed in a Web page.

    Use the strip_tags() or similar functions to clear HTML and potential JavaScript from submitted text.

  9. Do not reveal PHP errors on live sites.

    One of the most common ways to hack a site is to try to "break" it—do something unexpected to cause errors—in the hopes that the errors reveal important behind-the-scenes information.

  10. Nullify the possibility of SQL injection attacks.

    Use a language-specific database escaping function, like mysqli_real_escape_data(), to ensure that submitted values will not break your queries.

  11. Program with error reporting on its highest level.

    While not strictly a security issue, programming with error reporting on its highest level can often show potential holes in your code.

  12. Never keep phpinfo() scripts on the server.

    Although vital for developing and debugging PHP applications, phpinfo() scripts reveal too much information and are too easily found if left on a live site.

Monday, May 14, 2007

Google searches web's dark side

One in 10 web pages scrutinised by search giant Google contained malicious code that could infect a user's PC.

Researchers from the firm surveyed billions of sites, subjecting 4.5 million pages to "in-depth analysis".

About 450,000 were capable of launching so-called "drive-by downloads", sites that install malicious code, such as spyware, without a user's knowledge.

A further 700,000 pages were thought to contain code that could compromise a user's computer, the team report.

To address the problem, the researchers say the company has "started an effort to identify all web pages on the internet that could be malicious".

Phantom sites

Drive-by downloads are an increasingly common way to infect a computer or steal sensitive information.

They usually consist of malicious programs that automatically install when a potential victim visits a booby-trapped website.

"To entice users to install malware, adversaries employ social engineering," wrote Google researcher Niels Provos and his colleagues in a paper titled The Ghost In The Browser.

"The user is presented with links that promise access to 'interesting' pages with explicit pornographic content, copyrighted software or media. A common example are sites that display thumbnails to adult videos."

The vast majority exploit vulnerabilities in Microsoft's Internet Explorer browser to install themselves.

Some downloads, such as those that alter bookmarks, install unwanted toolbars or change the start page of a browser, are an annoyance. But increasingly, criminals are using drive-bys to install keyloggers that steal login and password information.

Other pieces of malicious code hijack a computer turning it into a "bot", a remotely controlled PC.

Drive-by downloads represent a shift away from traditional methods of infecting a computer, such as spam and email attachments.

Attack plan

As well as characterising the scale of the problem on the net, the Google study analysed the main methods by which criminals inject malicious code on to innocent web pages.

It found that the code was often contained in those parts of the website not designed or controlled by the website owner, such as banner adverts and widgets.

Widgets are small programs that may, for example, display a calendar on a webpage or a web traffic counter. These are often downloaded from third-party sites.

The rise of web 2.0 and user-generated content gave criminals other channels, or vectors, of attack, it found.

For example, postings in blogs and forums that contain links to images or other content could unwittingly infect a user.

The study also found that gangs were able to hijack web servers, effectively taking over and infecting all of the web pages hosted on the computer.

In a test, the researchers' computer was infected with 50 different pieces of malware by visiting a web page hosted on a hijacked server.

The firm is now in the process of mapping the malware threat.

Google, part of the StopBadware coalition, already warns users if they are about to visit a potentially harmful website, displaying a message that reads "this site may harm your computer" next to the search results.

"Marking pages with a label allows users to avoid exposure to such sites and results in fewer users being infected," the researchers wrote.

However, the task will not be easy, they say.

"Finding all the web-based infection vectors is a significant challenge and requires almost complete knowledge of the web as a whole," they wrote.