1. #121
    Sencha - Community Support Team jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    DC Area =)
    Posts
    16,364
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    Quote Originally Posted by joeri View Post
    @mschwartz: your strategy of encoding before sending to the browser only works if all the clients are web clients. I am writing apps that have a multi-client model, where some of the clients calling the web services are not web apps.
    That's irrelevant. Ext JS is the focused subject matter here.

  2. #122
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Austin, TX
    Posts
    11
    Vote Rating
    1
    normanrichards is on a distinguished road

      0  

    Default


    Chods - how exactly do you disable encoding on MY browser? If the client properly encodes data from the server before inserting it into the html, where is the issue? Nobody cares what you do with your browser. You own your browser and all it's functions. The server will validate data as appropriate to the type, and the client will encode it correctly so that non-HTML is not treated as HTML. While I can bypass this encoding in my browser and you can bypass this encoding in your browser, YOU cannot bypass this encoding in MY browser, right? If you can, please teach me. I'd love to learn.

  3. #123
    Ext JS Premium Member
    Join Date
    Mar 2010
    Posts
    1
    Vote Rating
    0
    ecassady is on a distinguished road

      0  

    Default


    Quote Originally Posted by jgarcia@tdg-i.com View Post
    That's irrelevant. Ext JS is the focused subject matter here.
    This is relevant precisely because Ext JS is the subject matter. Are you saying that using Ext JS as a client framework precludes my developing other, non-Ext, clients for my application?

    Ext JS, like any well-designed presentation layer framework, should certainly not require the application to be aware of its existence. In fact I would suggest that if it does so it is displaying an extreme level of design schizophrenia. Ext JS supports RESTful conversations with the application layer. REST is emphatically presentation-layer agnostic as a transport. If I want to build an Ext JS user interface against my REST application as well as a headless data processing client application, I should be able to do so. If you are saying I must HTML-encode data before it leaves the application layer, I have to do one of two odious things:

    1) Add another, Ext JS-aware (or at least webapp aware) layer between the REST apis and the client.
    2) HTML encode my data within the application layer, requiring my headless data processing client to now be aware of an implementation detail af another, completely unrelated, client application.

    Seriously?

  4. #124
    Sencha - Community Support Team jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    DC Area =)
    Posts
    16,364
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    Quote Originally Posted by normanrichards View Post
    Chods - how exactly do you disable encoding on MY browser? If the client properly encodes data from the server before inserting it into the html, where is the issue? Nobody cares what you do with your browser. You own your browser and all it's functions. The server will validate data as appropriate to the type, and the client will encode it correctly so that non-HTML is not treated as HTML. While I can bypass this encoding in my browser and you can bypass this encoding in your browser, YOU cannot bypass this encoding in MY browser, right? If you can, please teach me. I'd love to learn.
    I can understand some value in this, however placing security in JavaScript, which is insecure by nature, is not something you should put too much trust.

  5. #125
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Austin, TX
    Posts
    11
    Vote Rating
    1
    normanrichards is on a distinguished road

      0  

    Default


    Quote Originally Posted by jgarcia@tdg-i.com View Post
    I can understand some value in this, however placing security in JavaScript, which is insecure by nature, is not something you should put too much trust.
    OK - now we are getting somewhere. Let's clarify this idea some. What insecurity of javascript are you worried about? The only person who can bypass the HTML encoding in my browser is me, right? Yes, I could change the values in my browser. I could load firebug and change methods. I can insert new HTML, etc... However, I can only make changes to javascript in my browser. I cannot reach
    into your browser and cause the HTML to not be encoded, right? I could do that, couldn't I reach into your browser and cause my own HTML to be added to your page even if you are encoding on the client?

    Are you saying you don't trust javascript to correctly encode values or that you don't trust extjs to perform the encoding? What exactly are you not trusting about javascript. If it is functional, why do you trust javascript for anything in an extjs app? I'm not immediately dismissing your concerns, I'm just trying to figure out what javascript vulnerability you are concerned with here.

  6. #126
    Sencha User dorgan's Avatar
    Join Date
    Dec 2007
    Location
    Cocoa, FL
    Posts
    286
    Vote Rating
    -1
    dorgan is an unknown quantity at this point

      -1  

    Default


    The server should be the relied upon method of "securing" the data.....Encoded data should not be stored in the database because as a couple of people stated earlier you could end up with other "frontends"...and HTML unless using a WYSIWYG for the exact purpose of generating HTML should not be stored in the database....use bb cod eor something of the such to create tokens that can be replaced by the frontend or the server/if your server is aware of the frontend currently in use.

    Relying on javasript to filter content is the biggest security risk you could create when it comes to "securing" the data. All someone needs to do is include another javscript file that overrides your code or even extends and Ext Object that, in your opinion, needs the filtering....and now your screwed because you relied on javascript to handle it.
    Last edited by dorgan; 6 Aug 2010 at 7:48 AM. Reason: typos

  7. #127
    Sencha - Community Support Team mschwartz's Avatar
    Join Date
    Nov 2008
    Location
    San Diego, Peoples' Republic of California
    Posts
    2,053
    Vote Rating
    17
    mschwartz will become famous soon enough mschwartz will become famous soon enough

      0  

    Default


    Quote Originally Posted by joeri View Post
    @mschwartz: your strategy of encoding before sending to the browser only works if all the clients are web clients. I am writing apps that have a multi-client model, where some of the clients calling the web services are not web apps.
    Then your other non-web clients should be asking for data responses from your www services in a different format than the web clients. Or those clients can munge the responses to whatever form you need.

    I'm not seeing the issue here.

    No matter how you spin it, the client code is insecure (can be hacked by a malicious user). The server is where you have the ability to control the content.

  8. #128
    Sencha Premium Member
    Join Date
    Apr 2009
    Posts
    110
    Vote Rating
    0
    Chods is on a distinguished road

      0  

    Default


    Quote Originally Posted by normanrichards View Post
    OK - now we are getting somewhere. Let's clarify this idea some. What insecurity of javascript are you worried about? The only person who can bypass the HTML encoding in my browser is me, right? Yes, I could change the values in my browser. I could load firebug and change methods. I can insert new HTML, etc... However, I can only make changes to javascript in my browser. I cannot reach
    into your browser and cause the HTML to not be encoded, right? I could do that, couldn't I reach into your browser and cause my own HTML to be added to your page even if you are encoding on the client?
    I think I may be able to reach into your browser by injecting some javascript into the application which rewrites the 'encode' method whatever that maybe and then sending all your cookies to a new url.

  9. #129
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Austin, TX
    Posts
    11
    Vote Rating
    1
    normanrichards is on a distinguished road

      0  

    Default


    Quote Originally Posted by dorgan View Post
    The server should the relied upon method of "securing" the data.....Encoded data should not be stored in the database because as a couple of people stated earlier you could end up with other "frontends"...and HTML unless using a WYSIWYG for the exact purpose of generating HTML should not be stored in the database....use bb cod eor something of the such to create tokens that can be replaced by the frontend or the server/if your server is aware of the frontend currently in use.
    Ok, so are you saying that no HTML unsafe data should ever be stored or sent to the client? (No "I <3 puppies" or "My favorite html tag is <blink>" -anything that could be potentially misunderstood by HTML, even if all clients aren't HTML oriented, are invalid) Or, are you saying that the service that provides DATA to your client, which happens to be a web app but doesn't have to, should only send HTML encoded values to the client, forcing the client to decode the value to work with the actual data. (the only advantage being that you can do an inherently unsafe thing like insert data from the server into the DOM, crossing a data boundary that should normally require encoding, without actually performing the encoding) Or, are you suggesting some third thing that I'm not following?

    Relying on javasript to filter content is the biggest security risk you could create when it comes to "securing" the data. All someone needs to do is include another javscript file that overrides your code or even extends and Ext Object that, in your opinion, need that filtering layer....and now your screwed because you relied on javascript to handle it.
    Could you please clarify this. Who is this "someone", and how are they "including another javascript file"? Is someone hacking my server and adding javascript to my app? (if so, then neither html encoding or not encoding is safe) Are you saying that you are adding javascript to my app running in your browser? (if so, how is your data ending up not being encoded in any of my other users browsers) I'm really failing to see the vector of attack you are proposing and why you think that the server side DATA service should encode for issues relevant only to HTML extjs clients.

  10. #130
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Austin, TX
    Posts
    11
    Vote Rating
    1
    normanrichards is on a distinguished road

      0  

    Default


    Quote Originally Posted by Chods View Post
    I think I may be able to reach into your browser by injecting some javascript into the application which rewrites the 'encode' method whatever that maybe and then sending all your cookies to a new url.
    Can you clarify what "injecting some javascript into the application" means in this context? Do you mean you that you are injecting javascript into YOUR browser? If so, how does this affect anything in another of my users' browsers?