From Massimo.Forni at turboden.it Wed Jun 2 17:26:05 2021 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Wed, 2 Jun 2021 16:26:05 +0000 Subject: [ZendTo] Not use before? In-Reply-To: References: <41865b09-c38f-eb4b-8a76-b00b16b87c54@Zend.To>

, Message-ID: Hello Jules, this did not fixed the issue :( Any ideas ? ________________________ Live long and prosper ________________________________ From: Jules Sent: Friday, May 28, 2021 10:27:16 AM To: Massimo Forni ; ZendTo Users Subject: Re: [ZendTo] Not use before? You might need to clear the cache of compiled templates: sudo rm -f /var/zendto/templates_c/*php Cheers, Jules. On 28/05/2021 08:53, Massimo Forni wrote: Hello Jules, So sorry for the late reply. I applied your fix, but the issue persists. The target of the request need to wait 60 minutes to start dropping the files Than k you ________________________________ From: Jules Sent: Monday, May 17, 2021 13:25 To: ZendTo Users Cc: Massimo Forni Subject: Re: [ZendTo] Not use before? Hi Massimo, Yes, you're absolutely right. I was trying to solve the problem of the user creating the request being East of the server's timezone, and accidentally created a problem if the user is West of the server's timezone. The simple fix to this, if you want to patch your server manually, is to edit /opt/zendto/templates/request.tpl and change line 310 from minDate: 0, // Disallow dates in the past to minDate: -1, // Start at yesterday to avoid timezone problems That should be the only change required. This fix will be in the next release. Cheers, Jules. On 11/05/2021 11:13, Massimo Forni via ZendTo wrote: I see in the "reqtable" there is a column "Start" with a timestamp that is set to the date+time of the locale of the end user In this case it has been set to 1620728545 which is at 10:22:25 UTC The user created the request at 12:22:xx of his local time (09:22:xx UTC) I suspect there is some timezone miss-calculation somewhere ________________________________ From: ZendTo

Message-ID: Massimo, The fix was a little more complicated than I thought. I've just tested my new fix and it seems to work and look okay. Please try the latest beta release 6.10-7 which you can download from ????? https://zend.to/beta That should solve it. Please do let me know how you get on, I would like to do a production release as soon as possible. Cheers, Jules. On 02/06/2021 17:26, Massimo Forni wrote: > Hello Jules, this did not fixed the issue :( > Any ideas ? > > > > ________________________ > > Live long and prosper? > > > ------------------------------------------------------------------------ > *From:* Jules > *Sent:* Friday, May 28, 2021 10:27:16 AM > *To:* Massimo Forni ; ZendTo Users > > *Subject:* Re: [ZendTo] Not use before? > ? > You might need to clear the cache of compiled templates: > ?????? sudo rm -f /var/zendto/templates_c/*php > > Cheers, > Jules. > > On 28/05/2021 08:53, Massimo Forni wrote: >> Hello Jules, >> >> So sorry for the late reply. >> >> I applied your fix, but the issue persists. >> The target of the request need to wait 60 minutes to start dropping >> the files >> >> Than k you >> ------------------------------------------------------------------------ >> *From:* Jules >> *Sent:* Monday, May 17, 2021 13:25 >> *To:* ZendTo Users >> *Cc:* Massimo Forni >> >> *Subject:* Re: [ZendTo] Not use before? >> ? >> Hi Massimo, >> >> Yes, you're absolutely right. I was trying to solve the problem of >> the user creating the request being East of the server's timezone, >> and accidentally created a problem if the user is West of the >> server's timezone. >> >> The simple fix to this, if you want to patch your server manually, is >> to edit >> ?????? /opt/zendto/templates/request.tpl >> and change line 310 from >> ?????? minDate: 0, // Disallow dates in the past >> to >> ?????? minDate: -1, // Start at yesterday to avoid timezone problems >> >> That should be the only change required. >> >> This fix will be in the next release. >> >> Cheers, >> Jules. >> >> On 11/05/2021 11:13, Massimo Forni via ZendTo wrote: >>> I see in the "reqtable" there is a column "Start" with a timestamp >>> that is set to the date+time of the locale of the end user >>> >>> In this case it has been set to??1620728545 which is at 10:22:25 UTC >>> The user created the request at 12:22:xx of his local time (09:22:xx >>> UTC) >>> >>> I suspect there is some timezone miss-calculation somewhere >>> ------------------------------------------------------------------------ >>> *From:* ZendTo >>> on behalf of Massimo Forni via >>> ZendTo >>> *Sent:* Tuesday, May 11, 2021 11:47 >>> *To:* zendto at zend.to >>> >>> *Cc:* Massimo Forni >>> >>> *Subject:* [ZendTo] Not use before? >>> ? >>> Hello, >>> >>> I have some strange issue with the latest build. >>> If a user with a different timezone (ahead of mine, in this case 1 >>> hour) uses the "Request a Drop-off" and I click on the link I am >>> presented the following error: >>> >>> >>> Could it be that when zendto generates the link for the request it >>> sets a "not use before" field with the users local time? >>> >>> -- >>> >>> *Massimo Forni* >>> ICT Manager >>> >>> Mobile: +393474110278 >>> >>> ------------------------------------------------------------------------ >>> >>> *Turboden S.p.A.* *I* via Cernaia 10 *I* 25124 Brescia *I* Italy >>> t. +39 030 3552001 *I* f. +39 030 3552011 >>> www.turboden.com >>> >>> >>> *Confidentiality notice*: this message, together with its >>> attachments, may contain strictly confidential and/or legally >>> privileged information and it is destined solely to the intended >>> addressee(s), who only may use it under his/their responsibility. >>> Opinions, conclusions and other information contained in this >>> message, that do not relate to the official business of this firm, >>> shall be considered as not given or endorsed by it. If you have >>> received this communication in error, please notify us immediately >>> by responding to this email and then delete it from your system. Any >>> use, disclosure, copying or distribution of the contents of this >>> communication by a not-intended recipient or in violation of the >>> purposes of this communication is strictly prohibited and may be >>> unlawful. >>> >>> -- >>> >>> *Massimo Forni* >>> ICT Manager >>> >>> Mobile: +393474110278 >>> >>> ------------------------------------------------------------------------ >>> >>> *Turboden S.p.A.* *I* via Cernaia 10 *I* 25124 Brescia *I* Italy >>> t. +39 030 3552001 *I* f. +39 030 3552011 >>> www.turboden.com >>> >>> >>> *Confidentiality notice*: this message, together with its >>> attachments, may contain strictly confidential and/or legally >>> privileged information and it is destined solely to the intended >>> addressee(s), who only may use it under his/their responsibility. >>> Opinions, conclusions and other information contained in this >>> message, that do not relate to the official business of this firm, >>> shall be considered as not given or endorsed by it. If you have >>> received this communication in error, please notify us immediately >>> by responding to this email and then delete it from your system. Any >>> use, disclosure, copying or distribution of the contents of this >>> communication by a not-intended recipient or in violation of the >>> purposes of this communication is strictly prohibited and may be >>> unlawful. >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto [jul.es] >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'When a man points a finger at someone else, he should remember >> that four of his fingers are pointing at himself.' - Louis Nizer >> >> www.Zend.To [zend.to] >> Twitter: @JulesFM >> >> -- >> >> *Massimo Forni* >> ICT Manager >> >> Mobile: +393474110278 >> >> ------------------------------------------------------------------------ >> >> *Turboden S.p.A.* *I* via Cernaia 10 *I* 25124 Brescia *I* Italy >> t. +39 030 3552001 *I* f. +39 030 3552011 >> www.turboden.com >> >> >> *Confidentiality notice*: this message, together with its >> attachments, may contain strictly confidential and/or legally >> privileged information and it is destined solely to the intended >> addressee(s), who only may use it under his/their responsibility. >> Opinions, conclusions and other information contained in this >> message, that do not relate to the official business of this firm, >> shall be considered as not given or endorsed by it. If you have >> received this communication in error, please notify us immediately by >> responding to this email and then delete it from your system. Any >> use, disclosure, copying or distribution of the contents of this >> communication by a not-intended recipient or in violation of the >> purposes of this communication is strictly prohibited and may be >> unlawful. >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'When a man points a finger at someone else, he should remember > that four of his fingers are pointing at himself.' - Louis Nizer > > www.Zend.To [zend.to] > Twitter: @JulesFM > > -- > > *Massimo Forni* > ICT Manager > > Mobile: +393474110278 > > ------------------------------------------------------------------------ > > *Turboden S.p.A.* *I* via Cernaia 10 *I* 25124 Brescia *I* Italy > t. +39 030 3552001 *I* f. +39 030 3552011 > www.turboden.com > > > *Confidentiality notice*: this message, together with its attachments, > may contain strictly confidential and/or legally privileged > information and it is destined solely to the intended addressee(s), > who only may use it under his/their responsibility. Opinions, > conclusions and other information contained in this message, that do > not relate to the official business of this firm, shall be considered > as not given or endorsed by it. If you have received this > communication in error, please notify us immediately by responding to > this email and then delete it from your system. Any use, disclosure, > copying or distribution of the contents of this communication by a > not-intended recipient or in violation of the purposes of this > communication is strictly prohibited and may be unlawful. > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Do not go gentle into that good night, Old age should burn and rave at close of day; Rage, rage against the dying of the light. Though wise men at their end know dark is right, Because their words had forked no lightning they Do not go gentle into that good night. Good men, the last wave by, crying how bright Their frail deeds might have danced in a green bay, Rage, rage against the dying of the light. Wild men who caught and sang the sun in flight, And learn, too late, they grieved it on its way, Do not go gentle into that good night. Grave men, near death, who see with blinding sight Blind eyes could blaze like meteors and be gay, Rage, rage against the dying of the light. And you, my father, there on the sad height, Curse, bless, me now with your fierce tears, I pray. Do not go gentle into that good night. Rage, rage against the dying of the light.' - Dylan Thomas www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 94307 bytes Desc: not available URL: From Massimo.Forni at turboden.it Thu Jun 3 13:37:10 2021 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Thu, 3 Jun 2021 12:37:10 +0000 Subject: [ZendTo] Not use before? In-Reply-To: References: <41865b09-c38f-eb4b-8a76-b00b16b87c54@Zend.To>

, Message-ID: Dear Jules, Is there a way to have the patch for only this issue? I don't have a test environment and I am not sure about installing the beta on top of our zendto installation, what if something does not work? ? ________________________________ From: Jules Sent: Thursday, June 3, 2021 12:04 To: Massimo Forni ; ZendTo Users Subject: Re: [ZendTo] Not use before? Massimo, The fix was a little more complicated than I thought. I've just tested my new fix and it seems to work and look okay. Please try the latest beta release 6.10-7 which you can download from https://zend.to/beta [zend.to] That should solve it. Please do let me know how you get on, I would like to do a production release as soon as possible. Cheers, Jules. On 02/06/2021 17:26, Massimo Forni wrote: Hello Jules, this did not fixed the issue :( Any ideas ? ________________________ Live long and prosper ________________________________ From: Jules Sent: Friday, May 28, 2021 10:27:16 AM To: Massimo Forni ; ZendTo Users Subject: Re: [ZendTo] Not use before? You might need to clear the cache of compiled templates: sudo rm -f /var/zendto/templates_c/*php Cheers, Jules. On 28/05/2021 08:53, Massimo Forni wrote: Hello Jules, So sorry for the late reply. I applied your fix, but the issue persists. The target of the request need to wait 60 minutes to start dropping the files Than k you ________________________________ From: Jules Sent: Monday, May 17, 2021 13:25 To: ZendTo Users Cc: Massimo Forni Subject: Re: [ZendTo] Not use before? Hi Massimo, Yes, you're absolutely right. I was trying to solve the problem of the user creating the request being East of the server's timezone, and accidentally created a problem if the user is West of the server's timezone. The simple fix to this, if you want to patch your server manually, is to edit /opt/zendto/templates/request.tpl and change line 310 from minDate: 0, // Disallow dates in the past to minDate: -1, // Start at yesterday to avoid timezone problems That should be the only change required. This fix will be in the next release. Cheers, Jules. On 11/05/2021 11:13, Massimo Forni via ZendTo wrote: I see in the "reqtable" there is a column "Start" with a timestamp that is set to the date+time of the locale of the end user In this case it has been set to 1620728545 which is at 10:22:25 UTC The user created the request at 12:22:xx of his local time (09:22:xx UTC) I suspect there is some timezone miss-calculation somewhere ________________________________ From: ZendTo

on behalf of Massimo Forni via ZendTo Sent: Tuesday, May 11, 2021 11:47 To: zendto at zend.to Cc: Massimo Forni Subject: [ZendTo] Not use before? Hello, I have some strange issue with the latest build. If a user with a different timezone (ahead of mine, in this case 1 hour) uses the "Request a Drop-off" and I click on the link I am presented the following error: [cid:part1.la8wcjbZ.7aJTn9nv at Zend.To] Could it be that when zendto generates the link for the request it sets a "not use before" field with the users local time? -- Massimo Forni ICT Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- Massimo Forni ICT Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto [jul.es] Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'When a man points a finger at someone else, he should remember that four of his fingers are pointing at himself.' - Louis Nizer www.Zend.To [zend.to] Twitter: @JulesFM -- Massimo Forni ICT Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'When a man points a finger at someone else, he should remember that four of his fingers are pointing at himself.' - Louis Nizer www.Zend.To [zend.to] Twitter: @JulesFM -- Massimo Forni ICT Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Do not go gentle into that good night, Old age should burn and rave at close of day; Rage, rage against the dying of the light. Though wise men at their end know dark is right, Because their words had forked no lightning they Do not go gentle into that good night. Good men, the last wave by, crying how bright Their frail deeds might have danced in a green bay, Rage, rage against the dying of the light. Wild men who caught and sang the sun in flight, And learn, too late, they grieved it on its way, Do not go gentle into that good night. Grave men, near death, who see with blinding sight Blind eyes could blaze like meteors and be gay, Rage, rage against the dying of the light. And you, my father, there on the sad height, Curse, bless, me now with your fierce tears, I pray. Do not go gentle into that good night. Rage, rage against the dying of the light.' - Dylan Thomas www.Zend.To [zend.to] Twitter: @JulesFM -- Massimo Forni ICT Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 94307 bytes Desc: image.png URL: From liam.gretton at leicester.ac.uk Fri Jun 18 08:43:40 2021 From: liam.gretton at leicester.ac.uk (Gretton, Liam) Date: Fri, 18 Jun 2021 07:43:40 +0000 Subject: [ZendTo] Incoming folder filling up References: Message-ID: Hi, I've only just noticed that over the last few months the Filedrop incoming folder has accumulated hundreds of files. The files in question don't appear to match what's in the dropoff area (obviously those older than a couple of weeks are no longer dropoffs anyway). Therefore I guess these left-over files are a result of interrupted or abandoned uploads. Does Filedrop have a mechanism for clearing up the incoming folder? I'm not sure of the mechanism for recognising a completed upload and turning it into a dropoff, and how this could go wrong. The start of the problem roughly coincides with the point that AV (not ClamAV) was installed on the server: could the AV be locking the file and preventing Filedrop from deleting it? If there's not an existing mechanism to clean this folder up I'll create a simple cron job to delete old files there. Would I be right in thinking that there should only ever be in-flight uploads present there? I'm still on 6.03-5, planning to upgrade over the summer. Thanks, Liam Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D7641E.08C2A750] Follow us on Twitter or visit our Facebook page -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: image001.gif URL: From zend.to at neilzone.co.uk Mon Jun 21 10:06:08 2021 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Mon, 21 Jun 2021 10:06:08 +0100 Subject: [ZendTo] Upgrade to beta: clamav not working References: <9572AF6B-233C-4307-ACEA-4C614D110BDC@neilzone.co.uk> Message-ID: Hello Jules I?ve just tried upgrading to the beta version of zend.to, and I have run into a problem I am struggling to fix. I?m not sure if it is related to the beta or not but, since the service worked last time I used it, I?m not sure what else it might be. Application error: "The attempt to virus-scan your drop-off failed. Please notify the system administrator.? /var/zendto/zendto.log: ?could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory" systemctl status clamav-daemon.service: "^lchown to user 'clamav' failed on log file '/var/log/clamav/clamav.log'. Error was 'Operation not permitted? I?ve had a brief look online, and I can?t find any obvious reason for this, or indeed anything suggesting it is a broader clamav issue. I?m accepting it might be me rather than zend.to but, if you?ve any thoughts, they would be greatly appreciated. Best wishes Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Mon Jun 21 10:20:15 2021 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Mon, 21 Jun 2021 10:20:15 +0100 Subject: [ZendTo] Upgrade to beta: clamav not working In-Reply-To: <9572AF6B-233C-4307-ACEA-4C614D110BDC@neilzone.co.uk> References: <9572AF6B-233C-4307-ACEA-4C614D110BDC@neilzone.co.uk> Message-ID: > On 21 Jun 2021, at 10:06, zend.to at neilzone.co.uk wrote: > > Application error: > > "The attempt to virus-scan your drop-off failed. Please notify the system administrator.? > > > /var/zendto/zendto.log: > > ?could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory" > > > systemctl status clamav-daemon.service: > > "^lchown to user 'clamav' failed on log file '/var/log/clamav/clamav.log'. Error was 'Operation not permitted? After some further digging, it looks like it was an AppArmor issue. I updated /etc/apparmor.d/usr.sbin.clamd to have 'capability chown', as well as 'capability dac_override?, and restarted AppArmor, and it is now working. I?m not sure if this is an issue in the beta or something else on the system, but I pass it on in case it helps someone. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Mon Jun 21 14:14:06 2021 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Mon, 21 Jun 2021 14:14:06 +0100 Subject: [ZendTo] Problems uploading files to drop-off requests References: <4F4CF211-A2AC-4A28-9213-2A612290EF60@neilzone.co.uk> Message-ID: It?s not my day with the beta, is it! So far, transferring files seems fine. But drop-off requests are more problematic. I can send a drop-off request, and the recipient receives it. They can access the platform, and they can upload the files, but, after clicking ?Drop-off Files? and after the ?Uploading? window, they get a javascript error: "ZendTo upload failed: error" "Sorry, I failed to drop-off your files! Note that you cannot drop-off directories, only files? (Yes, it was two files, not a directory.) Nothing in /var/zendto/zendto.log, but I have this is my apache ssl error log: [Mon Jun 21 14:08:42.849598 2021] [proxy_fcgi:error] [pid 1387:tid 140685411809024] [client 195.254.135.76:45183] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function NSSDropbox::ReadReqData(), 11 passed in /opt/zendto/lib/NSSDropoff.php on line 2566 and exactly 12 expected in /opt/zendto/lib/NSSDropbox.php:2847\nStack trace:\n#0 /opt/zendto/lib/NSSDropoff.php(2566): NSSDropbox->ReadReqData('119128215', '', '', '', '', '', '', '', 0, 0, '')\n#1 /opt/zendto/lib/NSSDropoff.php(496): NSSDropoff->initWithFormData()\n#2 /opt/zendto/www/dropoff.php(60): NSSDropoff->__construct(Object(NSSDropbox))\n#3 {main}\n thrown in /opt/zendto/lib/NSSDropbox.php on line 2847\n' Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam.gretton at leicester.ac.uk Wed Jun 23 11:52:48 2021 From: liam.gretton at leicester.ac.uk (Gretton, Liam) Date: Wed, 23 Jun 2021 10:52:48 +0000 Subject: [ZendTo] Incoming folder filling up In-Reply-To: References: Message-ID: Hi, I've only just noticed that over the last few months the Filedrop incoming folder has accumulated hundreds of files. The files in question don't appear to match what's in the dropoff area (obviously those older than a couple of weeks are no longer dropoffs anyway). Therefore I guess these left-over files are a result of interrupted or abandoned uploads. Does Filedrop have a mechanism for clearing up the incoming folder? I'm not sure of the mechanism for recognising a completed upload and turning it into a dropoff, and how this could go wrong. The start of the problem roughly coincides with the point that AV (not ClamAV) was installed on the server: could the AV be locking the file and preventing Filedrop from deleting it? If there's not an existing mechanism to clean this folder up I'll create a simple cron job to delete old files there. Would I be right in thinking that there should only ever be in-flight uploads present there? I'm still on 6.03-5, planning to upgrade over the summer. Thanks, Liam (I first sent this to the list on June 18 but it didn't appear) Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D7641E.08C2A750] Follow us on Twitter or visit our Facebook page -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: image001.gif URL: From zend.to at neilzone.co.uk Thu Jun 24 09:54:26 2021 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Thu, 24 Jun 2021 09:54:26 +0100 Subject: [ZendTo] Potential SQL injection vulnerability? References: <40C106B1-B23C-4834-85B1-65928139A230@neilzone.co.uk> Message-ID: Hello Jules I?ve conducted an OWASP web application test against our installation of zend.to, using ZAP (https://www.zaproxy.org ). It has indicated one potential high risk, as a potential SQL injection vulnerability. Do you have any thoughts on this, and whether it is a false positive, please? Best wishes Neil Description SQL injection may be possible. URL https://filetransfer.decoded.legal/pickup.php?getdata=%5B%5D%27+AND+%271%27%3D%271&getdata=%7B%22getdata%22%3A%22%5B%5D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%5B%5D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C%5C%5C%22%3A%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%7B%5C%5C%5C%22getdata%5C%5C%5C%22%3A%5C%5C%5C%22%5B%5D%5C%5C%5C%22%2C%5C%5C%5C%22getput%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22goingto%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22gothere%5C%5C%5C%22%3A%5C%5C%5C%22pickup.php%5C%5C%5C%22%2C%5C%5C%5C%22locale%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22postdata%5C%5C%5C%22%3A%5C%5C%5C%22%7B%5C%5C%5C%5C%5C%5C%5C%22auth%5C%5C%5C%5C%5C%5C%5C%22%3A%5C%5C%5C%5C%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%5C%5C%5C%5C%22%7D%5C%5C%5C%22%2C%5C%5C%5C%22template%5C%5C%5C%22%3A%5C%5C%5C%22claimid_box.tpl%5C%5C%5C%22%7D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C%5C%5C%22%3A%5C%5C%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getput=&goingto=&gothere=pickup.php&locale=&postdata=%7B%22auth%22%3A%22%22%7D&postdata=%7B%22auth%22%3A%2295ca1f5b66aba21cc2698ead33d03285%22%7D&postdata=%7B%22auth%22%3A%22a6d31fa9ec46a6cffb3668e43af5c28b%22%7D&template=claimid_box.tpl Method GET Parameter getdata Attack []' AND '1'='1 URL https://filetransfer.decoded.legal/pickup.php Method POST Parameter claimID Attack ZAP" AND "1"="1" -- Instances 2 Solution Do not trust client side input, even if there is client side validation in place. In general, type check all data on the server side. If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?' If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries. If database Stored Procedures can be used, use them. Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality! Do not create dynamic SQL queries using simple string concatenation. Escape all data received from the client. Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input. Apply the principle of least privilege by using the least privileged database user possible. In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact. Grant the minimum database access that is necessary for the application. Other information The page results were successfully manipulated using the boolean conditions [[]' AND '1'='1] and [[]' AND '1'='2] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 30 11:24:23 2021 From: Jules at Zend.To (Jules) Date: Wed, 30 Jun 2021 11:24:23 +0100 Subject: [ZendTo] Incoming folder filling up In-Reply-To: References: Message-ID: <57e2ceab-fe3b-e3d5-e130-a6964c870c9b@Zend.To> Hi Liam, In /etc/cron.d/zendto you should see, among other lines, a "find" command which does this: 5 */4 * * * root find -H /var/zendto/incoming -type f -mmin +1440 -delete >/dev/null 2>&1 Every 4 hours, at 5 minutes past the hour, that should delete all files in the "/var/zendto/incoming" directory that are more than 24 hours (1440 minutes) old. Check your /etc/cron.d/zendto has that line, which 6.03-5 certainly should have. Have you moved the /var/zendto/incoming directory to somewhere else? If so, fix the path in this line or ensure there is a link from /var/zendto/incoming to wherever your "incoming" directory is now. Cheers, Jules. On 23/06/2021 11:52, Gretton, Liam via ZendTo wrote: > > Hi, > > I've only just noticed that over the last few months the Filedrop > incoming folder has accumulated hundreds of files. The files in > question don't appear to match what's in the dropoff area (obviously > those older than a couple of weeks are no longer dropoffs anyway). > Therefore I guess these left-over files are a result of interrupted or > abandoned uploads. > > Does Filedrop have a mechanism for clearing up the incoming folder? > I'm not sure of the mechanism for recognising a completed upload and > turning it into a dropoff, and how this could go wrong. The start of > the problem roughly coincides with the point that AV (not ClamAV) was > installed on the server: could the AV be locking the file and > preventing Filedrop from deleting it? > > If there's not an existing mechanism to clean this folder up I'll > create a simple cron job to delete old files there. Would I be right > in thinking that there should only ever be in-flight uploads present > there? > > I'm still on 6.03-5, planning to upgrade over the summer. > > Thanks, > > Liam > > (I first sent this to the list on June 18 but it didn't appear) > > *Liam Gretton > Systems Specialist*** > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:*+44 (0)116 252 2254 > *e:*liam.gretton at leicester.ac.uk > *w:*www.le.ac.uk _ > _ > Follow us on Twitter or visit our > Facebook page > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'I have lost friends, some by death ... others through sheer inability to cross the street.' - Virginia Woolf www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: not available URL: From Jules at Zend.To Wed Jun 30 11:29:38 2021 From: Jules at Zend.To (Jules) Date: Wed, 30 Jun 2021 11:29:38 +0100 Subject: [ZendTo] Upgrade to beta: clamav not working In-Reply-To: References: <9572AF6B-233C-4307-ACEA-4C614D110BDC@neilzone.co.uk> Message-ID: <6ab5e446-73c4-b259-e477-6932cec92ff4@Zend.To> Neil, Thanks for that. You really want to put your change into ??? /etc/apparmor.d/*local/*usr.sbin.clamd or else it is likely to be overwritten by future apt upgrades. I'll add that to the Zendto Installer. Thanks! Jules. On 21/06/2021 10:20, Neil via ZendTo wrote: > > >> On 21 Jun 2021, at 10:06, zend.to at neilzone.co.uk wrote: >> >> Application error: >> >> "The attempt to virus-scan your drop-off failed. Please notify the >> system administrator.? >> >> >> /var/zendto/zendto.log: >> >> ?could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: >> No such file or directory" >> >> >> systemctl status clamav-daemon.service: >> >> "^lchown to user 'clamav' failed on log file >> '/var/log/clamav/clamav.log'. ?Error was 'Operation not permitted? > > After some further digging, it looks like it was an AppArmor issue. > > I updated?/etc/apparmor.d/usr.sbin.clamd to have 'capability chown', > as well as 'capability dac_override?, and restarted AppArmor, and it > is now working. > > I?m not sure if this is an issue in the beta or something else on the > system, but I pass it on in case it helps someone. > > > Neil > > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll sit in a boat and drink beer all day.' - Anon www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 30 11:39:35 2021 From: Jules at Zend.To (Jules) Date: Wed, 30 Jun 2021 11:39:35 +0100 Subject: [ZendTo] Problems uploading files to drop-off requests In-Reply-To: References: <4F4CF211-A2AC-4A28-9213-2A612290EF60@neilzone.co.uk> Message-ID: Sorry Neil, that was a bug in that release. It's fixed in the latest production release. Cheers, Jules. On 21/06/2021 14:14, Neil via ZendTo wrote: > It?s not my day with the beta, is it! > > So far, transferring files seems fine. > > But drop-off requests are more problematic. > > I can send a drop-off request, and the recipient receives it. They can > access the platform, and they can upload the files, but, after > clicking ?Drop-off Files? and after the ?Uploading? window, they get a > javascript error: > > "ZendTo upload failed: error" > > "Sorry, I failed to drop-off your files! > Note that you cannot drop-off directories, only files? > > (Yes, it was two files, not a directory.) > > Nothing in /var/zendto/zendto.log, but I have this is my apache ssl > error log: > > [Mon Jun 21 14:08:42.849598 2021] [proxy_fcgi:error] [pid 1387:tid > 140685411809024] [client 195.254.135.76:45183] AH01071: Got error 'PHP > message: PHP Fatal error:? Uncaught ArgumentCountError: Too few > arguments to function NSSDropbox::ReadReqData(), 11 passed in > /opt/zendto/lib/NSSDropoff.php on line 2566 and exactly 12 expected in > /opt/zendto/lib/NSSDropbox.php:2847\nStack trace:\n#0 > /opt/zendto/lib/NSSDropoff.php(2566): > NSSDropbox->ReadReqData('119128215', '', '', '', '', '', '', '', 0, 0, > '')\n#1 /opt/zendto/lib/NSSDropoff.php(496): > NSSDropoff->initWithFormData()\n#2 /opt/zendto/www/dropoff.php(60): > NSSDropoff->__construct(Object(NSSDropbox))\n#3 {main}\n? thrown in > /opt/zendto/lib/NSSDropbox.php on line 2847\n' > > > > > Neil > > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Learn from yesterday, live for today, look to tomorrow, rest this afternoon.' - Charles M Schulz www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 30 12:01:59 2021 From: Jules at Zend.To (Jules) Date: Wed, 30 Jun 2021 12:01:59 +0100 Subject: [ZendTo] Potential SQL injection vulnerability? In-Reply-To: References: <40C106B1-B23C-4834-85B1-65928139A230@neilzone.co.uk> Message-ID: <394a349b-1316-4bfd-2a32-bd64523efb73@Zend.To> Hi Neil, Curious. What I can definitely say is that "pickup.php" does not have a parameter called "getdata", so you can set that to anything you like and it shouldn't have any effect whatsoever. "changelocale.php" does, but that's not where they found any problem. And even in "changelocale.php" it isn't recognised as a GET parameter, only a POST. So again, setting it in the URL can't have any effect. So I would say this is a false positive. Cheers, Jules. On 24/06/2021 09:54, Neil via ZendTo wrote: > Hello Jules > > I?ve conducted an OWASP web application test against our installation > of zend.to, using ZAP (https://www.zaproxy.org). > > It has indicated one potential high risk, as a potential SQL injection > vulnerability. > > Do you have any thoughts on this, and whether it is a false positive, > please? > > Best wishes > > Neil > > > Description > > SQL injection may be possible. > > > URL > https://filetransfer.decoded.legal/pickup.php?getdata=%5B%5D%27+AND+%271%27%3D%271&getdata=%7B%22getdata%22%3A%22%5B%5D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%5B%5D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C%5C%5C%22%3A%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%7B%5C%5C%5C%22getdata%5C%5C%5C%22%3A%5C%5C%5C%22%5B%5D%5C%5C%5C%22%2C%5C%5C%5C%22getput%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22goingto%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22gothere%5C%5C%5C%22%3A%5C%5C%5C%22pickup.php%5C%5C%5C%22%2C%5C%5C%5C%22locale%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22postdata%5C%5C%5C%22%3A%5C%5C%5C%22%7B%5C%5C%5C%5C%5C%5C%5C%22auth%5C%5C%5C%5C%5C%5C%5C%22%3A%5C%5C%5C%5C%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%5C%5C%5C%5C%22%7D%5C%5C%5C%22%2C%5C%5C%5C%22template%5C%5C%5C%22%3A%5C%5C%5C%22claimid_box.tpl%5C%5C%5C%22%7D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C%5C%5C%22%3A%5C%5C%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getput=&goingto=&gothere=pickup.php&locale=&postdata=%7B%22auth%22%3A%22%22%7D&postdata=%7B%22auth%22%3A%2295ca1f5b66aba21cc2698ead33d03285%22%7D&postdata=%7B%22auth%22%3A%22a6d31fa9ec46a6cffb3668e43af5c28b%22%7D&template=claimid_box.tpl > > > Method GET > Parameter getdata > Attack []' AND '1'='1 > URL https://filetransfer.decoded.legal/pickup.php > Method POST > Parameter claimID > Attack ZAP" AND "1"="1" -- > Instances 2 > Solution > > Do not trust client side input, even if there is client side > validation in place. > > In general, type check all data on the server side. > > If the application uses JDBC, use PreparedStatement or > CallableStatement, with parameters passed by '?' > > If the application uses ASP, use ADO Command Objects with strong type > checking and parameterized queries. > > If database Stored Procedures can be used, use them. > > Do *not* concatenate strings into queries in the stored procedure, or > use 'exec', 'exec immediate', or equivalent functionality! > > Do not create dynamic SQL queries using simple string concatenation. > > Escape all data received from the client. > > Apply an 'allow list' of allowed characters, or a 'deny list' of > disallowed characters in user input. > > Apply the principle of least privilege by using the least privileged > database user possible. > > In particular, avoid using the 'sa' or 'db-owner' database users. This > does not eliminate SQL injection, but minimizes its impact. > > Grant the minimum database access that is necessary for the application. > > Other information > > The page results were successfully manipulated using the boolean > conditions [[]' AND '1'='1] and [[]' AND '1'='2] > > The parameter value being modified was NOT stripped from the HTML > output for the purposes of the comparison > > Data was returned for the original parameter. > > The vulnerability was detected by successfully restricting the data > originally returned, by manipulating the parameter > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Once is happenstance, twice is coincidence, three times is enemy action.' - Ian Fleming www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.v.sangster at abdn.ac.uk Wed Jun 30 13:10:24 2021 From: m.v.sangster at abdn.ac.uk (Sangster, Mark) Date: Wed, 30 Jun 2021 12:10:24 +0000 Subject: [ZendTo] Potential SQL injection vulnerability? In-Reply-To: References: <40C106B1-B23C-4834-85B1-65928139A230@neilzone.co.uk> <394a349b-1316-4bfd-2a32-bd64523efb73@Zend.To> Message-ID: Hello, I tested this myself? Visiting: /pickup.php?getdata=[123] Results in this in the source: ?'+ So, whilst pickup.php doesn?t use it the variable, it does cause it to be set in the which would then POST to changelocale.php via JS. It is also possible to set the postdata variable for example with curl: $ curl -s --data "postdata=[123]" https:// /pickup.php | grep 123 ''); The data is encoded but it seems like it is normally encoded as it is (noting the auth). It might be feasible to craft something to impact changelocale.php depending on how it handles sanitising the getdata/postdata input. If it is unexpected to accept input from GET/POST to pickup.php, then it shouldn?t be set and passed to changelocale.php. I presume the detection it made was simply that the submitted string appears in the source. Cheers Mark From: ZendTo On Behalf Of Jules via ZendTo Sent: 30 June 2021 12:02 To: ZendTo Users Cc: Jules Subject: Re: [ZendTo] Potential SQL injection vulnerability? CAUTION: External email. Ensure this message is from a trusted source before clicking links/attachments. If you are concerned forward this email to spam at abdn.ac.uk Hi Neil, Curious. What I can definitely say is that "pickup.php" does not have a parameter called "getdata", so you can set that to anything you like and it shouldn't have any effect whatsoever. "changelocale.php" does, but that's not where they found any problem. And even in "changelocale.php" it isn't recognised as a GET parameter, only a POST. So again, setting it in the URL can't have any effect. So I would say this is a false positive. Cheers, Jules. On 24/06/2021 09:54, Neil via ZendTo wrote: Hello Jules I?ve conducted an OWASP web application test against our installation of zend.to, using ZAP (https://www.zaproxy.org). It has indicated one potential high risk, as a potential SQL injection vulnerability. Do you have any thoughts on this, and whether it is a false positive, please? Best wishes Neil Description SQL injection may be possible. URL https://filetransfer.decoded.legal/pickup.php?getdata=%5B%5D%27+AND+%271%27%3D%271&getdata=%7B%22getdata%22%3A%22%5B%5D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%5B%5D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C%5C%5C%22%3A%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22aut h%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getdata=%7B%22getdata%22%3A%22%7B%5C%22getdata%5C%22%3A%5C%22%7B%5C%5C%5C%22getdata%5C%5C%5C%22%3A%5C%5C%5C%22%5B%5D%5C%5C%5C%22%2C%5C%5C%5C%22getput%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22goingto%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22gothere%5C%5C%5C%22%3A%5C%5C%5C%22pickup.php%5C%5C%5C%22%2C%5C%5C%5C%22locale%5C%5C%5C%22%3A%5C%5C%5C%22%5C%5C%5C%22%2C%5C%5C%5C%22postdata%5C%5C%5C%22%3A%5C%5C%5C%22%7B%5C%5C%5C%5C%5C%5C%5C%22auth%5C%5C%5C%5C%5C%5C%5C%22%3A%5C%5C%5C%5C%5C%5C%5C%2295ca1f5b66aba21cc2698ead33d03285%5C%5C%5C%5C%5C%5C%5C%22%7D%5C%5C%5C%22%2C%5C%5C%5C%22template%5C%5C%5C%22%3A%5C%5C%5C%22claimid_box.tpl%5C%5C%5C%22%7D%5C%22%2C%5C%22getput%5C%22%3A%5C%22%5C%22%2C%5C%22goingto%5C%22%3A%5C%22%5C%22%2C%5C%22gothere%5C%22%3A%5C%22pickup.php%5C%22%2C%5C%22locale%5C%22%3A%5C%22%5C%22%2C%5C%22postdata%5C%22%3A%5C%22%7B%5C%5C%5C%22auth%5C% 5C%5C%22%3A%5C%5C%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%5C%5C%22%7D%5C%22%2C%5C%22template%5C%22%3A%5C%22claimid_box.tpl%5C%22%7D%22%2C%22getput%22%3A%22%22%2C%22goingto%22%3A%22%22%2C%22gothere%22%3A%22pickup.php%22%2C%22locale%22%3A%22%22%2C%22postdata%22%3A%22%7B%5C%22auth%5C%22%3A%5C%22a6d31fa9ec46a6cffb3668e43af5c28b%5C%22%7D%22%2C%22template%22%3A%22claimid_box.tpl%22%7D&getput=&goingto=&gothere=pickup.php&locale=&postdata=%7B%22auth%22%3A%22%22%7D&postdata=%7B%22auth%22%3A%2295ca1f5b66aba21cc2698ead33d03285%22%7D&postdata=%7B%22auth%22%3A%22a6d31fa9ec46a6cffb3668e43af5c28b%22%7D&template=claimid_box.tpl Method GET Parameter getdata Attack []' AND '1'='1 URL https://filetransfer.decoded.legal/pickup.php Method POST Parameter claimID Attack ZAP" AND "1"="1" -- Instances 2 Solution Do not trust client side input, even if there is client side validation in place. In general, type check all data on the server side. If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?' If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries. If database Stored Procedures can be used, use them. Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality! Do not create dynamic SQL queries using simple string concatenation. Escape all data received from the client. Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input. Apply the principle of least privilege by using the least privileged database user possible. In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact. Grant the minimum database access that is necessary for the application. Other information The page results were successfully manipulated using the boolean conditions [[]' AND '1'='1] and [[]' AND '1'='2] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Once is happenstance, twice is coincidence, three times is enemy action.' - Ian Fleming www.Zend.To Twitter: @JulesFM The University of Aberdeen is a charity registered in Scotland, No SC013683. Tha Oilthigh Obar Dheathain na charthannas cl?raichte ann an Alba, ?ir. SC013683. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Wed Jun 30 16:15:29 2021 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 30 Jun 2021 16:15:29 +0100 Subject: [ZendTo] Upgrade to beta: clamav not working In-Reply-To: References: <9572AF6B-233C-4307-ACEA-4C614D110BDC@neilzone.co.uk> <6ab5e446-73c4-b259-e477-6932cec92ff4@Zend.To> <09CE3B32-B071-4870-8F65-9710B82C79A5@neilzone.co.uk> Message-ID: > On 30 Jun 2021, at 11:29, Jules wrote: > > You really want to put your change into > /etc/apparmor.d/local/usr.sbin.clamd > or else it is likely to be overwritten by future apt upgrades. Much appreciated ? thanks, Jules. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: