Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts

    Question About scripting attacks...

    SEEKING: comments from anyone with something valuable to contribute.

    ISSUE: escape() and unescape() are deprecated, HTMLEncode() is strictly a server-side implementation, and I am considering options of mitigating scripting attack risks via client-side scripting.

    DETAILS: an app takes user input and embeds it into an XML tag prior to uploading it to DB. the app is required to encode <, > and ". Converting these symbols to entities is preferred, so encodeURI(), encodeURIComponent() and escape() are not my first choice, even if effective in mitigating attacks.

    THE BRASS TACKS: what are the advantages and disadvantages in customizing JavaScript Object.HTMLEncode() and Object.HTMLDecode() functions that will simply convert <, > and " to/from their entity references, versus sticking with existing native JavaScript functions? What are considered to be "industry best practices"? Please keep this discussion within the context of client-side JavaScript, security and performance.

    Many thanks.

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,602
    Thanks
    78
    Thanked 4,387 Times in 4,352 Posts
    Wrong forum. This should be in the general JavaScript forum, I think. It has nothing to do with either JSON or the DOM.

    And as I said, encodeURI, encodeURIComponent, and escape are all completely wrong solutions, as they convert (for example) < to %3C instead of to the &lt; that is required by XML.

    And I don't think you would want Object.HTMLEncode, in any case. Since you say you want to produce XML from (presumably) a tree of objects, you would presumably do it with an object-to-xml method, and I think you will find that all browser can do that for you.
    Code:
    For Internet Explorer:
    var string = xmlNode.xml;
    For others:
    var string = (new XMLSerializer()).serializeToString(xmlNode);
    where of course xmlNode can be a root node of an entire tree to be converted to XML string.

    And I'm pretty darned sure that either of those will happily handle encoding the needed entities.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    apologies if i missed the correct forum, i only saw four (DOM and JSON scripting, Ajax and Design, JavaScript frameworks and Post a JavaScript), and this looked most likely.

    i'm afraid that my issue has nothing to do with serialization.

    writing a script that will convert characters to entities is simple. I posted this thread to inquire about options and current industry standards. Always wise to look for options before implementing a decision that may become a future dependency.

    basically, my question is to all readers here who mitigate scripting attack risk on the client side, what is your preferred method, and why?

  • #4
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    Quote Originally Posted by sbhmf View Post
    basically, my question is to all readers here who mitigate scripting attack risk on the client side, what is your preferred method, and why?
    client side scripting has nothing to do with XSS attacks. i know that sounds funny, but it's true. XSS results from a failure of the server that saves and re-distributes user-entered data without sanitizing it correctly.

    simply put, a hacker won't abuse your web page to inject js into your comment form, he will simply use a curl script that ignores any javascript on the page.

    in theory, using ajax, it might be possible to filter XSS from user-entered data, but the page would not work without JS, the content would be invisible to search engines by default, and you would have to maintain your scrubber code as new escape sequences and attack patterns are developed.

    usually, the raw values don't show up from ajax, they hide in a <title> tag on an items view page, or in the title attrib of a list view. again, this points to the fact that the issue is in the html delivered by the server, not the js code itself. by the time any of your js executes, it's already too late...


    EDIT:
    just to be clear: the bottom line is that you MUST sanitize your data on the server, not using client-side javascript.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #5
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    I've not seen this before, and though my brief 3-hour search on curl is terribly insufficient I have not seen anything that that threatens the integrity of the server, db or client in my specific scenario (as defined in my opening post in the details section). [Note that I believe that the server and db are not vulnerable because the server never deserializes the xml tag, it only drops it as a blob/clob into the db via sproc, and hence it will never execute. MY concern is about what happens when the xml stream is desrialized on the client.] Please elaborate and if possible point me to a resource where such an attack is clearly explained, so that I may adequately prepare for it. Thanks.

    On another note, my question also addressed performance. Specifically, if I were do define an HTML encoding function then there are many ways to do it, and I prefer to rely as much as possible on native js functions because they run on binary which is much more efficient. Please compare the following two options, neither of which will outperform a replacement done in binary, and offer any comments on options for enhanced performance using client-side js:

    /*reads the string 3 times:*/
    function encodeHtml(Value){
    return Value.replace('<', "&lt;').replace('>', "&gt;').replace('"', "&quote;');
    }

    /*reads the string once:*/
    function encodeHtmlInput(Value){
    var tmp='';
    for(var i=0; i<Value.length; i++)
    tmp+= Value[i]=='<'?'&lt;':Value[i]=='>'?'&gt;':Value[i]=='"'?'&quote;':Value[i];
    return tmp;
    }
    Last edited by sbhmf; 01-09-2013 at 09:06 PM. Reason: fixed typo

  • #6
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    well its you three vs. myself one, so I'm obviously missing something and will need to research this some more.

    Meanwhile, thank you all for responding... it ain't over yet.

    Anyone else with something to offer is equally appreciated.

  • #7
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Validating ALL user inputs on the server before doing anything else with them will take care of most security issues - that way the attack can only be made using fields that can validly contain something that could be misinterpreted as code.

    Next keep the data separate from code as much as possible - for example use prepare and bind statements for database access instead of query.

    Finally where data can't be kept separate from the code (such as inserting into HTML) that's where you need to escape the data so that it can't be misinterpreted as being a part of the code.

    Defense in Depth means that you might do all of these even on fields where there is no possibility of the field ever containing anything harmful after the validation step just in case someone finds a hole in your validation.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #8
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    Thanks to you too Stephen,

    Perhaps you can help me understand the vulnerability in my case.

    I upload an xml stream as a string to the server, and without deserializing or executing the stream the server packs it into the db via stored procedure. Later, when the stream is requested, it is pulled from the db via stored procedure and sent to the client, again without deserializing or executing it. How could that possibly compromise the server or db?

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by sbhmf View Post
    packs it into the db via stored procedure.
    The code in the stored procedure would be what you'd need to look at with regard to vulnerabilities - if there was something harmful in the XML could it be misinterpreted as code for the stored procedure to run instead of saving?
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    I concur, and it's not likely since one sproc does nothing but put it in a cell, and the other does nothing but pull it out of the cell and send it back to the web server for direct delivery to the client.

    As far as I can see the vulnerability is with the client, since embedded scripts will break application integrity on the client side, and possibly cause harm to other users who view the content if it is not adequately scrubbed. I suppose one issue under discussion is whether or not encoding the HTML on the client prior to uploading it is sufficient to inhibit scripting attacks, and so far I'm outnumbered three to one here, the three asserting that it is not sufficient. I am not convinced because a user's input must be able to circumvent the JavaScript encoding process from adequately scrubbing executable code, and only an unstable system would possibly allow that.

    Any thoughts on this?
    Last edited by sbhmf; 01-10-2013 at 08:12 AM.

  • #11
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by sbhmf View Post
    I suppose one issue under discussion is whether or not encoding the HTML on the client prior to uploading it is sufficient to inhibit scripting attacks
    NEVER encode HTML when it is input - that would make it unusable for any purpose other than displaying in an HTML page. The time to encode HTML is when actually adding it to an HTML web page that you want to display it.

    For example: You would save the < characters as < in the database and only convert them to &lt; when outputting HTML.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #12
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    Quote Originally Posted by sbhmf View Post
    I upload an xml stream as a string to the server, and without deserializing or executing the stream the server packs it into the db via stored procedure. Later, when the stream is requested, it is pulled from the db via stored procedure and sent to the client, again without deserializing or executing it. How could that possibly compromise the server or db?
    strictly speaking, and depending upon how the input is passed to mysql, it won't, but that's not the issue here.

    there are two common patterns you need to defend against: SQL injection, and XSS, both of which rely upon the server validation routine to prevent. Someone can disable client-side javascript and it's validation, or use something besides a browser to launch the attack.

    SQL injections CAN damage your DB eg: "drop table customers". typically, it happens from using php templates to build SQL statements by naively moving POST fields into VALUES statements.


    XSS on the other hand has no deleterious effect on the server itself; it's about stealing authentication cookies or driving traffic to another site by embedding malicious redirects. Even error pages are useful for this because they often echo back the submitted data. If you are using GET, that screen is linkable and most users will trust about any link coming from a site they know and love.


    you can use <textarea>s and ajax to show non-html text without any risk of XSS.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #13
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    Thank you all for the great feedback. Your responses speak to the heart of some important security issues that are addressed at design-time based on application requirements.

    The app's architecture uses nonces (encrypted, non-sequential rotating keys) that are validated upon every request using https, so interacting with the system from outside the app is quite useless (Not discussing DOS-type attacks here...). Multiple, sequential invalid requests summarily terminate the session and suspend the IP address (or the user's proxy address) for a limited time.

    Within the app all db operations are executed via stored procedures, and embedded SELECT statements are not possible, so SQL injections are quite unlikely.

    Speaking of the client layer, if JavaScript is disabled then the app will not instantiate (including a <NOSCRIPT> message), and app interaction is not possible since AJAX, the sole app-interaction method, is thus disabled.

    Client-side, the app may be compared to an application that publishes poems. A user types a poem into a textarea and submits it. Upon submission, a js AJAX call retrieves a binary unique ID from the db (transformed into base64), then embeds it into an XML tag which contains the submitted poem in addition to some metadata such as the title, formatting instructions and other data. The db stores the xml tag in a simple table with about five fields (binary id, date created, last accessed, xml tag containing the poem, userId who owns the poem).

    The xml tag is retrieved in its entirety from the db, and is only processed on the browser (understand now why I need to maintain the XML's angle brackets while HTML-encoding those that are in the tag's value). In view mode the xml tag is available to public and is simply parsed by the browser and it's poem is displayed via xsl transformation and/or CSS. In edit mode the tag is parsed by js and its content embedded into INPUTs and TEXTAREAs.

    Regarding security in such an application, I am concerned with malicious scripts that interfere with usability (and certainly securtiy) while in view mode, and less concerned with usability in edit mode (let the user who is screwing around go scr*w himself lol).

    ...which brings us around to encoding angle brackets and quotes as entity references in order to protect viewers. If I appear to have overlooked anything then I would thank you for pointing it out.

    ...also, this bring us back to a discussion on the most efficient and effective way to encode/decode the entity references. Native js functions are executed in js' native low-level language, and thus execute more efficiently than interpreted functions that parse text. If a native js function can get this done then I would like to know about it, otherwise, what is the best option for performance?

  • #14
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    js performance is not a concern for this application, they will both encode a poem in less than a milisecond on an iphone3...

    BUT, simply replacing the angles and quotes is nowhere near enough scrubbing!

    depending on the xsl used, you could end up duplicating any/all tags and attribs submitted by the uploader. many of these are vectors: onmouseover for example. also, these chars can be escaped in myriad ways. i've seen attacks in some contexts that use nothing but digits. there's octal and utf encoding, malformed tags, all sorts of goodies. check the "xss cheatsheet" for details.


    your editing setup sounds safe, but your view setup sounds open to xss attacks, even if you XML escape the quotes and angle brackets.

    i recommend a char whitelist, [\w\s\-$=,.!?'"()@%+], or something like that. remove anything not needed for your app and force plain-ascii formatting. this can be just plain text of markdown or bbcode, but not HTML. you turn the low-level markup into pretty HTML at the last second on the client...

    make sure you parse the XML BEFORE you scrub it to defeat tricky escape routines.
    this should all be done before any HTML is set or it's fed to XSL.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • Users who have thanked rnd me for this post:

    sbhmf (01-12-2013)

  • #15
    Regular Coder
    Join Date
    Jan 2013
    Location
    Sunnyvale, CA
    Posts
    104
    Thanks
    6
    Thanked 7 Times in 7 Posts
    I concur with your assertions about the performance, though I might as well do it right on principle.

    I'll need to spend more time reviewing xhtml xss cheat sheets, though I prefer books and tomes . Any in particular that you might recommend?


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •