Get started with managing Facebook App ads through OpenX

To manage your Facebook App ads through OpenX Hosted, you must have an OpenX Hosted account. If you don't already have an account, it's free to sign up.

Once you have logged into your OpenX Hosted account, follow these steps:

1. Add a website to represent your Facebook App.

Add a website


2. Add a zone. A zone represents a location on your Facebook App page where ads will display.

Add a zone


3. On the zone's Invocation Code tab, select the type "Facebook App Tag" then follow the directions to
get the demographic targeting script and the OpenX zone tag for your Facebook App ad.

zone invocation code


4. Add an advertiser.

Add an advertiser


5. Add a campaign. A campaign represents the collection of ads you will be delivering.

add a campaign


6. Add a banner. To add demographic targeting to your banner, select the desired targeting criteria on
the banner's Delivery Options tab. For your Facebook App ads, you will be able to select demographic
targeting criteria such as Age Group, Education, Gender and Relationship Status.

add banner


7. Link your banner to your zone. Go to your banner's Linked Zones tab and select the zone you created in step #2 to display your Facebook App ad.

add banner

That's all it takes to start serving Facebook App ads through OpenX.
Sign up for your free OpenX Hosted account to get started!

-->

That's all it takes to start serving Facebook App ads through OpenX.
Sign up for your free OpenX Hosted account to get started!

Loading mentions Retweet
Filed under  //  apps   facebook   website  
Comments (0)
Posted 3 days ago

Developer tools: what's in your box?

Hey software/web developer friends,

I've been keeping a list of the software that should come standard on our developer boxes (ya know, on the off chance Dustin and I ever get around to hiring someone), but I'm curious what tools other people are using that are sweet/useful. Here's what we've got (excluding SDKs and Unixy tools):

Windows and Mac
gvim
Firefox 3.0, Chrome 1.0, Safari 4
Firebug
FireScope [great find by Star]

Windows specific
cygwin
IE6, IE7, IE8 (is there something better than MultipleIEs for this?)
Microsoft Script Editor (for IE<8 debugging)
PuTTY
SharpKeys by RandyRants (for remapping Caps Lock)
Pixie by Nattyware (for determining the color of a pixel on the screen)
PrintScreen by Gadwin (for screenshots)
Free Extended Task Manager by Extensoft (task as in "OS process," not "project to-do")

Mac specific
Parallels (for IE testing)

Any additions? Any substitutions, cases where there's a better tool for the thing we're trying to accomplish?

Loading mentions Retweet
Filed under  //  apps   hardware   MicrosoftWindows   software  
Comments (0)
Posted 4 days ago

How to get local results on ShopSavvy

The most compelling feature about ShopSavvy is NOT the ability to scan a barcode, instead it is the ability to expose inventory and pricing information from local retailers.  In the Android version of ShopSavvy our standard screen had a Web tab and a Local tab that exposed the number of results for each.  If the user scans an item that we don’t have a local result for we show “0″ as the number of results.  Over the past year we have regretted this decision as users will email us letting us know they aren’t pleased we don’t have local results.  In our iPhone version we fixed this issue.

In the iPhone version of ShopSavvy if you scan an item WITHOUT local prices we simply show a tab that says “Prices”.  If we have local prices we show the two tabs, i.e. Web and Local price.  By not calling attention to the fact that we don’t have a local price for an item we don’t get many emails from annoyed users relative to local results.  Of course, in our world, not many is hundreds so I thought I would explain how to get local results on ShopSavvy.

Most new users (i.e. the vast majority of support emails) download ShopSavvy at their house and begin scanning items they already to own.  Many of these items are grocery related and we don’t cover groceries very well (read more here).  The rest are old books and DVDs – many of these are still available online, but they are no longer in local stores.  These ‘DEMO’ scans often yield poor results, a) the items are no longer sold in local stores, b) they are of groceries and c) the barcodes are hard to read.  We have received hundreds of negative ratings from these users even though they have never actually tried to use ShopSavvy to shop.  My advice?  Use ShopSavvy when you shop – you will be surprised how helpful ShopSavvy can be.

The reason ShopSavvy performs well in retail stores is fairly obvious.  First, the items sold in one retail store are likely sold in other retail stores – meaning we will have local inventory and price.  Major local retailers carry between 10,000 and 100,000 items – this is out of millions of items.  Second, the lighting in retail stores is often far better than the lighting in your house – this means scanning will be faster.  Third, the barcodes are almost always printed on flat surfaces – this means scanning will be faster.  Trying to scan items in your house means you are scanning items that might not be currently sold, might have hard to read barcodes and scanning in low light.  Before you give us a poor review or rating, please actually use ShopSavvy when you are shopping for Christmas.

 

http://www.biggu.com/

via: http://www.biggu.com/2009/11/21/how-to-get-local-results-on-shopsavvy-2/

 

Loading mentions Retweet
Filed under  //  apps   google   software   technology   web  
Comments (0)
Posted 17 days ago

Designing CSS Buttons: Techniques and Resources

http://www.smashingmagazine.com/

 

Buttons, whatever their purpose, are important design elements. They could be the end point of a Web form or a call to action. Designers have many reasons to style buttons, including to make them more attractive and to enhance usability. One of the most important reasons, though, is that standard buttons can easily be missed by users because they often look similar to elements in their operating system. Here, we present you several techniques and tutorials to help you learn how to style buttons using CSS. We’ll also address usability.

Links vs. buttons

Before we explain how to style buttons, let’s clear up a common misconception: buttons are not links. The main purpose of a link is to navigate between pages and views, whereas buttons allow you to perform an action (such as submit a form).

In one of his articles, Jakob Nielsen writes about command links, which are a blend of links and buttons. But he recommended that command links be limited to actions with minor consequences and to secondary commands. To learn more about primary and secondary commands (and actions), check out Primary and Secondary Actions in Web Forms by Luke Wroblewski. To learn more about the differences between links and buttons, read Creating Usable Links and Buttons at UXBooth.

Basic Styling

The simplest way to style links and buttons is to add background color, padding and borders. Below are examples of the code for the link, button and input (”Submit”) elements.

Sample button
<button class="button" id="save">Sample button</button>
<input class="button" value="Sample Button" type="submit" />
.button {
padding:5px;
background-color: #dcdcdc;
border: 1px solid #666;
color:#000;
text-decoration:none;
}

This simple code minimizes the visual differences between links and buttons. And here are the rendered examples of the code above:

Different Buttons in Designing CSS Buttons: Techniques and Resources

The important thing to note is that these three elements render differently with the same CSS. So, you should style these elements carefully to ensure consistency across your website or application.

Images

Adding images to buttons can make the buttons more obvious. Sometimes the image itself clearly communicates the purpose of a button; e.g. a loupe icon for searching or a floppy disk icon for saving. The easiest way to add an image to a button is to use a background image and then position it accordingly. Below are our examples with a checkmark icon.

.button {
padding: 5px 5px 5px 25px;
border: 1px solid #666;
color:#000;
text-decoration:none;
background: #dcdcdc url(icon.png) no-repeat scroll 5px center;
}

Different Buttons2 in Designing CSS Buttons: Techniques and Resources

Button States

In addition to their default state, buttons and links can have two other states: hover and active (i.e. pressed). It is important that buttons appear different in different states so that users are clear about what is happening. Any element in a hover state can be styled by invoking the :hover CSS pseudo-class.

a:hover {
color:#f00;
}

Though very important, the active state is rarely implemented on websites. By showing this state, you ensure that your buttons are responsive and send a visual cue to users that a button has been pressed. This is called isomorphic correspondence, and it is “the relationship between the appearance of a visual form and a comparable human behavior” (Luke Wroblewski, Site-Seeing). The article Pressed Button State With CSS elaborates on the importance of the active state.

a:active {
color:#f00;
}

There is yet one more state, one that is seen when navigating with the keyboard: the focus state. When the user navigates to a button using the Tab key, it should change appearance, preferably to have the same appearance as the hover state.

a:focus {
color:#f00;
}

The examples below shows the common way to style button states. The hover state is a bit lighter than the normal state, while the active state has an inverted gradient that simulates a pressed action. Although you need not limit yourself to this styling, it is a good place to start.

Button States in Designing CSS Buttons: Techniques and Resources

We should talk about how to handle the outline property for the :active and :focus states. Handling this property well is important for the experience of users who employ the keyboard as well as the mouse. In the article Better CSS Outline Suppression,” Patrick Lauke shows how buttons and links behave in different combinations of states and explains why the outline property should be invoked only with the :active state.

Apple in Designing CSS Buttons: Techniques and Resources

The blue “Buy now” button on Apple.com has a slightly lighter background for the hover state and an inset style for active state. Even the main navigation button on Apple’s website implements all three states.

Tearoundapp in Designing CSS Buttons: Techniques and Resources

Although it doesn’t implement the active state, this fancy button on Tea Round has a nice fading effect on hover.

Uxbooth Button in Designing CSS Buttons: Techniques and Resources

The “Read more” button on UX Booth turns green on hover and moves down one pixel in the active state, which simulates the effect of pressing a button.

Useful Reading

The article Rediscovering the Button Element shows the differences between links and buttons and explains how to style buttons easily.

Rediscover Button in Designing CSS Buttons: Techniques and Resources

Styling Form Buttons covers the basics of styling buttons, with many examples.

Tyssendesign in Designing CSS Buttons: Techniques and Resources

Beautiful CSS Buttons With Icon Set shows how to style buttons using background images. Although not scalable, these are really nice buttons.

Buttonnice in Designing CSS Buttons: Techniques and Resources

Recreating the Button is a very good article that explains how Google ended up with the buttons that it uses on majority of its websites.

Stopdesign in Designing CSS Buttons: Techniques and Resources

Scalable CSS Buttons Using PNG and Background Colors explains how to create really stunning buttons for all states. Although it uses jQuery, it degrades gracefully if JavaScript is turned off.

Monc in Designing CSS Buttons: Techniques and Resources

Sliding Doors: Flexible Buttons

One important consideration needs to be made when styling buttons: scalability. Scalability in this context means being able to stretch a button to fit text and to reuse images. Unless you want to create a different image for each button, consider the “sliding doors” technique. This technique enables you to create scalable, rich buttons.

Sliding Doors in Designing CSS Buttons: Techniques and Resources

The principle involves making two images slide over each other, allowing the button to stretch to the content. Usually, this is done by nesting a span element within a link. As shown in the image above, each element has its own background image, allowing for the sliding effect. The two code snippets below show the structure and basic styling for this effect.

Typical sliding doors button
a {
background: transparent url('button_right.png') no-repeat scroll top right;
display: block;
float: left;
/* padding, margins and other styles here */
}
a span {
background: transparent url('button_left.png') no-repeat;
display: block;
/* padding, margins and other styles here */
}

The advantages of this technique are that it:

  • Is an easy way to create visually rich buttons;
  • Ensures accessibility, flexibility and scalability;
  • Requires no JavaScript;
  • Works in all major browsers.

Useful Reading

The “Sliding Doors of CSS” article on A List Apart (part 1 and part 2) covers the basics of this technique. Although a bit old, these articles are a must-read for every Web developer.

Alistapart in Designing CSS Buttons: Techniques and Resources

Also a bit old, Creating Bulletproof Graphic Link Buttons With CSS is an excellent article that shows how to create bulletproof, resizable, shrunk-wrap buttons. Also a must-read.

456bereast in Designing CSS Buttons: Techniques and Resources

Filament Group has a variety of excellent articles and tutorials. Its second article on CSS buttons, Styling the Button Element With CSS Sliding Doors,” explains how to create buttons by combining techniques. Although it doesn’t support the active state, it can be easily extended.

Filament in Designing CSS Buttons: Techniques and Resources

How to Make Sexy Buttons With CSS is one of the best and simplest explanations of the sliding doors technique. It also contains a little fix for the active state in Internet Explorer.

Oscaralexander in Designing CSS Buttons: Techniques and Resources

If you want Wii-like buttons, the article Simple Round CSS Links (Wii Buttons) provides all the necessary resources and explanation on how to style them.

Wii in Designing CSS Buttons: Techniques and Resources

The common way to achieve the CSS sliding doors technique is to use two images. However, the article CSS Sliding Door Using Only One Image shows that it is possible to achieve the same effect with only one image.

Kailoon in Designing CSS Buttons: Techniques and Resources

CSS Oval Buttons and CSS Square Buttons from Dynamic Drive are two other articles that show the effectiveness of CSS sliding doors.

Dynamicdrive in Designing CSS Buttons: Techniques and Resources

CSS Sprites: One Image, Not Many

With CSS Sprites, one image file contains multiple graphic elements, usually laid out in a grid. By tiling the image, we show only one Sprite at a time. For buttons, we can include graphics for all three states in a single file. This technique is efficient because it requires fewer resources and the page loads faster. We all know that many requests to the server for multiple small resources can take a long time. This is why CSS Sprites are so handy. They significantly reduces round-trips to the server. They are so powerful that some developers use CSS Sprites for all their graphics. The Holy Sprites round-up on CSS Tricks offers some very creative solutions.

The example below shows the simplest use of CSS Sprites. A single image contains graphics for all three button states. By adjusting the background-position property, we define the exact position of the background image we want. The image we’re choosing to show here corresponds to a background position of top: -30px and left: 0.

Sprites in Designing CSS Buttons: Techniques and Resources

a {
background: white url(buttons.png) 0px 0px no-repeat;
}
a:hover {
background-position: -30px 0px;
}
a:active {
background-position: -60px 0px;
}

For general information and resources on CSS Sprites, check out The Mystery of CSS Sprites: Techniques, Tools and Tutorials.”

Useful Reading

In this easy-to-follow tutorial How to Build a Simple Button with CSS Image Sprites,” Chris Spooner explains how to create a CSS Sprites image in Photoshop and use it with CSS.

Line25 in Designing CSS Buttons: Techniques and Resources

Transforming the Button Element With Sliding Doors and Image Sprites shows how to enrich a button element with a combination of sliding doors and image Sprites. It implements the active state in a very interesting way, not by using different images or colors but rather by positioning.

CSS 3: Buttons Of The Future

CSS 3 allows us to create visually rich buttons with just a few lines of code. So far, this is the easiest way to create buttons. The downside of CSS 3 is that it is currently supported only by Firefox and Safari. The upside is that buttons styled with CSS 3 degrade gracefully in unsupported browsers. By using the browser-specific properties -moz-border-radius (for Firefox) or -webkit-border-radius (for Safari), you can define the radius of corners. Here are a few examples of what can be done with the border radius property.

Css3 Rounded in Designing CSS Buttons: Techniques and Resources

For better results, you can combine CSS 3 rounded corners with the background image property. The example below shows a typical button with a gradient image, the first without rounded corners, and the second with.

Rounded Corners in Designing CSS Buttons: Techniques and Resources

Compared to sliding doors, this technique is far simpler. However, if you want to maintain visual consistency across all browsers, then use sliding doors, because it works in all major browsers, including IE6. To learn more about the capabilities of CSS 3, read CSS 3 Exciting Functions and Features: 30+ Useful Tutorials.” And here are a few good tutorials on styling buttons with CSS 3 features.

Useful Reading

Super Awesome Buttons With CSS 3 and RGBA shows the power of CSS 3 with rounded corners, Mozilla box shadows and RGBA, which is a color mode that adds alpha-blending to your favorite CSS properties. This is one of the best examples of CSS 3 buttons.

Zurb in Designing CSS Buttons: Techniques and Resources

Create a CSS 3 Button That Degrades Nicely is a good example of CSS 3 buttons that degrade gracefully in browsers that don’t support CSS 3.

Stylizedweb in Designing CSS Buttons: Techniques and Resources

Creating buttons without Images Using CSS 3 explains the drawbacks of using images for buttons and shows several options for creating image-less CSS 3 buttons.

Opera in Designing CSS Buttons: Techniques and Resources

Emulating Google-Syle Buttons Using CSS 3 & dd_roundies JS is a fantastic article that shows how to create Google-like buttons. It goes even further and shows how to create the button pillbox commonly seen on Google pages.

Instant Tools: Are They Useful?

Tools exist for creating buttons, such as Easy Button and Menu Maker and My Cool Button, and for creating CSS Sprites, such as CSS Sprite Generator, but the question is, do they really help you create buttons that fit your needs. Although they are configurable and easy to use, your creativity and control over the results are limited, which makes for average-looking buttons. Using one-size-fits-all buttons is not a good idea.

The solution is to use Photoshop (or a free alternative) and the proven techniques described in this article. If you are a beginner with Photoshop, here are several excellent tutorials on creating amazing buttons.

If you don’t know where to start, iPhone-Like Button in Photoshop is the perfect choice. In only 10 to 15 minutes, you will be able to create the kind of buttons seen on the iPhone.

Iphone Button in Designing CSS Buttons: Techniques and Resources

How to Create a Slick and Clean Button in Photoshop is a very detailed tutorial that guides you through 30 simple steps and helps you learn the Photoshop basics. In addition, the article explains how to use these graphics in combination with HTML and CSS to create fully functional CSS buttons.

Sixrevisions in Designing CSS Buttons: Techniques and Resources

Photoshop Button Maker is a fantastic tutorial from PSD Tuts that shows how to create fancy oval buttons (or badges).

Psdtuts in Designing CSS Buttons: Techniques and Resources

Buttons And Usability: Instead Of Conclusion

The techniques described above can help you create stunning buttons. However, because they play a critical role in website usability, the buttons should meet some key principles:

  1. First consider the labeling. Always label buttons with the name of the action that the user is performing. And always make it a verb. A common mistake is to label buttons “Go” for various actions such as searching, sending email and saving. Labels should also be short and to the point; no need to clutter the user interface.
  2. As mentioned, include all button states (default, hover, active) to provide clear visual cues to the user as to what is happening. Button outlines should remain in the active state only.
  3. Clearly distinguish between primary and secondary actions. The most important action should be the most prominent. This is usually done by giving primary and secondary actions different colors.
  4. Pay close attention to consistency. Buttons should be consistent throughout a Web application, both visually and behavior-wise. Use CSS sliding doors for reused buttons or CSS 3 rounded corners to maintain consistency.
  5. Though obvious, we should note that the entire button area should be clickable.

The articles below provide even more usability guidelines and best practices for designing buttons.

Make Complete Button Surface Active and Enhance Usability is an in-depth article that shows mistakes in button design and that explains why the entire button surface should be clickable.

Uxpassion in Designing CSS Buttons: Techniques and Resources

Creating Usable Links and Buttons explains why users expect buttons sometimes and links other times. It also shows how to choose between the two elements.

Uxbooth in Designing CSS Buttons: Techniques and Resources

How to Design Buttons to Help Improve Usability explains some usability principles that should be considered when designing buttons. It covers the basics of icon usage, appearance, behavior, hierarchy and consistency.

(al)

Loading mentions Retweet
Filed under  //  apps   pgm   software   technology  
Comments (0)
Posted 18 days ago

75% of Facebook users are giggly and poke; 25% are serious and import bookmarks

Facebook users fall into two categories: giggly and serious. Facebook user experience could be better if Facebook took this dichotomy into account. Ignoring the difference pushes apps to be giggly and serious users to be unhappy.

Giggly 75% like pokes, quizzes, pic forwarding, fun games, selling friends, glitter on profiles. They express themselves through style and interact with friends using the mouse.

Serious 25% like bookmark import, utility apps, discussions. They express themselves with text and pictures containing them and interact with friends using the keyboard.

Because you’re reading this, and made this far, you’re serious. (Giggly users tend to not read much at all, certainly not blobs of text, and quite certainly not my blog.) Let me tell you a few things about the giggly majority and propose how to make Facebook better for both giggly and serious users.

Giggly users are

  • younger
  • less educated
  • lower-income
  • less likely to have credit cards
  • far less likely employed
  • more suburban and rural
  • more frequently female.

Giggly users love to have fun with their friends, love to chit-chat and giggle, forward things easily and without a second thought. Giggly users generally don’t review applications because it requires typing. They don’t visit the about pages much. The prototypical giggly user is a female teenager who might later go to a party school to major in English.

You’re far more familiar with the serious users. Serious users are Harvard students, Silicon Valley types who use Facebook for professional networking, young professionals, etc. Serious users vote in primaries, care about privacy, understand the importance of financial planning, and are somewhat hesitant about the exposure of personal information by social networks. Serious users dislike the apps, infrequently use them, but write many of the reviews. Their notion of fun on Facebook is Scrabulous. Serious users are a bit boring. They make up for it by extreme sports and odd personal styles. The prototypical serious users are you and I. (Facebook employees and shareholders are also serious Facebook users.)

Problems:

  1. Giggly users send a bunch of giggly communication to the serious users, for whom it’s annoying noise that drowns the signal from serious friends
  2. Giggly users want more self-expression tools, which Facebook won’t create because of concern about serious users, who will hate them and cry “MySpace

Solution: Have each user and each app self-elect into giggly or serious categories and treat them differently.

API calls returning list of friends, friend selectors, etc., should, by default, only return giggly friends for giggly apps and serious friends for serious apps. There should be a way to override this with some difficulty and user involvement.

Giggly users should be given tools to create different backgrounds for their profiles with different text colors and an option to play music on load. The default text color for giggly users should be pink, on a purple background with starbursts. Facebook should partner with RockYou to enable displaying the profile owner’s name in her favorite style of glitter, and a larger font. Latest photo album should start playing as a slide show on load. Applications should be given hooks into these extra self-expression tools, allowing iLike to set the song to play on load, etc. Self-expression should reign supreme.

Serious users should continue to see profiles of any users, including giggly, as they do today, minus the app boxes. Utility and uniformity should be emphasized.

The division of the app ecosystem will be particularly valuable. Giggly users will continue to have their silly apps, but the silly apps will stop bothering the serious users.

This will create an opening for serious and useful apps, now squeezed out of the ecosystem by the higher virality of the silly apps. This will allow engaging and useful apps to flourish in the subset of Facebook users whom Facebook clearly values the most, who are far more valuable for monetization, without spoiling the fun the giggling girls are having over in the other corner of Facebook.

It is in the apps’ interests to be classified correctly, therefore self-classification will be sufficient. The division will reduce Facebook’s need to police the apps, because serious apps will treat serious users more in line with their expectations and giggly users are more tolerant of highly viral tactics.

The 75% and 25% numbers are my approximations, based on polls about the Beacon program and forced invites, on the demographics, review of statistics, and a great dose of guess. The dichotomy is not firm, and the numbers may not be exactly 75/25. There is, however, a giggly majority and a serious minority, there’s greater conversion to inviting among the giggly users, there’s Facebook’s desire to be a social utility and thus to appeal to the serious minority, and there’s the problem of higher virality of the silly apps on Facebook, combined with the desire to have serious apps.

There are two ways in which Facebook would enable engaging useful apps:

  1. change the distribution model from viral to directory and
  2. segregate the users into groups.

Directory-based distribution would be bad news as it would replace competition with arbitrary choice, reducing the overall quality of apps. I believe Facebook understands this, as they have resisted this route thus far.

Segregation of users and apps into groups is the next natural choice, and I do not believe it has been explored. The minimum useful number of groups is two, and two groups might well be sufficient.

Facebook already has good data that separates the giggly users from the serious ones. I expect that serious users have been far more likely to change their privacy settings from the defaults. Why not start from there?

Update, July 24, 2008: Facebook has made a choice.  Apps will no longer compete on a level playing field.  Instead, Facebook will separate them into three tiers of preference.  The replacement of competition with arbitrary choice by Facebook employees will obviously lower the overall quality, except as perceived by the particular employees making the choice.  Yet it’s Facebook’s platform and their choice how to run it.

Loading mentions Retweet
Filed under  //  apps   facebook  
Comments (0)
Posted 23 days ago

10 useful Facebook apps

Most Facebook apps are giggly.  But serious apps exist even today when they cannot spread.

A comment on my earlier post 75% of Facebook users are giggly and poke; 25% are serious and import bookmarks asks if there are, indeed, any serious Facebook apps.  Here are some of the serious apps that I have installed:

  1. Analytic Polls — opinion comparison/sharing.
  2. Antlook — news.  Personalized recommendations from AI.
  3. Causes — charity.  The only popular serious Facebook app.
  4. Dopplr — business travel.  Tells when contacts are in the same place as you.
  5. Feedheads — tool for importing Google Reader shared items and RSS in general.
  6. Mento — bookmarking tool that tells you when friends click. Firefox extension that takes screenshots.
  7. Neighborhoods — meet your neighbors on Facebook.  I’ve become friends with two great people this way.
  8. PayPal — fundraising.
  9. SeenThis — news.  All WSJ content for free.
  10. Truemors — tips and rumours.

You’ll notice that no-one uses these excellent apps, with the exception of Causes.  Because serious apps are not used, developers have no incentive to create more.  If my proposal were implemented, there would be more, and better, serious apps.

But before then, you can still enjoy these apps that developers made against their best interest and judgment.

Loading mentions Retweet
Filed under  //  apps   facebook  
Comments (0)
Posted 23 days ago

Safety in the Cloud(s): 'Vaporizing' the Web Application Firewall to Secure Cloud Computing

Cloud computing was not designed for security, although organizations such as Cloud Security Alliance (CSA) and Open Web Application Security Project (OWASP) are making great strides in helping the industry solve the myriad security problems confronting cloud computing. The benchmark guidelines established by the CSA in the document, Guidance for Critical Areas of Focus in Cloud Computing, are a great first step. This article is intended to pick up where the CSA guide left off in terms of defining what a distributed Web application firewall (dWAF) should look like in order to meet the standards set within the CSA document.

                      Alex Meisel is the CTO of Art of Defence GmbH, member of OWASP and Cloud Security Alliance. Alex’s core focus is Web application security.                   

In order to accurately outline how a dWAF is possible while maintaining all the benefits of a completely virtualized environment – reduced IT overhead, flexible footprint management, virtually unlimited scalability – a brief overview of cloud technology is needed. Far more than simply maximizing current hardware resources to benefit from unused CPU power, today there are three main technologies available in a cloud that provide the backbone for real productivity gains and compelling business services for companies that don’t want to invest in the hardware scaling burdens common today.

Software as a service (SaaS) offers users virtualized software through a thin client, usually any standard Web browser. The benefit for users is access to software without any of the headaches of owning the programs – scaling and resources are taking care of, and patching and upgrades are managed.

Platform as a service (PaaS) provides users with virtual databases, storage and programming languages with which custom applications can be built. This service provides nearly unlimited resources behind the platform and allows customers to scale throughout the lifetime of the application. It is an effective solution for companies ranging from the very small to those serving millions of customers. The customer does not worry about the infrastructure needed to run the services and is billed in per usage model.

Infrastructure as a service (IaaS) allows users access to virtually unlimited resources to build and manage their own virtual network. Customers can commission and decommission virtual resources depending on their need. The most obvious benefit is that there is no end-of-life for hardware anymore for the customers. The providers move them according to their service level from hardware to hardware without any downtime.

The common user benefit of services available through a cloud is access to key resources via the Internet, which provides an incredible degree of scaling without the need to invest in expensive hardware infrastructure.

Cloud Applications Are Highly Exposed to Threats

Accessing cloud technologies requires a thin client, and the world’s most commonly used thin client for this purpose is a Web browser. This means the vast majority of all applications on the Internet have some kind of Web and/or application server on which the business logic is implemented. Currently, most of the money spent on security goes into firewalls and antivirus solutions, but in the last 10 years the typical target for attacks has shifted from the network layer to the application layer because the operating systems and services available to the general public were cut down. As a result, it is now easier to target the application logic or framework of an application than the actual server behind the hardened network perimeter. Applications are mostly developed by the businesses themselves and not every developer considers security the highest priority, which leads to a wide variety of problems.

The IBM X-Force® 2008 Annual Report highlights that Web application vulnerabilities are the Achilles’ heel for corporate IT security. The impact of not being able to secure these vulnerabilities is far reaching.

 

GO20090814-01.gif

 

GO20090814-02.gif

 

 

Further, attack vectors increase exponentially in correlation with the mainstream adoption of cloud computing. Their increase is dictated by hosting and delivering infrastructure, platform and software. Establishing a comprehensive patch management system is the common solution offered by most in the industry, however, in practice this approach has proved very difficult and costly. Typical Web applications are built on open source components, by third parties, who rely on Web frameworks. This approach has the obvious benefits of interoperability and shortened development time, however, patching becomes exponentially more difficult. A flaw in one piece of open source code must be patched for each instance it is used throughout each application in which it is used. In a cloud setting, this becomes a very large issue.

 Applications developed specifically for a cloud are often very complex, designed for access speed, scalability and flexibility for third-party development through an open API. For example, Salesforce.com, Google Docs, MySpace, Facebook and Twitter, are all prime examples. These ‘as a Service’ applications are developed two ways today: by moving on-premise applications to a cloud, and by developing and operating applications directly in a cloud.

Applications that are forced out of the internal company network and into a cloud carry the risks of exposing protected software to Web threats it was not designed to combat. Common security threats include injection attacks, cross site scripting or cross site request forgery.

There are a variety of services available for developing in a cloud, such as MS Azure Services, Google App Engine or Amazon EC2. There are many security challenges involved in developing Web applications in a cloud. For example, parameter validation, session management and access control are 'hotspots' for attackers. Developers not trained in those three fields of application development will most definitely create/develop applications that have security problems.

 

GO20090814-03.gif

 

Why a Traditional Web Application Firewall Will Not Work

 

In a cloud, the infrastructure and the services are shared between customers, meaning one set of hardware is used by many business, organizations and even individuals. Each of these cloud operator customers adds a unique layer of policy settings, use cases and administrative enforcement requirements. For the cloud or service provider, security quickly becomes very complex. The average provider may have 10,000 customers subscribing to its service, each with varied policy settings for individual divisions within the company. The service provider now has to manage an nth degree of application filter settings.

Currently, Web application firewalls (WAF) and other security solutions are restricted to hardware appliances, which creates a serious bottleneck for cloud service providers. Dedicated hardware boxes simply don't allow for reasonably scalable levels of multiple administrators’ duties within a box’s singular security policy mechanism. Ironically, in addition to the traditional network hardware, cloud service providers are forced to have a rack full of dedicated WAF machines – one per customer – that take up space and eat up resources. Security becomes counter to the efficiency promises of a fully virtualized environment. This cost is passed on to customers, increasing adoption barriers to mainstream cloud computing.

In an ideal world, applications would be designed from the ground up to meet the rigors of a virtualized world, integrating security measures directly into the applications and thus solving a core problem with current cloud computing. Until the industry reaches this ideal), traditional Web application firewall boxes are preventing the industry from reaching the full potential of a cloud computing.

Defining the Distributed Web Application Firewall (dWAF) for Cloud Protection

Web application security in a cloud has to be scalable, flexible, virtual and easy to manage.

A WAF must escape hardware limitations and be able to dynamically scale across CPU, computer, server rack and data center boundaries, customized to the demands of individual customers. Resource consumption of this new distributed WAF must be minimal and remain tied to detection/prevention use instances rather than consuming increasingly high levels of CPU resources. Clouds come in all sizes and shapes, so WAFs must as well.

The dWAF must be able to live in a wide variety of components to be effective without adding undue complexity for cloud service providers. Today’s providers are using a variety of traditional and virtual technologies to operate their clouds, so the ideal dWAF should accommodate this mixed environment and be available as a virtual software appliance, a plug-in, SaaS or be able to integrate with existing hardware. Flexibility with minimal disruption to the existing network is central.

A Web-based user interface must allow customers to easily administrate their applications. Configuration should be based on the applications under protection, not defined by a singular host, allowing far more granular settings for each application. Ruleset configuration must be supported by setup wizards. Statistics, logging and reporting has to be intuitive and easy to use and must also integrate seamlessly into other systems. Most importantly for a dWAF, multi-administrator privileges must be made available and flexible enough to effectively manage widely divergent policy enforcement schemes. Cloud providers should look for a set of core protections.

Detection and Protection

Foundational security using black, white and grey listings for application requests and responses must be possible. To make sure pre-set policy enforcements are not activated or deactivated without approval from an administrator, deployment and policy refinement through establishing rulesets must be possible in a shadow monitoring or detection-only mode. Once the shadow monitoring ruleset is stable, only then should it be allowed to deploy in an enforcement mode on the dWAF. This allows complete transparency for the administrator into the real-world effect of this ruleset, while at the same time allowing layered rulesets to be tested without compromising existing policy enforcement. Avoiding false positives and relaxed established defenses is essential for a real-world, usable dWAF in a cloud.

Automated learning and ruleset suggestions based on intelligent algorithms or recommendations from a static source code analyzer or Web vulnerability scanner are also desirable from a manageability view. Again, this only holds true if the administrator retains full control over activation/deactivation of each ruleset. Without this control, wanted traffic may become blocked and policy settings would become compromised.

Application Shielding

Pro-active security functions are highly recommended to reinforce any application in a cloud. Detection is simply not enough for today’s Web application security. Features like transparent secure session management, URL encryption and form-field virtualization will provide strong deterrence to attack, while saving application development and deployment time. These features are effective because session management, URL encryption and form-field virtualization is done at the dWAF level and not in the application itself.

An authentication framework support that enables businesses to consolidate their applications under one management schema is also desirable for a dWAF. This enables users to handle the authentication in front of their applications rather than behind, which adds another perimeter of security. A consolidation of all applications with dedicated rights-management ability is also a strong usability function that will make an administrator’s life easier.

Integration with Existing Technology

Avoiding vendor lock-in is a common best practice for both networking and application security. Any technology that is added to an infrastructure, platform or application itself must connect as seamlessly as possible with existing technology. Security is all about layering technologies to create the best possible protection, so a dWAF must communicate freely between a security incident and the event management system (SIEMs).

Loading mentions Retweet
Filed under  //  apps   cloud computing   technology  
Comments (0)
Posted 2 months ago

FlyChat iPhone App Promo

Loading mentions Retweet
Filed under  //  apps   iphone   technology  
Comments (0)
Posted 4 months ago