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).
Related
I am building a a web app with Spring MVC and hibernate. I am struggling with scope. E.g., create parent and children on same interface requires resetting child bean after first child created. Spring MVC does not allow removal of bean from session scope. At the same time, shifting children across multiple request scopes is not practical. I need a conversation scope.
I am now looking at Spring Web Flow as a solution. However, it is poorly documented and seems to depend entirely on xml configuration. Both these features seem to suggest it is an older and perhaps not well supported project.
Can anyone advise on whether I should invest time learning Spring Web Flow, or perhaps suggest alternative solutions that tie into Spring MVC.
I've spent some time on this now.
I think the reason for xml as opposed to annotation is design. Once one has one's head around it, the flow config is simple and leads to very fast development.
Yes, it seems to be in maintenance mode, but the design is solid and reliable and development seems to be very efficient. Learning curve is a little steep, especially if integrating into an extant webapp, but I was up and running in about three days.
Webflow's own documentation is not great, but the tutorial linked here is excellent.
UPDATE
5 months on and I have built a complete assessment system (i.e test/exam system). My background is in IT and I have a Ph.d in psychology.
The system I built has been thoroughly tested and stress tested.
Advantages of webflow.
A person can start a test, give up and restart in the same session with no problems since flowState takes care of everything
There is full control of when the user can use the back button and how far back the user can go. Returning to state after an illegitimate backbutton usage is easy and user friendly.
Stress test performance is excellent
Configuration is easy. I spent almost no time dealing with design or bug issues related to Webflow.
FRom a higher level design perspective, there were no use cases that were required from a business perspective that could not be implemented.
Disadvantages
Since all objects are serialized before presentation on the webpage, you have to be very careful about how you cache objects if you take them out of the flowState beans.
Spring Web Flow appears to be maintained, but not in active development. I see a handful of commits, mostly updating dependency versions and fixing bugs.
You are correct that the configuration of the flow is XML-only, which I believe is the single biggest drawback of this aging Spring project. I have searched for a DSL or dynamic builders and I did not find anything.
Having said that, I'd give it a shot. Simple flows—even dynamic and inherited flows—are possible. In addition, the backing form and the POST-Redirect-GET Pattern implementations may be useful to you. That last technique prevents form resubmission when you use the browser back button.
I have been looking at webflow myself (for the past day, ~16 hours) since after I seen "primefaces".
Webflow offers varying types of states and transitions to those states. States can have a view associated with it (HTML page or JSP page -> primefaces comes in here). Each JSP pages are templates, like PHP just using java and xhtml. Using primefaces components the interaction between the client and server "seems" almost automated (a plus for quick development). Webflow also offers flow variables, which is a java data object. The flow variable can have the life over the flow and is used by views and templates. Webflow allows you to control transitions between all states.
However, I think this is where I stop my research. First, what is the advantage of webflow over a good client side web application using AngularJS with Spring MVC (#RequestMapping), if flow control is needed build it on the client. If you would like a variable that exists over the lifetime of the session, make a javascript variable, however if the variable needs to only exist on the server and you would like to use templates, then webflow seems like a ideal choice.
If you need a state-ful webapp then it might be a good idea to checkout Spring HATEOAS type concept (passing the state as a parameter to the client), and that parameter refers to limited time availability variables. Less coding and seems to conform to internet model better.
I am new to .NET and ideally want to make several layers of abstraction for making a fairly complex website. Being the first layer handling login, authentication, etc, with another layer handling the built in apps (how they look, predefined functions, database connections), and the lower level will be specific app implementation details.
This favors uniformity as all apps will inherit from one place allowing for easier maintenance and rapid development of all the smaller apps once the overhead abstraction layers handle their responsibilities.
The only problem is I am not 100% sure where to start with .NET ASP webpage inheritance. I tried Google and searching but I may not be looking for the right thing. I am hoping with someone with experience on the matter may direct me towards resources to make this kind of webpage inheritance/abstraction easier!
I am using Visual Studio 2010.
Edit:
I also want to add the purpose to my question: Another individual is creating the base of the website which will handle authentication, portal, UI look, etc
I want to make an app base that uses their website framework and adds onto it standards that every app must meet, function library, any addition UI overrides not applicable from portal, etc.
From there a third layer that will directly inherit from the above app base framework (abstraction) and further specify based on the guide lines made.
I appreciate the feedback so far!
In ASP.NET you have 4 common ways to reuse code/abstractions to serve you application-wide
The first way is just using a base page, which will inherit the standard asp.net Page and share the common logic for all of your pages, as explained here
The second way is using a master page: a master page defines a common design (html / css - wise) for all the pages that use it throughout the application. It can also be accessed programmatically by pages that use it, and therefore share a common logic
The third way is using an http module: An http module is basically a class, which is responsible for handling an HTTP request before its handled by the expected pages code on the server, and it allows you to add any common logic you want your application to use (such as authentication / authorization handling, getting relevant user information from the DB, etc)
Global.asax: contains application/session wide event handlers, which allow you to handle those events in once place (everything from application starting to a user session ending)
Using modules and base page is the preferred way, if you want to build few applications, sharing common behaviour. A master page can be used as well, of course, if you want them to share the same design as well.
That's quite a broad question. Welcome to ASP.NET!
I would suggest researching these topics:
Web page inheritance -> Master Pages,
Skinning -> App_Themes,
separation of responsibilities -> MVP design
pattern for the Web Forms platform, or MVC if you have a choice.
Login, roles -> Membership
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
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).
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.