About

Hyperguarding your Web Applications is maintained by affiliates of art of defence as a forum for discussing news and issues in Web Application Security, dWAF technology, PCI compliance and data protection.

Archive for September, 2009

The ‘as-a-service’ – or XaaS – opinion and future-casting has officially taken off. Thinking Out Cloud gives a good overview (although we have a slightly different view of the conclusion). Risk Bloggers shared a few worthy thoughts on making sure you end up with a stable XaaS (referred to as cloud) provider.

Security is the giant reality check to the hype curve here. It’s being discussed in terms of web application development from the ground-up, combined with policy changes. See Jon Oltsik’s commentary. Vendors are having their say, such as GigaSpace. Amazon of course is leading the discussion. The busy folks at Rackspace are in full tilt on the issue (as you’d expect).

So what’s missing? Only that the before mentioned musings all focus on security as a starting point before launching XaaS’s. All well and good, however, what about the raft of applications that have been pushed out of the network and live as XaaS’s right now? Are they left ‘to the wild’ as it were?

Companies can’t take the time, effort and risk of taking applications offline to refactor (or re-architect from scratch). One approach is to hook a source code scanner into your distributed Web application firewall (dWAF) to create a virtual patch until the developers can get their hands on the code and fix it. Art of Defence’s thoughts on dWAF use here.

Starting security from scratch for XaaS’s is the right thing to do, yet there are ways to shore up existing applications right now.

What’s missing is ruleset flexibility and control, which also happen to be the biggest points of contention with WAF technology today. A little variety in deployment is also handy in a virtualized setting for ease of deployment – a distributed WAF if you will, or dWAF. Specifically:

Detection and Protection

Foundational security using black, white and grey listings for application requests and responses must be possible. To make sure pre-set policy enforcements are not activated or deactivated without approval from an administrator, deployment and policy refinement through establishing rulesets must be possible in a shadow monitoring or detection only mode. Once the shadow monitoring ruleset is stable, only then should it be allowed to deploy in an enforcement mode on the dWAF. This allows complete transparency for the administrator into the real-world effect of this ruleset, while at the same time allowing layered rulesets to be tested without compromising existing policy enforcement. Avoiding false positives and relaxed established defenses are essential for a real-world, usable dWAF in a cloud.

Automated learning and ruleset suggestions based on intelligent algorithms or recommendations from a static source code analyzer or web vulnerability scanner are also desirable from a manageability view. Again, this only holds true if the administrator retains full control over activation / deactivation of each ruleset. Without this control, wanted traffic may become blocked and policy settings would become compromised.

Application Shielding

Pro-active security functions are highly recommended to reinforce any application in a cloud. Detection is simply not enough for today’s web application security. Features like transparent secure session management, URL encryption and form-field virtualization will provide strong deterrence to attack, while saving application development and deployment time. These features are effective because session management, URL encryption and form-field virtualization is done at the dWAF level and not in the application itself.

An authentication framework support that enables businesses to consolidate their applications under one management schema is also desirable for a dWAF. This enables users to handle the authentication in front of their applications rather than behind, which adds another perimeter of security. A consolidation of all applications with dedicated rights-management ability is also a strong usability function that will make an administrator’s life easier.

“I perform security code reviews of internally written and commercial packages every day. It is stunning how many problems I see. Why does XSS still happen? For one, time pressure. Developers are under time constraints to deliver so they cut corners and push things out. Management for the most part does not take security seriously or they adopt a see no evil mindset and ignore the problem until they get bitten down the road. Lack of understanding is a big one too. I have been a developer for a long time and I was not trained or even sensitized to the issue until relatively recently. I know a lot of my colleagues past and present are in the same boat. We aren’t doing Cobol on a mainframe either, we are all Java/.Net/Ajax/Web 2.0 developers. The problem simply isn’t well understood and not enough attention is paid to it.”

“The problem with XSS, and cyber security in general, is awareness. People don’t see security as a problem until it impacts them. Next, highly secure software is a consumer EXPECTATION. It’s not generally a feature consumers are willing to pay extra to include in their products.

I recently read a very interesting article, Tech Insight: XSS Exposed, by Dark Reading’s John Sawyer. He discusses how a cross-site scripting (XSS) attack can steal a user’s credentials, exploit their Web browsers and take action on their behalf without their knowledge. I wanted to add some of my thoughts on this article and share ways users can prevent and protect themselves against these attacks.

As stated in the article, XSS is always caused by missing input validation, the place where hyperguard comes into play. It scans every request (and therefore every user input) for malicious code that wants to be stored or executed. When a user is tricked into clicking a link containing XSS, the request is denied by the distributed web application firewall (dWAF) and the script will not run. Also, the script will not get stored into a database if the dWAF prohibits the request with the data from entering the web application.The problem with persistent XSS is that it is typically done on a prepared site that has bait for the victim, resulting in running malicious code.

The mechanism behind the protection that hyperguard delivers is easy and contains blacklist rules. These patterns know what an XSS looks like and causes the dWAF to deny the request. The second and more secure approach is to whitelist all input in the application. This is more work, but it helps to create a very secure web application, where every user input is validated. XSS attacks can take on many forms so you should never trust input from users.

In John’s article, he mentions OWASP’s XSS Prevention Cheat Sheet, which provides detailed information on when and where encoding should be done. XSS attacks should be taken seriously because they do happen often and can be very costly for businesses. It is important to take the necessary steps to prevent them and learn how to protect yourself if they do occur.

Earlier this month, SANS Institute issued a new biannual report with some scary statistics about web applications. If you don’t have time to sift through the entire report (it’s worth a the time if you can), basically OS attacks are down, application threats are up and web applications (such as websites) are way up – 60% of the total activity according to Rohit Dhamankar of TippingPoint’s DVLabs. Mr. Dhamankar’s company provided a lot of the data for the SANS report. Here’s an excerpt for the report:

“Attacks against web applications constitute more than 60% of the total attack attempts observed on the Internet. These vulnerabilities are being exploited widely to convert trusted web sites into malicious websites serving content that contains client-side exploits. Web application vulnerabilities such as SQL injection and Cross-Site Scripting flaws in open-source as well as custom-built applications account for more than 80% of the vulnerabilities being discovered. Despite the enormous number of attacks and despite widespread publicity about these vulnerabilities, most web site owners fail to scan effectively for the common flaws and become unwitting tools used by criminals to infect the visitors that trusted those sites to provide a safe web experience.”

Think about cloud computing after reading what SANS has found and realize cloud applications are subjected even further to this problem. Those in the industry have known this to be the case for a long time so it’s good to see SANS making headlines with the actual data! Hopefully the New York Times coverage helps shed much needed light on this issue.

Great article on the 16thfrom SearchSOA.com by Rob Barry. He interviews a developer at Mozilla Labs – Joe Walker – about a few of the OWASP Top 10 and how to develop around them. Walker’s focus as a developer is on creating / patching / managing security threats to apps. What’s missing from Barry’s article, however, is the incredible pain this approach causes companies right now.

Refactoring code once it’s in use (particularly WebApps and cloud services) is incredibly expensive, time consuming and difficult. Source code scanners play a role in easing some of this pain, although web application firewalls (WAF’s) are a much more practical fix, AND, linking the scanner software directly with the WAF cuts down the need for application downtime.

If done right, the scanner detects software vulnerabilities and feeds any findings directly into the WAF. For our distributed WAF (dWAF) solution, hyperguard, all security lapses identified by a scanner are immediately presented to the administrator through dynamic ruleset suggestions. Conflicting dWAF rulesets, which may leave holes in web application shielding, are prevented. In plain English, this means that development, testing and deployment of new application security policies can happen in real-time without ever relaxing the established defenses or risking false positives. ‘Patches’ are applied through the dWAF until regular maintenance cycles can be scheduled to refactor the actual application code.

I recently read Web security is about scalability, a very interesting post by Jeremiah Grossman of White Hat Security. He discusses the importance of scalability in overcoming today’s Web security challenges. I would like to add some of my thoughts.

It has taken the industry over 10 years to realize that when dealing with Web application vulnerabilities, they must also deal with the scalability issues these applications face. This needs to happen in parallel with normal security testing. As Jeremiah highlights the incredible scaling needed today:

“Consider that there are 240+ million websites, millions more added every month, an unknown number of Intranet Web applications, 17+ million developers, and over one billion people on the Web. Any solution capable of making a real difference must be valued by its potential worldwide impact.”

Testing a web application on a single system (how most are tested before being sent out into the world) without taking into account scalability is costly. Once that application hits it’s performance limit it usually means a redesign and rewrite of core elements to make it more scalable, changing how and what is important to test. Think of the OWASP top 10 on Jeremiah’s scale!

Cluster computing, or cloud computing, presents a remedy to developing, testing and scaling web applications in a much more practical sense.

Flip the coin to protecting the applications once they’re live and in action, and Jeremiah’s scalability point becomes painfully apparent. Web application firewall’s (WAF) are the industry standard for this purpose, however they are predominantly hardware. Hardware doesn’t scale – you have to buy another box. More boxes, more resource drain, less virtualized resources and on and on.

The article Jeremiah references in his post (check here for the white paper), outlines my view of what the market needs from a WAF.