|
A quick journey through issues every team leader and software architect should be speaking to themselves and their developers about.
Software architects of today spend much of their time developing robust APIs (Application Programming Interfaces) for web based applications and sites. From Twitter to Evernote to Google Mail, web service API’s are becoming necessary when launching a “web 2.0” application. Perhaps the most important reason for this is to encourage and facilitate community development. This increase in development, traffic and most important “eyeballs” essentially provides the business with free marketing and advertising.
Despite the emergence of copious amounts of new web applications, security has still taken a back seat to design, marketing and implementation. From the large to small web companies are proving that history really does repeat itself.
“Twitter user Orli Yakuel, with 650 followers, had a nasty surprise this morning - her direct messages (private messages between two Twitter users) showed up in her normal Twitter stream (and were subsequently published to her FriendFeed account). Friends messaged her to tell her about the embarrassing issue.” [1]
“It is true that Evernote logs in (and apparently does a bit more) over SSL, but for some reason it falls back to plain, unfettered (and quite readable) HTTP to transmit your data to their servers. Which might be understandable for performance reasons, but which is regrettable in a service that aims to help you store and manage your information across multiple machines.” [2]
“The exploit makes use of a specially prepared website to steal the Google Mail cookie from the user to set the filter in an hidden iframe. This is why the account owners were never logged out of their account by the attacker. He never had physical access to the account. But the filter was enough to hijack the domains.” [3]
So, what is the issue with application security? Both the big and little guys are struggling with it, so we can assume its not primarily a money or talent issue. Is security still taking a back seat, to....just about everything else?
...Yes.
What can you do when working with developers and engineers during API definition to make [the resulting software] more secure? The first recommendation is that security concerns are realized and addressed at each and every phase of the software development process. Let's take a detailed look.
You have received the business requirements from the client and [you are now] defining the API. Some items to discuss with the development team.
- Only expose resources that are necessary. Remove everything else.
- Make sure every resource requires authentication, and if possible, two factor authentication.
- Store sensitive user data encrypted - yes, more overhead, but if a server is compromised, the data is still safe. Probably.
- Require all requests and responses flow over HTTPS.
- Use valid certificates only.
- Logging - Want to thwart bruce force attempts? Knowing about them is a great first step.
- Encrypt configuration data - db strings, passwords, etc.
Above are only a few ideas to get your thoughts flowing in API design meetings. Some may say this doesn't belong in an API meeting – but what a better place to get those involved in the project thinking about things they probably have spent little time thinking about in the past. During design!
Your API and DB have been defined, languages and platforms chosen. Your now working with the developers to schedule tasks and define the implementation details of the API. Again, here are some things to keep in mind when working with developers:
- Sanitize user input. Trust NOTHING coming in from the web.
- Do not write your own scrubbing, sanitizing and filtering code. Use a package with a solid track record.
- Do not store sensitive data in cookies. If you must, encrypt it. Otherwise, use the session scope.
- Logging & Accountability. You need to know who did what and when.
A first iteration of the API has been developed. The QA department is ready to make it break. Make sure QA is also ready to:
- Test resources not defined in the API. How does the application handle unexpected requests.
- Use invalid credentials.
- Check for information leakage. The API should not provide information on its language, OS, db, file system, etc.
- Attempt cross site scripting and sql injection. Ideally the application would stop and log such attempts.
Development and testing is going well. The application is on its way to production. Have your resident “security expert” spend an afternoon attempting to penetrate the application. The most important item to come from this is a brief report that highlights attempted attacks and system responses. This provides a record of the audit and generates a high level security view of the application release that can be provided to managers.
At this point you can feel confident that you have worked hard to design security into your application. Don't get too confident though, because your job is never done. As features requests and API changes are made the above security process should be repeated.
Abstract
What I provided is a BRIEF introduction to security. It's meant to get you thinking like an attacker. Feel free to contact me if you need advice, want to complain or just share stories.
Resources
[1] http://www.techcrunch.com/2008/04/23/privacy-disaster-at-twitter-direct-messages-exposed/
[2] http://the.taoofmac.com/space/blog/2008/04/29/2242
[3] http://www.ghacks.net/2008/11/24/new-google-mail-security-vulnerability-emerges/
|
