Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Security

    Server side frameworks mention security as their first argument over client side frameworks. What is the Isomorphic position on the subject ? What are the smartGWT capabilities on this point ? Does SmartGWT has some mechanisms against the most common web attacks (see OWASP http://www.owasp.org/index.php/Top_10_2010) ?

    This subject is not easy whatever we have a general understanding or being able to follow technical given informations because many specialists with a long experience are still in opposition :) For example Isomorphic has an impressive experience with all kind of customers but experience of some others like David Pollak (creator of the Lift framework) is no less impressive for exactly the same reasons and you when you talk with him, you have been given many reasons based on his experience (including financial environment) for which if the security is not managed on the server side, then it's something like signing our death... well a little extreme :) but on financials projects, it can be closed to :), for example can a bookmarker or a betting exchange provider trust smartclient for its web site ? How SmartClient is secure enable where others client side frameworks are not (or not enough) ?
    Last edited by Cloud; 16 Nov 2010, 22:28.

    #2
    You're likely misinterpreting David Pollack comments - security *is* managed on server-side in SmartGWT. That's the only way it can be done.

    For our part we consider client-server frameworks like SmartGWT far more secure than server-centric solutions, for the simple reason that there is far less code running on the server hence far less opportunities for mistakes.

    An architecture where the server just provides secure data services is much easier to understand.

    Specifically in SmartGWT, consider also:
    1. our SQL Templating approach makes it much harder to write SQL injection attacks since everything is escaped by default
    2. in Pro and above you declare validation and security rules in one place - the .ds.xml file - and it is enforced on both the server and client-side. This makes it impossible to (incorrectly) implement a security check only on the client-side

    Comment


      #3
      Originally posted by Isomorphic
      You're likely misinterpreting David Pollack comments - security *is* managed on server-side in SmartGWT. That's the only way it can be done.
      I may misinterpreting David Pollack comments or not but exposing the meaning of David comments you talked about would be much more interesting :)

      David created the Lift framework, which is a server side framework. As a start and as an example of security issues on the client side, he says that relying on cookies, whatever encrypted or not, is not reasonable if we have security in mind. Usually, Lift developers relies on sticky sessions and their storage in a database.

      I read several entries of Charles Kendrick from Isomorphic and his famous troll with Marc Logemann here http://www.logemann.org/2010/09/ext-gwt-or-smartgwt-or-vaadin.html.

      Charles has strong arguments and, if i well understood some things sometimes mentionned by half, it seems to confirm what we may think natural of a client side framework, that is sticky session management is not a requirement, as well as web session clustering. If it's correct, then it's an incredible huge advantage.

      What i can't misinterpreting is that people creating or using server side framework mention security as their first argument against client side framework. I'm by no mean a security expert but i guess some of them are and that they have reasons for saying such things:), maybe these reasons don't match at all with smartgwt, then how smartgwt manages to circumvent these supposed issues... that's what my questions are all about in order to know if there are extreme sensible contexts smartgwt can have some security issues (even littles, smartgwt can't be excellent in everything after all :) ).

      Originally posted by Isomorphic
      For our part we consider client-server frameworks like SmartGWT far more secure than server-centric solutions, for the simple reason that there is far less code running on the server hence far less opportunities for mistakes.
      Yes, that's a valid way to consider the question but i doubt people using server side framework are talking of this aspect.
      Yes, i'm reading the quickstart smartclient pdf but don't find clear answers on this.

      Comment


        #4
        Yes, you are correct that client-centric frameworks like SmartGWT do not require sticky sessions and do not need to store things in a server-side session. This is a huge advantage, but it also ranks about 4th behind other gigantic advantages: 1) client-side events, make customized drag and drop possible 2) offline capability 3) better responsiveness, especially over high-latency networks.

        There is very little that proponents of server-centric frameworks can name as advantages, so they throw security up there as a bullet point. Typically the justification is extremely vague: some say that you are exposing your business logic on the client-side. Yes, you are exposing some business rules, but for the most part these rules are already obvious to end users just by looking at the UI, and unless you have made fundamental mistakes, it doesn't matter if an attacker can see client-side business logic, because you're still doing all your actually security *enforcement* server-side.

        And again, with less server-side processing, there is less code that can have a security flaw, and a simpler architecture to audit.

        As far as not using cookies - cookies and sticky sessions are orthogonal concepts, so again you may not be getting his point correctly. If David is actually against cookies, presumably his point is that exploits like this one rely on cookies. But then, banks use cookies. However, if you want to take the somewhat extreme measure of eliminating cookies based on possible future exploits, SmartGWT does make it very easy, since it's straightforward to add code that adds a non-cookie based session id to all requests.

        Comment


          #5
          Originally posted by Isomorphic
          But then, banks use cookies. However, if you want to take the somewhat extreme measure of eliminating cookies based on possible future exploits, SmartGWT does make it very easy, since it's straightforward to add code that adds a non-cookie based session id to all requests.
          Interesting but then it will time to store things in a server-side session, no ? that would be a lost of one of these SmartGWT huge advantages, maybe that's what you mean by "extreme" :)

          Comment


            #6
            No. Use of cookies vs other means of passing a sessionId is completely orthogonal from whether application state needs to be stored in a server-side session.

            If you'd like a structured approach to learning these concepts, consider our training courses.

            Comment


              #7
              Thanks, that's useful

              Comment

              Working...
              X