1. #151
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    @joeri,
    Incorrect, you should always have Server Side protection/validation/encoding/decoding etc to ensure that the data that’s being sent or received by the client is as you require/is to the specification you impose.

    You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.

    You are also (sort of) right to say that having multiple methods is an overhead. A simple condition check (server side) is all that’s needed to determine if the data being sent from the client is to spec.

    Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

    The Server is under your control, the Client is not.


  2. #152
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    16,813
    Vote Rating
    607
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      1  

    Default


    @joeri We're looking at having some kind of global config that will htmlEncode <stuff>, the things that immediately spring to mind are grids/trees/combos, however it's difficult to know where to draw the line for this (think templates, renderTpl, Element.update).
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  3. #153
    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


    Quote Originally Posted by MrSparks View Post
    You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.
    Please don't confuse data with context. You encode to suit the context. The context is separate from the type of data. For example, I may show a user's first and last name in a tooltip (HTML attribute) and in a panel (HTML element). In that case I have to encode the same data in two different ways. According to you I would be sending the same data twice from server to client. That's a hack in my opinion.

    I come from the perspective of having shared web services between ExtJS and Android / iOS. The web service has to return data in unencoded form for the mobile platforms. In this example I would have to send the data in three different formats. Ugly, ugly, ugly. And completely unnecessary, because...

    Quote Originally Posted by MrSparks View Post
    Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

    The Server is under your control, the Client is not.
    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.

    XSS protection is about protecting your user against hidden page modification by a stranger. The only "trust" you need to have here is that your or your user control all changes to the page. In other words, you need to trust that the ExtJS code you're sending isn't modified in transit, and that no other code gets injected into the page. Encoding on the client can guarantee that just as easily (in fact more easily) as encoding on the server.

    What you are right on is that the client cannot be trusted to send valid data back to the server, which is why the server always must do input validation and authentication / authorization checks. But that's an orthogonal issue from XSS, which is best solved on the client.

  4. #154
    Sencha User
    Join Date
    Jun 2012
    Posts
    8
    Vote Rating
    0
    similian is an unknown quantity at this point

      0  

    Default


    I would like to be more clear. My problem is not that EXT JS does not support proper html encoding in some places. Its more serious.

    Ext Js breaks in simple json data containing " characters.

    For example:
    the following json:
    Code:
    {        "name": "this is some awesome object",
             "description": "containing a secret html property i will not show to anyone",
            "otherAttribute": "poop \" goes the weasel !"
    }
    This is valid JSON

    Suddenly when I call the store. My page halts.
    I look into the source and in some strange place i find this.

    HTML Code:
    <div internalid="201911863024" 
    raw="
    name:this is some awesome object;
    description:containing a secret html property i will not show to anyone;
    otherAttribute:poop " goes the weasel !.....
    suddenly the page shows ' goes the weasel !'

    As you noticed the " is unescaped very well. Yet not reencoded internally.
    Which breaks the page, and this is a XSS threat not created solely by the ui yet very much encouraged by it.

    This is where I have to start developing server side responses that fix my not so smart ui.
    And quadruple reencode double quotes.

  5. #155
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    Quote Originally Posted by joeri View Post
    XSS protection is about protecting your user against hidden page modification by a stranger.
    That’s an Interesting way of looking at it but it's placing the trust on the user, which of course you can never do. Fundamentally if the sever side controls have been developed correctly, there is no way a stranger could have injected malicious content into the data in the first place. Of course there’s always man in the middle attacks but that’s a different problem.

    Am I right in thinking that your issue is, you are potentially connecting to untrusted sources of data (web services etc provided by someone else) and you are worried that someone might have compromised that data?

    If that’s the case you will need to add a server side layer for XSS protection between EXT JS and the untrusted source.

  6. #156
    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


    Quote Originally Posted by MrSparks View Post
    That’s an Interesting way of looking at it but it's placing the trust on the user, which of course you can never do.
    You are supporting my argument. The user can always mess up his own page, regardless of what you do on the server.

    Let's go into specifics, please explain how this code can be hacked:
    Code:
    success: function(data) {
       panel.body.update(Ext.util.Format.htmlEncode(data));
    }
    PHP Code:
    echo $DB->fetchOne("SELECT TEXT FROM MYDATA WHERE ID = :id", array("id" => "1234")); 
    (Assume that htmlEncode follows the encoding rules of the ESAPI encoder, which it doesn't right now.)

  7. #157
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    Quote Originally Posted by joeri View Post
    Let's go into specifics, please explain how this code can be hacked:
    In its simplest 101 form....

    Right click, save page as, edit page / recraft the source path's and adjust the code to suite your malicious needs, save changes, run page.

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


    OK, now explain why this code can't be hacked the same way:
    Code:
    success: function(data) {
       panel.body.update(data);
    }
    PHP Code:
    echo htmlentities(
    $DB->fetchOne("SELECT TEXT FROM MYDATA WHERE ID = :id", array("id" => "1234")),
    ENT_QUOTES); 

  9. #159
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    You've listed server and client side code. Are you just talking about 1 or both?

  10. #160
    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 MrSparks View Post
    You've listed server and client side code. Are you just talking about 1 or both?
    I'm talking about the interaction between client and server.

    I'm trying to get my point across that encoding on the server doesn't offer more protection against XSS than encoding on the client. Any scenario you think up that involves someone hacking the client-side encoding can equally apply to a situation where the encoding happens server-side.

    If you're encoding on the server your code can be made as secure as when you're encoding on the client. But I maintain that it's the wrong place because its further removed from the rendering code, and the rendering code is the only code that really knows which encoding context is the current context. The risk for security issues is bigger, not smaller, if you're encoding on the server.

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