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.

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)

Watcher: Spotting dubious webishness

November's toolsmith features Watcher, a great passive security auditor from Chris Weber of Casaba Security, that detects web application security issues as well as operational configuration concerns. Watcher plugs neatly into Fiddler, an indispensable proxy that should be an inherent part of your web application assessment tool kit.
The toolsmith article covers using Watcher to detect "dubious" comments, unset HTTPOnly flags, open redirects, and bad cross domain flash policy, so I won't repeat myself here.
Watcher is also excellent for detecting likely XSS vulnerabilities, and will passively detect prospective parameters while you browse.
As an example, a visit to a site that shall remain anonymous only to those without fundamental Google skills results in Figure 1, seen by Watcher as it passively reviews a site with 37 different checks.


Figure 1

Note that Watcher spots what it declares is a potentially high severity user controllable HTML element attribute. Watcher further indicates that the fourth input tag value attribute is specific to the keyword variable. A quick "active" test by the author quickly validates Watcher's assumptions as seen in Figure 2.


Figure 2

Passive security auditing indeed; no effort required!
Results are easily exported as well.
Browse a client site while enjoying a good sandwich and coffee, dump the results, and build your work list as a preliminary recon step for your next penetration testing engagement.
Enjoy this excellent tool; use it in good stead.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Desktopsmiley: Annoying and insecure

Adware giant desktopsmiley.com annoys me in ways I can't repeat here (to protect the innocent and moral among you), so I'll keep this simple.

Some facts:
1) desktopsmiley.com is ranked 287 in the world according to Alexa.
This is simply stupefying to me, and testament to the fact that there are way too many oblivious people installing this crapware.
2) The geniuses at Desktopsmiley.com have wrestled long and hard with the antiviruse vendors such that their latest installer doesn't trip a single signature per Virustotal. Further ground for to be much annoyed...and perhaps impressed at their obvious negotiation skills.
3) Desktopsmiley.com has a privacy policy. Rejoice! Now we can all install it and know our data and our privacy is protected. Or not. Just read this dreck and you'll shudder at the clearly defined consequences of installing this "not spyware".

I am therefore inclined to point out that this spectacular product offering cares little for your privacy or your security.

Case in point 2x:
That privacy page? Not so private. It's vulnerable to XSS, and I'm sure this isn't the only example.
Explore for yourself: http://tinyurl.com/qv9zkw

Screen shot, if you prefer.



The next one is particularly fun as it is clearly indicative of bad Flash coding practices. The clickTag variable is wide open on smiley.swf.
Follow this URL, then click the super happy swf! Hurray!

http://download2.desktopsmiley.com/landing/images/tm106/smiley.swf?clickTag=http://cwe.mitre.org/data/definitions/601.html

Can you say arbitrary redirect? I knew you could, boys and girls.

I hereby declare the creation of a new Holisticinfosec award for just such occasions, the ID Ten C Award.
Don't get it? Spell it out and say it with me: ID 10 C...you should be able to handle it from there.
Desktopsmiley.com, consider yourselves awarded, for being both annoying and insecure.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Open Redirects and Common Weakness Enumeration

Hopefully, you're more than familiar with CVE (Common Vulnerabilities and Exposures), but perhaps you're less familiar with CWE (Common Weaknesses Enumeration). Both are significant efforts, international in scope, and the excellent products of The MITRE Corporation, sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.
Approximately six months ago I was discussing open redirect vulnerabilities with Steven Christey of MITRE, who mentioned that that CWE entry for open redirects was sparse and dated, with little reference material. In particular, he pointed out the lack of defining papers. I accepted this information as a challenge and produced an article that was published in (IN)SECURE Issue 17. Soon after Issue 17 went live, I also took note of an excellent academic paper specific to the topic of open redirect vulnerabilities; Shue, Kalafut and Gupta's Exploitable Redirects on the Web: Identification, Prevalence, and Defense. Complete with these two papers as references, as well as two current CVE identifiers for popular web applications suffering from open redirect vulnerabilities (discovered by yours truly), CVE-2008-2052 & 2951, CWE-601: URL Redirection to Untrusted Site (aka 'Open Redirect') is now current and complete.
As open redirects are undoubtedly one of my biggest pet peeves, I am pleased to no end. Hopefully CWE-601 will help drive more application vendors and site operators to put an end to this easily mitigated vulnerability.

CWE:
"International in scope and free for public use, CWE™ provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design."

del.icio.us | digg | Submit to Slashdot

XSF & XSS: Double your pleasure, double your fun

If you've read this blog, or those of my peers, you're likely quite familiar with cross-site scripting, and the problems associated with open redirect vulnerabilities. A vulnerability you may be less familiar with is cross-site framing, which largely couples the best of both above-mentioned vulnerabilities.
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624

Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80

Now here the same job posting spewing massive cookie data:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3

Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.



It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778

Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html



What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/



Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?

It hurts twice as much, in my book.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3



The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)

Double the headache, double the dumb.

del.icio.us | digg

Open redirect vulnerabilities article - (IN)SECURE Issue 17

I've written a comprehensive piece on the dangers of open redirects that's been published in Issue 17 of (IN)SECURE Magazine. Page 43 for your reading pleasure.
"An open redirect is a vulnerability that exists when a script allows redirection to an external site by directly calling a specific URL in an unfiltered, unmanaged fashion, which could be used to redirect victims to unintended, malicious web sites."
This issue is a giant pet peeve of mine; the article is intended to increase awareness of the dangers of this vulnerability and promote mitigation.

del.icio.us | digg