Critical security issues found in the Spring Framework

Discussions

News: Critical security issues found in the Spring Framework

  1. Ounce Labs recently discovered two vulnerabilities that can affect Java Web applications that use the Spring Framework. The company is working with SpringSource to ensure developers know how to protect against these security issues. You can find more information on our sister site, SearchSoftwareQuality.com, at http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1321417,00.html

    Threaded Messages (87)

  2. Okay so the way I see these issues: Issue 1: If you've got a Model object with more fields than a HTML form you have setup then if you fake a request you can populate the object with 'extra' data. Okay could be a problem if you've got some internal fields you never ever want a form to populate. That said if you're really worried about this have your real domain objects in the background taking your Model objects as constructor parameters; not the nicest of solutions but solves the problem :) Issue 2: Using a hidden field in a form to set what template to use to render a controller's response. Oh come on surely that's not in 'Spring'; that's just an implementation issue (and by implementation I mean that probably the lookup name should be hardcoded into the controller).
  3. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc... Issue 2: If I leave my door wide-open, and someone robs my TV, is it a security issue? Or am I stupid? (No comments from the peanut gallery)
  4. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc...

    Issue 2: If I leave my door wide-open, and someone robs my TV, is it a security issue? Or am I stupid? (No comments from the peanut gallery)
    We encountered this with WebWork / Struts 2 a few years back. Several of us like to use our domain objects in the view, and things like the object's Id were available to be set. I solved this personally by putting an interceptor in there that created a proxy that only had methods from the interfaces implemented by the returned object, then I left off setters for sensitive fields from my interfaces. Since then they've added a nice feature to a lot of the interceptors that deal with parameters that let you filter out some param names (either inclusive or exclusive). So the answer is yes, it's been seen before and dealt with before.
  5. I solved this personally by putting an interceptor in there that created a proxy that only had methods from the interfaces implemented by the returned object, then I left off setters for sensitive fields from my interfaces.
    +1 Another option would be to implement domain objects with just those setters and getters needed for the business, and then introduce via AOP additional interfaces exposing those setters and getters needed by the web forms: there is a sub-project into Spring Modules which does exactly this. Cheers, Sergio B.
  6. I solved this personally by putting an interceptor in there that created a proxy that only had methods from the interfaces implemented by the returned object, then I left off setters for sensitive fields from my interfaces.


    +1

    Another option would be to implement domain objects with just those setters and getters needed for the business, and then introduce via AOP additional interfaces exposing those setters and getters needed by the web forms: there is a sub-project into Spring Modules which does exactly this.

    Cheers,

    Sergio B.
    As mentioned already, using DTOs instead of exposing domain objects solves this problem by forcing the development to manually transfer submitted values, and for my 2c is the best approach anyway. Pusing domain objects to the UI quickly leaves you with a ball of string. Only the most simple and naive apps can expect to have a 1:1 relationship between form fields and domain objects. Using a DTO approach means that: - You can inspect the DTO to see exactly what data the UI requires, excepting any AJAX calls. - You can write tests against code which populates a page. - You can keep your service layer clean, where its clearer to pass a command object (as per the GOF definition). Using something like Spring Webflow goes one step better by providing additional scopes to help further clean up form backing objects, that is, any application state required *only* to drive the UI can typically be stored in flow scope and the DTO/form backing object can be passed to the service layer without feeling too 'dirty' about it. That is, the DTO typically only contain data required to support the use-case. So, writing an app 'properly' (with DTOs), in such a way that there's clear separation of layers isn't going to get you into trouble in the first place with this security issue. You'll also typically get further payback if you need to do integration with other systems, where message handlers and pages both need to call the same business logic.
  7. So, writing an app 'properly' (with DTOs), in such a way that there's clear separation of layers isn't going to get you into trouble in the first place with this security issue.
    If one has to use DTO's to do this (the DTO anti-pattern), then one should probably choose a better framework.
  8. So, writing an app 'properly' (with DTOs), in such a way that there's clear separation of layers isn't going to get you into trouble in the first place with this security issue.

    If one has to use DTO's to do this (the DTO anti-pattern), then one should probably choose a better framework.
    DTO's have nothing to do with framework choice, its an approach. Sure, DTO's seems like an anti-pattern compared to nice easy binding to domain objects until an app reaches a certain size/complexity. After that, it becomes difficult to determine what fields are being posted back to a page or pages without opening up all the JSF/JSP/FreeMarker/whatever pages. I'm going to agree with you that for simple apps its probably workable to just bind directly to a domain object. Beyond that, NOT using DTOs typically equals spaghetti code, with no clear demarcation between UI and services. Building a DTO Java class purely to support the use-case is extra overhead on one side -- no argument there, but you more than pick benefits in the maintainability department on the other side, and you would also avoid this security error.
  9. Sure, DTO's seems like an anti-pattern compared to nice easy binding to domain objects until an app reaches a certain size/complexity. After that, it becomes difficult to determine what fields are being posted back to a page or pages without opening up all the JSF/JSP/FreeMarker/whatever pages.
    I thought you said:
    DTO's have nothing to do with framework choice, its an approach.
    If you choose something like RAP or Echo then you don't have this issue and there is no need for DTO's.
    Beyond that, NOT using DTOs typically equals spaghetti code, with no clear demarcation between UI and services.
    LOL. Ok, if you say so. I've done large Strut apps with DTO's. Major spaghetti.
  10. If you choose something like RAP or Echo then you don't have this issue and there is no need for DTO's
    Like I said, DTOs are just an approach and not related specifically to a framework. Put another way, using DTOs just recognises that data representations/models used by the UI are different than the service representation, but also: - solve this security problem, and - provides a nice way to store the data required for a unit of work, whether that's doing a search, or creating an invoice, or whatever. - make it easier to extend an app when messaging needs to call services that were previously only being called directly via the UI. I'm not quite sure where you're heading with 'LOL', 'RAP', and 'Echo'. All very good points I'm sure.
  11. 'RAP', and 'Echo'. All very good points I'm sure.
    I can directly bind to objects and easily find where they are used by doing "Find all references" in Eclipse. And no security issues.
    make it easier to extend an app when messaging needs to call services that were previously only being called directly via the UI
    We are doing this already with domain objects. Works great. I use them to to bulk loading, remote services and ESB/Messaging.
    provides a nice way to store the data required for a unit of work
    Well, if this is what you mean by DTO, then I would agree with you. This is not the standard definition of DTO though (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html). It is more along the lines of what Hibernate calls projections. I do use these, but I am very careful to use them for read-only things like search results or reports.
  12. We are doing this already with domain objects. Works great. I use them to to bulk loading, remote services and ESB/Messaging.
    We've already gone a fair way off topic for this thread, but I'd be interested to understand how you prevent the project from turning into spaghetti binding directly to domain objects. The DTO/UnitOfWork approach means that there are typically less objects floating about the UI layer than need to be there, since the UI gets supplied with a DTO only, not a whole bunch of domain objects from which it can pick and choose properties to display. I used to lean towards accessing domain objects directly, and have done half a dozen or so projects that way. After v2, v3, of the project, and after its been modified several times, the 'bind directly to domain objects' approach starts going pear shaped. The DTO/UnitOfWork approach seems to survive maintenance better, since it is clearer what data is required to support the use-case at the UI layer and service layer. Frameworks supporting conversation scopes, e.g. Spring Webflow for one, take it a step further by letting you store state required to drive the GUI someplace other than your DTO.
  13. We've already gone a fair way off topic for this thread,
    Yeah, I know but others can ignore this. :)
    but I'd be interested to understand how you prevent the project from turning into spaghetti binding directly to domain objects.
    I don't know. It just works. I am not sure how you don't have the same problem with DTO's. I have done plenty of projects in multiple "OO" languages (Java/VB/VB.Net/C#). And using domain objects just works. Maybe I have not done enough Struts style apps for it to be a pain.
    The DTO/UnitOfWork approach means that there are typically less objects floating about the UI layer than need to be there, since the UI gets supplied with a DTO only, not a whole bunch of domain objects from which it can pick and choose properties to display.
    First, I don't see that it really means that many more objects and attributes (IDE's are great for this) and second, you are just moving the pain somewhere else you when you have to match the DTO's back up to domain objects and try to determine what state the DTOs are since they only contain attributes.
  14. ...you are just moving the pain somewhere else you when you have to match the DTO's back up to domain objects and try to determine what state the DTOs are since they only contain attributes.
    I am not so sure of this. Using a command pattern it is natural to map the command parameters to something different from the target domain object(s). In fact, a web form might contain data for a moltitude of objects and the business logic (the use case) that controls how the global update takes place must be put somewhere. Guido
  15. So, writing an app 'properly' (with DTOs), in such a way that there's clear separation of layers isn't going to get you into trouble in the first place with this security issue.

    If one has to use DTO's to do this (the DTO anti-pattern), then one should probably choose a better framework.


    DTO's have nothing to do with framework choice, its an approach.

    Sure, DTO's seems like an anti-pattern compared to nice easy binding to domain objects until an app reaches a certain size/complexity. After that, it becomes difficult to determine what fields are being posted back to a page or pages without opening up all the JSF/JSP/FreeMarker/whatever pages.

    I'm going to agree with you that for simple apps its probably workable to just bind directly to a domain object.
    Small applications have the bad habit of becoming large applications before you realize it.
    Beyond that, NOT using DTOs typically equals spaghetti code, with no clear demarcation between UI and services.

    Building a DTO Java class purely to support the use-case is extra overhead on one side -- no argument there, but you more than pick benefits in the maintainability department on the other side, and you would also avoid this security error.
    Totally agree. Even if you use "command pattern" (GoF) instead of "DTO" in your posts it sounds more sexy and less prone to remarks. Guido
  16. Even if you use "command pattern" (GoF) instead of "DTO" in your posts it sounds more sexy and less prone to remarks.

    Guido
    I'd agree with that.
  17. A command object encapsulates an action and its parameters a DTO only encapsulates parameters. Something entirely different
  18. A command object encapsulates an action and its parameters a DTO only encapsulates parameters. Something entirely different
    Well, the sense of the referred post, or at least the one I 've got, was to use a command pattern with a DTO -not a domain object- to hold the content of the form. That's why I suggested to emphasize the command part ;-) Guido
  19. A command object encapsulates an action and its parameters a DTO only encapsulates parameters. Something entirely different

    Well, the sense of the referred post, or at least the one I 've got, was to use a command pattern with a DTO -not a domain object- to hold the content of the form.
    That's why I suggested to emphasize the command part ;-)

    Guido
    Yep, DTOs only make sense to me in the GOF Command style usage, or Unit of Work Usage. I don't think creating a 1:1 mirror image of your domain objects as DTOs delivers any benefits. The Command or Unit of Work approach to building DTOs sort of acknowledges that there is a mismatch between fields shown on a page, and the datamodel, and that you don't want to expose the datamodel to the UI for a multitude of reasons.
  20. A command object encapsulates an action and its parameters a DTO only encapsulates parameters. Something entirely different

    Well, the sense of the referred post, or at least the one I 've got, was to use a command pattern with a DTO -not a domain object- to hold the content of the form.
    That's why I suggested to emphasize the command part ;-)

    Guido


    Yep, DTOs only make sense to me in the GOF Command style usage, or Unit of Work Usage.

    I don't think creating a 1:1 mirror image of your domain objects as DTOs delivers any benefits.

    The Command or Unit of Work approach to building DTOs sort of acknowledges that there is a mismatch between fields shown on a page, and the datamodel, and that you don't want to expose the datamodel to the UI for a multitude of reasons.
    I understand your point and probably do do that on occasion. But I seldom update small parts of many domain entities. Your use of the term DTO is not "standard". A 1:1 for domain objects is. Like I mentioned before, it is more of a "projection".
  21. Hey Jason, Slightly offtopic but based on your post I searched for the interceptor based solution in Struts2. The only thing i found resembling what you speak about seems to be the excludeParams attribute on ParametersInterceptor however it seems to me that that attribute would be very hard to use for security purposes because the parameter names are actually evaluated as ognl expressions an expression like isAdmin would filter out "isAdmin" but not "(isAdmin)" for instance is there some other solution i am missing
  22. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc...
    JSF is definitely not vulnerable. JSF uses components, and if there is no component defined for the field there is no way data other than the one that is destined to be updated will be updated. Unless you use client side state saving with unencrypted state.
  23. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc...

    JSF is definitely not vulnerable. JSF uses components, and if there is no component defined for the field there is no way data other than the one that is destined to be updated will be updated. Unless you use client side state saving with unencrypted state.
    JSF is also vulnerable.. even when it uses server side state save.
  24. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc...

    JSF is definitely not vulnerable. JSF uses components, and if there is no component defined for the field there is no way data other than the one that is destined to be updated will be updated. Unless you use client side state saving with unencrypted state.


    JSF is also vulnerable.. even when it uses server side state save.
    Oh, and why? Explain please and give an example of such vulnerability in JSF (if you can).
  25. Issue 1: Are other frameworks affected by this? JSF, SEAM, etc...
    Both Seam and Spring Faces are not affected by this kind of vunerability. Reason: In JSF the update of model objects happens during the JSF "Update Model" phase. Only those properties of a model object are updated (with converted and validated user data!) for which there is an explicit Expression Language binding.
  26. Issue 1[ Go to top ]

    You can also explicitly tell your controller which fields to bind. e.g. @Override protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) throws Exception { binder.setAllowedFields(new String[] {"firstName", "lastName"}); binder.setRequiredFields(new String[] {"firstName", "lastName"}); }
  27. As Ounce noted in their report, and Andy also pointed out here, both of these issues pertain to web application developer's use of the Web MVC module of the Spring Framework (and are not the result of bugs or design flaws in the Spring Framework itself). We at SpringSource have posted a FAQ describing the two issues and how to determine if they could present a problem in your application: http://www.springsource.com/securityadvisory Keith Donald SpringSource Principal
  28. I spend a lot of time working with Spring both professionally and informally. I am one of the main contributors in the Spring Web forum at forum.springframework.org. From spending a lot of time on that forum helping users, I can tell you that this is a *very* common question and point of confusion. And while the argument of "it's available in the framework" is _true_, the Spring team has done a very poor job of advertising that this feature exists and should be used as a way to secure outward-facing web applications based on Spring MVC. A quick grep through the Spring 2.5.4 distribution illustrated the following: - setAllowedFields is used exactly once in all sample applications that ship with Spring. - setRequiredFields is used exactly 0 times. - setAllowedFields is mentioned exactly 0 times in the written (not API) documentation that ships with Spring. - setRequiredFields is also mentioned 0 times in the documentation. Obviously I have been very involved in the Spring community and know that there are a bunch of good-hearted folks behind it. Regardless of its technical merit or objective accuracy, I hope that this serves as a big heads-up to the Spring Web team that security is something that they should take very seriously, both in their shipping products, and in the ongoing Spring 3.0 and Spring Web Flow work. Peter Mularien System Architect, Edgewater Technology, Inc. http://www.mularien.com/blog/
  29. Oh, please[ Go to top ]

    Seriously, these so called "Critical security issues" wasn't that impressive. A more appropriate description would be "Careless use of MVC_FRAMEWORK_OF_CHOICE may result in unintended security problems". Follow the simple advice a) Don't let the web client choose view freely and b) Don't blindly map fields recieved from a form into your object model. and you are should be safe from the problems described. I would say that those pieces of advice are at the level of "don't use abc123, letmein or password for password" or "Don't put a Windows XP box on the internet without security updates or firewall protection".
  30. Re: Oh, please[ Go to top ]

    Seriously, these so called "Critical security issues" wasn't that impressive. A more appropriate description would be "Careless use of MVC_FRAMEWORK_OF_CHOICE may result in unintended security problems".
    +1 Considering the amount of code these guys put out, and considering how long they've been doing it, 2 "critical" issues is an impressively low number. Tom
  31. Considering the amount of code these guys put out, and considering how long they've been doing it, 2 "critical" issues is an impressively low number
    As others pointed out and as you can read in our security advisory (http://www.springsource.com/securityadvisory), the issues are not directly related to the quality of code we put out. The fundamental issue here is that developers shouldn't build applications that blindly use data from clients that shouldn't be trusted. The framework being used is not in charge, you are. The framework cannot prevent a developer from doing a password comparison on the client for example, but we will discourage it if you do (for the record I don't think anyone here needed this advice). Ounce does a good job pointing out exactly how developers can introduce a vulnerability and our advisory describes the tools you have to close the gap. The title here may be misleading, the mechanisms described in the linked article are very real and developers should be aware of them when they build applications that need to be secure. That last bit is crucial, the developer has to decide if the application needs to be secure and act accordingly. The defaults and the implementation of the tools are open for discussion as always.
  32. OWASP A4 and A5 in Spring MVC[ Go to top ]

    I agree with you when you say "the developer has to decide if the application needs to be secure ". For example, suppose that I need a secure web application (the usual case) and I need to be secure from two of most common web vulnerabilities such as OWASP A4 and A5 (the usual case). As far as I know as many other web frameworks Spring MVC is vulnerable to these two vulnerabilities and don't offer any solution for that (of course devolopers can implement them by hand). Do you really think Spring MVC doesn't have any responsability to solve these kind of problems? I don't think so. Maybe I'm wrong but there are more people as Struts 1 developers that are worried about these security real problems and as you can see here they are trying to solve them. Other web frameworks such as JSF, .NET or Wicket are already solving some of the security problems related with A4 vulnerability. Please I would like to know the proposal of Spring MVC team to solve A4 and A5 vulnerabilities in Spring MVC web applications.
  33. Re: Oh, please[ Go to top ]

    Seriously, these so called "Critical security issues" wasn't that impressive. A more appropriate description would be "Careless use of MVC_FRAMEWORK_OF_CHOICE may result in unintended security problems".

    Follow the simple advice
    a) Don't let the web client choose view freely
    and
    b) Don't blindly map fields recieved from a form into your object model.
    and you are should be safe from the problems described.

    I would say that those pieces of advice are at the level of "don't use abc123, letmein or password for password" or "Don't put a Windows XP box on the internet without security updates or firewall protection".
    +1 Application developers need to stop being so damn lazy and actually think for once instead of relying on a framework to do every freaking thing for them. Use some common sense, people!!!
  34. Marketing trick[ Go to top ]

    I agree completely with Andy Y. Just another company that wants to ride on the wave that Spring created. - They hope to work with SpringSource on the next release of Spring. Sure they do! But come on, when you can actually do it the right way without changing a letter of code, I don' see how it's a real critical issue. It's like saying Java is insecure because not all J2EE applications are hack-proof. - A happy Spring user.
  35. is it joke of the month ? is it a good advertising for the silly peiople who came up with this report ? if this is the quality of their report they really lost a lot of us as their future customer. bad coding should not be called out as spring secutrity issues. Anyone who is a decent programmer should know about common hacks like buffer overflow, cross site scripting, sql injection etc.
  36. Something like "pathetic attempt at security paper fools new TSS editor" would do the trick
  37. Something like "pathetic attempt at security paper fools new TSS editor" would do the trick
    I second that proposal. :)
  38. +1
  39. The SpringSource response states: "Both issues result from usage of the Web MVC module of the Spring Framework, and are not the result of bugs or design flaws in the framework." This claim is highly debatable (and that's putting it politely). One of the reasons for using a web framework is to ensure your application is secure. If a framework design allows for attacks, in any way, then, by definition, its design is flawed. A robust framework would make it impossible for a hacker to inject undesirable data. Period.
  40. The SpringSource response states:
    "Both issues result from usage of the Web MVC module of the Spring Framework, and are not the result of bugs or design flaws in the framework."

    This claim is highly debatable (and that's putting it politely). One of the reasons for using a web framework is to ensure your application is secure. If a framework design allows for attacks, in any way, then, by definition, its design is flawed. A robust framework would make it impossible for a hacker to inject undesirable data. Period.
    So .. if a user creates a website with sql injection vulnerability, who you blame? database server, java, spring mvc, html protocol, or the developer? ....
  41. I mostly blame the framework[ Go to top ]

    I mostly blame the framework. My point is that a good framework design should block as many attack vectors as it possibly can; a mediocre framework will not block them, and blame the application programmer for "not being smart enough".
  42. I mostly blame the framework. My point is that a good framework design should block as many attack vectors as it possibly can; a mediocre framework will not block them, and blame the application programmer for "not being smart enough".
    As already stated, the framework allows for both of these attacks to be avoided, and the option of preventing certain fields from being set is documented in the Spring-MVC docs. But because the framework gives you choices as to how to use it, a user is free to choose easier usage over security. I would be interested to see how you design a framework that allows a user to use any form-backing object and then magically determines which fields should not be mutable. Spring-MVC, like many web frameworks, let's you use any object as the model, and it's up to you to determine which fields can be populated. The framework should provide a mechanism to do this - which Spring-MVC does - but it can't force you to use it. So I don't think your logic applies here - the programmer has to be held responsible for the choice of easier usage over ignoring a security hole.
  43. Why not?[ Go to top ]

    @Rob Rudin "The framework should provide a mechanism to do this - which Spring-MVC does - but it can't force you to use it." Why not?
  44. Re: Why not?[ Go to top ]

    @Rob Rudin

    "The framework should provide a mechanism to do this - which Spring-MVC does - but it can't force you to use it."

    Why not?
    If the framework gives you the option to use any object to back the form, and it gives you the option to disallow binding to specific fields on that object, then you have to choose which fields to disallow. The framework could force you to specify which fields can be bound, but that wouldn't be a very pleasant thing to deal with. If you disagree with the notion of the framework allowing you to use any object to back the form, then that's fair - but as other posters have stated, this is very common in web frameworks in all languages (I don't know about JSF, I'd be interested to see the details as to how binding is prevented unless the page has a specific input on it). To me, it boils down to the fact that dynamically mapping request parameters to n object is a very handy feature that saves a lot of tedious coding, but obviously it opens up a security hole if you have properties on that object that you don't want set. And again, it's the programmer's choice to use such an object. I think Spring-MVC strikes a pretty good balance - provide the feature, and provide an easy way to avoid security holes. If JSF can do even better, then that's good to know too.
  45. Re: Why not?[ Go to top ]

    @Rob Rudin

    "The framework should provide a mechanism to do this - which Spring-MVC does - but it can't force you to use it."

    Why not?


    If the framework gives you the option to use any object to back the form, and it gives you the option to disallow binding to specific fields on that object, then you have to choose which fields to disallow. The framework could force you to specify which fields can be bound, but that wouldn't be a very pleasant thing to deal with.
    The problem is stated as: "there's no default checking to make sure the users are only submitting fields that are visible in the form". 99.999% of the time (at least), the developer doesn't want the user submitting fields that are not visible on the form and ideally, preventing such actions should be the default behavior. Are you suggesting there is not way to implement such a check in Spring-MVC without extra developer effort? I agree that calling these issues critical may be a bit of a stretch but the argument that it's OK to default to insecure behaviors is ridiculous. If I used a tool to help me do queries against the database and it's default behavior was to allow SQL injection attacks, it's a flaw in that tool. Any argument that it isn't is just a rationalization.
  46. Re: Why not?[ Go to top ]

    Are you suggesting there is not way to implement such a check in Spring-MVC without extra developer effort?
    Amazingly, I am. And if you're implying that Spring-MVC "defaults to insecure behaviors" because it doesn't provide automated scanning of HTML responses and using that analysis to verify the subsequent incoming request (which is what HDIV appears to do, and maybe I've been living in a cave and just don't know of any web frameworks that do that out of the box), then I guess we just have very different standards for what's an acceptable web framework.
  47. Re: Why not?[ Go to top ]

    If I used a tool to help me do queries against the database and it's default behavior was to allow SQL injection attacks, it's a flaw in that tool. Any argument that it isn't is just a rationalization.
    So by that logic, the Spring JDBC template libraries are flawed. Why? Because query(String sql, RowMapper rowMapper), when used to create dynamic SQLs, "by default" allows SQL injection attacks. Come on, give me a break.
  48. Re: Why not?[ Go to top ]

    @Rob Rudin

    "The framework should provide a mechanism to do this - which Spring-MVC does - but it can't force you to use it."

    Why not?


    If the framework gives you the option to use any object to back the form, and it gives you the option to disallow binding to specific fields on that object, then you have to choose which fields to disallow. The framework could force you to specify which fields can be bound, but that wouldn't be a very pleasant thing to deal with.


    The problem is stated as: "there's no default checking to make sure the users are only submitting fields that are visible in the form". 99.999% of the time (at least), the developer doesn't want the user submitting fields that are not visible on the form and ideally, preventing such actions should be the default behavior. Are you suggesting there is not way to implement such a check in Spring-MVC without extra developer effort?

    I agree that calling these issues critical may be a bit of a stretch but the argument that it's OK to default to insecure behaviors is ridiculous. If I used a tool to help me do queries against the database and it's default behavior was to allow SQL injection attacks, it's a flaw in that tool. Any argument that it isn't is just a rationalization.
    A very simple use-case is to use a special form-backing object and use its collected data to populate a domain object. This form-backing object would only contains allowed fields anyways and no other (even the method in the Spring MVC Controller has that name: protected Object formBackingObject(HttpServletRequest request)!). The problem shows up when you start using your domain object as a form-backing object. In that case, you have to take care and limit the field access, as already suggested in the posts. There is really no need for complicated "synchronizations" and checking. The current solution is perfectly simple and good.
  49. Re: Why not?[ Go to top ]

    The problem shows up when you start using your domain object as a form-backing object. In that case, you have to take care and limit the field access, as already suggested in the posts. There is really no need for complicated "synchronizations" and checking. The current solution is perfectly simple and good.
    I'm not really interested in debunking any more "seat-belts aren't needed as long as you don't wreck your car" type arguments. It's boring. This kind of safety check shouldn't be difficult to implement. Other MVC frameworks implement this feature as pointed out in other posts. Stating that a work around exists confirms that there is an issue.
  50. Re: Why not?[ Go to top ]

    The problem shows up when you start using your domain object as a form-backing object. In that case, you have to take care and limit the field access, as already suggested in the posts. There is really no need for complicated "synchronizations" and checking. The current solution is perfectly simple and good.


    I'm not really interested in debunking any more "seat-belts aren't needed as long as you don't wreck your car" type arguments. It's boring.

    This kind of safety check shouldn't be difficult to implement. Other MVC frameworks implement this feature as pointed out in other posts. Stating that a work around exists confirms that there is an issue.
    Please at least read the corresponding Spring documentation before posting such incorrect statements: http://static.springframework.org/spring/docs/2.5.x/reference/mvc.html#mvc-features Customizable binding and validation - type mismatches as application-level validation errors that keep the offending value, localized date and number binding, etc instead of String-only form objects with manual parsing and conversion to business objects. Further docs: http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/validation/DataBinder.html#setDisallowedFields(java.lang.String[]) http://static.springframework.org/spring/docs/2.5.x/reference/mvc.html#mvc-ann-webdatabinder On short, and as stated from someone previously: there are legitimate, non-workaround ways to restrict bean properties to get bound without hacks and with properly placed control. If a developer is incapable to use it, it should be his fault. Spring provides the optimistic API for you: it allows to bind everything that is there by default, which is the common case, and you must specify the exception cases. It provides you less work than in the opposite: binding nothing and specifying the binding...
  51. Re: Why not?[ Go to top ]

    [In] short, and as stated from someone previously: there are legitimate, non-workaround ways to restrict bean properties to be bound without hacks and with properly placed control. If a developer is incapable [of] [using] it, it [is] his fault. Spring provides the optimistic API for you: it allows to bind everything that is there by default, which is the common case, and you must specify the exception cases. It provides you less work than in the opposite: binding nothing and specifying the binding...
    It's the common case to allow fields that are not on the form to be submitted? I find that hard to believe. This idea that the only way to resolve this is to force the developer to specify each binding explicitly is nonsense. All that is required is that submitted fields in the submission be checked against the visible field names in the form. Spring-MVC should do this by default and only be lenient when developers explicitly request it.
  52. Re: Why not?[ Go to top ]


    It's the common case to allow fields that are not on the form to be submitted? I find that hard to believe.

    This idea that the only way to resolve this is to force the developer to specify each binding explicitly is nonsense. All that is required is that submitted fields in the submission be checked against the visible field names in the form. Spring-MVC should do this by default and only be lenient when developers explicitly request it.
    Ok, you are right, if you follow the application state on the server. However if you don't use unique ids for each form, you will have 'security issue' when the user opens a new tab, browses there and then later returns to the previous... (furthermore if it not the tabs but to fake requests...) Or you have unique ids, storing each form for a specific time, consuming a _lot_ server resource if used by more users. I don't think that is the recommended way to build scalable applications. There are much more potential in stateless service providing, and yes, that cannot be achieved by the way you have described. Again: choice in technology, not security. If your developers are stupid, you go the restrictive way, but don't cry if your application does not scale as much...
  53. Re: Why not?[ Go to top ]


    It's the common case to allow fields that are not on the form to be submitted? I find that hard to believe.

    This idea that the only way to resolve this is to force the developer to specify each binding explicitly is nonsense. All that is required is that submitted fields in the submission be checked against the visible field names in the form. Spring-MVC should do this by default and only be lenient when developers explicitly request it.


    Ok, you are right, if you follow the application state on the server. However if you don't use unique ids for each form, you will have 'security issue' when the user opens a new tab, browses there and then later returns to the previous... (furthermore if it not the tabs but to fake requests...)

    Or you have unique ids, storing each form for a specific time, consuming a _lot_ server resource if used by more users.

    I don't think that is the recommended way to build scalable applications. There are much more potential in stateless service providing, and yes, that cannot be achieved by the way you have described. Again: choice in technology, not security. If your developers are stupid, you go the restrictive way, but don't cry if your application does not scale as much...
    OK we are getting somewhere. I buy that this might be more expensive so it should be possible to turn off the feature and avoid the extra overhead but should be turned off by default. Here's why: 1. The argument that the developers need to know how to use the tool properly goes both ways. If this feature is killing scalability, it's the developers fault for not understanding the tool. 2. If the developer is not aware of this feature, they will likely find out about it when it starts limiting scalability. 3. When the developer finds out about how to turn this off, they will also likely find out about the possible security issues. 4. If the developer is unaware of this feature and it doesn't hurt the scalability of their system, the will be blissfully unaware of how the framework is protecting them. As an industry, we need starting putting security ahead of performance. We should err on the side of security and then optimize for performance and not the err on the side of performance and then address security. This is especially true for frameworks.
  54. Moreover, if anybody is interested to work with frameworks with 'prohibitive' designs then M$ frameworks are among the best. consider that for your next project (oh yes they come with lots of security promises!)
  55. know it's a yesterdays' news but. . . I don't believe you guys are putting blame on "frameworks" and protecting the developers!!! First: Every code and every framework has vulnerabilities, it's only a matter before such vulnerabilities are found. Second: Some frameworks are so powerful that if not used properly, could introduce vulnerabilities to your otherwise "non-vulnerable" application. For example: Should we blame AOP (all flavors) for it's capabilities to introduce "load-time malice, code highjacking etc. . ." to your otherwise perfect code or should we govern its misuse and educate the developers of the danger of such misuse? Or better off, should we outlaw all frameworks, which will shorten the problem to 10 actors, programming languages and developers which will make it much easier to play the finger-pointing game. And John. . . Promoting your framework is a noble thing (i think everyone here would agree with that), however promoting it by misstating and simply lying about other frameworks you want to compete with and jumping on every chance to bash them, is "less then noble" and probably turning off a lot of people. You might like to claim that your framework doesn't have such vulnerabilities, but one could easily say that may be no one cares enough to find them. . . you decide.
  56. I believe the point of the response was that the problem is with the Web MVC framework that the Web MVC module provides, not with the overall Spring framework itself. That's an important distinction. A lot of FUD could be read from the article by people who don't make that distinction. And I would guess that the vast majority of people using Spring are not using the web MVC module (including me), and are thus not affected.
  57. I know I'm just giving myself a need to buy a new set of flame-resistant undies, but... "Spring-MVC, like many web frameworks, let's you use any object as the model, and it's up to you to determine which fields can be populated." There's an unwritten part to this statement I think that's implied: when you can use any object as the model, *AND* that object is being exposed to the view layer, that's when there's an issue. S2 does this, JSF does this, many other frameworks these days are doing it: your model objects are available as-is to the view layer. It's at once a model object and a DTO. This is where the problem comes from I believe. It seems that developers decided at some point that being lazy (lazy not necessarily being a bad thing!!) was the way to go... so instead of having to do any object-to-object transfers, instead of isolating the layers by having to have a DTO between them, let's just have one object that gets used in all places. By doing that you open up the possibility of new vectors of attack, plus, IMO, making the architecture not as clean (less code is not necessarily equal to a cleaner architecture, although I'd agree it tends to be). Ironically, I think Struts Classis, as I like to call S1 these days, had it right all along: an ActionForm, which is conceptually a DTO between the view and control (and is therefore isolated from the model too). Sure, you had to write more code. Sure, it was a lot of boring boilerplate-type code. Maybe the implementation details weren't perfect. But you always *KNEW* which fields were mutable (any in the ActionForm are presumed to be). You always *KNEW* what fields were going into your model objects (because you yourself were doing the transfer). It was more work, but in some ways it was better. Architecturally too: it's the input and output that the view sends and receives, nothing more nothing less, and no question about it (if you used it as designed anyway).
  58. Agreed[ Go to top ]

    @Frank Zammetti: We're creating the very same design flaws in Java frameworks that PHP gets slammed for as being secure. You can't have your cake and eat it too, period. And the more brainless we try to make our coding environments, the more braindead our code becomes.
  59. Yawn, that's nothing new![ Go to top ]

    I don't see how this is news in any way. Just take a look at the spring forum. This behavior and workaround has been discussed there for 4 years (e. g. http://forum.springframework.org/showthread.php?t=10820). Just because some company decides to issue a press release about documented behavior of a web framework and another company then feels urged to issue a security advisory because of that doesn't make it a security _discovery_.
  60. nor critical, nor news[ Go to top ]

    Let me quote from the excellent "Webwork in Action" book (P. Lightbody and J. Carreira; 2006)
    Another issue to consider when directly using domain objects in your web tier is security. When you’re taking the user’s request parameters and setting them on a domain object before saving it back to the database, you have to be careful not to let the user modify properties they shouldn’t. For instance, what if the user put in saveUser.action?userId=100&user.id=1? The userId parameter might be used to load the User object, but then the user.id parameter might overwrite the id of the User object. Similarly, there are other properties you may not wish the user to set. Currently, no single right answer exists for this problem. One option is to have no getter for the domain object; instead, you put the getters and setters for the properties you want the user to be able to set on the action and have them delegate to the domain object properties, like this: public String getUsername() { return user.getUsername(); } public void setUsername(String username) { user.setUsername(username); } Although this approach effectively protects the properties you don’t want modified, you’ve lost a lot of advantages of using the domain object, because you need to duplicate the getters and setters for the properties on your action. Another option that is being worked on is using dynamic proxies to expose only the methods on interfaces implemented by the domain object. Using Aspect-Oriented Programming (AOP), these proxies can be built automatically without your having to do it manually in your code. If you have an interface named User with getters and setters for the properties username, firstname, lastname, and email, and a class named UserImpl that implements the User interface but adds properties with getters and setters for id, version, lastUpdate, and createDate, then the proxy implementing User will block access to these UserImpl specific properties. Because the proxy only implements the User interface, only the getters and setters for username, firstname, lastname, and email will be accessible.
  61. Re: nor critical, nor news[ Go to top ]

    Let me quote from the excellent "Webwork in Action" book (P. Lightbody and J. Carreira; 2006)

    Another issue to consider when directly using domain objects in your web tier is security. When you’re taking the user’s request parameters and setting them on a domain object before saving it back to the database, you have to be careful not to let the user modify properties they shouldn’t.
    For instance, what if the user put in saveUser.action?userId=100&user.id=1? The userId parameter might be used to load the User object, but then the user.id parameter might overwrite the id of the User object. Similarly, there are other properties you may not wish the user to set.
    Currently, no single right answer exists for this problem. One option is to have no getter for the domain object; instead, you put the getters and setters for the properties you want the user to be able to set on the action and have them delegate to the domain object properties, like this:

    public String getUsername() {
    return user.getUsername();
    }
    public void setUsername(String username) {
    user.setUsername(username);
    }

    Although this approach effectively protects the properties you don’t want modified, you’ve lost a lot of advantages of using the domain object, because you need to duplicate the getters and setters for the properties on your action.
    Another option that is being worked on is using dynamic proxies to expose only the methods on interfaces implemented by the domain object. Using Aspect-Oriented Programming (AOP), these proxies can be built automatically without your having to do it manually in your code. If you have an interface named User with getters and setters for the properties username, firstname, lastname, and email, and a class named UserImpl that implements the User interface but adds properties with getters and setters for id, version, lastUpdate, and createDate, then the proxy implementing User will block access to these UserImpl specific properties. Because the proxy only implements the User interface, only the getters and setters for username, firstname, lastname, and email will be accessible.
    Hey, somebody read it! Excellent! ;)
  62. In my opinion these security problems can't be considered as security advisories because they are already known by all. As people say, they are not a news, but I think they are still are a security risk. In other words, for expert web developers they are not a security problem because they know the internal behaviour of web frameworks and HTTP and they know what kind off data can or can't be exposed to the client. But to be honest, not all Java web developers are expert developers, and are conscious about the behaviour of web frameworks or HTTP. For example it's very usual to find developers or clients that are not conscious that all data sent to the clients can be tampered (OWASP top ten A4) by them (links parameters , hidden fields, comboboxes, cookies, ...) or know what is CSRF vulnerability (OWASP top ten A5). These problems can't be solved easily with best practices, even with expert developers. In my opinion if we want a high level of security we need more secure web frameworks and we need to automatize the input validation process. One pragmatic solution to this problem is HDIV project that adds a web application security extra layer to some of most common web frameworks such as Struts 1 , Struts 2 or Spring MVC. HDIV solves these two "vulnerabilities": - Doesn't allow new extra parameters (it only accepts the parameters defined within web form or link) - By default (you can desactivate it), it doesn't allow to edit hidden fields or non editable data in general (links, selects, cookies, comboboxes, ...) In conclusion, in my opinion many web frameworks (including Spring MVC) weren't designed with web application security on mind and delegate too many responsability to web developers. Of course, you can solve all security problems by hand but it's very hard to implement it. By the way, we are using Spring MVC + WebFlow + HDIV in our projects. Roberto Velasco HDIV team
  63. Hm... I've got another one for you: "A shopping cart included a price in the hidden field which I could modify and get the goods for free..." I should probably sit down and discuss this "security issue" with the Spring people... Both "security holes" are completely trumped up. Both are typical cases of naive implementations. And for those clamouring for more protection from Spring: you need to understand the security implications in your domain model. No framework can do it for you. It's up to you to understand security implications when running web applications, such as "don't trust the client", etc.
  64. Well, there are at least 3 issues... Third (turd?) one: I've successfully implemented my Spring mvc app and, after a few weeks, my server room catch fire and burned some of the equipment. It may ve said that the extensive usage of hash tables and getters/setters overheating the room a bit and it is not my fault for keeping gasoline tanks beside my servers, now is it!? In the next release, Spring people, be advised to fix this issue and provide us with some gasoline management recomendation in your docs. Dejan Rudic
  65. FWIW, in Stripes it's very simple: add @StrictBinding on your ActionBean and only the parameters that you validate - which typically correspond to those in your form - are allowed to be bound from the request. You don't have to worry about users injecting values by faking other request parameters. Fred Daoud Stripes ...and Java web development is fun again
  66. Now I would need to spend the whole week convinving the higher ups that this is a non-issue for us (as we don't use Spring MVC). *sigh*
  67. Now I would need to spend the whole week convincing the higher ups that this is a non-issue for us (as we don't use Spring MVC). *sigh*
  68. Another idea to get struck by: Imagine a bean that deletes all files from a hard drive at instantiation. Now, when you instantiate that bean via spring context, you loose all your files! Damn, I should have filed a spring framework security breach announcement before posting this...
  69. Regarding the 'ModelView Injection' exploit: The basics are : - views are identified in code using magic strings - these magic strings can define forward/include behavior, using a special prefix - request parameters are Strings Hence: It is theoretically possible for unvalidated request parameters to control what view is returned, including, possibly, arbitrary files which should never be exposed. In practice, how likely is it that such an incident will occur? It's likely non-trivial. It's not at all unreasonable for a user to select which view they would like. For an programmer with little experience, unfamiliar with the importance of validating all incoming data, the likelihood of them using an unvalidated request parameter is non-trivial. Why wouldn't they? They are both strings. Simple mapping, one to one...go for it, right? It is the inexperienced programmers that need the most protection. Even experts makes silly mistakes sometimes. I consider that this issue is indeed a fault in Spring MVC. It is based on the use of magic String identifiers for important items in code. If the design of Spring MVC were different, then this problem wouldn't have arisen in the first place. Spring doesn't seem able to admit that it has warts. Pity. Is it a bit of "cognitive dissonance", perhaps? Or just plain old fashioned hogwash?
  70. Sarcastic: An incompetent developer can destroy the data with bad SQL e.g. DELETE statement without WHERE condition. It is the platform that must stop him! Oh wait, it is written is Java/JDBC, file a security issue at once... Serious: Spring provides a lot feature for the average developer, including the Spring MVC. If a developer misuses it without the knowledge how it works, who do you blame? Java provides a lot feature for the average developer, including the JDBC. If a developer misuses it without the knowledge how it works, who do you blame? Linux provides a lot feature for the average developer, including the rm command. If a user misuses it without the knowledge how it works, who do you blame? You could blame the framework / platform / OS, however that is the same as blaming the guns for having deaths in war... It is always the people using the 'tools'...
  71. If a developer misuses it without the knowledge how it works, who do you blame?
    The problem isn't that the feature exists, it's that the feature allows something that is insecure by default. If I explicitly changed a setting that allowed for people to submit values that were not part of the form, then I am to blame. This reminds me of a security issue in the first (IIRC) version of Firefox. There was an option to allow arbitrary system commands to be run on the users machine by websites (again IIRC.) This option was turned on by default. Some people argued that this wasn't a security issue. The user just needed to turn this off. Thankfully, and to the benefit of Firefox, more rational heads prevailed. It doesn't serve Spring-MVC well to pretend this isn't an issue. I expect the Spring team is bright enough to understand this and will address it sooner or later. Having said all of that, can you give an example of when you would want to allow a submit to contain fields that were not visible on the associated form?
  72. If a developer misuses it without the knowledge how it works, who do you blame?


    The problem isn't that the feature exists, it's that the feature allows something that is insecure by default. If I explicitly changed a setting that allowed for people to submit values that were not part of the form, then I am to blame.
  73. If a developer misuses it without the knowledge how it works, who do you blame?


    The problem isn't that the feature exists, it's that the feature allows something that is insecure by default. If I explicitly changed a setting that allowed for people to submit values that were not part of the form, then I am to blame.
    Oooops, sorry for the misclick... This tends to be pointless if you ignore some facts. There are two schools, independent of Spring MVC: the ones who are saying that we should allow dynamic binding on the given object and restrict the exceptions manually, and those who would like to enlist every parameter on a binding explicitly. The first one gives you more freedom and dynamic behavior (e.g. you can have multiple forms targeting the same processing method! - something that is out of scope of the simple one form - one processing concept you are constantly referring to), however you must be aware that parameters can be faked, so either don't but objects there with anything internal, or initialize the binding to restrict the field you want. It takes the freedom _and_ the responsibility to the developer. The other school would restrict the freedom and the responsibility of the developer, enforcing either strict list of fields that can be bound or enforcing a page flow that for each form you have one and only one processing method, and for each method you have only one form. This is not about 'security' or 'issue' or 'vulnerable library', it is just the way you organize your code. As said previously: you can misuse SQL-injections, but don't blame JDBC for it, blame the developer!
  74. This tends to be pointless if you ignore some facts. There are two schools, independent of Spring MVC: the ones who are saying that we should allow dynamic binding on the given object and restrict the exceptions manually, and those who would like to enlist every parameter on a binding explicitly.
    This is a false dichotomy. It ignores that you can have dynamic binding and validate the submitted fields were in the form. There is no reason that Spring-MVC couldn't implement this as the default behavior other than possibly limitations within the framework itself.
  75. This tends to be pointless if you ignore some facts. There are two schools, independent of Spring MVC: the ones who are saying that we should allow dynamic binding on the given object and restrict the exceptions manually, and those who would like to enlist every parameter on a binding explicitly.


    This is a false dichotomy. It ignores that you can have dynamic binding and validate the submitted fields were in the form. There is no reason that Spring-MVC couldn't implement this as the default behavior other than possibly limitations within the framework itself.
    Could you please explain what do you mean by that 'default'? I mean let's pick a dictionary search application, that can be linked from other sites as well. It takes a few input parameters (e.g. word, from language, to language, originator site) and displays the result. As a developer I would do the following: - create an object that has the fields I mentioned above - create a validator that validates the field (actually I have ways to generate such e.g. from annotations) - create an annotated method that takes this object as a parameter and a binding result object afterwards to store the binding errors. (more info on that at Spring MVC's annotation documentation) - process the data, do the search and prepare the results in a list - present the form again and display the result through a template, e.g. freemarker as my default choice This is the default way a developer should implement this. It has dynamic binding and proper validation. I don't see what is missing by default...
  76. Hi guys, don't forget to change default password for admin user of your portal or database. We are always our own ennemies.
  77. That's considered news[ Go to top ]

    I'm no Spring fanboy, but that's not a bug and isn't news. As others have pointed out, it's a common "user error".
  78. Re: That's considered news[ Go to top ]

    I'm no Spring fanboy, but that's not a bug and isn't news. As others have pointed out, it's a common "user error".
    True.. its about robustness of the framework, i think James Watson got it right, frameworks by default should provide the more secure option. Well not just frameworks actually... if users can shoot themselves in the foot, they ultimately will, in this case of course the users are the developers. Calling it a critical security issue might be a stretch.
  79. Re: That's considered news[ Go to top ]

    i think James Watson got it right, frameworks by default should provide the more secure option.
    [joke] Well, if I would be a lawyer I could find the right wording of the sentence to prove the following: Spring actually secure by default: if you don't put you object there, it won't get bound. Furthermore you can bind simple parameters too, leaving no chance for unwanted binding... [/joke] Anyway, I still believe that this is the problem of the programmer, not the problem of the framework: Spring provides you bunch of ways to solve your task, if you choose this way, bear the consequences. You can do it other ways too, your choice. Again: don't blame the SQL language if you leave your WHERE clause out of the DELETE statement...
  80. Re: That's considered news[ Go to top ]

    Anyway, I still believe that this is the problem of the programmer, not the problem of the framework: Spring provides you bunch of ways to solve your task, if you choose this way, bear the consequences. You can do it other ways too, your choice. Again: don't blame the SQL language if you leave your WHERE clause out of the DELETE statement...
    In JSF (and other framework) there is no way to bind parameters in an unsecure manner. You don't seem to recognize this point.
  81. Re: That's considered news[ Go to top ]

    Anyway, I still believe that this is the problem of the programmer, not the problem of the framework: Spring provides you bunch of ways to solve your task, if you choose this way, bear the consequences. You can do it other ways too, your choice. Again: don't blame the SQL language if you leave your WHERE clause out of the DELETE statement...


    In JSF (and other framework) there is no way to bind parameters in an unsecure manner. You don't seem to recognize this point.
    As I've said earlier there are two schools of this, and JSF is in the 'enlist every binding' school (you know, #{Page1.myProperty} is enlisting...), which is of course 'secure' in this regards. Spring is in the other camp, that you specify an object and it fills for you from the request... Actually Spring is in both camp, as you can create the following to: @RequestMapping("/imageUpload") public String processImageUpload( @RequestParam("name") String name, @RequestParam("description") String description, @RequestParam("image") MultipartFile image) throws IOException { // processing... return "redirect:imageList"; } (source url: http://blog.springsource.com/main/2007/11/14/annotated-web-mvc-controllers-in-spring-25/ ) or as stated previously you can enlist every property you would like to bind: http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/validation/DataBinder.html#setAllowedFields(java.lang.String[]) I mean, you can do your mantra as you wish, but again the fact is, Spring gives you large spectrum of opportunities. You can use the very compact default behavior and if you are mixing some domain object in the binding, you can enforce 'security' on it. However if you cannot live with it, you shall use JSF or whatever you want, but that does not mean the framework is 'insecure'... SQL DELETE is 'insecure', oh dear, I'm repeating this too much...
  82. "I don't see that it really means that many more objects and attributes (IDE's are great for this)..." That right there is the problem: when your IDE is effectively hiding the underlying complexity of a solution, it's not a good thing. If you have a simple, clean, elegant solution it's easier to understand and easier to comprehend without the use of any tool. If on the other hand you have complex, inflexible spaghetti code that only *LOOKS* simple, clean and elegant because your IDE hides all the warts from you by making complex tasks easy, that's the wrong path to be going down. It's far better to have a solution that actually *IS* as simple, clean and elegant as it can be. By way of analogy: it's better to have a pretty wife than to have an ugly one that looks pretty when the expert at Glamour Shots makes her look good in pictures for you :)
  83. "I don't see that it really means that many more objects and attributes (IDE's are great for this)..."

    That right there is the problem: when your IDE is effectively hiding the underlying complexity of a solution, it's not a good thing. If you have a simple, clean, elegant solution it's easier to understand and easier to comprehend without the use of any tool. If on the other hand you have complex, inflexible spaghetti code that only *LOOKS* simple, clean and elegant because your IDE hides all the warts from you by making complex tasks easy, that's the wrong path to be going down.

    It's far better to have a solution that actually *IS* as simple, clean and elegant as it can be.
    Wise words. Guido
  84. "I don't see that it really means that many more objects and attributes (IDE's are great for this)..."

    That right there is the problem: when your IDE is effectively hiding the underlying complexity of a solution, it's not a good thing. If you have a simple, clean, elegant solution it's easier to understand and easier to comprehend without the use of any tool. If on the other hand you have complex, inflexible spaghetti code that only *LOOKS* simple, clean and elegant because your IDE hides all the warts from you by making complex tasks easy, that's the wrong path to be going down.

    It's far better to have a solution that actually *IS* as simple, clean and elegant as it can be.

    Wise words.

    Guido
    If so, then we had better dump OO and go back to programming in notepad. Sadly he misses the point. I am using an IDE to help with complexity, not hide it. Which text editor do you write your code in? And you and Frank probably have no use for http://www.eclipse.org/mylyn/
  85. If so, then we had better dump OO and go back to programming in notepad.

    Sadly he misses the point. I am using an IDE to help with complexity, not hide it.

    Which text editor do you write your code in?

    And you and Frank probably have no use for http://www.eclipse.org/mylyn/
    It is not a matter of editor, I know you know. I think that the key words are:
    when your IDE is effectively hiding the underlying complexity of a solution, it's not a good thing.
    and
    clean and elegant as it can be.
    Obviously IDE/tools are there to help with complexity (try to think to CORBA idl compiler). The problems arise when the complexity is unecessary and tools make the solution just **look** simple. These cases at least make me think. Guido
  86. My point is that many developers these days, too many, (and I spend a lot of hours every day mentoring junior developers so I see this all the time) use an IDE in a way that results in them not having a clue what's really going on. They are more than happy to allow a tool to think for them. They wind up churning out wildly complex solutions that (a) didn't need to be anywhere near that complex and (b) they didn't even realize were that complex because the IDE made it all so easy for them. Look, many developers use an IDE properly: it's a tool to help them work more effectively. Take away the IDE and they might be slowed down a little, but they'll still get the job done. They're still good developers who are capable of engineering a good solution. Other developers, far too many in my experience, can barely do a damned thing with some sort of tool helping them. They are incapable of coming up with a reasonable design on their own. That's my point. Complexity as a result of not realizing you engineered complexity is bad. Complexity because the problem is inherently complex (which you try to reduce as much as possible) is what good developers do.
  87. Err... "...can barely do a damned thing with some sort of tool helping them." ...should have been... "... can barely do a damned thing WITHOUT some sort of tool helping them.' Kind of an important correction to make I'd say :)
  88. "I don't see that it really means that many more objects and attributes (IDE's are great for this)..."

    That right there is the problem: when your IDE is effectively hiding the underlying complexity of a solution, it's not a good thing. If you have a simple, clean, elegant solution it's easier to understand and easier to comprehend without the use of any tool. If on the other hand you have complex, inflexible spaghetti code that only *LOOKS* simple, clean and elegant because your IDE hides all the warts from you by making complex tasks easy, that's the wrong path to be going down.

    It's far better to have a solution that actually *IS* as simple, clean and elegant as it can be.
    What we do is complex. Having less objects makes it less complex. Having multiple "struct" objects and command objects so you have less attributes to look at in the UI just moves the complexity and you will still need a good IDE to figure it all out. Using domain objects IS simple and clean. Is it always right and perfect? No. But it is not fair to look at CONs on one technique and PROs on the other. If IDEs don't help with complexity, then what is the point of an IDE? I would rather code an all domain solution without and IDE than a VO/Command/Domain solution. Remember that when you point your finger, three more point back at you.