Can anyone shed some light on why DotNetNuke comes configured with request validation and event validation disabled? They’re both off at the web.config level for a default install which seems to be a regressive approach. Are there any sound reasons for this and what is the functional impact on DotNetNuke if they’re turned back on?
Obviously appropriate input validation should be happening in code anyway but the native .NET framework behaviour is always a nice fallback.
Update: further thoughts on this in Request Validation, DotNetNuke and design utopia
It turns out the folks at DotNetNuke have disabled this in order to facilitate submission of HTML content through rich text controls. Turning off both request and event validation are by design.
I would have preferred to see this done at the page level where required. Global validation in no way absolves the developer from validating input at each point where it’s captured but I still maintain having this feature is good insurance and disabling it does create a risk. I’d be very interested to see how many DNN sites out there have XSS vulnerabilities as a result of no global validation combined with poor development practice.
Global validation of all input is a bad practice. Like most applications DotNetNuke works on a by function by function basis for input validation.
The creation of a vulnerable code is highly dependent on how the user input is being used. For instance SQL Injection and XSS both rely on very different control characters. SQL injection can be caused by not filtering one of three characters '"\, where as most XSS is caused by not filtering <>. SQL Injection can also be caused by not using control characters, for instance this code is vulnerable to SQL Injection because it doesn't have have quote marks around id:
SqlCommand("SELECT username FROM users where id="+id)
Global input validation such as magic_quotes_gpc under PHP will also fail to prevent this type of attack, and that is one of the reasons why its being removed in PHP6.
Related
We have existing ASP.Net Application 3.5. We have done Security Audit and we found that we can have XSS attack with our application.
As we have existing application and more than 100 modules - can we have easy way where with some configuration (minimal effort rather than going to every page and encode output).
We also have few pages where we need to allow even HTML Editor as well.
Please suggest me the easy and quick way to resolve this.
As we have existing application and more than 100 modules - can we have easy way where with some configuration (minimal effort rather than going to every page and encode output).
There are hacks, like the built-in ASP.NET “Request Validation”, or the “Security Runtime Engine” in MS Anti-XSS, which attempt to filter out what it thinks might be an attack on the way into your application.
These are generally a very poor solution in the long term, because they can't address all possible attacks and they'll break some input that isn't an attack. But this might be a useful temporary workaround measure until you can fix the app properly to escape everywhere it puts strings into a containing context, and set suitable development standards and controls to stop more context-naïve templating getting into the codebase.
We also have few pages where we need to allow even HTML Editor as well.
You will need an HTML sanitiser library to filter out all but acceptable whitelisted tags/attributes. Here is one.
We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.
I have recently been investigating methods of creating web-based forms for an ASP.NET web application that can be edited and managed at runtime. For example an administrator might wish to add a new validation rule or a new set of fields.
The holy grail would provide a means of specifying a form along with (potentially very complex) arbitrary validation rules, and allocation of data sources for each field. The specification would then be used to update the deployed form in the web application which would then validate submissions both on the client side and on the server side.
My investigations led me to Xforms and a number of technologies that support it. One solution appears to be IBM Lotus Forms, but this requires a very large investment in terms of infrastructure, which makes it infeasible, although the forms designer may be useful as a stand-alone tool for creating the forms. I have also discounted browser plug-ins as the form must be publicly visible and cross-browser compliant.
I have noticed that there are numerous javascript libraries that provide client side implementations given an Xforms schema. These would provide a partial solution but server side validation is still a requirement.
Another option seems to involve the use of server side solutions such as the Java application Orbeon. Orbeon provides a tool for specifying the forms (although not as rich as Lotus Forms Designer), but the most interesting point is that it can translate an XForms schema into an XHTML form complete with validation. The fact that it is written in Java is not a big problem if it is possible to integrate with the existing ASP.NET application.
So my question is whether anyone has done this before. It sounds like a problem that should have been solved but is inherently very complex. It seems possible to use an off-the-shelf tool to design the form and export it to an Xforms schema and xhtml form, and it seems possible to take that xforms schema and form and publish it using a client side library. What seems to be difficult is providing a means of validating the form submission on the server side and integrating the process nicely with .NET (although it seems the .NET community doesn't involve themselves with XForms; please correct me if I'm wrong on this count).
I would be more than happy if a product provided something simple like a web service that could validate a submission against a schema. Maybe Orbeon does this but I'd be grateful if somebody in the know could point me in the right direction before I research it further.
Many thanks.
I'm probably missing something but...
The way I've done this sort of thing in the pass is to create a schema for form declaration & an xslt to convert that xml to html. You can then add all sorts of validation, based on the xml schema you've designed. What I am usually missing is the form designer though.
You can use XHTML for the forms, or like Simon suggested, a custom language as an abstraction layer. The application can load the form at runtime, transform/style it and serve it to the user. You can edit the form and make changes without the need to recompile/redeploy.
For validation you can use Schematron, this can also be easily edited at runtime using XML-aware tools.
You can use Javascript to produce XML data in the browser, or you can transform application/x-www-form-urlencoded to XML on the server (that is what I do on this page).
Is there any comparison to show why JSP/ASP.Net is better from security point of view? As I think, security depends on the server security, and website architecture and implementation, and only a name like JSP/ASP.Net will not guarantee your website and will not make hackers to run away!!
Is there any study or article to show bugs or security issues in the framework itself?
Both are just view technologies. Both are as secure as you can program it to be. Both does not automagically take care about security risks like XSS, CSRF, SQL injections, etcetera. It's the developer who's responsible for that, regardless of the view technology in question.
MVC frameworks on the other hand (like JSF which runs on top of JSP and ASP.NET MVC which runs on top of ASP.NET), by default already prevents XSS (if you code the view the right way, i.e. display user-controlled input using a component), but you still have to take CSRF and SQL injection risks into account yourself. The former is usually to be done using either a request based token or a captcha and the latter is usually to be done by prepared statements / named queries (for which a decent ORM framework would already take the work from hands).
Is the source code for the common login controls available?
Those are the controls which are available under Login section in Toolbox:
Login,
LoginView,
PasswordRecovery,
LoginStatus,
LoginName,
CreateUserWizard,
ChangePassword
Eventually could you point me to a good source of custom implementation of functionality that those controls provide, or some guidance on implementing this functionality without using the mentioned controls.
I am using Visual Studio 2005 (.net2)
I will be using SQLMembershipProvider as the MembershipProvider but that probably should make no difference.
"the entire framework is available" is not true. :)
The source code for the entire framework is available. The link below provides some details as to how to access:
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
I am going to give this a qualified "NO".
I have gone down the road of implementing an implementation of the Login server control using reflected source as a starting point (this was before symbol server integration).
Things seem to go swimmingly, with a few reflection hacks to get to core framework members that obviate reams of code.
Until you get to the designers. That infrastructure is a minefield and gets wide and deep with a quickness and is filled with even deeper buried internal types that need implementations or reflection hacks.
Ultimately wound up with a working control that I could extend but would never want to maintain.
The effort was not wasted; I learned a lot about how over engineered server controls are designed.
And then I just shifted a login control to template mode and got everything I needed to get done in a few lines of code. ;-)
Except as a learning experience I would certainly recommend against going down that road.
Good luck.