Posts tagged as:

SDL

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

by Russ McRee on August 28, 2011

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 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

by Russ McRee on July 22, 2011

in SBN

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.

WASC Announcement: ‘Static Analysis Tool Evaluation Criteria’ Call For Participants

by Robert A. on June 27, 2011

in SBN

I sent the following out to The Web Security Mailing List (which I moderate) announcing a new WASC Project. "The Web Application Security Consortium is pleased to announce a new project "Static Analysis Tool Evaluation Criteria (SATEC)". Currently WASC is seeking volunteers from various sections of the community including security researchers, academics,...

Application Security and Quantum Mechanics

by C. Warren Axelrod on May 17, 2011

in SBN

It’s funny how analogies pop up in the strangest of places. There is an “Annals of Science” article by Rivka Galchen in The New Yorker of May 2, 2011 about physicist David Deutsch with the title “Dream Machine: The mind-expanding world of quantum computing.” It describes the weird concepts of quantum mechanics. I actually took a course in quantum mechanics when I was an undergraduate electrical engineer, and I must admit that I was totally confused.

The Galchen article describes that “Deutsch questioned whether computational complexity was a fundamental or a relative property.” The analogy is described in terms of mass and weight, as follows:

“Mass … is a fundamental property because it remains the same in any setting; weight is a relative property, because an object’s weight depends on the strength of gravity acting on it. Identical baseballs on earth and on the moon have equivalent masses, but different weights.”

The author goes on to say:

“Just as an object’s weight depends on the force of gravity in which it’s measured, the degree of computational complexity depended upon the computer on which it was measured.”

While I am not pretending that my position on context as a major factor in application security is anywhere near as sophisticated as the mass-gravity-complexity arguments in the article, I must say that there is some measure of support for my views, and the views of some others, in the discussion.

An application has some intrinsic level of security based upon such factors as the stringency of the SDL (Security Development Lifecycle), the enforcement of SDL rules, the language in which an application is written, the platform on which it runs, and the like. These might be considered the fundamental properties of applications.