1. #161
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,616
    Vote Rating
    327
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      2  

    Default


    16 pages of people re-covering the same material over and over again...

    I get the impression that people are talking about different things here. I think MrSparks is advocating server-side input sanitization whereas joeri is trying to argue the case against server-side HTML encoding. Different things but both relevant to XSS.

    I fall into the camp that believes it is primarily the UI's responsibility to encode data to avoid HTML/JS-injection attacks but it would be wrong to suggest that the server can't help through input validation.

    For example, imagine a username should only contain alphanumeric characters and that users can see each other's usernames. This is potentially a target for a script-injection attack. In this case the server (or DB) should be ensuring that all new users have valid alphanumeric usernames, thus removing any potential for them to contain script tags.

    However, that is where the server's responsibility ends. It should not be HTML encoding data before including it in JSON responses. HTML encoding should be done in the UI and where possible it should be the default. Perhaps if all of your user-provided data is purely alphanumeric you can protect yourself just using server-side input sanitization but in the general case that doesn't apply. I'd argue it's naive to skip HTML encoding even in the alphanumeric case: relying on a distant part of the security layer to protect you is asking for trouble. All systems have security holes and not encoding is just another chink in the armour for hackers to exploit - many successful attacks rely on multiple small holes like this to get in.

    Sencha have acknowledged that there's a problem here. There are a number of reasons why it hasn't been implemented yet: performance, increased code complexity, backwards compatibility, time investment required, availability of workarounds, ...

  2. #162
    Sencha Premium Member
    Join Date
    Aug 2012
    Posts
    10
    Vote Rating
    0
    timmc_basis is on a distinguished road

      0  

    Default Recommendation: Document where explicit HTML-encoding is required

    Recommendation: Document where explicit HTML-encoding is required


    Even if Sencha decides to continue treating user data as HTML, it is imperative that they at least document the locations in ExtJS where they do this. Otherwise, I cannot help but view ExtJS as a minefield of potential XSS holes and double-encoding surprises waiting to happen.

    I was greatly aggravated to see Sencha representatives in this thread pooh-poohing the OP's complaint and berating other users for storing raw data in their databases. For now, and until Sencha takes encoding seriously, I am recommending that my colleagues avoid deploying ExtJS applications on public-facing dynamic sites.
    Last edited by timmc_basis; 1 Oct 2012 at 2:07 PM. Reason: typo

  3. #163
    Sencha User SimoAmi's Avatar
    Join Date
    Oct 2008
    Location
    New York
    Posts
    119
    Vote Rating
    3
    SimoAmi will become famous soon enough

      0  

    Default


    Quote Originally Posted by joeri View Post
    That is true but irrelevant in this discussion. You say that encoding on the server is safer because the client cannot be trusted. What is to prevent a user from having an ExtJS override that automatically de-encodes the data coming back from your web service before it gets injected into the page? Bingo: "XSS attack". But that's not what XSS is.
    Hi joeri,
    I just want to weigh it and say that your argument above is only applicable per individual case. How did the user manage to get such an override in place? Having an override that decodes incoming data from the server is a separate subject and does not affect other users.

    The server is more trusted as far as encoding/decoding data in my opinion because it protects attacks from reaching all users at once. Remember the pre web 2.0 era when everything was served remotely?

  4. #164
    Ext Premium Member Jan (HL)'s Avatar
    Join Date
    Aug 2010
    Location
    Germany
    Posts
    111
    Vote Rating
    9
    Jan (HL) will become famous soon enough

      1  

    Default


    Okay, just read all pages and I'm just wondering how several stuff was mixed (skirtle already noted this) and other stuff is unavoidable or irrelevant.

    So, just to clear some stuff.

    #1 The application is a stack of modules
    A frontend in a browser, a server backend and optionally a serverside database. And each module (layer) has some sub modules (sub layers).
    Each layer (and even each sub layer) is responsible to archive it's security, validity and reliability of its own context. This includes everyones interfaces to the next layer but only in the context of call (let's say, the [browser] data request). Because of this, I don't need to check the user's credentials when performing a database write. Why on earth should someone do this? This is not the responsible layer for this (answer: Ask the security (sub) layer).
    If the server backend writes data to the database, it won't care of stuff like HTML It will be (mostly) completely irrelevant. Everyone who admits that this would be easy, necassary or anything else just ignores that fact that in databases stored data are only... stored. It's okay for a mini website with only one way for now and forever, but not for a serios scalable environment. They can be used from other (http) endpoints, from other services. Let's talk about pdf. Too easy? PDF via XSLT (xslfo)? What about Mailing, what about Mailing with HTML mails?

    The backend loads and writes data from and to the database. It MUST use a proper technique to avoid sql injections. And yes, not to use them is highly negligent . Just have a look into the latest security news. But that's it. Nothing more. Neither the request type nor the response type of content is relevant.
    Additionally, the backend (in most cases a sub layer called "view") MUST encode the output correctly (likewise he does it decoding the request content). And that implicates that the (loaded) data could be encoded as well (regarding to @similian issue) no to break the output encoding/format. The encoding process is different between HTML and JSON.. even XML and HTML. Another point why encoded storage is a very bad idea. Content encoding is not part of the database layer. This would mean you would fixed the content type.

    #2 Browser is the consumer / view
    Why should someone care about HTML in a document which is actually JSON requested and therefor encoded? This is exactly what the browser in the most cases did.

    In fact, the browser is only a (one?) consumer of data provided by a service located on the backend server. Let's say, you are using a simple API outputting JSON. If this API encodes implicitly the output how could we difference between a consumer for HTML (a browser) and a consumer for a desktop application (a native app). Both is JSON. The only encoding which matters if the transport itself (each string have to be encoded not to break JSON).

    ===

    This means: I do not want to change any input from the user.. I DO WANT to get the same (HTML) content back from the server to the client. This is a feature of an interface like a HTTP endpoint, we have not to fear from HTML or JavaScript. We (the browser) can encode it ourself. Only if a fetch of encoded content was happened where this would be relevant -- i.e. a rendered HTML page with the data, like this forum -- the encoding must be done serverside before adding it to the view. However, this means that the view processing is server-side.
    You get it? Encoding processing must be done where the view will be actually used.

    Indeed, the view (the browser => the JavaScript => the framework => Ext JS) is responsible to avoid any browser/html injections (remember: a stack of modules). But despite of some arguments already made, I would prefer another way: Ext JS SHOULD gives tools to avoid it (e.g. short cut with "htmlEncode", best practices, an util (and this is already available in Ext.String.htmlEncode)) and SHOULD documentate this (demos, tutorials, doc) more explicitly in places of interest like columns (see it as a service). But there is only a MAY adding this as a default option. In larger grids and/or in applications with more than 3 grids this can be a performance issue. Providing a global setting is actually the same as overriding a -- potential -- column property "htmlEncode".

    A list of how to make applications better and scalable for further changes:
    1. Do not trust anyone on server side. Do really you think only your frontend could talk encoded with the server?
    2. Do not encode data on client side. This follows Rule #1: Do not trust the client. Because if you have to check if the content is already encoded (and you have to).. ehm that's weird.
    3. Do not decode encoded stuff or vice-versa. Following rules #1 and #2 give you always the option to add another output format, another service (PDF generator, mail reporting) or other hot stuff: Do you really want to escape the insane username of "<&>" in a tweet status call? Decoding already encoded stuff within your own application stack only proves that something is wrong.
    4. Encodings only where it is necessary. I think, anyone knows the time when the content is "&amp;amp;"--fied because the encoding had run amok. If the output is JSON, there won't be any HTML encoding required.
    5. If you want to get trusted HTML (i.e. a rich text editor in combination with a html rendered page like CMS) you have to validate the input. But in that case this is a special validation requirement "valid html with our constraints" of a special attribute of a concrete entity of your system. Even in a CMS this isn't default but a special case of a form value.

  5. #165
    Sencha User metalinspired's Avatar
    Join Date
    Apr 2012
    Posts
    98
    Vote Rating
    4
    metalinspired is on a distinguished road

      0  

    Default


    I haven't read the whole argument (sorry no time) but I don't see any point in trying to make front end more secure because a malicious user could as easily bypass it. Reminds me on how I cheated (some) of my faculty online exams because they never bothered to check time inconsistency on server side. For example: I had five minutes to complete the test. It had a java script timer and it was smart enough not to load the test if JS is disabled. However, a simple code extended my time to 24 hours. They could have made JS code to check for this but I would bypass it easily. The only way they could have caught me is to check time test was started and completed on server side, which they never did.

  6. #166
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    561
    Vote Rating
    45
    joeri is a jewel in the rough joeri is a jewel in the rough joeri is a jewel in the rough

      1  

    Default


    Quote Originally Posted by metalinspired View Post
    I haven't read the whole argument (sorry no time) but I don't see any point in trying to make front end more secure because a malicious user could as easily bypass it. Reminds me on how I cheated (some) of my faculty online exams because they never bothered to check time inconsistency on server side. For example: I had five minutes to complete the test. It had a java script timer and it was smart enough not to load the test if JS is disabled. However, a simple code extended my time to 24 hours. They could have made JS code to check for this but I would bypass it easily. The only way they could have caught me is to check time test was started and completed on server side, which they never did.
    Please read the thread. You're arguing something different from what this thread is about.

  7. #167
    Sencha User metalinspired's Avatar
    Join Date
    Apr 2012
    Posts
    98
    Vote Rating
    4
    metalinspired is on a distinguished road

      -1  

    Default


    naaah I'll just stay out

  8. #168
    Sencha User
    Join Date
    May 2009
    Posts
    136
    Vote Rating
    5
    DiscoBoy is on a distinguished road

      0  

    Default


    I do care about XSS and think it is better to have any possible measurements in place against XSS instead of only trusting that the server filters scripts for you. There is also a plenty of sources for XSS scripts - one of them of course the database content, but also content consumed from other APIs, HTTP headers, internal chat messages and so on...

    Therefore I'm planning to have a global sanitising function for all strings, representing user input! Now I wonder what ocation would be the best in ExtJS from where I call this sanitising function. In models, readers & writers, fields?
    Should I place event listeners that call a the sanitiser function on "beforerendering" fields (but then we miss grids and data views) or when we read data from a resource? I'd be thankful if you could share best practices and suggestions!

  9. #169
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    561
    Vote Rating
    45
    joeri is a jewel in the rough joeri is a jewel in the rough joeri is a jewel in the rough

      0  

    Default


    I'm not sure whether you mean sanitizing on input or sanitizing on output. You should sanitize input on the server.

    Sanitizing on input is in my opinion not a good practice. Even the space character is dangerous in some places (e.g. in unquoted html attributes). I prefer to leave the input as-is (except for html which I run through htmlpurifier) and to encode context-aware for output per the OWASP XSS cheat sheet:

    https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet

    The challenge here is that rendering is context-specific. So, while htmlEncode will do fine in most cases, it is not sufficient in some others. You always have to be aware of the specific context you're rendering into. This makes it harder to encode properly for output.

  10. #170
    Sencha User
    Join Date
    May 2009
    Posts
    136
    Vote Rating
    5
    DiscoBoy is on a distinguished road

      0  

    Default


    Thanks for your answer. I already discovered this cheat sheet and htmlpurifier and was thinking about a similar strategy. Filtering INPUT on the server with htmlpurifier (Works only for text payload that could have malicious html or script tags???) and OUTPUT filtering in te UI. I understand that this has to happen context wise - just to be sure: When outputting text in a textfield or as the HTML of a container (CASE A), htmlEncode should be enough to catch malicious code or scripts. The part where I need to be carful is when I use OUTPUT parameters inside of HTML tags (CASE , for instance <img src=a onload="doEvil()" /> because here SPACES would matter.

    Now I have some more questionsr egarding this:

    1) What if I use input ExtJS fields, where I would use OUTPUT in the value parameter (checkbox {value: MALICIOUSCODE}). How would you address this?

    2) I have plenty of UI parts where I display server OUTPUT. Wouldn't it be better to sanitize already at the level of receiving the OUTPUT from the server, means overwriting certain MODEL/READER methods to catch malicious code already at the point when I load it from an external resource? This way I need to sanitize once and not for every UI component.

    3) The cheat sheet is quite long, did you implement checks for every mentioned case? Would you share your code? I would imagine this sanitizing is quite costful in processing time

    4) How do you sanitize strings wthat are displayed in grids/trees?