1. Error messages enabled
2. Cross-Site Scripting (unescaped input)
3. And yes, SQL Injection of some sort

The (un)fortunate thing is that most of these issues are easily solvable. A generic error page, as opposed to a stack trace or verbose error message, can usually be implemented with a couple configuration changes. Yet, I still see large websites that spit out stack traces and code when an error occurs.

Cross-Site Scripting is another issue that still plagues us. Testing for it is simple – just enter something like test"> into an input field and if the resulting page displays that in raw HTML, chances are you have a problem. Every language has some form of HTML-escaping function and, if possible, it’s good to turn this on by default. This will be the case in Rails 3.0, thankfully.

Finally, I still see traces of SQL Injection on an all-too regular basis. Identified by the oh-so-dangerous single tick mark – ‘ – and typically resulting in an error page that shouldn’t be showing up anyway if the first issue were address. That said, even if the error is obscured, it’s still possible to retrieve data using a technique called Blind SQL Injection. Any data getting sent to an SQL server should also be properly escaped or sent through stored procedures depending on the backend technology. Think SQL Injection isn’t a problem? Talk to RockYou, whose database of 32 million usernames and passwords was compromised because of it.

Address those three things and (sadly) you’ll be ahead of the game.

As App Engine does not automatically escape output, you need to do this yourself.

As an example, here’s a very simple snippet:
Welcome, {{ firstname }}!

If “firstname” is not properly sanitized when stored in the database or escaped on output, I could easily make my first name the following:
damon<script>alert('hi!')</script>

And then we would have stored JavaScript code execution, aka Cross-Site Scripting, as the <script> tag would get interpreted by the browser when echoed out.

The solution?

Simple, just |escape your output when coding in Google App Engine:
Welcome, {{ firstname|escape }}!

You can also sanitize data prior to storing it in the database, but as an additional layer it’s good to escape it on output as well.

I’m not sure if this is a derivative of the fact that GAE utilizes Django 0.9.7, but I guess we’ll see when they upgrade to Django 1.0 as it autoescapes all output by default (thank you, Django!).

And what I’m finding is a little disappointing.

Perhaps I’ve become a little jaded in the past few years as a security consultant. Working with some large organizations where people usually “get” security makes most (yes, there is definitely still a decent level of feedback) conversations surrounding security fairly straightforward. Not only that, but large organizations generally have the benefit of staff that understand security risks and can effectively merge them with the desires of the business to reach a reasonable solution. But let’s take a brief tour over what I’ve come across recently. (Names left out to protect the innocent.)

Exhibit 1 – A random startup (Company A) allows signups on its web page. As with any new service, I’m sure reporters would have liked to have seen who was signing up from what companies, particularly in order to validate Company A’s claims of rampant success and signups. Company A, unfortunately, would display a users’ email address on the confirmation signup page. That confirmation signup page had a parameter that could be incremented up or down to reveal email addresses of anybody that signed up.

Class: Basic design flaw, forced browsing.
Status: Fixed, within a half-hour of reporting.

Exhibit 2 – Another random startup (Company B) has a new service that claims to solve some of your email woes. One of the features of this service is that you can subscribe to RSS feeds of your Inbox. Unauthenticated RSS feeds. Yes, yes, there’s a SHA-256 hash in the URL, but both Google Reader and Bloglines are searchable, not to mention the potential for referral sniffing or just plain information leakage issues.

Class: Design flaw, lack of authentication.
Status: Removed, within a half-hour of reporting. Put back into place using HTTPS. Authentication still not used.

Exhibit 3 – Company C has a sweet iPhone app. They also have a web page that is somewhat integrated into the application. That web page is vulnerable to SQL Injection.

Class: Input validation, SQL Injection.
Status: Reported, twice. No response. Depression ensues.

Exhibit 4 – Company D releases an update to their product and is highly regarded as their service no longer requires the installation of an additional component. Unfortunately, the new feature that permits for that is Cross-Site Scriptable.

Class: Input validation, Cross-Site Scripting.
Status: Reported on October 13. Waiting.

I guess what depresses me is that some of these are pretty basic issues. With all of these problems, I came across them within 5 minutes of using the application. I suppose this post is a plea to the startup’s of the world…

Please, if you aren’t familiar with security, take the time to either talk to somebody that is or bring in a security person for even just half a day to take a look at your product. If nothing else, it’s one less fire that you’ll have to put out. You can even contact me directly if you’re not sure what questions to ask, although I’ll probably put a post up about that at some point.

Granted, the statement above applies to everybody as even Russ McRee frequently points out on his HolisticInfoSec blog, many other organizations struggle with basic security flaws regardless of their size or status.