1. #61
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      0  

    Default


    Quote Originally Posted by Foggy View Post
    I can disable your "secureness" easily with firebug...
    I've been talking about two scenarios and I think that you are now commenting on something else than these two things.

    First, there are possible XSS problems, if a developer forgets to use encodeHtml when coding an application that would print content to user B something written by user A. This has nothing to do with Firebug or such.

    Second, there are minor issues such as my '<b>foo' example. This has nothing to do with security, since the user has just supplied the data himself. (Also see the previous post by me to jgarcia.) No problem here. But you suggest that I should fix this by setting the grid cell renderer to encodeHtml. This suggestion conflicts with what seems to be the way Ext applications are meant to be coded: plain-text data should be sent from the server html encoded already. The two possiblities here are:

    1. Html encode all existing data on the server before sending it to the client (via JSON/XML/etc). The encoded data is in the Ext.data.store object. It will be rendered to the grid without further encoding. This all leads to the '<b>foo' problem.

    2. Send the existing data as-is from the server (via JSON/XML/etc again). The data is stored as-is in the Ext.data.store and will be viewed in the grid with the encodeHtml renderer. When the user saves the data, it will be posted to the server as-is. No problem here. BUT: several other posts suggested that all data should be html encoded already on the server, before sending it to the client (via JSON/XML/etc again). I still cannot see why.

    3. Some other way?


    We'll get back to the seat belt metaphor once this subject is clear. :P

  2. #62
    Ext JS Premium Member Foggy's Avatar
    Join Date
    Apr 2007
    Location
    Switzerland
    Posts
    477
    Vote Rating
    0
    Foggy is on a distinguished road

      0  

    Default


    First, there are possible XSS problems, if a developer forgets to use encodeHtml when coding an application that would print content to user B something written by user A. This has nothing to do with Firebug or such.
    Of course it has, as soon as you count on your safety implemented in the view layer...
    I can change all of this stuff, as a normally user (with firebug) and send to your backend whatever i want.
    Thats why i said it is so much important to do this stuff on backend...

  3. #63
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      0  

    Default


    Quote Originally Posted by Foggy View Post
    Of course it has, as soon as you count on your safety implemented in the view layer...
    I can change all of this stuff, as a normally user (with firebug) and send to your backend whatever i want.
    Thats why i said it is so much important to do this stuff on backend...
    I'm not suggesting to implement WRITE-safety on the client.

    See the two options in my previous mail. In option 1, this implies that the server must first decode and then re-encode the data sent by client A (or strip tags...) before sending it to client B. That is one of the reasons I'm not quite interested in this option. Or, maybe I STILL haven't figured what other people really are suggesting when they say the data should be encoded when sending the data to the client in a JSON/XML response.

    In option 2, all data is sent as-is to the server. The server sends it to any client as-is (properly wrapped in JSON/XML) and the client renders it with encodeHtml. No problem here, right?


    I would still want to see "the Ext way" example of an editable grid whose (plain-text) content can be saved and then retrieved back for re-editing. I mean something like this one: http://extjs.com/deploy/dev/examples...edit-grid.html but without the cosmetic '<b>foo' bug, and at least a brief description of what is happening on the server.

    Could someone please give me a complete example?

  4. #64
    Ext User Blackhand's Avatar
    Join Date
    May 2008
    Posts
    42
    Vote Rating
    0
    Blackhand is on a distinguished road

      0  

    Default


    Specifically for ensuring characters are encoded so that they display correctly, I think doing your htmlEncode on either the server side or client side in a renderer would be acceptable.

    If your using an MVC framework for instance, it would make sense that your server would encode the text, while if your using web services that are not only being used for web applications, you might consider a client side renderer.

    Back to the main topic, client side scrubbing to protect against XSS and SQL injection is pointless, since you will have to repeat the process on the server anyway. There really shouldn't be any XSS protection in a javascript framework, server side frameworks sure.

  5. #65
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      0  

    Default


    Quote Originally Posted by Blackhand View Post
    Specifically for ensuring characters are encoded so that they display correctly, I think doing your htmlEncode on either the server side or client side in a renderer would be acceptable.
    I agree.

    Quote Originally Posted by Blackhand View Post
    If your using an MVC framework for instance, it would make sense that your server would encode the text, while if your using web services that are not only being used for web applications, you might consider a client side renderer.
    Ok, I think we are getting to the point. I'm using a client-side encoding for reasons you mention. I just set up the encodeHtml renderer in my editable grid, and everything is fine.

    BUT I'm very curious to find an answer to this: if I used a server-side encoding, as several posters suggest, how would I avoid the (cosmetic) '<b>foo' bug I mentioned?

    Quote Originally Posted by Blackhand View Post
    Back to the main topic, client side scrubbing to protect against XSS and SQL injection is pointless, since you will have to repeat the process on the server anyway.
    We are talking about two different things here. See my post above:

    In option 1, the server must scrub/sanitize all input before writing it to the database.

    However, in option 2, there is no need for client-side OR server-side scrubbing. When sending data to clients, the server OR the client must encode the data before rendering - just as you suggest above. If client-side encoding is chosen, this IS the XSS protection. It's absolutely needed, and it's perfectly OK way wrt security.

    This is why I disagree with you here:

    Quote Originally Posted by Blackhand View Post
    There really shouldn't be any XSS protection in a javascript framework, server side frameworks sure.
    IMHO there shouldn't be any *forced* XSS protection in a js environment, but it would increase security if it was on by default.

  6. #66
    Ext User Blackhand's Avatar
    Join Date
    May 2008
    Posts
    42
    Vote Rating
    0
    Blackhand is on a distinguished road

      0  

    Default


    Quote Originally Posted by naapuri View Post
    BUT I'm very curious to find an answer to this: if I used a server-side encoding, as several posters suggest, how would I avoid the (cosmetic) '<b>foo' bug I mentioned?
    Well, if you were using MVC, your view would display/format the data correctly for viewing on your client, so you can htmlEncode the <b>foo on your server and it would display fine.

    If you were using a web service, that is being re-used elsewhere, then it is probably not a good idea to htmlEncode the appropriate fields on the server as other things may need the data in its original (but safe) format.

    Whether a client side htmlEncode of data for display purposes should be the default in ExtJS is debatable, but the Ext team have chosen not to have it as default and its not likely to change because of the amount labor that would be required to make apps work correctly again.

    Once again, this is purely for display, by the time the data reaches your client, whatever server side solution your using, it MUST be safe to display without any client side encoding.

    XSS attacks are not a vulnerability in ExtJS, and any code/time invested by the ExtJS team to try provide some security against it would be in vain and just result in code bloat.

    Quote Originally Posted by naapuri View Post
    We are talking about two different things here
    And yes, I realize I'm talking about two different things in my posts:
    1.Displaying/encoding of XHTML characters on the server/client.
    2.The supposed/alleged XSS vulnerability in ExtJS.

    But the main topic is about no. 2, and I feel the need to re-iterate that if your adding XSS protection in your javascript AND relying on it, its going to be a gaping hole in your sites security. If can't rely on it, why even bother to put it there?

  7. #67
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      0  

    Default


    Thanks for the reply again.

    Quote Originally Posted by Blackhand View Post
    Well, if you were using MVC, your view would display/format the data correctly for viewing on your client, so you can htmlEncode the <b>foo on your server and it would display fine.
    My concern was about a scenario of using the grid component: YES, the '<b>foo' stored in the database would be encoded to '&lt;b&gt;foo' on the server and then rendered nicely on the client, in grid cell with no htmlEncode renderer set. THE PROBLEM: (I repeat - this is not a security problem, just a cosmetic one): if I enter '<b>foo' in a grid cell, then it would be incorrectly displayed as bolded 'foo' , because there is no htmlEncode renderer. How should I work around this problem, if I was to use server-side encoding? (I bring up this question in this XSS discussion jsut because I want to understand how people are supposed to code in an environment where encoding is done server-side.)

    Quote Originally Posted by Blackhand View Post
    Whether a client side htmlEncode of data for display purposes should be the default in ExtJS is debatable, but the Ext team have chosen not to have it as default and its not likely to change because of the amount labor that would be required to make apps work correctly again.
    I agree - it would be impossible to completely change that now. IMHO the minimum thing to do would be to point this out clearly in the docs. Especially in these very misleading cases where a property is named 'text' even though it is rendered as html. (See my earlier post: http://extjs.com/forum/showthread.ph...144#post221144)

    Let's say there was some js code:
    alert(var_containing_some_plain_text_supplied_by_a_user);

    If the developer wants to "upgrade" this code to use Ext, he would write:
    Ext.Msg.alert('foo', var_containing_some_plain_text_supplied_by_a_user);

    --> kaboom! Quite unexpected, right? The Ext.Msg.alert() docs say this about the second argument:

    msg: String
    The message box body text

    I think it should say: "The html content to shown as the message body text". The same applies in numerous places.

    Quote Originally Posted by Blackhand View Post
    Once again, this is purely for display, by the time the data reaches your client, whatever server side solution your using, it MUST be safe to display without any client side encoding.
    Why is that? In option 2 of my examples, any data can be sent eg. in JSON format:
    {"data": "<script ... something evel here...>"} if it's displayed with a htmlEncode renderer. Where is the problem here?

    Quote Originally Posted by Blackhand View Post
    XSS attacks are not a vulnerability in ExtJS, and any code/time invested by the ExtJS team to try provide some security against it would be in vain and just result in code bloat.
    I agree partly: this thread is not about vulnerabilities in Ext as such - it's about how the design of Ext makes it quite easy for an unwary developer to code XSS holes. This is why I'm proposing improvements in the API docs.

    Quote Originally Posted by Blackhand View Post
    And yes, I realize I'm talking about two different things in my posts:
    1.Displaying/encoding of XHTML characters on the server/client.
    2.The supposed/alleged XSS vulnerability in ExtJS.

    But the main topic is about no. 2, and I feel the need to re-iterate that if your adding XSS protection in your javascript AND relying on it, its going to be a gaping hole in your sites security. If can't rely on it, why even bother to put it there?
    I'll repeat my question about my proposed option 2. Where it the hole?

  8. #68
    Ext User
    Join Date
    Nov 2007
    Posts
    72
    Vote Rating
    0
    fallenrayne is on a distinguished road

      0  

    Default


    If you want a hole to be found, here is one for you. If you start feeding your data and you do your htmlEncoding on the output in the client side, rather than the input server side, anyone who injests your data needs to make sure that they also htmlEncode the data before displaying it. If you choose to use a different frontend you have to make sure that you find every place that you display data to make sure you are htmlEncoding the data else you leave a hole. It is much easier, and more secure, to encode the data server side. I would really hate to offer up a web service and "forget" to inform anyone using the service that my data is all raw and they HAVE to handle it rather than it is all encoded and they SHOULD handle it just in case.

    Now you could always htmlEncode the feed that the web service is using, thus nullifying this worry, but then again, why is there a need to go around patching all of the holes when simply encoding on input is a cleaner, simpler form of protection.
    ------------
    Brandon

  9. #69
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      0  

    Default


    fallenrayne, I'm *not* suggesting that data should be encoded on the client before writing it the database.

    I'm into a model where data is transferred in JSON or XML packets both directions, without html encoding. See option 2 in my earlier post: http://extjs.com/forum/showthread.ph...197#post221197

  10. #70
    Ext User
    Join Date
    Nov 2007
    Posts
    72
    Vote Rating
    0
    fallenrayne is on a distinguished road

      0  

    Default


    I realize that your not wanting to encode data on the client side before writing to the database. I was talking about the differences between encoding on the server side before it is written and encoding on the client side before it is displayed. I reread my post and I didn't find a place where I said that incorrectly so I am not sure where the confusion is coming from.

    If you encode your data when it is coming out of the database on the client side vice encoding it going into the database on the server side you will force yourself to patch every hole that comes up rather than fixing the problem in one location. By encoding it before it goes into the database you are still changing their data less than it would be changed if it were encrypted. Basically encoding is just a simplified version of encryption that ensures the safetly of your application. If your users believe that it is wrong to encrypt their data for the security of the web application then they have other issues that they need to work out first, because the security of the application should always come first.

    I am not saying that your method is necessarily "wrong" but it requires diligence in your security practices to make sure you don't open a hole. With that, it all comes back to the request that ExtJS have the option to do this for you so you don't have to worry about it as much.
    ------------
    Brandon

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar