“Change is the constant, the signal for rebirth, the egg of the phoenix” — Christina Baldwin
Many of the security issues we are beginning to see with Web applications are issues that we have seen in some form with traditional client/server applications. Unlike the Phoenix, the Web application security issues are not rising from the ashes of traditional client/server applications. Client/server security is still very much alive. The Phoenix just provides better imagery then the Hydra, where if you cut the head off the Hydra two came back in its place. In the old days of the Internet (a few years ago), everything was done on the server. When you think about vulnerabilities in ftp, mail, and Web servers, it was the infrastructure groups responsibility for fixing it. Fixes were done by doing such things as setting up firewall rules, patching systems, upgrading server software, etc. With Web 1.0, the intelligence was pretty much on the Web server. Your Web browser would simply talk to your server where the applications resided.
Asynchronous JavaScript and XML (Ajax) changes the traditional model by having the application running on the browser where more of the work is done. The JavaScript engine runs on the browser, talking to the server and third party sources on your behalf. This is not unique to Ajax. Anywhere you have Rich Internet Applications (RIA), there will be this interplay between the server, third party sources, and the client. State information has to be shared between the client and server. Unfortunately, one of the lessons we have learned over the years is that you cannot trust the client. Outside of client side certificates, there really is no way for the server to know who is talking to it.
Shreeraj Shah, the author of Web 2.0 Security – Defending Ajax, RIA and SOA; Web Hacking (Stuart McClure and Saumil Shah co-authors); and Hacking Web Services, did a presentation at the HITB Security Conference titled “Web 2.0 hacking, keeping focus on Ajax and Web Services.” In the presentation, Shreeraj discusses the vectors of change between Web 1.0 and Web 2.0. In Web 1.0, the entry points were structured, there were limited dependencies, the vulnerabilities were on the server side (typically through injections), and there were server side exploitations. In Web 2.0, everything changes. You have scattered and multiple entry points. There are dependencies on multiple technologies, information sources, and protocols. Vulnerabilities can be exploited on Web services through payloads and on the client side through such exploits as XSS and XSRF. Exploits exist for both server and client.
More worrisome is that in many organizations, security remains solely network focused while developers are left untrained and unaware. Up until now, developers have not had to deal seriously with security problems. Add to this changing environment, pressure on developers to meet deadlines and develop code quickly. Some developers main goal is simply getting their application not to crash. It is easy to understand how due to lack of exposure and the need for quick code turn around, developers can fail to put security measures in place sufficient for a Web 2.0 world. Ross Anderson and Tyler Moore add some great insight into the software development environment in their paper, “Information Security Economics – and Beyond.” Ross and Tyler wrote:
In many markets, the attitude of ‘ship it Tuesday and get it right by version 3’ is perfectly rational behaviour. Many software markets have dominant firms thanks to the combination of high fixed and low marginal costs, network externalities and client lock-in noted above, so winning market races is all-important. In such races, competitors must appeal to complementers, such as application developers, for whom security gets in the way; and security tends to be a lemons market anyway. So platform vendors start off with too little security, and such as they provide tends to be designed so that the compliance costs are dumped on the end users. Once a dominant position has been established, the vendor may add more security than is needed, but engineered in such a way as to maximise customer lock-in.
In some cases, security is even worse than a lemons market: even the vendor does not know how secure its software is. So buyers have no reason to pay more for protection, and vendors are disinclined to invest in it.
Another outstanding article is by Sergey Bratus in the July/August 2007 IEEE Security and Privacy magazine titled “What Hackers Learn that the Rest of Us Don’t: Notes on Hacker Curriculum.” Sergey makes the following comparisons between developers in the academic programs to those in the hacking community:
- Developers are under pressue to follow standard solutions, or the path of least resistance to “just making it work.”
- Developers tend to be implicity trained away from exploring underlying APIs because the extra time investment rarely pays off.
- Developers often receive a limited view of the API, with few or hardly any details about its implementation.
- Developers are de facto trained to ignore or avoid infrequent border cases and might not understand their effects.
- Developers might receive explicit directions to ignore specific problems as being in other developers’ domains.
- Developers often lack tools for examining the full state of the system, let alone changing it outside of the limited API.
No one said it was going to be easy. The first step is to recognize that there is a problem. Actually, there are multiple issues to deal with when getting into application security. Just keep reminding yourself, one step at a time. The second step is to reach out and seek help. To help us on our road to security recover, Billy Hoffman and Bryan Sullivan have written the book Ajax Security. Billy has an interview on IT Conversations Technometria titled “Ajax Security” where he talks about Ajax in general and reviews some of the specific security issues most likely to occur. He also gives a number of examples of where security is likely to be a problem.
Richard Bejtlich provided the following very favorable review of “Ajax Security:”
Ajax Security was the last book I read and reviewed in 2007. However, it was the best book I read all year. The book is absolutely compelling and every security professional and Web developer should read it. It’s really as simple as that.
I am not a Web developer. I was not very familiar with Ajax (beyond its buzzword status and a vague notion of functionality) when I started reading Ajax Security. I attended the authors’ Black Hat 2007 talk and was thoroughly impressed and disturbed by the security implications they presented. I expected Ajax Security to be a good book, but one can never be sure if talented hackers and presenters can transfer their skills to the written word. Ajax Security gets the job done.
This is extremely high praise considering Richard’s background and the number of books Richard reviews.
Billy has done some outstanding presentations at Black Hat. In 2006, he presented Ajax (in)security. In 2007, Bryan Sullivan and Billy Hoffman presented “Premature Ajax-ulation“. If video is more to your liking, Bill presented “0wn3d: How AJAX Makes Web Hacking Easier.” In the presentation area of this site, there are a couple very interesting talks on Ajax:
- Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) by Dave Wichers
- Ajax Security by Andrew van der Stock
- Ajax Security Concerns by Rohini Sulatycki
- Hacking Ajax and Web Services: Next Generation Web Attacks on the Rise by Shreeraj Shah
Borrowing from Dave Wicher’s presentation, security issues that need to be dealt with include secure communications, authentication and sessions, access control, data protection, input validation and output encoding, error handling, logging & intrusion detection, availability, and concurrency. Not a simple task. Is Ajax applications less secure then other Web applications? Ajax, in and of itself, is neither secure nor insecure. The OWASP 3.0 Guide chapter on Ajax and “Other” Rich Interface Technologies states, “AJAX applications face exactly the same security issues as all other Web applications, plus they add their own particular set of risks that must be correctly managed. By their complex, bidirectional, and asynchronous nature, AJAX applications increase attack surface area.” Because of the increase attack surface area of Ajax applications, one can argue these applications are less secure. The truth is that other Rich Internet Applications, such as Flash, Java applets, and Active X controls can be just as insecure.
How do you go about securing Ajax applications? Borrowing from Rohini Sulatycki presentation, you need to validate all inputs, all client side validation must be backed up by server side validation, do not implement business logic validation client side, implement whitelist validation, do not trust third party source (filter it out), identify valid data and reject everything else, no direct cross domain call back, and encode all outputs. Do not cripple Web development in the name of security. Instead, organizations need to make sure developers know the security issues. Get security involved on the application side.
Expanding from securing Ajax applications to moving your organizations toward software security and application security, Gary McGraw wrote a nice concise article titled “Four ways to kick off your organization’s software security initiative in the New Year.” Read the article along with everything Gary writes. To summarize the four methods:
- A top-down framework approach…perform a gap analysis between where you are and where you want to be from a software security perspective. Then build a plan to address the gaps….
- The portfolio risk method takes a more business-oriented approach to the software security problem. The idea here is to assess the entire application portfolio according to some risk criteria agreed on in advance. …
- The training first approach to software security is more grounded in the technical world. This approach helps developers who love to do the right thing but just don’t know what the right thing is when it comes to security. …
- The lead with a tool approach, meanwhile, makes sense for an organization that has already purchased and attempted to roll out a security analysis tool….
Gary also does the Silver Bullet Security Podcast, where on broadcast titled “Show 021 – A Panel Discussion with Cigital’s Principals“, the principals at Cigital discuss the best ways for large companies to get started with software security.
Gunnar Peterson is his post titled “Go Wide and Deep, Incrementally” makes the point that the best method for an organizations depends on “what you are trying to do, your company culture, and the people’s skills who are working on software security.” Gunnar suggest a fifth method, “namely decentralized specialized teams, or centers of excellence in PHB speak.” He makes the important point that “to deploy any of the current cutting edge stuff in software security at scale, requires technical depth and deployment width. This automatically limits your resource pool of who can deliver this stuff.”
Gunnar offers additional advice in his post titled “Phasing Security into the SDLC – A Comparison of Approaches.” He suggest four main ways to get started: top down, testing and validation, start in the middle, and training. Gary and Gunnar favor a mix approach of top down and bottom up, “that approach often leads with the creation of a special ops execution team that becomes the software security group. By far, this is the most impressive approach in terms of results and the one that is the most effective in well-run enterprises” (Gary quote). They will not get any arguments from me.
Moving an organization towards an environment where secure code can be produced, let it be Ajax or any RIA, is not an easy endeavor. Like the software development life cycle, an iterative, incremental delivery is the way to go. You do what you can. You work the program, one day at a time. This way, you take the needed steps to a secure recovery.
