ASP.NET vs. ASP.NET.MVC & security considerations

I just read a recent Dr. Dobb's article, as posted in Information Week and online, that provides perspective regarding moving from ASP.NET to ASP.NET.MVC.
Some quick highlights from the article to frame this discussion.
First, ASP.NET.MVC applies the "Model-View-Controller (MVC) to ASP.NET. The MVC pattern, which is frequently used in the design of web sites, aims to separate data, business logic, and the presentation to the user. The challenge in many cases is keeping business logic out of the presentation layer; and careful design based on MVC greatly reduces the prospect of this intermingling."
Second, the various perspectives.

ASP.NET.MVC upside:
"ASP.NET MVC is technically superior to ASP.NET Web Forms because, having been released five years later, it addresses the business and technology changes that have occurred during the intervening period — testability, separation of concerns, ease of modification, and so on."

The ASP.NET.MVC vs ASP.NET middle ground:
"When it comes to the core function, however, there is nearly no difference."

The ASP.NET.MVC downside:
"ASP.NET MVC has greater startup costs. And in some applications, ASP.NET MVC is a substantial turnaround from ASP.NET Web Forms."

I have no take on these positions either way; they all seem reasonable, but the topic triggered dormant thoughts for me bringing back to mind some interesting work from a couple of years ago.

The Dr. Dobb's M-Dev article, while clearly operating from the perspective of development and deployment, does not discuss some of the innate security features available to ASP.NET.MVC users that I think help give it an edge.

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC is a November 2009 paper that I've already discussed and is well worthy of another read in this context.
I'll use this opportunity to simply remind readers of ASP.NET.MVC's security-centric features, including available tutorials.

1) Preventing Open Redirection Attacks
Open redirection (CWE-601) is easily prevented with ASP.NET.MVC 3 (code can be added with some modification to ASP.NET MVC 1.0 and 2 applications).
In short, the ASP.NET MVC 3 LogOn action code has been changed to validate the returnUrl parameter by calling a new method in the System.Web.Mvc.Url helper class named IsLocalUrl(). This ASP.NET.MVC tutorial is drawn from Jon Galloway's blog.

2) Prevent CSRF
From the Windows Live paper:
"To defend a Web site against XSRF attacks, ASP.NET MVC provides AntiForgeryToken helpers. These consist of a ValidateAntiForgeryToken attribute, which the developer can attach to controller classes or methods, and the Html.AntiForgeryToken() method."

3) JSON hijacking
Casaba contributed to the Windows Live paper. From their blog:
"For JSON hijacking, they ensure that the JSON result included a canary check by default. This prevented developers from being able to return JSON without a canary, thus preventing JSON hijacking."
Much like the CSRF mitigation, the canary check comes through again.
The Windows Live method defined a custom ASP.NET MVC Action Filter attribute to define the HTTP verbs they would accept and ensure that each action required the use of a canary.

It's also a straightforward process to prevent JavaScript injection & cross-site scripting (XSS) in the ASP.NET.MVC View or Controller via HTML.Encode where you:
a) HTML encode any data entered by website users when you redisplay the data in a view
b) HTML encode the data just before you submit the data to the database
See Stephen Walther's tutorial for more.

In summary, in addition to ASP.NET.MVC's development and functionality features, perhaps these security-centric features may help you decide to make the move to ASP.NET.MVC.

Cheers.

APWG Survey and deja vu all over again

As a participant in the APWG IPC, and a contributing researcher, I was pleased to see Dave Piscitello's APWG Web Vulnerabilities Survey Results and Analysis get some press coverage as it went live in mid-June.
Rather than focus on the survey results (you can read those for yourself), I'd like to focus briefly on mitigation and concerns.
The Results and Analysis-compiled responses "suggest that web sites would benefit from broader implementation of preventative measures to mitigate known vulnerabilities and also from monitoring for anomalous behavior or suspicious traffic patterns that may indicate previously unseen or zero day attacks."
Given the broad scope of CMS platforms, forums, galleries, wikis, shopping carts, and others riding on top of the popular LAMP stack, the absence of such preventative measures and monitoring make for hacker nirvana.
Consider the problems shared servers introduce where vulnerabilities in any of the above-mentioned applications preloaded for on demand end-user deployment via cPanel (not to mention cPanel vulnerabilities) can lead to "game over."
Clearly there are challenges: resources, level of commitment to security by site operators, and hosting provider scrutiny to mention a few.
The problem is not new.
When pending Black Hat presentations are describing tools sets such as Diggity "that speed the process of finding security vulnerabilities via Google or Bing", or Embedded Web Servers Exposing Organizations To Attack, you know it's Groundhog Day. Great tool set (Diggity), but that we're still unfortunately talking about the ease with which hacker groups are finding "opportunities" is troubling to say the least.
When #3 on Kelly Jackson Higgins' list of suggestions to repel attackers states "eliminate SQL injection, XSS, other common website flaws" it's deja vu all over again.
The APWG Web Vulnerabilities Survey asked "What actions did you take to stop the attack?" Compiled answers resulted in data such as:
We patched or updated vulnerable software packages 21%
We had our developers fix our custom software 8%
While other results lean heavily towards security misconfiguration issues, there are still clear opportunities to improve SDL/SDLC practices.
As the survey report indicates, "This article barely scratches the surface of the intelligence the APWG IPC has accumulated from the Web Vulnerability Survey. A complete analysis of the survey results—with specific recommendations, remedies, and practices."
I'm in the midst of research focusing on the scanning and misconfiguration elements of Internet Background Radiation (IBR) using a variety of Web logs. This research still points back to the above mentioned problem space and suggestions, but will drive deeper into attacker and victim trends and traits. This work, coupled with earlier web application security research will feed the analysis paper pending publication by the APWG IPC.
My hope is to also present the IBR work at an upcoming security conference along with a paper or article.
Stay tuned.

OWASP Top 10 Tools and Tactics @ InfoSec Resources

I've been a busy lad of late and haven't been keeping up on posts, but I have been turning out some work elsewhere.
If you haven't already taken note, checkout my second installment for InfoSec Resources, specifically OWASP Top 10 Tools and Tactics.
It even made #4 on Reddit under NetSec and was March 24th's Post of the Day on PenTestIT. ;-)

{excerpt}

Lesson 1:

Software will always have bugs and by extension, security vulnerabilities. Therefore, a practical goal for a secure software development lifecycle (SDLC) should be to reduce, not necessarily eliminate, the number of vulnerabilities introduced and the severity of those that remain.

Lesson 2:

Exploitation of just one website vulnerability is enough to significantly disrupt online business, cause data loss, shake customer confidence, and more. Therefore, the earlier vulnerabilities are identified and the faster they are remediated the shorter the window of opportunity for an attacker to maliciously exploit them.

The conclusion is therefore simple: reduction and remediation of web application security flaws will shrink the number of attack vectors and improve security posture. Ground breaking, right? No, it’s old news, “security posture” is a worn out buzz phrase, and if everyone was diligent about the above mentioned reduction and remediation, we’d likely not need a Top 10 list or a 12th Website Security Statistic Report (count on one). But hey, then we’d have to find different work, right?

Gifford Pinchot once said “Never bet on a race unless you are running in it.”

As solutions are always better than complaints, let’s discuss how to get in the race with some tooling options as we explore each of the Top 10.

{/excerpt}

You know I'm an SDLC fan, and an ardent supporter of OWASP. This article blends those passions along with some insight as to how I conduct web application vulnerability research.

Note: Over the next few months, I'll be drilling into to each of the OWASP Top Ten, exploring the specific vulnerability and the aforementioned tooling and tactics to aid in better discovery and mitigation.
Look forward to those followup articles at InfoSec Resources.

Hope you enjoy.
Cheers.

CSRF flaws that pack a punch

Note: These findings were responsibly disclosed and vendor updates have been issued.
See the eBbox Platform advisory here and the Snare advisory here.

A year after DEFCON 17, cross-site request forgery (still one of my favorite bugs) continues to present itself in some mighty interesting places.
I've already talked about it in the likes of wireless routers, UPS units, and a variety of web apps.
But it gets more sketchy when the vulnerable application gives up the keys to the castle via CSRF.
I don't mean just admin rights to the app, I mean compromise leading to control of the OS or platform itself.
Before I go into detail please know that both vendors in question responded instantly, provided fix time-lines, and met them precisely with corrective updates.
Two cases in point, keeping in mind that CSRF is often referred to as the one-click attack.
First, eBox Platform.
eBox Platform describes itself as a catchall that can act as a Gateway, Infrastructure Manager, Unified Threat Manager, Office Server, Unified Communication Server or a combination of them. One single, easy-to-use platform to manage all your network services.
Er, or one really broad attack surface.
Give away all that power to one tiny code snippet.


Figure 1

Failure to tokenize requests to the application means successful compromise with one errant victim click. Sending a halt order as seen in Figure is but a pittance as any request submitted via the browser-driven web management interface can be maliciously manipulated.
Preventing this attack clearly should be prioritized by developers; CSRF is number six in the OWASP Top 10 for a reason.

Next on our list: Snare from InterSect Alliance.
From their website: Snare for provides front end filtering, remote control, and remote distribution for audit log and event log data.
One agent to rule them all; one CRSF bug to rule all agents.
Meh.
Even though the web app for the Snare client can be configured with a password and localhost restrictions, an attacker need only convince a victim to click a link; it's simple GET request CSRF to finish the job.
http://192.168.248.231:6161/setremote?str_RestrictIP=192.168.248.235&dw_Password=on&str_Password=password&dw_PortChange=on&dw_WebPort=84
This request resets the password and the port, restricts IP access as well (in case you couldn't tell ;-)) and, as an example, via Snare for Windows, allowing the attacker to dump local users, domain users, registry, etc. On the likes of an AIX system add "remote control, and remote distribution for AIX audit data, interfacing with the underlying AIX audit subsystem as a custom stream object."
Scary.

eBox has issued the following fixes:
The problem can be corrected by upgrading your system to the
following package versions:

eBox Platform 1.4:
ebox 1.4.7-0ubuntu1~ppa1~hardy1
libebox 1.4.5-0ubuntu1~ppa1~hardy1
ebox-remoteservices 1.4.7-0ubuntu1~ppa1~hardy1

Snare has issued the following fixes:
SnareWindows - 3.1.8
SnareWindowsVista - 1.1.5
SnareAIX - 1.5.1
SnareIrix - 1.4.1
SnareSolaris - 3.2.4
EpilogWindows - 1.5.4
EpilogUNIX - 1.3

Typical recommendations apply.
For system owners, be on the lookout for vulnerabilities of this nature as you make use of convenient web-based system management interfaces such as eBox and Snare.

For vendors, make use of SDL or SDLC methods, and mitigate these risks in advance of release.

Convenience and efficiency are critical to success in enterprise computing environments, but with great power comes great responsibility. ;-)
Cheers.

Whitepaper Review - Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC

As part of a security team that cares deeply about the well being of Windows Live, I was extremely pleased to review a paper written by web application security specialists for whom I have deep respect.
Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC was written by a powerhouse team whose talent speaks for itself, including Casaba's Chris Weber; his Watcher was discussed in November's toolsmith.

First, I am an unabashed SDL fanboy. Any work that accentuates SDL principles is off to a great start in my book: security by default being paramount.
Second, of this paper's three subtopics (CSRF, open redirects, JSON hijacking), two (CSRF, open redirects) consistently count as pet peeves for me.
As for JSON hijacking, the best explanation available is also offered by one of the paper's authors, Phil Haack: JSON Hijacking.

"ASP.NET MVC provides a new Model-View-Controller framework on top of the existing ASP.NET 3.5 runtime. This framework enables developers to easily take advantage of the MVC architectural pattern to build Web applications."

When Windows Live moved to ASP.Net MVC it presented the opportunity to build mitigations into the framework that prevent developers from making accidental errors that could result in security flaws. Specifically, they targeted the three above mentioned web application security flaws – CSRF, open redirects, and JSON hijacking.

Highlights (thanks to Deepak Manohar):
CSRF is mitigated via ASP.Net MVC in that, by default, all HTTP requests are checked for a canary except for HTTP GET requests, or requests that developers specifically request not to be checked (keep an eye on those developers :-)).
"To defend a Web site against XSRF attacks, ASP.NET MVC provides AntiForgeryToken helpers. These consist of a ValidateAntiForgeryToken attribute, which the developer can attach to controller classes or methods, and the Html.AntiForgeryToken() method. The Windows Live team implemented a modified version of this approach."

To protect against open redirects, the Windows Live "could have added a new SafeRedirectResult class that checked the list of allowed Web sites and required all developers to use new class. However, a given developer might not know about this rule and might use the RedirectResult object manually. If this code was not caught by performing a code review and testing, it could result in a security bug. Thus, the team did not create a new class opting instead to change the behavior of the default class."

To protect against JSON hijacking, enter the WLXSecurityAttribute: "The WLXSecurity custom filter attribute is a class that implements the IActionFilter interface. This interface defines two methods called OnActionExecuting and OnActionExecuted. The OnActionExecuting method runs just before an action executes, and the OnActionExecuted method runs when the action has completed. OnActionExecuted is checked for an action result with a content type set to JSON or JavaScript; if matched, the result is checked to ensure that canary validation has been applied. The canary validation is typically included as part of the form post when using POST actions, but it can also be part of the query string."
Any action requiring canary checking where a canary is not provided with the request results in an exception: no data interchange for you!

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC is a recommended read, specifically for those of you managing developers or aiding them in securing their code.

Give it a read, and by all means feel free to provide feedback via comments.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

IT Infrastructure Threat Modeling Guide now available

In April I discussed the IT Infrastructure Threat Modeling Guide (then in beta), a Solutions Accelerator I've written with the Solution Accelerators for Security and Compliance team.
The IT Infrastructure Threat Modeling Guide is now available for download via the Technet Library and the Download Center.

Networkworld's kind coverage of the guide's release provides additional insight.

Purpose of this Guide:
Provide an easy-to-understand method that enables IT professionals to develop threat models for their environments and prioritize their investments in IT infrastructure security.
IT infrastructure threat modeling should be incorporated into an organization's IT mindset as a matter of policy, much like any other part of the validation, implementation, and installation process. Threat modeling in the name of secure infrastructure should be performed throughout the technology implementation process, much like any other component that is measured for performance, usability, and availability.

This guide maps directly to SDL guidance and marries threat modeling infrastructure to a sound, existing framework.
This has been quite an effort and a valuable learning experience for me.
I'd like to thank the following for their contributions, leadership, and effort during this process:
Kelly Hengesteg, Steve Wacker, Karina Larson, Adam Shostack, Frank Simorjay, Jeff Sigman, Chase Carpenter, Sumit Parikh, and Shruti Kala.
To the numerous people who reviewed and provided feedback, thank you as well.

When you use a structured method as described in this guidance to develop threat models for your IT infrastructure, you identify and mitigate threats to your environment in an efficient and effective manner.
It is the intent and hope of this guidance that the benefits of choosing to develop a threat model portfolio for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

I look forward to your feedback as you read the IT Infrastructure Threat Modeling Guide and hope to learn of your success stories as you utilize it to enhance security in your associated environments.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

The IT Infrastructure Threat Modeling Guide

After reading a toolsmith article I'd written on PTA: Practical Threat Analysis, Frank Simorjay, a local ISSA chapter member, friend, and co-worker reached out to a peer team in the Microsoft Solutions Accelerators (SA) group and suggested the prospect of something similar to be added to the SA roster.
After meeting with the SA Security & Compliance team, and a couple months of excellent collaborative effort with the likes of SDL expert Adam Shostack, group PM Kelly Hengesteg, editor Steve Wacker, and contributor Jeff Sigman, I authored the IT Infrastructure Threat Modeling Guide, now released in beta on the Connect site.
Sign up for the beta program here, then bookmark this.

Threat modeling has been well applied during the software development process, but there has been a noteworthy, Internet-wide lack of documentation and guidance with regard to applying threat modeling methodology to infrastructure. While many people and organizations threat model infrastructure in some form or fashion, we believed it was time to create a unified process that anyone from a small, one person IT shop, to a major enterprise could follow, and thus improve their security posture.

The IT Infrastructure Threat Modeling Guide provides an easy-to-understand method that enables you to develop threat models for your environments and prioritize your investments in IT infrastructure security. This guide describes and considers the existing Microsoft Software Development Lifecycle (SDL) threat modeling process and uses it to establish a threat modeling process for IT infrastructure.

Please feel free to give it a close look and submit feedback, we really do welcome it.

It is the intent and hope of this guidance that the benefits of choosing to develop a threat model for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

del.icio.us | digg | Submit to Slashdot

The 100th post: Philosophy feeding action

As I was writing this I realized that this is my 100th post, and it therefore seemed somehow significant. With some interesting personal news to report it also provides me with the opportunity to declare a current philosophical mission statement:
No matter the activity, be it researching, advising, and disclosing ailing web applications, tracking malware attributes, or researching and documenting useful tools and methodology for incident responders and security professionals, I do it for one reason.
I simply believe it is our inherent responsibility to try to thwart miscreants in anyway possible. There are too many of them, and too few of us. Thus, the more we disclose and fix, the better we understand maliciousness, the stronger our implementations and investigations, the more secure we may become.

Two recent developments speak directly to this philosophy:
1) The Solutions Accelerators group at Microsoft, my employer, asked me to write the IT Infrastructure Threat Modeling Guide, born of an ISSA Journal toolsmith article I'd written on PTA (Practical Threat Analysis).
2) I was invited to join the APWG Internet Policy Committee, born of conversations with Dave Piscitello regarding the Anatomy of an XSS Attack.

First, with regard to the IT Infrastructure Threat Modeling Guide, this guide takes the SDL appproach to threat modeling and applies it specifically to infrastructure. When the beta goes this Friday, you can register and provide feedback here.
One can consider threats to IT infrastructure from four specific perspectives:

1) Re-architect and re-implement to eliminate them.
2) Apply well understood mitigations.
3) Invent new mitigations.
4) Accept the risk.

These are entirely viable perspectives, but the practice of threat modeling your infrastructure must precede these considerations.
To that end, the IT Infrastructure Threat Modeling Guide is designed to help IT professionals accomplish the following:

• Identify threats that could affect their organizations’ IT infrastructures
  
• Discover and mitigate design and implementation issues that could put IT. infrastructures at risk.
  
• Prioritize budget and planning efforts to address the most significant threats.
  
• Conduct security efforts for both new and existing IT infrastructure components in a more proactive and cost-effective manner.

Second, with regard to the APWG Internet Policy Committee, my intended focus here is to participate in guidance to help harden web services in defense against the dark arts...cybercrime, phishing, fraud, etc.
To get a better sense of what the APWG IPC is all about, see see Co-Chair Laura Mather's series on online fraud here.

As pertinent to either of these recent developments, I invite feedback and participation. Please feel free to contact me via comments here or email.
This work, this blog, my philosophy, my mission, are all carried out with you in mind, dear reader.
I thank you for your support and readership, and I look forward to the next 100 posts.

del.icio.us | digg | Submit to Slashdot