1. #71
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      1  

    Default


    This is not a security issue at all. I think this discussion has been side-tracked to long by framing it as if it has anything to do with security or XSS.

    The point is this:
    - When using a web service to fetch data, it is simply bad design to format the data for rendering on the server-side, because your web service should be usable across front-ends (html encoding data on the server makes no sense when your web service is also accessed by a Delphi win32 application)
    - Having to explicitly html-encode data for rendering on the client is clumsy and needless typing. The default situation will be that you want to encode, not that you won't want to encode, so the toolkit should reflect this.

    In conclusion, in my opinion: ext should encode to html by default when rendering data to the screen.

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

      0  

    Default


    So encoding on the client side is clumsy and should be handled by whatever toolkit you are using by default so you don't have to do it yourself, yet now when you change frontends you have to fix all of the locations that the toolkit was handling the encoding for you. This opens up the possibility for mistakes that do not need to be there if it is handled on the server side.

    If you are worried about your web service being used in an application that is not web based then you do 1 of 2 things, unencode your data for the web service or tell the users of the web service that the data is encoded.

    So it comes down to the fact that neither way is necessarily wrong, just one has more possibility for mistakes. With that, no, the toolkit should not do it by default. If the Ext team wants to add it in there as an option then cool, but not by default. There are already helper methods so that it is not as "clumsy" or "needless" to encode the data. Use the helper methods or override the grids to do it on your own.
    ------------
    Brandon

  3. #73
    Ext User
    Join Date
    Oct 2007
    Posts
    15
    Vote Rating
    0
    kmbarr is on a distinguished road

      0  

    Default


    I would like to see the default behavior remain the same, but allow the programmer to set it to htmlEncode by default by setting some global flag, similar to how BLANK_IMAGE_URL is handled now.

    ...and, honestly, I think implementing that would've taken a lot less effort than all this arguing about which way it should be.

  4. #74
    Ext User
    Join Date
    Jul 2007
    Posts
    17
    Vote Rating
    0
    danp is on a distinguished road

      0  

    Default


    I would like to note that our company just hit this issue too and I am of the opinion that this is a failing on the part of Ext.

    Data should always be stored in a raw format and the decisions about how to render that data should be handled by the outermost presentation layer (in this case Ext.) As such, the prudent choice for Ext (as a presentation layer that primarily runs within web browsers) would be to default-to-secure by encoding all data it receives unless explicitly told not to.

    As joeri said, the idea that our data/service-layer should pre-encode data is silly, that layer has no idea how the data will be used.

    I'm actually quite a bit saddened that so many people on here don't get this.

    EDIT: I apologize, I just realized this was from September 2008, not September 2009.

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

      0  

    Default Nothing new

    Nothing new


    danp,

    as you probably noticed, the problem still exists, even though the thread is old.

    Even 'the <b>foo problem' I mentioned earlier (not the actual XSS problem, but a sign of the larger problem) is still everywhere: just try the current editable grid demo.

    All this seems quite ridiculous. But XSS ignorance seems to be a very common problem.

  6. #76
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,962
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Default


    Quote Originally Posted by danp View Post
    ..Data should always be stored in a raw format and the decisions about how to render that data should be handled by the outermost presentation layer (in this case Ext.) As such, the prudent choice for Ext (as a presentation layer that primarily runs within web browsers) would be to default-to-secure by encoding all data it receives unless explicitly told not to....
    Sorry, but this one really puzzles me.

    The browser is the consumer, not Ext. The Ext framework is not the User-agent. It does not have a native, low-level TCP socket to filter with -- to protect you with. It lacks sufficient privilege and useful context to make decisions about what-is-safe?

    It would seem the prudent choice would be that the browser should assume that role (whatever that should be), since it already enforces/provides same-origin, HTTP-Auth, NTLM, and recently -- native JSON parsing support.

    Ext cannot
    'default-to-secure by encoding all data it receives
    until it recieves it from where?

    The browser
    (after it's filtered by myriad plugins and popup/ad-blockers).

    I sounds like your barking up the wrong tree of abstraction.

    Are todays web-browsers 'off the hook' just because you might permit errant/malformed 'data' to be persisted in your ass-end architecture?

    Are you implying that EVERY Ajax response the 'framework' received from a host is to be analyzed, filtered, or mangled for 'safety' based on its content-type (and who decides how that's done)?

    Sure sounds like it.
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.


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

      0  

    Default This is about escaping, not filtering

    This is about escaping, not filtering


    hendricd,

    I'd like to hear how you would fix 'the <b>foo problem' I mentioned earlier.

    If we have user-supplied text/plain data, "<b>foo" is a perfectly valid string. One could write an article titled "The <blink> tag considered harmful".

    Ext cannot Quote:
    'default-to-secure by encoding all data it receives
    until it recieves it from where?


    No, this is not for Ext or the browser to decide - the *developer* must know the content-type of each type of data he/she has. Let's say that one wants a grid with towo columns: column A contains html text (already filtered on the server), column B contains user-supplied plain text.

    * The *developer* configures the grid so that all data in column A will be printed as-is, and all data in column B will be html escaped before printing.
    * The *developer* feeds the grid with data, eg. via a JSON request.

    hendricd, I don't see any problems with the pattern above. Do you?

    Are you implying that EVERY Ajax response the 'framework' received from a host is to be analyzed, filtered, or mangled for 'safety' based on its content-type (and who decides how that's done)?
    HTML escaping is not "analyzing, filtering and mangling". It's just a way of rendering text/plain content safely in a text/html context.

    Yes, I'm implying that when an application receives data from the server, it should escape the plain text data for safe viewing. As doeri pointed out, "it is simply bad design to format the data for rendering on the server-side, because your web service should be usable across front-ends". And not escaping on the client side leads to odd problems, such as the <b>foo problem.

  8. #78
    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


    because your web service should be usable across front-ends
    If the web service should be usable across front-ends, html is a bad choice anyway.
    In the case of a pdf or flash output, you have to convert html. So this is a meanly reason...

    As doeri pointed out, "it is simply bad design to format the data for rendering on the server-side
    And what about if you will show html in any case? In my opinion you have to know wich html tags are valid. For example <b>, <i>, <a> and so on. You have to eliminate <script> Tags on the backend for preventing XSS...
    Another reason, if you do this in frontend (in case of ExtJS it is meaning by JavaScript) i can annul this mechanism by my XSS attack. Thats another reason for doing this on backend, wich is almost saver than frontend...

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

      0  

    Default Let's just talk about text/plain content

    Let's just talk about text/plain content


    Foggy, please re-read my previous post with the <blink> tag example. Let's talk about text/plain content now.

    The user writes text/plain content and expects to get that back *verbatim*. Let's call this use case 1. This thread is mostly about keeping text/plain as is.

    Then we have use case 2: the user supplies html content. This must be filtered on the server, of course.

    Let's keep these cases separate. The developer must *always* the content-type of his/her data.

    Foggy, how would you fix my '<b>foo problem'?

  10. #80
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    Quote Originally Posted by Foggy View Post
    If the web service should be usable across front-ends, html is a bad choice anyway.
    Exactly! Which is why the web service _must not_ return HTML, but must return plain text. Why then does Ext require me to each time explicitly tell it to encode the plain text it receives from the web service as valid HTML, when the optimal design of a web service will be that it does not return pre-encoded HTML?

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi