Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Async SendStream leaves files in IW user cache
#1
Using 15.2.11,.12.
C++ Builder 10.3.2

After feeling the Garmin hack I decided to inventory scenarios where my customer data could be exposed and decided to stop using download links to the user cache.  I changed download links to async button events with WebApplication->SendStream reading from an encrypted database thinking nothing raw would touch the disk anymore.  On a single click / download it works, no file in the user cache.  Re-click for subsequent download, filename.tmp appears in the user cache folder. Re-click again, filename (minus .tmp) appears in the user cache folder.  These files in the user cache don't go away after the session ends, they just accumulate until shutdown (if the app crashes they stay).  These files are not accessible through IW but accessible for anyone with access to the cache folder.  In my app's case they were excel files with financial data so I wouldn't want a network admin to be able to view.

Work around:  use onclick + LockOnSubmit = false with sendstream.

Demo attached:


  1. Click 3 buttons on left 3 times each, you'll see the raw files accumulate in the user cache folder.
  2. Click button on right, works correctly every time.


Attached Files
.zip   IWTEST.zip (Size: 9.18 KB / Downloads: 3)
Reply
#2
"These files are not accessible through IW but accessible for anyone with access to the cache folder."

This will be true with any application. If someone has access to your server, they have access. You can simply remove permissions to that folder for all users except the one that your application runs under using standard Windows security.

SendStream can help, but large files can still be cached to disk during the transfer.
Reply
#3
(08-12-2020, 07:09 PM)kudzu Wrote: "These files are not accessible through IW but accessible for anyone with access to the cache folder."

This will be true with any application. If someone has access to your server, they have access. You can simply remove permissions to that folder for all users except the one that your application runs under using standard Windows security.

SendStream can help, but large files can still be cached to disk during the transfer.

>>If someone has access to your server, they have access.

Yep, I don't have a problem if they have access to my encrypted database as that won't be easy to decipher.  The problem is the raw data that's being saved to disk by the framework, it's unexpected and probably unintended.


>>You can simply remove permissions to that folder for all users except the one that your application runs under using standard Windows security.

I may or may not have control over that depending on how it's deployed.  In this particular case I don't have control over it.  What I'm claiming to the customers is that my product inherently won't expose their data (at least in an obvious way).


>>SendStream can help, but large files can still be cached to disk during the transfer.

Not an issue in this case.
Reply
#4
I will have a look, but temporary files are not and have never been encrypted. Temporary files can contain basically anything (including HTML, JS, CSS, images or any file transfered by your application). It is not that it is "unintended". If you can't trust the security of the server where your application runs, I think that any measure that you take to protect your data is simply ineffective. It will give you a false sense of security but that's just it: false.
Reply
#5
BTW, it seems that this issue only happens on Chrome. In Firefox it works correctly. Chrome is caching the file and not requesting it again. Firefox does correctly.
Reply
#6
>>I will have a look, but temporary files are not and have never been encrypted.

Definitely not expecting temporary files be encrypted, I was trying to eliminate temporary files altogether by using SendStream instead of links to cache files.  It works correctly when not using async as there are no temp files left over from SendStream.  The other issue is that the async temporary files don't get deleted after the session ends, they stay until the app shuts down or stay permanently if the app crashes.  In my case the temp files contained plane text names and figures so I would have a hard time explaining that to a customer if there were an issue discovered.  My plan was to deliver the data from encrypted database -> memory -> SSL connection but did not expect an intermediate plane text to disk step. 


>> It is not that it is "unintended".

In the IW code it looks like for async SendStream a temp file is specifically created using the ctOneTime flag (delete after download) so it is probably failing somewhere in there.


>>it seems that this issue only happens on Chrome.

Also fails in Edge.
Reply
#7
I've changed our file caching mechanism to force browsers not to cache these files and request them again which will remove the files from the disk. A new update will be released as soon as the tests have been finished.
Reply
#8
Yes, for all practical purposes, currently, Edge == Chrome
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)