/dev/sec/webapp

As one of the most anticipated gadgets in a while, and with the recent attention that Safari received, it will be interesting to see what kind of attack surface is available on the iPhone. There’s already been mention of “bringing down the AT&T network” with an iPhone exploit, but that’s simply a play off of something Steve Jobs said and really quite unlikely.

With that being said, it will be interesting to see what the attack surface of the iPhone will be. For the first time ever, a full-featured browser (ok, fine…minus Flash and Java) will be in use on a phone platform. Yes, I realize that MobileIE has been around for a while and it successfully utilizes JavaScript as well…but has anybody really had as much motivation as there is now to burst Apple’s bubble? With respect to Safari for Windows, security researchers were pounding on that within hours after its release. Will the iPhone be any different? Who’s going to be the first to find a host of bugs in the iPhone. What is the possibility for remote code execution? All these things remain to be seen and the attack surface might be relatively low, but there was one feature in a recent summary of iPhone browser capabilities that caught my eye:

- new telephone links allows you to integrate phone calls directly from your webpage. remember this is only on safari.

*pause*

*evil grin*

I wonder if the possibility will exist to automatically dial that number via some sort of path that the developers may not have considered. That could prove particularly interesting with the right combination of a site vulnerable to cross site scripting. I know other phones do this as well, but I’m not sure what the capabilities are of those phones vs. the iPhone as I’ve never researched the security of mobile web browsers to any great extent. Nevertheless, it will be interesting to see who pokes some holes in that thing first.

I’ve been doing web application security for over two years now, and while I’ve seen the tools get better and better, there is also an upper limit that they seem to have reached.  In the early days of web application security, most of the issues were fairly straight-forward.  Improper server configuration and easily-identifiable input validation issues were two of the most common problems and very easy to detect with an automated tool.  As web applications have matured (disclaimer: some still have a long way to go), the problems have gotten a little more obscure and more difficult to detect.

The Problems

Take the case of parameter manipulation, for example.  In most cases, parameter manipulation is as simple as changing a form submission variable and having data returned to you that you shouldn’t have access to.  Although extremely easy for a human to test, it is quite a challenge for an automated web application to understand what it should and should not have access to.  This also comes into play in the admin vs. user case where I’ve seen admin pages simply be restricted by the fact that they are not linked to from the user’s session.

Allowing a user to upload a file to your webserver is also extremely risky functionality.  Nevertheless, it may be necessary.  A web application scanner has to first identify potential file upload capability (which they can do), but then they have to determine if it’s dangerous…which they really can’t.  This isn’t just your standard PUT HTTP method…

With respect to input validation, web app scanners can detect the simple SQL injection errors and cross-site scripting that are instantly re-displayed to the page, but what about the more complex situations?  Take, for example, the form field that will happily accept html input but not actually output the malicious script until a summary page is accessed five pages further into the application. Or perhaps the application is doing some filtering of script characters, but it can be bypassed with a little manipulation.

When a web application scanner is referred to as “stateful”, it means that it can evaluate a web application that requires the browser to maintain some sort of state, such as being logged in to the application.  It does not, however, mean that the scanner is aware of the current state of the application itself and the data within that application!  This is a minor distinction, but a rather important one as web applications evolve and become more complicated.

Also, a web app scanner cannot safely scan a production environment.  There is way to much risk involved and while this is not an ideal means of security testing, it does happen from time-to-time.  Throwing a web application scanner at your dynamic production website is like sticking your hand in a wood-chipper and seeing if it comes out whole on the other end.

Finally, encryption.  Encryption is not easy.  There are well-tested standards for implementing crypto.  Many programmers don’t use them and feel the need to implement their own whether it’s for “speed” or some other reason.  They’re web app scanners…not crypto-analysis tools (although some have some quite good tools built in, once you identify the data to be tested…).

 Possible Solutions?

I don’t feel like I should just point out the problems, so here are some potential solutions!

Parameter Manipulation/Authorization - Allow the web application scanner to utilize multiple accounts for testing.  Try to access the same set of pages and see what the differences are.  Although there are definitely flaws in this approach, user intervention could assist in making this easier to achieve.  Most stateful web app scanners are based off an interactive user session, so it wouldn’t be too difficult to have a human identify pages that only that user should have access to.

File Uploads - Attempt to determine if cetain file types are allowed or disallowed through the file upload form.  While this may also require user intervention, it might not be too difficult to attempt to upload a set of files with different extensions and compare the results.  Realistically, however, the variety of web applications makes this nearly impossible to do effectively.

Advanced Input Validation - Make a real stateful web application scanning engine.  Maintain an internal hash structure of the application’s pages and how a user advances through those pages.  If an interactive session is used as the base of the scanning, attempt to identify what pages have output that was previously input by a user, as well as the path to those pages.  This will require quite a bit of logic, but theoretically seems feasible. In addition, allow for the ability for some page variables to be dynamic.  I haven’t seen this too often myself, but occasionally web applications will automatically increment or otherwise change some variable from page to page and the inability of a web app scanner to adjust for that will cause it to be inefficient.

Statefulness - As mentioned above, try to make web application scanning engines even smarter than they are today.  Web apps are becoming more complex and as they do so more advanced methods of tracking user data throughout the application are necessary.

Production testing - It might be possible to have a set of safe and unsafe tests, but the effectiveness of this approach will be severly limited. Safe production testing can only be done by hand.

Encryption - Good luck! Encryption is hard enough to get right while using it, nevermind trying to detect when it’s being used improperly.

To summarize, while web application scanners are good for evaluating the base level of security within a web application, there are a myriad of issues that currently cannot be detected by web application scanners available today.  While this is fairly well-known among security professionals, managers or other upper-level executives may not realize that the $100,000 they just dropped on automated web scanning is not nearly as effective as they believe it to be.  At this point in time, it still takes an experienced security person to not only analyze the results of the scans, but also to perform the necessary manual tests to catch what the scanners cannot. Toss in some source code review and you might have a good idea of your application’s security posture - it’s no replacement for having security embedded into every stage of  your SDLC, however! *wink*

I close with a few quotations:

Computers are magnificent tools for the realization of our dreams, but no machine can replace the human spark of spirit, compassion, love, and understanding.
- Louis Gerstner, CEO, IBM

Any science or technology which is sufficiently advanced is indistinguishable from magic.
- Arthur C. Clarke

Any technology that is distinguishable from magic is not sufficiently advanced.
- Gregory Benford

 

Along the same lines of my last post about reporting web application security vulnerabilities, Acunetix released a press statement stating that 70% of websites are at immediate risk of being hacked!  While this is indeed some marketing at play (note: immediate risk and hacked!), I wouldn’t be surprised if this were an accurate figure.  However, Paul McNamara  of Network World has dropped the gauntlet and as well as a $1000 challenge that the Acunetix claims are not true.  And we all know us security folk like nothing more than a good challenge!

Now the thing to note is that Acunetix obtained these statistic from websites that specifically requested an automated scan.  This is an evaluation of websites that are aware of potential security issues and are being proactive about security.  This does not include those sites that just don’t give a damn and happily go along spitting out SQL DB errors and unencoded user input.

So while this will help to raise the awareness of web site security, I still believe there’s the need for the responsible disclosure of web vulnerabilities for those companies that have _not_ had their sites scanned.

Nevertheless, it should be interesting to see this unfold.  I’m curious  whether Network World has regular web application security assessments…

I came across a new tool recently called Stompy, that appears to be a promising HTTP cookie analysis tool.  The author’s home page is here, and there are quite a few other useful tools there as well.  As mentioned on the SecuriTeam page, the well known cookie generation mechanisms have been analyzed and found to be quite robust, but any time a development team takes it upon itself to make their own implementation, there are frequently problems.  I hope I get a chance to use this tool in the near future.

A recent Slashdot article made reference to a story about the legality of reporting web vulnerabilities. This isn’t a new issue and it’s been discussed before in a variety of places, but I think it’s time that something be done about it.

Responsible disclosure is well-defined and commonly practiced in the software industry. Most companies will acknowledge vulnerability research, those who do it and attempt to address critical issues as necessary. Those who don’t…well that’s what the full disclosure list or MO*B’s are for. Yet the researcher’s in the latter cases generally do not fear legal retribution. Unfortunately, the same is not true for web-based vulnerabilities.

While I can see the reasoning (by testing for a web vulnerability, not only are you actively exploiting it but you are also exploiting it on a system that you do not own, have a license for, have control over, and one that has a massive amount of data you have no right to), I feel that well-minded Internet citizens should have a means by which to report these vulnerabilities to the appropriate authorities without fear of negative response. I’m not saying that we go out and try to actively evaluate random web applications, but I am saying that when you come across a website that happens to spit out verbose database error messages due to a simple typo…there should be some process for reporting that. This could not only serve to enhance the security of specific sites, but also to raise awareness with respect to secure web application coding in general. Yes there have been disclosures for some high-profile sites, but what of that one-off site you go to that has the pitiful id field in the URI that isn’t a high target but at just as much risk.

So what can be done? A few options come to mind and I’d love to hear a few more.

1. Draft a “Responsible Web Vulnerability Disclosure” document that defines the guidelines, limits and processes for reporting a potential vulnerability.
2. Partner with CERT, OWASP, governmental agencies for some sort of web vulnerability reporting.
3. Create a site for concerned netizens to report vulns in websites following similar guidelines(?) to standard disclosure practices.
4. Upload anonymous stop motion video to youtube of vulns in miscellaneous sites…(that’s a joke).

So those are just a few options, but ultimately it seems like some light should be shed on this and it seems like OWASP is a good place to start this push from. Lots of people are already on board including Jennifer Granick.  I’m scared to think of how many websites out there continue to remain at risk.

Welcome to my new OWASP blog, where I’ll be discussing various aspects of web application security including methodologies, techniques, tools, trends and anything else I come across that might be interesting.  Here’s hoping you find something useful!