Search Type: Posts; User: naapuri

Search: Search took 0.04 seconds.

  1. hendricd wrote:


    How I think that the example is broken: if I try to input the string "<b>foo" in a text field, it is displayed as a bold "foo", not as "<b>foo".

    mschwartz wrote:


    Yes,...
  2. 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...
  3. 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...
  4. 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...
  5. Hello,

    I wanted to create a drag'n'drop tree, similar to this: http://extjs.com/deploy/dev/examples/tree/reorder.html - but with something fancier than plain text as the node text. But it seemed...
  6. 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,...
  7. Thanks for the reply again.



    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...
  8. I agree.



    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.
    ...
  9. 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...
  10. 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...
  11. jgarcia, I agree that it's very good to be able to write any html to buttons and such. :) I only meant to criticize the method/property *names* that are misleading.

    However, I think that in 99% of...
  12. Would you care to elaborate on this one?



    Are you saying that a framework that defaults to encoding html entities would make people write worse code? I think that's a bit like saying that seat...
  13. jgarcia, thanks for commenting again. I think we can agree that security should be all parties' responsibility. A framework can only do so much for the security, but I think that the approach taken...
  14. Foggy, this particular Grid problem ("foo<b>") I described is not an XSS problem, as I said. But this example shows how the present Ext Grid forces the developer to *manually* take care of HTML...
  15. ApocalypseCow, thanks for your reply. I think it's all about data types. If we are talking about plain-text data, it's not "unsafe" until it's rendered as raw HTML. And the same data source could be...
  16. This seems to be a fundamental decision by the Ext team to ignore the XSS problem by forcing the user to remember to type all these encodeHtml calls *everywhere*. And this isn't only about the Grid...
Results 1 to 16 of 16