Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bvG5y-0002ri-6s for pgadmin-hackers@arkaria.postgresql.org; Sat, 15 Oct 2016 03:57:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bvG5x-0007Wh-Pn for pgadmin-hackers@arkaria.postgresql.org; Sat, 15 Oct 2016 03:57:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bvG5k-0007IN-Ek for pgadmin-hackers@postgresql.org; Sat, 15 Oct 2016 03:57:00 +0000 Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bvG5g-0006Q8-0e for pgadmin-hackers@postgresql.org; Sat, 15 Oct 2016 03:56:59 +0000 Received: by mail-it0-x232.google.com with SMTP id 4so7916380itv.0 for ; Fri, 14 Oct 2016 20:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JfK0cMMnHdI/EOaUkBTdQq5Fe4szjVIlLaGn3H09u7c=; b=Q4NxC6qyGNo4aKnFFlMzRFpTpqL6S8JI69xEwUBAc0ELraAQB6JLQYKsnNnCxTnrlo eISCmVUZT+4+gvbJjDACyHVBpXHMIH7uP/qvB6LVpFXozk8dzEuskOa4hzMw65eWaGrP 8lPhD0eboRK0bqoO8/P0uBlEMkJkGwdHJtHpy4Dn8vDaDoTu+a4dE3ki5K1wqJxFmo3M A0nNqFsuKG10BSYr4DzUh0bEgSiP/S2UtQVpNt1pWrBwyl40bHIIEs/BKULRaSePD6tS LbbcmU7SK8/1SuCP8snihsN4VyUxJ2SdYjxWvEmrUsRoOXXL8+PH8LDVazArjrxIdY36 bVLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JfK0cMMnHdI/EOaUkBTdQq5Fe4szjVIlLaGn3H09u7c=; b=ZuX7biPIGF7Us+b+c8Ikv9uZCV6uc1QH//kVBiGHMO55oGCH/yxE2i2ke0LvczNpZE ycAX1wKZ6xWiD3SKOuvvlYAEGH88X69TgbNtSi3Qp4VOUnKECBjHZbBSsi9CoJbJethI nJRuKWwn/Wiyt2YRLoyuzG5B0Rjt03p9Og+jxPYV5ctDXaJo7ZpMo9No2jsHh21AOdus RDhxy9sBVF5EvmvzkSLK7YQn8sNslOVGUgnR1hkILyey0/xtiHgijQj2T0lDaB8KUNmj zTfvGBjUy/E1afr0eLhZXttnfzRVY3Y4hNIOG06RTryGkQrDhNlCw2dfupVVmn7+Ot/5 O8cg== X-Gm-Message-State: AA6/9RmWpq9QVnltHBvrwSlYFfPpwJh4YjDnXk5vlSQ5QO4KakL8a1FQDoX+XNaJ8lij8yKNAXizVPo03TwFv3RZ X-Received: by 10.36.3.3 with SMTP id e3mr483587ite.57.1476503813762; Fri, 14 Oct 2016 20:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.139 with HTTP; Fri, 14 Oct 2016 20:56:33 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Sat, 15 Oct 2016 09:26:33 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]: Fixed RM 1603 & RM 1220 To: Dave Page Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a1144968454485c053edf5569 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a1144968454485c053edf5569 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 15, 2016 at 4:59 AM, Dave Page wrote: > Hi > > On Friday, October 14, 2016, Khushboo Vashi com> wrote: > >> Hi, >> >> Please find the attached patch to fix the below 2 bugs. >> >> RM 1603: [Web Based] Export database failed if object contains double >> quotes. >> RM 1220: Backup database is not working with special characters >> >> The issues which were fixed: >> >> 1. Client side data were not unescaped >> 2. Required command line arguments were quoted twice >> > > This is not working for me: I tested using Table Export as per Fahar's > instructions. As I'm in desktop mode, the first problem was that we get an > error at line 210 of import_export/__init__.py, because > get_server_directory returned None for the directory. If I fix that, then > the job says it's created, but as far as I can see, nothing else happens. > hmm.. > > Secondly, this patch seems to push quoting responsibilty to the front end. > No - that's not the case, we're using _.escape(..) function on the node's label to fix the issue of XSS vulnerability on client side. Hence - during sending back the data, we're using _.unescape(..) function to return the same data coming sent by the server. Though - IIRC - we have a original label stored in another variable '_label', which we can use it instead of unescape it again. > This doesn't seem right, because we might want to use the RESTful APIs for > another purpose in the future, which would mean needing to re-implement > quoting if something else uses an affected API. > As I explained above, it wont affect the RESTful API. -- Thanks & Regards, Ashesh Vashi > > Thanks. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > --001a1144968454485c053edf5569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 15, 2016 at 4:59 AM, Dave Page <dpage@pgadmin.org>= wrote:

Hi
On Friday, October 14, 2016, Khushboo Vashi <khushboo.vashi@enterprisedb= .com> wrote:
Hi,

Please find the attached patch t= o fix the below 2 bugs.

RM 1603:=C2=A0[Web Based] = Export database failed if object contains double quotes.
RM=C2=A0= 1220: Backup database is not working with special characters

=
The issues which were fixed:

1. Client = side data were not unescaped
2. Required command line arguments w= ere quoted twice=C2=A0

T= his is not working for me: I tested using Table Export as per Fahar's i= nstructions. As I'm in desktop mode, the first problem was that we get = an error at line 210 of import_export/__init__.py, because get_server_direc= tory returned None for the directory. If I fix that, then the job says it&#= 39;s created, but as far as I can see, nothing else happens.
hmm..=C2=A0

Secondly, this patch seems to push quoting responsibil= ty to the front end.
No - that's not the case, w= e're using _.escape(..) function on the node's label to fix the iss= ue of=C2=A0XSS=C2=A0vuln= erability on client side.
Hence - during sending back the = data, we're using _.unescape(..) function to return the same data comin= g sent by the server.

Though - IIRC - we have a or= iginal label stored in another variable '_label', which we can use = it instead of unescape it again.=C2=A0
This doesn't seem right, because we might want= to use the RESTful APIs for another purpose in the future, which would mea= n needing to re-implement quoting if something else uses an affected API.
As I explained above, it wont affect the RESTful API.=

--
<= div>Thanks & Regards,

Ashesh Vashi

Thanks.


--
Dave Page
Blog: http://pgsnake.blogspot.comTwitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterpris= e PostgreSQL Company


--001a1144968454485c053edf5569--