Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9E936200C18 for ; Sat, 11 Feb 2017 16:31:46 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 92F93160B51; Sat, 11 Feb 2017 15:31:46 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DB966160B4A for ; Sat, 11 Feb 2017 16:31:45 +0100 (CET) Received: (qmail 6723 invoked by uid 500); 11 Feb 2017 15:31:44 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 6712 invoked by uid 99); 11 Feb 2017 15:31:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Feb 2017 15:31:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 53305180B10 for ; Sat, 11 Feb 2017 15:31:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id dwFk_G60Gf62 for ; Sat, 11 Feb 2017 15:31:43 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 5DDA65FD3B for ; Sat, 11 Feb 2017 15:31:43 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id A9B80E0436 for ; Sat, 11 Feb 2017 15:31:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id B1C2321D67 for ; Sat, 11 Feb 2017 15:31:41 +0000 (UTC) Date: Sat, 11 Feb 2017 15:31:41 +0000 (UTC) From: "Rob Tompkins (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (TEXT-42) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sat, 11 Feb 2017 15:31:46 -0000 [ https://issues.apache.org/jira/browse/TEXT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862424#comment-15862424 ] Rob Tompkins commented on TEXT-42: ---------------------------------- I'm fairly neutral on new methods. I doubt adding something named "secureFoo" would ever be reasonable because it's the virtue of the name seems to indicate that it's entirely secure. Whereas, that seems difficult to achieve because security is determined by the usage context. Sebb's point: bq. I guess the question is: would using hex-encoding for all but alphanumeric characters break any scripts? seems reasonable, maybe we could implement such a method named something like "escapeEcmaWithHexEncodingsScript" after some exploration has been done to resolve that question. > [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript? > ------------------------------------------------------------------ > > Key: TEXT-42 > URL: https://issues.apache.org/jira/browse/TEXT-42 > Project: Commons Text > Issue Type: Bug > Reporter: Andy Reek > Labels: XSS > Fix For: 1.x > > > org.apache.commons.lang3.StringEscapeUtils.escapeEcmaScript does the escape via a prefixed '\' on all characters which must be escaped. I am not sure if this is really secure, if am looking at the comments on https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_JavaScript_Data_Values. They say it is possible to do an attack by escape the escape. I tested this with the string '\"' and the output was '\\\"'. Is this really ecma-/java-script secure? Or is it better to use the implementation used by OWASP? -- This message was sent by Atlassian JIRA (v6.3.15#6346)