OWASP’s Top Ten and Your False Sense of Security

This past weekend, I attended the No Fluff Just Stuff conference (twitter.com/nofluff). While there, I saw a great presentation from Ken Sipe briefly discussing OWASPS current top 10 security vulnerabilities web developers should be concerned with today. As any good talk should, it really got me thinking. I love web security…but am I alone?

Web security is important. In fact, it is extremely and increasingly important. And no, I am not alone. There are many others out there that love this stuff. Sadly that is part of the problem. There are tons of smart people out there who want to know everything there is to know about web security, but is it the right people? Are they white hat developers working hard for their clients? Are they the business owners managing the projects and writing the checks? Or are they script kiddies living in their grandma’s basement…

I am realistic. There will always be people who want to learn about the latest and greatest in the security world so they can make it better, and others who want to learn so they can bend break or obliterate it. My gripe is, web security seems to take a back seat in the minds of many. The priority instead lies in what businesses “really care about.” This includes user experience, business requirements, time to market; basically any buzzword you pull out of that dusty Agile book on your desk.

Those things all sound pretty important (after all, as I said, they are writing books about them, right?) However, I argue that the sparkliest html5 presentation layer will do you no good if someone can drop your database tables with nothing more than Firebug and a 10 minute World-of-Warcraft break.

So what do I expect? Should companies spend the money to make sure all of their developers know how XSS attacks happen? And why you can’t use two-way functions to store passwords? Or why a nonce should be part of every form submission?

Yes. Yes they should.

Don’t get me wrong, there are many ways to make a site safer. Code reviews are a great way to catch and prevent OWASP’s top 10, and many others that didn’t make their list [assuming the reviewer knows what they are looking for.] OWASP’s ESAPI library is another, providing an api for the ‘more novice’ developer [though reviews on ESAPI are mixed, and it doesn’t seem to be fully baked yet.] But this will only get us so far. To be cliche, there is power in numbers, and we are only as strong as our weakest link. The more greater the number of informed folks that lay eyes on our code, the fewer vulnerabilities will make it through.

Needless to say, I consider a basic understanding of modern vulnerabilities a must. I also consider it the burden of the informed to convince the others that this really is worth the time and money. I know many clients/business owners do not want to know the nitty gritty details of how a teenager with enough spare time can put the screws to them, and that’s ok. They don’t need the details, as long as they know their developers are well educated on the subject and can therefore believe them when they say “this has to be done.” So get out there and advocate for education on web security! And while you wait for your employer to get on board, why not get a head start? Useful links follow:

OWASP Top 10
OWASP’s WebGoat security lab
Google’s Gruyere Web Security lab

Finally, be sure to check out posts, whitepapers, and other great content at http://blog.credera.com

Intercepting Android’s action_send Intents


The folks at Google get it.  Eating a sandwich isn’t good enough.  You need to make sure everyone you know KNOWS you ate a sandwich, what you thought of it, how much it costs, and any other critical cuisine-related details you’ve picked up in the last 28 seconds.  And because Google gets it, they designed a remarkably easy to use model for “sharing”.

Of course I don’t mean sharing your sandwich.  I’m talking about sharing in the context of social media.  With so many social media outlets and more coming out every day, attempting to find and learn an API and integrate each one into your Android app so users can share would be an impossibly cumbersome task.  The clean solution is this: Let the social media platforms worry about the integration.  All this requires is that NewSocialSiteX puts a bit of code in their own app that lets a user’s Android device know it is receptive to sharing, as well as how to handle the incoming data.  Of course this really just follows Google’s intent-based API model and likely has little to do with sandwiches.

This model buys developers some incredible functionality with very little work.  With a minimal amount of code, we can allow users to post to Facebook, Tweet, text, email gmail or any other mail they’d like, provided they have an app installed on their phone that has registered the action_send intent.


Well that’s all great, but what happens when I want to disallow SMS clients?  Or the Facebook app won’t allow my app to pre-populate a wall post?  This was the case I was faced with.  I needed my app to allow sharing of any kind, including Facebook.  Unfortunately, Facebook’s standard wall post functionality [after July 12th 2011] ignores the ‘message’ parameter to prevent apps from pre-populating wall post data.  Now we’re back to square one and looking at individually integrating each client just because one doesn’t work as we would like!  Fortunately, I found a better option that I feel is worth sharing.


What I wanted was a way to fire an action_send intent but intercept the users choice so I could then do what I wanted, and that is exactly what I managed.  The solution is relatively simple, but does assume you have some knowledge about using ListViews [here for help] and the ACTION_SEND intent [here for help].  Here is some code to bring some context, then we’ll examine each part.

package com.example.blog;

import java.util.List;
import android.app.Activity;
import android.app.AlertDialog;
import android.content.Context;
import android.content.DialogInterface;
import android.content.Intent;
import android.content.pm.ResolveInfo;
import com.facebook.android.Facebook;
import com.goldsgym.android.spotter.R;

public class ShareHelper {
	Context context;
	String subject;
	String body;
	Facebook facebook;
	public ShareHelper(Context context, String subject, String body) {
		this.context = context;
		this.subject = subject;
		this.body = body;
		facebook = null;
	public Facebook share() {
	Intent sendIntent = new Intent(android.content.Intent.ACTION_SEND);
	List activities = context.getPackageManager().queryIntentActivities(sendIntent, 0);
	AlertDialog.Builder builder = new AlertDialog.Builder(context);
	builder.setTitle("Share with...");
	final ShareIntentListAdapter adapter = new ShareIntentListAdapter((Activity)context, R.layout.basiclistview, R.id.text1, activities.toArray());
	builder.setAdapter(adapter, new DialogInterface.OnClickListener() {
		public void onClick(DialogInterface dialog, int which) {
			ResolveInfo info = (ResolveInfo) adapter.getItem(which);
			if(info.activityInfo.packageName.contains("facebook")) {
				new PostToFacebookDialog(context, body).show();
			} else {
				Intent intent = new Intent(android.content.Intent.ACTION_SEND);
				intent.setClassName(info.activityInfo.packageName, info.activityInfo.name);
				intent.putExtra(Intent.EXTRA_SUBJECT, subject);
				intent.putExtra(Intent.EXTRA_TEXT, body);
	return facebook;


In the code above, you see my ShareHelper. This class has a single constructor that takes 3 arguments: the context of the activity where it is instantiated, the subject text we would like to share [eg subject line of an email] and the body text we would like to share [eg body of an email]. Past that we see the class’ single method, ‘share’. This method takes no parameters, but does almost all of the work. Let’s take a look.

In the share method, we first create a new action_send intent and set the type to text/plain. Next, we create a List. We make the call to the package manager to query for all Activities with the action_send intent registered. This call returs a list of ResolveInfo objects, each corresponding to an Activity on the device that claims to handle send actions.

Now this is when the magic happens. Rather than launching the action_send intent and letting it create its own dialog [one that we would have no control over], we will build our own with the AlertDialog.Builder. First we give it a title, then set its adapter to the list adapter we just created with the activities list as our data set [list adapter code posted at the end of the article, but there is nothing special about it].

The next important piece we need to look at is the OnClick listener we gave the Builder. To find which item the user clicked, we use the adapter.getItem(int which) method. This will return the object in that position of our original list, in this case, a ResolveInfo object corresponding to the selected Activity. For my case in particular, I only care about separating things into two groups: Facebook and not Facebook. To do this, I simply check if the selected Activity’s package name contains ‘facebook’. If it does not, I create a new action_send intent, set the class name to the selected activity, and launch it. However, if the package name DOES contain ‘facebook’, I instantiated my personal PostToFacebookDialog object which will create a basic Android dialog with post and cancel buttons, and will post to Facebook directly using the Graph API, thus circumventing the user’s installed Facebook app.

Closing Notes

This solution may seem Facebook specific, but it is actually quite powerful. Using this same idea, you can eliminate certain apps from the list, filter the content the user has chosen to share, or even reorder the list to give preference to apps you feel users prefer. I hope this post was clear, but I know all too well that reading someone else’s code can get a little mind bending. If you are feeling lost, please do not hesitate to post questions! I will do my best to help. Also, see screenshots of the custom Activity list dialog and Facebook post dialog below, as well as my list adapter code. Finally, be sure to check out posts, whitepapers, and other great content at http://blog.credera.com

package com.example.blog;
import android.app.Activity;
import android.content.pm.ResolveInfo;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.ArrayAdapter;
import android.widget.ImageView;
import android.widget.TextView;
public class ShareIntentListAdapter extends ArrayAdapter
    Activity context;
    Object[] items;
    boolean[] arrows;
    int layoutId;
    public ShareIntentListAdapter(Activity context, int layoutId, Object[] items) {
        super(context, layoutId, items);
        this.context = context;
        this.items = items;
        this.layoutId = layoutId;
    public View getView(int pos, View convertView, ViewGroup parent) {
        LayoutInflater inflater=context.getLayoutInflater();
        View row = inflater.inflate(layoutId, null);
        TextView label = (TextView) row.findViewById(R.id.text1);
        ImageView image = (ImageView) row.findViewById(R.id.logo);

Tackling Android’s Camera Resolutions


Anyone who has played with Android knows that form factor is not to be taken lightly.  The platform is available on an ever growing number of devices with a wide variety of resolutions and pixel densities.  This can give developers grief, particularly if they are coming from iPhone dev, where, with few exceptions, the hardware is the same across all  users.  Recently, I was developing an app that made use of the devices camera.  Everything was going swimmingly until my app began crashing on my Nexus S, but not on my Galaxy Tab or the Evo.  After some digging, it became clear that I was trying to set a camera resolution that was not compatible with the Nexus S.

My first go-around seemed simple enough.  I had not hard-coded a resolution, but instead was polling the device for its display size, and using the width and height as my camera resolution [swapping the two if necessary to ensure a ‘portrait’ resolution].  However, there are apparently many phones who’s display resolution is not available as a camera resolution.  Fail.

My thoughts then began to trend toward just setting the highest resolution available as I am sure many do, but that didn’t seem good enough.  I can think of many times wherein a developer may want a SurfaceView that is a particular portion of the screen, and thus a compatible resolution that is close to that size.


Fortunately after a bit of tinkering, I came up with a solution I am pretty fond of.  Rather than picking the highest resolution and cramming it into a SurfaceView, why not find a resolution that most closely matches the SurfaceView we specified?  That is what I chose to do, using the following algorithm.

public int[] findCompatibleResolution(int width, int height) { 
    List<Size> sizes = camera.getParameters().getSupportedPreviewSizes();
    int[] resolution = { 0, 0 };
    int delta = Integer.MAX_VALUE;
    int temp = 0;
    for(Size size : sizes) {
        temp = Math.abs(size.width - width) + Math.abs(size.height - height);
        if(temp < delta) {
            delta = temp;
            resolution[0] = size.width;
            resolution[1] = size.height;
    return resolution;

This method takes width and height parameters and looks tries to find a resolution that varies from these the least.  It will then return an int array with the compatible width in [0] and compatible height in [1].

Hope you find this useful!  Please feel free to post questions and I will do my best to get back to them. Also, check out posts, whitepapers, and other great content at http://blog.credera.com

Blockbuster is No More

The credits roll, the music fades, and the lights come up. Blockbuster is no more.

At least, not like it used to be.

For those who havent come up for air in a while, Blockbuster just couldnt compete with Netflix, Redbox, and the like. It was purchased by Dish Network, and exactly what that means for the stores, the online site, and even the brand name itself, nobody knows quite yet. Before we all move on, I have a few things to say about it.

Maybe it’s because I have spent the last 6 months working with a team of 12 or so people to help revitalize Blockbuster through their online rental business, or maybe it is simply raw nastolgia as ever fiber of my being fights growing up now that I’m out of college and “in the real world”; either way, I cant help but feel sad to think that Blockbuster as we know it is gone. Gone are the days of driving around the corner, strolling through the isles, and pouring over boxes like looking through a photo album of our lives through rentals. I bet every person who reads this can think of not one or two but several memories that are placed so well by a movie. Maybe its a first kiss, maybe its the last movie you watched before moving to a new place, or maybe the first movie you watched after hearing some bad news. Regardless, movies have been event beacons in all of our lives, and seeing them all in one place helped give them a special place in our hearts, even it it wasnt as convenient as having a title sent to our mailbox.

So for every spur of the moment family movie night, every go-to 3rd date plan (and the success or failure soon thereafter), and for every laugh scream tear and cheer we ever put forward for a movie we took home from Blockbuster, I say thank you on behalf of our generation. Take a bow old friend, and good luck.