Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

  1. #171
    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 DiscoBoy View Post
    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?
    1. The value is not serialized into html but assigned via the DOM API, so there is no risk for XSS if you assign a value in this way. There is a danger in components that use a template for rendering (combobox, dataview, grid, ...), but this is only for the output of the selected value's label / data.
    2. In my personal opinion if you do this at the model level then you are embedding knowledge about how the view layer operates into your model (because of context-aware encoding). This is not a proper way to separate MVC concerns.
    3. For XSS entity encoding we only use the htmlEncode function (with a tweak, see my ExtJS 3.4.1 overrides on this forum) to generate data for the html or html attribute context (if you use double quotes religiously then you can use htlmEncode's output in an attribute). We never put untrusted data in other contexts. If we need data inside javascript, then we implement a web service to fetch it as JSON data.
    4. Grids and trees use htmlEncode just like anything else. You have to remember to put renderer: Ext.util.Format.htmlEncode on every column.

    You are right in pointing out that htmlpurifier is only good for html text (rich text). For input sanitization of non-html data on the server we have developed a DTO-based solution in PHP which uses static annotations to validate all data in the server-side web service layer automatically. I gave a tech talk about it recently, and there's an example implementation of it that I've put up on github.

  2. #172
    Sencha User
    Join Date
    May 2009
    Posts
    135
    Vote Rating
    1
    DiscoBoy is on a distinguished road

      0  

    Default


    Quote Originally Posted by joeri View Post
    1. The value is not serialized into html but assigned via the DOM API, so there is no risk for XSS if you assign a value in this way. There is a danger in components that use a template for rendering (combobox, dataview, grid, ...), but this is only for the output of the selected value's label / data.
    2. In my personal opinion if you do this at the model level then you are embedding knowledge about how the view layer operates into your model (because of context-aware encoding). This is not a proper way to separate MVC concerns.
    3. For XSS entity encoding we only use the htmlEncode function (with a tweak, see my ExtJS 3.4.1 overrides on this forum) to generate data for the html or html attribute context (if you use double quotes religiously then you can use htlmEncode's output in an attribute). We never put untrusted data in other contexts. If we need data inside javascript, then we implement a web service to fetch it as JSON data.
    4. Grids and trees use htmlEncode just like anything else. You have to remember to put renderer: Ext.util.Format.htmlEncode on every column.

    You are right in pointing out that htmlpurifier is only good for html text (rich text). For input sanitization of non-html data on the server we have developed a DTO-based solution in PHP which uses static annotations to validate all data in the server-side web service layer automatically. I gave a tech talk about it recently, and there's an example implementation of it that I've put up on github.
    Many thanks for your replies!!! It took me a while to answer as other things kept me busy but security must be a number one priority.

    1) Yes, my question was regarding the outputting in text fields. For instance I want to show an user object in an editor view. What you mean is that the normal fields use HTML INPUTS and do not get rendered as <input value="MALICIOUS CODE"> but rather as <input ID="ext-field-12345"> and later set by JavaScript like Ext.get('ext-field-12345').setValue("MALICIOUS CODE"); Correct?
    then I really only need to look at templated fields and this means generally all my views which somehow use a template...

    My thoughts are going towards overriding Templates and Xtemplates and to always call a sanitize() function for each {value} in the template, but this might be to complex as well...what would you advice? (Because I also would like to address templates with iterations, etc. (Example: <for '.'>{value1} {value2}</for>)

    2) Might be an effective place but I agree it doesn't really fit there by the MVC logic. Otherwise MVC doesn't really tell you where to put your security level...although the security issues are caused by the view rendering (HTML)

    3) Thx, I had a look and now use the Ext.String.addCharacterEntities({"code":"char"}) function to add further mappings. You just added "/" to these encoding pairs, but why not to encode more charcters?

    4) I use an extended table class for all my trees andd grids and put the encoding function at the right places. ON the other hand all tables and data view use templates again and the renderers are just inerceptor methods. Again...wouldn't it make more sense to centrally tweak the TEMPLATE rendering and out the encoding there?

    Thx for the github link...I'm looking into this right now :-)