Periodic Blurbs (Warning: Exhortation Inside)

There are so many things to talk about these days, but I don't have the time to start writing long posts on each and every subject, so I've decided to dedicate yet another "periodic blurbs" post to them all.

• Anurag Agarwal started a (blessed) thread on browser security restrictions, in which he suggested a high level solution for vulnerabilities such as XSS and XSRF. After reading this thread, and following some of the links, I've discovered that there is an abundance of suggested solutions for browser insecurities, and it seems to me that a lot of people took a stab at what I believe would be the next evolution/revolution in web security. Now, all we have to do is start nagging to browser and server vendors, to join hands in the war against client-side attacks. If you are interested in "browser security revolution" - check out these links:

1. Ivan Ristic (Mod Security) proposed what I think is the most holistic and promising solution for browser security. He even gave it a TLA, calling it SBM (Secure Browsing Mode). You can't beat that.
2. Ivan's work references Gervase Markham's article called Content Restrictions - which I believe is probably the best solution around. This is a must-read article!
3. While researching the subject, I stumbled upon a very interesting research paper called "Defending against Injection Attacks through Context-Sensitive String Evaluation". The paper was written by two IBM researchers (go IBM!), Tadeusz Pietraszek and Chris Vanden Berghe, The paper describes an approach for defending against injection attacks such as XSS, SQL Injections, Shell command injections, etc. by addressing the root cause of these attacks - ad-hoc serialization of user provided input. Definitely worth reading.
4. PDP shares his own (pessimistic) thoughts on the subject of browser security. Here are a few quotes to wet your appetite:

   So yes, we can setup a policy but it will never take off. First of all standardization bodies needs to except it. Then browsers have to implement it and we have a browser war going on at the moment. No developer will implement a standard that is not widely adopted.

    

   IMHO we need to look at security personalization options within the browsers rather then inventing new standards that may crash and burn like they’ve done so far.

    

   Let’s get back to the question about CSRF. You can’t stop CSRF. This is it! The technology does what it is supposed to do. I see how some policies can be used for good, for example in situations where attackers are after your router through some sort of CSRF attack, but again, I seriously doubt that something like what Anurag has proposed will ever work. For sure it will improve the situation security wise in certain areas but at the same time will make Web technologies rather inflexible which is something that developers hate. I don’t think that people like crossdomain.xml either, and this is the reason why most sites allow everyone to connect to their stuff, although they probably don’t know about the dangers of doing that.

5. Several researchers from the IBM Tokyo research labs (Go IBM!), explain the security issues with today's browsers and propose their own solution for the problem in this very interesting presentation called "Security Model for the Client-Side Web Application Environments"

 

• I've seen a few cases lately, where people are becoming more and more aggressive about what they believe in. A friend from work claims that people in the software industry turn everything into a religion (e.g. Linux vs. Windows, Blackbox vs. Whitebox, Manual Pen Testing vs. Automated Scanning, etc.). When I started this blog, I promised myself that I will not get into personal fights with people, I will not slander, trash or badmouth anyone in the industry just because I don't share their thoughts - and believe me, this is hard, because I am a very enthusiastic person. Check out this latest soap opera (I tried to keep the actual time flow): "Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript" >> "Timing attacks on web privacy" >> "Putting up, then shutting up" >> "RSnake Puts Up" >> "Drama".

 

• [Trash Alert] The soap opera mentioned above, reminded me that some people in this industry really don't have any class or style. You see, some players in the web application security market are finding it hard to sell their products by presenting their own products' virtues and benefits, so they use the tactics of leeching on to their competition (usually using FUD), and in some cases, I believe they cross the line. BTW, the same competitor that was mentioned above, actually uses the Watchfire & SPIDynamics logos on their own web site - how desperate can you get to actually incorporate  your competitors' logo in your own ad?!?!

 

• While I am on the subject of "security wars", it seems to me that the web security market is so ripe (and hence, loaded emotionally), that people have completely lost their heads. Instead of joining hands and cooperating to educate the market, they prefer getting at each other's throats, over and over again. For crying out loud, we should all be saying the same thing -- Being secure is not about using whitebox or blackbox technologies, it's not about using a hosted service, or an application firewall, and it will certainly not come if you only use an automated scanner -- like anything else in the software world, security is all about perception, process, and methodology. If you want to secure your applications, make sure that you (and your development & QA teams) know what the actual problem is, that you have a process for eliminating security issues from the project inception phase, and up until the application goes GA (and even further). You have to implement a security process throughout your entire development lifecycle, using more than a single solution or product.

This industry needs to preach for a holistic approach to web application security, to encourage end users to use multiple solutions, tailored together for a complete solution instead of turning against its own members, in what oftentimes looks like a farce.

 That's it for now.

Comments

[dre]

Maybe I can be objective about this since I try to be heavily involved in the webappsec movement as it is - yet have never worked for a primary company or vendor in that space (well, at least not in many years).

Last year I did some assessments through a few different security assessment companies - all as 1099-misc. Some used web application vulnerability scanners such as SPI, Watchfire, Cenzic, et al. I didn't find any of these tools to be mind-blowingly awesome - and I probably wouldn't buy them if I was in the most likely situation to buy. I'll get to some of the "why" behind this later in this comment.

I've also attended a few OWASP meetings, vendor events, and have tried to remain active on the related forums and blogs, including this one.

Ory - thanks for pointing out this problem because it is a problem. From my perspective (and this may be a result of BH/DefCon) - it is getting worse by the day.

Allow me to summarize the industry war over the last year and what I see happening for the future. I think it's best to understand the problems before we come up with the solutions.

First of all, FortifySoftware has been the primary force trying to sell the idea that SCA scanners find more security related defects than any other solution. By failing to prove this idiom - they designed Tracer (their immature version of a web application fault-injection scanner) along with AspectJ bytecode weaving and EMMA (a code coverage tool) to show that dynamic-only fault-injection scanners do very little testing of the overall application.

But SCA scanners don't do testing - they do inspection. These are developer tools, and they are much cheaper than dedicating more resources (people, process, time) to peer review. If you can put a $2k/dev SCA security scanning tool into the hands of all your developers along with an advanced code coverage tool such as the $250/dev Clover tool (from Cenqua, now Atlassian) - then you'll be able to demonstrate using security metrics (see: Jaquith) that this method improves application security and is certainly worth the money invested.

Could you use PMD and EMMA instead? The simple answer is yes, but Fortify SCA and Clover are much more advanced [today] and include support contracts. Depending on how your business operates - you'll have to figure out which best suits your needs.

Secondly, web application fault-injection scanners have had to come up with new models to even be sold properly ($2k for a pen-tester 2-week license, $15k for a one year SaaS license, integration with operations, QA, and dev tools, etc) because of customer needs. This has hurt their business tremendously. Instead of concentrating on selling their tools to smart people who know they need it - these companies are starting to sell tools to fools.

Gadi Evron already established in "Fuzzing the Corporate World" that the only people that buy fuzz testing tools today are security product vendors (fuzzing before release) and financial companies (fuzzing before purchase). You should know your market before you start spending a lot of company money trying to "create a market" after you spent too much money on the product and a sales team of dead ringers.

Vulnerability sportsmen are also fighting to stay alive. Do you know why? Because they add zero value to the development process. They are all ego-driven by their work. Have you ever heard of a vulnerability hunter talking about how they discovered a vulnerability? Talk about full-disclosure! Have you ever heard of one including a coverage report with code complexity metrics with their findings? Do they ever talk about which taxonomy of errors they used - or which heuristics they created? Do they say if they know it is only repeatable under certain conditions because it requires fuzz stepping? Do they indicate where in the threat-model of the application their vulnerability findings fits? No, not a single person has ever done this - and it's not included as features in the fault-injection scanners available today. It's all Finding #1,2,3 - High/Med/Low.

Vulnerability hunters will include such information in their vulnerability reports, especially going forward. The market for binary and bytecode analysis of code coverage is bound to be larger than the SCA scanner market - not because "companies won't give out their source" - but instead because it actually is a viable way to find vulnerabilities (as opposed to SCA security scanners which find defects). However, just like PMD could not replace Fortify SCA - FindBugs or FxCop also have no chance of replacing what Veracode does today - not that any of these are bad tools. It's all about who uses them and for what reasons. PMD, FindBugs - et al - are for finding all types of code level defects, not just security vulnerabilities.

So, in summary - static source code security scanners, and static file security analyzers will be marketable solutions to all web application developers across the world for the development inspection process.

Hybrid fault-injection scanners will be marketable solutions to QA and security professionals (in dev/QA/ops/3rd-party) - and the instructional capital behind these hybrid scanners (and their reports) will be marketable only to verticals that require this level of assurance (e.g. financial, high-end e-commerce, and maybe healthcare). However, more and more companies will be requiring this sort of acceptance, operations, and maintenance testing between each other (also see: PCI DSS, OWASP secure software contract annexes, etc).

Lastly, and almost not worth mentioning - is WAF and APIDS. I have always contended the uselessness of these solutions because I don't even understand the problem that they are trying to solve. FortifySoftware Defender and Determina Memory Firewall aside - these products sometimes prevent some scenarios for some application vulnerabilities under certain trivial circumstances. So they're a great one-week $25k answer to a $2.5M problem you're facing. You are certainly better off with a 2-week pen-test using a dynamic-only fault-injection scanner and you'll never hear that from me again.

So, again, Ory - good post. In the last paragraph you provide the viable solution that nobody wants to listen to. Don't you vendors know what's going on in the real world? Have you ever been a developer for a mission-critical web application? Have you ever been an operator (yes, I guess security engineering for Yahoo or eBay like RSnake and Jeremiah did count - but they are obviously too immature, and also can't remember any lessons learned: probably blinded by the dollar signs they are seeking, or possibly jealously of not being bought by big-named computer companies like some of their competitors)?

I think Andrew van der Stock has been saying similar things recently (1) especially concerning the problems with spending too much time on FUD - and not enough time on solutions.
(1) http://www.greebo.net/2007/07/23/final-score-oscon-4234-black-hat-592-defcon-1118-appsecurity-10444-statistically-insignificant/

[AppSecInsider]

"Last year I did some assessments through a few different security assessment companies - all as 1099-misc. Some used web application vulnerability scanners such as SPI, Watchfire, Cenzic, et al. I didn't find any of these tools to be mind-blowingly awesome - and I probably wouldn't buy them if I was in the most likely situation to buy. I'll get to some of the "why" behind this later in this comment."

>>>>
Fair enough – although I bet if you gave me 30 minutes of your time, I'll be able to "convert" you to the dark side :-)
>>>>

"First of all, FortifySoftware has been the primary force trying to sell the idea that SCA scanners find more security related defects than any other solution. By failing to prove this idiom - they designed Tracer (their immature version of a web application fault-injection scanner) along with AspectJ bytecode weaving and EMMA (a code coverage tool) to show that dynamic-only fault-injection scanners do very little testing of the overall application."

>>>>
I don't think this was the beginning of it all – there was a lot of anti-blackbox/anti-automation going on long before Fortify even existed. Actually, I think Fortify Tracer is a brilliant idea.
You see, blackbox scanners are not "robohackers", often times they require configuration and customization in order to be able to properly scan an application. Using Fortify Tracer (or any other code coverage tool), one can know what parts of the application where not scanned, and go back to tweak and configure the blackbox scanner to work properly on the application.
Having said that – I do think that Fortify's Tracer sales approach was a bit aggressive, and they took the easy path – pushing their own technology, while trashing the blackbox vendors. I actually mentioned this to Brian Chess during the OWASP Conf. in Milan.
I know that my own company (and probably other blackbox vendors) never trashed source code analysis as a technology. We never saw the need to advance our own technology on the expense of others. There are enough security issues for everyone!
>>>>

"Lastly, and almost not worth mentioning - is WAF and APIDS. I have always contended the uselessness of these solutions because I don't even understand the problem that they are trying to solve."

>>>>
You don't understand what WAFs are supposed to do? Come on…. I've seen some great WAFs around (especially Sanctum's AppShield RIP).
>>>>

Anyway dre, thanks for taking the time to read my long post, and posting your own long comment :-)

[dre]

@ Ory,

You said, "Fair enough – although I bet if you gave me 30 minutes of your time, I'll be able to `convert' you to the dark side".

Actually, it's funny you mention that. In the past two years, the only cold-call that I've received as a result of filling out whitepapers was from Watchfire. This was around November or December of last year. I talked with the sales guy for about an hour - he was highly entertaining and knew the subject-matter well. I told him that I didn't think [web app scanners] were mature enough to consider now, but that they probably will be in 2007.

Then you said, "I don't think this was the beginning of it all – there was a lot of anti-blackbox/anti-automation going on long before Fortify even existed".

Oh very true. It's just the starting point in our conversation that I chose to begin with. It's also one of the more popular arguments (SCA vs. Fuzz testing) on various mailing-lists (e.g. fuzzing, secure coding, et al).

You also said, "We never saw the need to advance our own technology on the expense of others. There are enough security issues for everyone!"

Not everyone sees it that way. I think the problems go much deeper than some of the issues we both hit on.

Lastly, you said, "You don't understand what WAFs are supposed to do? Come on. I've seen some great WAFs around (especially Sanctum's AppShield RIP)".

Sure, I mentioned Fortify Defender and Determina Memory Firewall... OWASP Stinger and others are certainly in this category. I guess I was referring to vendors such as F5, Cisco, et al. I certainly do understand the problem they are trying to solve - I'm just not certain that they solve it.