Web 2.0 Security

Is OpenID too open?

Lori MacVittie — Mon, 20 Oct 2008 11:02:43 GMT

One password to fool them all

One password to find them

One password to steal them all and in the ether become them

[with many apologies to J.R.R. Tolkien]

For years we've had it beat into our heads that using the same username and password for everything on the web leaves us open to compromise and identity theft. The on-demand nature of conversations and social networking has apparently left us all bereft of our wits as we embrace the very concept we've been warned about for years. But is it really as dangerous as we've been led to believe?

The concept of a single identity that can be shared across disparate sites is hardly new. Liberty Alliance proposed SAML as the underlying technology to provide a single sign on (SSO) functionality for the web years ago and it competed with Microsoft's Passport for mindshare.

But neither took off; both were "ahead of the times". Social networking hadn't taken over the web yet, and people didn't really see a need to take the risk.

That was then, this is now.

OpenID is succeeding where the Liberty Alliance with SAML and Microsoft's Passport (now "Live ID") failed. It's easy to use, easy to integrate with your own site, and seems to be everywhere. Just set up a single identity at OpenID or a participating site like Technorati and you can use that same identity over and over to sign into hundreds of social networking sites around the web.

Despite knowing that it's dangerous (or so we're told), that it's a risk (and a big one at that, they say), hundreds of thousands of us (and that 'us' is mutually inclusive, mind you) use OpenID either directly or indirectly by tying our identities at myriad social networking sites to a single identity. We do this despite knowing that if that single identity is compromised that it can be used against us at every site through which we use that identity to interact with others.

The uber-security minded folks may now commence screaming and holding their head in pain as they morph into something out of an Edvard Munch painting at what I'm going to say next.

HOW MANY WALLETS DO YOU CARRY?

The risk appears to be minimal, despite the advertisements and scary articles to the contrary, and the benefits apparently outweigh that risk. Much in the same way we rail against additional security precautions at the airport, referring to them as unnecessary and doing nothing but offering a false sense of security, perhaps the "never use the same password" precaution, too, offers little more than a false sense of security.

As Alan Shimel unfortunately discovered recently, separate identities doesn't really add a lot of security when the identity information is aggregated in a single place, which it all too often is. Compromise of your primary e-mail account is also likely to end up with your online identity compromised, whether you used OpenID or not.

The risks for you and I (I assume you aren't Alan Shimel, Robert Scoble, or Paris Hilton) having our identities targeted and stolen are likely on the same level as having our wallet stolen. If we leave it out on the table and walk away, yeah, it's probably going to get stolen. The digital equivalent would be, oh, posting the information somewhere public or using that single identity on a site that seems a bit less than trustworthy - or isn't implementing best practices in securing that data and preventing theft.

If you don't carry more than one wallet to protect your multiple credit cards and your identity, then is it really a problem using only one "digital wallet" to store you identity online? Probably not, as long as the owners of the sites at which you can use your OpenID are taking steps to ensure the security of the site and the underlying data.

MITIGATION OF THE RISK IS ON THE SITE, NOT THE USER

The risk of theft really has very little to do with users today, as we don't typically share our identities and passwords publicly. The risk has to do with the sites we frequent and what kind of security they have in place to prevent exploitation of vulnerabilities and data theft. There are no real regulations in place regarding notification of data loss for sites not storing personally identifiable information, as there are for financial and healthcare related institutions, so we may never know. And it's unlikely that your bank is going to offer OpenID as a means of identifying yourself. I shudder to even consider that as an option.

All things considered, using OpenID or at least the manual implementation of OpenID (same username/password over and over) doesn't seem to be really all that much of a risk unless you also use it for your online financial and healthcare information.

And I know none of us are doing that, are we?

Technorati Tags: MacVittie,F5,application security,OpenID,Liberty Alliance,SAML,Microsoft,Live ID,Passport,SSO,integration,password,e-mail,compromised,identity theft,security,Alan Shimel,Robert Scoble

Is Twitter the newest data security threat?

Lori MacVittie — Thu, 16 Oct 2008 11:00:02 GMT

One of the most dangerous threats to data security is also one of the least talked about: employees. Are Twitter and other microblogging sites yet another avenue through which sensitive data can leak out of the corporate database and into the hands of ... anyone? Perhaps more worrisome, what information are you giving away simply by being a part of the community?

Of course Twitter is a potential threat. Like personal e-mail accounts and instant messaging, Twitter and sites of its ilk are primarily messaging mechanisms, which translates into personal channels for exporting sensitive data outside the enterprise. If you aren't familiar with Twitter, its messaging mechanisms allow several "modes" of communication: a blast to the general twitterverse, a public reply to a specific twitter user, and a direct (private) message to another twitter user. The direct messages aren't displayed in your public timeline, only the intended recipient can see them, so they're perfect for sneaking out tidbits like customer information or competitive information like upcoming product features/launches.

Despite the good intentions of compliance initiatives like HIPAA and PCI DSS, implementation of security measures designed to comply with these standards tend to focus mainly on the easiest and most obvious ways in which sensitive personal information can be lost, stolen, or shared: web applications.

But Twitter is a web application, you say, so shouldn't it be covered?

Perhaps, but it likely isn't. Current regulations tend to concentrate on preventing data from being taken out of the enterprise database, not cut-and-pasted into a tweet or e-mail or instant message. While monitoring and even filtering of web applications is commonplace today, it's almost universally focused on filtering of inbound web content, not outbound except at the URI or domain level. Content filtering solutions can stop inbound web content containing naughty words and those naked pictures of Bea Arthur the transfer of which no one can explain. But they don't generally focus on filtering outbound requests and POST data, despite the inherent risk in allowing unfettered communication with the outside world.

There have been solutions offered to prevent this exact scenario from happening via e-mail, but monitoring around web and even instant messaging continues to primarily focus on inbound content rather than outbound content. This makes microblogging sites like Twitter a potential security risk when attempting to secure all the possible avenues through which sensitive corporate data may be leaked.

What's necessary to block these holes is a two-pronged attack posture:

Reiterate to employees the ramifications of exporting sensitive data, including recognition of having read and agreed to organizational policies regarding how the organization will deal with proven breaches involving data security. Hint: A slap on the hand may not be harsh enough, though getting medieval on them may be too much. Maybe.
Consider the implementation of a forward proxy security solution capable of at the very least monitoring outbound web content (over HTTP) and optimally blocking anything that appears to be a credit card or social security number or anything else that might be considered sensitive personal information.

Proactive information security (sometimes also known as 'due diligence' in legal speak) requires recognizing both possible holes and acting to block them.

CAN YOU SHARE TOO MUCH INFORMATION?

And even if you aren't concerned about Twitter as a possible data security threat, you might consider the number of brands that are using Twitter to communicate with customers. That means the folks following a particular brand (company) could be viewed as a very public customer list. In the past, vendors - especially startups, for whom Twitter is particularly attractive - have aggressively guarded their customer lists so that competitors can't swoop in and convince them to "change sides". Twitter offers a public view of customers - and potential customers - that could be easily used in sales strategies to obtain new customers.

Conversely, some companies have always been reluctant to admit whose solutions they use for security and software because they are juicy targets for bad guys. Letting the bad guys know which solutions might be securing or serving up their corporate data gives them an edge, and if employees are following a "brand" it might be a hat tip to those intent on harm or theft as to how to target their attacks.

Whether it's direct leaks of information coming from employees or inadvertently allowing too much information about customers or your own infrastructure to leak out publicly through deductive reasoning based on who you're following, the use of Twitter should be viewed as both a possible business benefit and a potential security threat.

Twitter and sites of its ilk are definitely a possible hole in your security strategy (isn't everything in the eyes of information security folks?) and should be evaluated and if necessary addressed sooner rather than later.

Related Links

The Unpossible Task of Eliminating Risk

What IT Security can learn from a restroom sign

PCI DSS Requirements 6.6: A best practice for the rest of us

New TCP vulnerability about trust, not technology

Technorati Tags: MacVittie,F5,application security,web security,security,Twitter,microblogging,risk mitigation,compliance,monitoring,filtering,http,web,internet,HIPAA,PCI DSS

Which security strategy takes more time: configuration or coding?

Lori MacVittie — Mon, 29 Sep 2008 11:38:22 GMT

One of the arguments against the deployment of web application firewalls (WAF) is that it takes time to configure these devices to fit each individual environment. This is allegedly one of the reasons that secure coding is preferred over security devices. But it takes time to code solutions and deploy them, too.

In fact, depending on the lifecycle management at any given organization, it can take more time to code a solution and get it moved through a phased environment into production. One of the benefits of an application delivery platform and web application security deployed at the perimeter of the network is that solutions are often deployed in days rather than weeks. Consider the case of BusinessWeek's infected site; a week after discovering the infection and vulnerability, the site was still not protected. Perhaps because the solution was still being put together and coded. A WAF could have protected that site within hours - if not sooner - of the vulnerability being discovered.

In some cases that time isn't all that important - perhaps the vulnerability being addressed is obscure, or highly peculiar to a custom application - and is highly unlikely to be exploited between the time it's discovered and the time a fix is put into production. But with language and platform specific vulnerabilities, the likelihood of that hole being discovered and exploited is much higher simply because attacks bots are often automated and sent to sniff out such holes like bloodhounds on an English fox hunt.

The configuration of an intelligent WAF in these situations is relatively quick compared to a code-based solution, and rarely must that configuration go through the same process, which results in reducing the likelihood your application will fall victim to the latest exploit.

But what about the normal configuration process, you say. That's where the time investment really adds up.

True. You can't simply deploy a WAF and click a button and say "start protecting my apps". Just as it takes time to code a solution so, too, it takes time to configure a web application firewall to secure your environment and applications, because they're all different. But it doesn't take nearly as much time as identifying where in the code to put a solution and what that solution should be, let alone doing the research to find the multitude of attacks you'll need to prevent.

The configuration of a WAF is partially automated; it can learn the hierarchy and architecture of your application and then begin applying security policies for them. The configuration really comes in with handling exceptions, and clicking some check-box options to determine how much security you want to apply. Yes, it takes some time, but not nearly as much time as asking developers to (1) learn every attack against which they'll have to code a solution, (2) code the solutions, (3) test the solution, and (4) deploy the solution.

A good WAF solution will also provide basic defenses against layer 2-7 attacks that are nearly impossible for a developer to code into their solution. An application does not generally keep tabs on each of the processes spawned to deal with a connection. A layer 7 DoS (Denial of Service) attack, for example, is unlikely to ever be recognized by an application because it requires a view of all requests across all connections, something an application is never coded to examine. Many of these protections require little to no specific configuration other than a check-box in a GUI.

There may be valid arguments out there against deploying a WAF, but the time it takes to configure them is not one of them.

Technorati Tags: MacVittie,F5,web application firewall,WAF,application delivery,application security,configuration,application lifecycle,internet,web,security

BusinessWeek takes viral advertising a little too seriously

Lori MacVittie — Tue, 16 Sep 2008 12:40:55 GMT

Yesterday it was reported that BusinessWeek had been infected with malware via an SQL injection attack.

[begin Mom lecture]

Remember when we talked about PCI DSS being a good idea for everyone, even though it's just a requirement for the payment card industry? If I've told you once, I've told you a million times: safer is better, more protection never hurts.

[end Mom lecture]

The coolest thing about the web is that, unlike being a mom with one teenager left in the house, I don't have to actually repeat myself. I can just link to it again...and again...and again.

Interestingly, the aforementioned report indicates that "Sophos informed BusinessWeek of the infection last week, although at the time of writing the hackers' scripts are still present and active on their site."

Why would that be? Perhaps because it takes time to find and fix the code responsible, and then actually deploy it out into production. This is one of the scenarios in which a web application firewall or an application delivery platform could be of assistance, as either could be quickly and easily configured to strip the offending scripts from all responses, giving developers the time they need to address the problem in the application.

Where's F5?

VMWorld
Sept 15-18 in Las Vegas
Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World
Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World
Oct 27-29 in Frankfurt

Article: Preventing SQL Injections

Technorati Tags: MacVittie,F5,WAF,web application security,security,application delivery,iRules,malware,BusinessWeek,SQL injection,web,internet,http,web application firewall,scripts

Why it's so hard to secure JavaScript

Lori MacVittie — Fri, 12 Sep 2008 11:49:44 GMT

The discussion yesterday on JavaScript and security got me thinking about why it is that there are no good options other than script management add-ons like NoScript for securing JavaScript.

In a compiled language there may be multiple ways to write a loop, but the underlying object code generated is the same. A loop is a loop, regardless of how it's represented in the language. Security products that insert shims into the stack, run as a proxy on the server, or reside in the network can look for anomalies in that object code. This is the basis for many types of network security - IDS, IPS, AVS, intelligent firewalls. They look for anomalies in signatures and if they find one they consider it a threat.

While the execution of a loop in an interpreted language is also the same regardless of how it's represented, it looks different to security devices because it's often text-based as is the case with JavaScript and XML. There are only two good options for externally applying security to languages that are interpreted on the client: pattern matching/regex and parsing.

Pattern matching and regular expressions provide minimal value for securing client-side interpreted languages, at best, because of the incredibly high number of possible combinations of putting together code.

Where's F5?

VMWorld
Sept 15-18 in Las Vegas
Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World
Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World
Oct 27-29 in Frankfurt

As we learned from preventing SQL injection and XSS, attackers are easily able to avoid detection by these systems by simply adding white space, removing white space, using encoding tricks, and just generally finding a new permutation of their code.

Parsing is, of course, the best answer. As 7rans noted yesterday regarding the Billion More Laughs JavaScript hack, if you control the stack, you control the execution of the code. Similarly, if you parse the data you can get it into a format more akin to that of a compiled language and then you can secure it. That's the reasoning behind XML threat defense, or XML firewalls. In fact, all SOA and XML security devices necessarily parse the XML they are protecting - because that's the only way to know whether or not some typical XML attacks, like the Billion Laughs attack, are present.

But this implementation comes at a price: performance. Parsing XML is compute intensive, and it necessarily adds latency. Every device you add into the delivery path that must parse the XML to route it, secure it, or transform it adds latency and increases response time, which decreases overall application performance. This is one of the primary reasons most XML-focused solutions prefer to use a streaming parser. Streaming parser performance is much better than a full DOM parser, and still provides the opportunity to validate the XML and find malicious code. It isn't a panacea, however, as there are still some situations where streaming can't be used - primarily when transformation is involved.

We know this already, and also know that JavaScript and client-side interpreted languages in general are far more prolific than XML. Parsing JavaScript externally to determine whether it contains malicious code would certainly make it more secure, but it would also likely severely impact application performance - and not in a good way. We also know that streaming JavaScript isn't a solution because unlike an XML document, JavaScript is not confined. JavaScript is delimited, certainly, but it isn't confined to just being in the HEAD of an HTML document. It can be anywhere in the document, and often is.

Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed. Not only would an intermediate security device need to parse the JavaScript, it would need to execute it in order to properly secure it.

While almost all web application security solutions - ours included - are capable of finding specific attacks like XSS and SQL injection that are hidden within JavaScript, none are able to detect and prevent JavaScript code-based exploits unless they can be identified by a specific signature or pattern. And as we've just established, that's no guarantee the exploits won't morph and change as soon as they can be prevented.

That's why browser add-ons like NoScript are so popular. Because JavaScript security today is binary: allow or deny. Period. There's no real in between. There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.

I am not aware of any security solution that currently parses out JavaScript before it's delivered to the client. If there are any out there, I'd love to hear about them.

Technorati Tags: MacVittie,F5,web application security,security,XML firewall,JavaScript,parserss,interpreted languages,XML,XSS,SQL injection

A Billion More Laughs: The JavaScript hack that acts like an XML attack

Lori MacVittie — Thu, 11 Sep 2008 11:01:27 GMT

Don is off in Lowell working on a project with our ARX folks so I was working late last night (finishing my daily read of the Internet) and ended up reading Scott Hanselman's discussion of threads versus processes in Chrome and IE8. It was a great read, if you like that kind of thing (I do), and it does a great job of digging into some of the RAMifications (pun intended) of the new programmatic models for both browsers.

But this isn't about processes or threads, it's about an interesting comment that caught my eye:

This will make IE8 Beta 2 unresponsive

<div id="test"></div>
..
t = document.getElementById("test");
while(true)
{
  t.innerHTML += "a";
}

What really grabbed my attention is that this little snippet of code is so eerily similar to the XML "Billion Laughs" exploit, in which an entity is expanded recursively for, well, forever and essentially causes a DoS attack on whatever system (browser, server) was attempting to parse the document.

What makes scripts like this scary is that many forums and blogs that are less vehement about disallowing HTML and script can be easily exploited by a code snippet like this, which could cause the browser of all users viewing the infected post to essentially "lock up". This is one of the reasons why IE8 and Chrome moved to a more segregated tabbed model, with each tab basically its own process rather than a thread - to prevent corruption in one from affecting others. But given the comment this doesn't seem to be the case with IE8 (there's no indication Chrome was tested with this code, so whether it handles the situation or not is still to be discovered).

This is likely because it's not a corruption, it's valid JavaScript. It just happens to be consuming large quantities of memory very quickly and not giving the other processes in other tabs in IE8 a chance to execute.

The reason the JavaScript version was so intriguing was that it's nearly impossible to stop. The XML version can be easily detected and prevented by an XML firewall and most modern XML parsers can be configured to stop parsing and thus prevent the document from wreaking havoc on a system. But this JavaScript version is much more difficult to detect and thus prevent because it's code and thus not confined to a specific format with specific syntactical attributes. I can think of about 20 different versions of this script - all valid and all of them different enough to make pattern matching or regular expressions useless for detection. And I'm no evil genius, so you can bet there are many more.

The best option for addressing this problem? Disable scripts.

The conundrum is that disabling scripts can cause many, many sites to become unusable because they are taking advantage of AJAX functionality, which requires...yup, scripts. You can certainly enable scripts only on specific sites you trust (which is likely what most security folks would suggest should be default behavior anyway) but that's a PITA and the very users we're trying to protect aren't likely to take the time to do this - or even understand why it's necessary.

With the increasing dependence upon scripting to provide functionality for RIAs (Rich Interactive Applications) we're going to have to figure out how to address this problem, and address it soon. Eliminating scripting is not an option, and a default deny policy (essentially whitelisting) is unrealistic.

Perhaps it's time for signed scripts to make a comeback.

Technorati Tags: MacVittie,F5,ARX,ASM,XML firewall,AJAX,JavaScript,billion laughs,exploits,digital signatures,RIA,IE8,Chrome,threads,processes,Scott Hanselman,security,Web 2.0,web,http,internet

You're Doing It Wrong

Lori MacVittie — Tue, 26 Aug 2008 12:01:04 GMT

Don and I were discussing security as a service and, as usual, he spouted off some wisdom in the form of an analogy that was too good to not to share.

When you're walking down the street with your entourage and an angry, I mean really angry, man steps out in front of you with a lead pipe where should your bodyguard be?

Yeah, that was my thought, too. He should be in front of me to stop the threat before I have to react. Even though the threat may not hit me if the bodyguard is beside me because he manages to reach out and grab the lead pipe before it lands a blow, I've probably expended unnecessary resources avoiding or flinching or cringing or screaming like a school girl at the action. Resources I didn't need to waste. I might even be (gasp) sweating from the exertion. And what a terrible faux pas for someone who can afford an entourage and a bodyguard to sweat in public.

Basically, if I get hit by that lead pipe or I expend effort avoiding being hit or even momentarily look like something out of an Edvard Munch painting, my bodyguard is fired because he wasn't doing his job. He's doing it wrong.

That's the difference between security as a service when provided by a web application firewall and security as a service when implemented as an internal, software service solution. The WAF is inline, in front of the application, preventing that lead pipe from damaging the application. The application never has to expend unnecessary resources or sweat in public (wasted CPU/memory utilization/connections) when the security is deployed in front of the application.

If you're thinking, "Hey, what's that really gonna do? Waste a couple milliseconds? Pshaw! No one will notice!" then you need to go now and read this post on latency. Really - go now. I'll wait.

Threat defense is necessarily defensive. And the best defense is a good offense; one that is proactive rather than purely reactive. That means acting before the threat truly becomes a threat. Allowing a threat to reach the application before it's been identified and filtered out is certainly better than doing nothing, but stopping it before it gets near the application is even better.

Technorati Tags: macVittie,f5,security,application security,waf,inline,services

What's the difference between a web application and a blog?

Lori MacVittie — Wed, 13 Aug 2008 10:35:44 GMT

Nothing. At least not from an attacker's perspective. A blog is an individual content management system, requiring storage (either database or flat file) and the ability to write to that storage. Comments allow discussion but also require access to files and or databases. It's an app, and that means it comes with all the baggage today's web applications necessarily come with: vulnerabilities.

Those vulnerabilities are likely to become more visible as more organizations adopt blogging and other Web 2.0 applications in the next two years. Analyst firm Gartner recently highlighted 27 technologies in its 2008 Hype Cycle for Emerging Technologies, and Web 2.0 is among the list of those that will be soon climbing out of the "Trough of Disillusionment" and entering mainstream adoption.

From the press release for Gartner's Hype Cycle

"Although Web 2.0 is now entering the Trough of Disillusionment, it will emerge within two years to have transformational impact, as companies steadily gain more experience and success with both the technologies and the cultural implications," said Jackie Fenn, vice president and Gartner Fellow.

Blogs are, by definition, a part of Web 2.0, as are many other tools that organizations are starting to adopt. Given that the SEC recently announced it would recognize corporate blogs as public disclosure, it's clear that blogs are coming into their own.

But no one writes their own blog software any more than they write their own content management systems. At least no one sane does. But that means relying upon, and trusting, third-party software like WordPress or TypePad. That means you're trusting that the software is free of vulnerabilities and has been developed with secure coding techniques.

It's one thing to insist your developers use secure coding techniques but it's a way different scenario when you're dealing with third-party, Internet facing applications like blogs. And you may recall that according to Verizon Business' 2008 Data Breach Investigations Report, 34% of breaches occurred through a web application.

If you're going to be using third party web applications that you cannot guarantee are secure (and you can't) then you ought to be taking advantage of a web application firewall. Yes, Fratto, I went there. But this time it's much harder to argue with the logic. You didn't write the software, you can't be certain it's secure, but you need to make sure it's as secure as it can be. A web application firewall can protect third-party applications just as easily as it can custom developed applications, and in many cases it's actually a lot easier.

And even if they are secure today, what about tomorrow? Sure, if a new vulnerability is discovered (and they always are, at an alarming rate) it'll eventually get patched, but in the mean time what are you going to do to secure it? Or will you take it down and lose the following you've built and the trust that goes with it?

Blogs, especially corporate blogs, are the Internet face to an organization. They are likely (one hopes) to be more visible and viewed than the corporate FAQ or product solution pages. But that visibility brings greater risks, especially in the face of a breach. A WAF can minimize the potential of a breach for your blog regardless of whether you or a third-party developed the software that powers it.

Technorati Tags: MacVittie,F5,security,web 2.0,web application security,application delivery,internet,web,http,application security,blogs,Gartner,SEC,Fratto

Three Web Application Vulnerabilities You Need to Know

Lori MacVittie — Fri, 18 Jul 2008 19:52:32 GMT

Via Hacker News and Peteris Kumins' blog on programming, hacking, software reuse and stuff comes the latest Google tech talk, this one on web application vulnerabilities and "how cybercriminals steal money".

While Peteris and Google are targeting web developers with this informative video talk, it's a great resource as well for security folks as well as network administrators tasked with understanding how to thwart web application attacks.

Even if you've deployed a web application firewall to protect you from these kinds of vulnerabilities, it's still a great idea to watch this one and get a better understanding of the attacks.

The three vulnerabilities covered are:

SQL Injection
Cross-Site Request Forgery (XSRF)
Cross-Site Script Inclusion (XSSI)

The video and direct link are included here as well, but check out Peteris' blog for an overview of interesting points in the tech talk.

Direct URL: http://www.youtube.com/watch?v=jc6Q1uCnbMo

Technorati Tags: MacVittie,security,Google,web application firewall,vulnerabilities,SQL injection,XSRF,XSSI,developers

Improving Security Through Dynamic Resource Obfuscation

Lori MacVittie — Mon, 16 Jun 2008 14:46:40 GMT

One of the most basic attacks against data-driven sites generated dynamically through scripting languages like PHP and ASP is to use the weaknesses of the language against the developer.

Attacks against sites that make use of scripting languages often attempt to exploit system level calls that can lead to all sorts of nastiness with very little work on the part of the attacker.

One of the ways to guard against this is to write secure code, of course, but we all know that we can only code against known attacks. The unknown is something we just can't always anticipate and that sometimes leaves us open to newly discovered hacks.

Resource obfuscation is an underused, overlooked capability on servers and application delivery platforms that can seriously improve the security of your web applications and decrease the chances of an accidental or automate breach of security. Resource obfuscation can be an added protection against attacks. By hiding or obfuscating the actual file/script being invoked you can prevent a lot of automated exploitation of vulnerabilities in the most popular scripting languages used to build dynamic web sites today.

Resource Obfuscation

Resource obfuscation, called "service virtualization" in the XML world, is really nothing more than rewriting the URI. In many cases you can simply "map" an external URI to an internal URI. For example, "/externalURI.php" will always map to "/internalURI.php".

If your solution is flexible enough, you could set up a map that can translate exceedingly obfuscated URIs such as "xyz123abc.php" into "internalURI.php". If you are really concerned about security and you have a truly dynamic application delivery platform with a feature like iRules you could even dynamically generate the external URIs, creating a per-session map, and replacing all the URIs in the payload with the session-constrained URIs. This is some serious work, but it would certainly keep the bad guys always guessing because the external URIs would never be the same because they would be uniquely generated on a per request basis.

In general, resource obfuscation is a simple, flexible addition to your security toolkit that is easy to implement and adds an additional layer of security around your web applications.

To make your web application even more secure try these additional simple security measures:

1. Make sure the internal URI isn't easily deduced from query parameters or the functionality of the script. For example, if you're calling a PHP script to delete a record, don't make the internal URI "deleteRecord.php", and don't include the name of the file in hidden parameters.

2. Use a WAF (Web Application Firewall) or your chosen solution for rewriting URIs to block external access to internal URIs if possible. This prevents exploitation of scripting level vulnerabilities in the event that an attack deduces the names of your internal scripts and applications.

3. Give your scripts and applications extensions (if applicable) that do not easily (and loudly) proclaim the language and platform on which your site is running. Consider changing PHP and ASP to .abc or .xyz, either on the server itself or using your chosen URI rewrite solution. It won't stop serious attackers, but it might confuse the heck out of automated bots and script kiddies, which can reduce the likelihood of someone discovering some overlooked vulnerability.

Imbibing: Coffee

Technorati Tags: MacVittie,F5,iRules,security,resource obfuscation,rewrite URI,service virtualization