Is there a way to open a presentation from a stream, memory file or isolated storage?
I have a presentation file that I want to open in PowerPoint, but do not want to allow user to access the file itself. Unfortunately the Presentations.Open() function of PowerPoint (and Open() of all other Office applications) only accepts a path parameter, which means I must save the file somewhere on the disk and then open it in PowerPoint, which will consequently give user access to the file.
Has anyone done this in any Office application?
You can use the OpenXML SDK to open documents from a stream, but not from within an Office application.
But, if you're motivated enough, you could delete the file after it's closed. It's pretty simple, you just need to create a separate process and wait for the file to not be locked for writing any more. Or, if you know when it's closed (e.g. if you do the closing in code), you may not need a separate process.
Related
I am implementing pdf upload using Carrierwave with Rails 4. I was asked by the client about malicious content, e.g. if someone attempts to upload a malicious file masked as a pdf. I will be restricting filetype on the frontend to 'application/pdf'. Is there anything else I need to worry about, assuming the uploaded file has a .pdf extension?
File uploads is often a security issue, since there are so many ways to get it wrong. Regarding just the issue of masking a malicious file as a PDF, checking the content type (application/pdf) is good, but not enough, since it's controlled by the client and can be modified.
Filtering on the .pdf extension is definitely advisable, but make sure you don't accept files like virus.pdf.exe.
Other filename attack techniques exist, e.g. involving null or control characters.
Consider using a file type detector to determine that the file is really a PDF document.
But that's just for restricting the file type. There are many other issues you need to be aware of when accepting file uploads.
PDF files can contain malicious code and are a common attack vector.
Make sure uploaded files are written to an appropriate directory on the server. If they aren't meant to be publicly accessible, choose a directory outside of the web root.
Restrict the maximum upload file size.
This is not a complete list by any means. Check out the Unrestricted File Upload vulnerability by OWASP for more info.
In addition to #StefanOS 's great answer, PDF files are required to start with the string:
%PDF-[VERSION]
Generally, at least often, the first couple of bytes (or more) indicate the file type - especially for executables (i.e., Windows executables, called PE files, should start - if memory serves - with "MZ").
For uploaded PDF files, opening the uploaded file and reading the first 5 bytes should always yield %PDF-.
This might be a good enough verification. for most use-cases.
In my application I want to lock the clipboard to prevent other application from changing the clipboard. How can I achieve this using Delphi 2007?
There is no facility for that. The user is the ultimate owner of the clipboard. When the user wants something else on the clipboard, the user will cut or copy something new. You, as the application developer, don't get a vote. (Users who discover programs trying to assert votes they don't have are likely to uninstall those programs and give them poor reviews.)
You can monitor the clipboard to discover when it changes with wm_ClipboardUpdate, but by the time you receive the notification, there's already something new there.
The purpose of the clipboard is to make data stored in it to be available to any program at any time and therefore provide easy way from transferring such data between different applications.
Because of that there is no official mechanism which would allow blocking access to the clipboard.
Any way if you are perhaps thinking of trying to block other application of accessing the clipboard in order to avoid them to be able to intercept some data from your application that has been stored there for copying purposes (which is the only reason I can think of why you would want to do this) there is another even better way.
Instead of using Windows default clipboard for string parts of data for copy and paste operations go and implement your own custom clipboard that will only be available from your own application similar as Microsoft does with its Office Clipboard (https://support.office.com/en-us/article/Copy-and-paste-multiple-items-by-using-the-Office-Clipboard-714a72af-1ad4-450f-8708-c2931e73ec8a).
In order to do this you only need to design a storing mechanism and then override default Cut, Copy and Paste shortcuts to use your mechanism instead of the default Windows Clipboard.
I am working with a program designed to record and display user-input data for tracking courses in a training process. One of the requirements was that we be able to keep a copy of each course's itinerary (in .pdf format) to display alongside the course. This program is being written in Delphi 7, expected to run on Windows 7 machines.
I've managed to get a remote location set up on the customer's main database (running CentOS 6), as a samba share, to store the files. However, I'm now running into a usability issue with the handling of the files in question.
The client doesn't want the process to go to a mapped drive; they've had problems in the past with individual users treating the mapped drive another set of programs require as personal drive space. However, without that, the only method I could come up with for saving/reading back the .pdf files was a direct path to the share (that is, setting the program to copy to/read from \\server\share\ directly) - which is garnering complaints that it takes too long.
What is the proper way to handle this? I've had several thoughts on the issue, but I can't determine which path would be the best to follow:
I know I could map the drive at the beginning of the program execution, then unmap it at the end, but that leaves it available for the end user to save to while the program is up, or if the program were to crash.
The direct 'write-to-share' method, bypassing the need for a mapped drive, as I've said, is considered too slow (probably because it's consistently a bit sluggish to display the files).
I don't have the ability to set a group policy on these machines, so I can't hide a drive that way - and I really don't think it's a wise idea for my program to attempt to change the registry on the user's machine, which also lets that out.
I considered trying to have the drive opened as a different user, but I'm not sure that helps - after looking at it, I'm thinking (perhaps inaccurately) that it wouldn't be any defense; the end user would still have access to the drive as opened during the use window.
Given that these four options seem to be less than usable, what is the correct way to handle these requirements?
I don't think it will work with a samba share.
However you could think about using (secure) ftp or if there is a database just uploading them as a blob.
This way you don't have to expose user credentials to a user.
I have an MFC app which is wizard based. The App asks a user a variable number of questions which are then written to an INI file which is later encrypted when the user clicks Finish.
All the INI file parsers I have seen so far seen read or write to a physical file on Disk. I don't want to do this as the INI file contains confidential information. Instead I would like the INI file to be only based in memory and never written to disk in an un-encrypted form.
As the app allows users to go back and change answers, It occurred to me that I could use an in memory Database for this purpose but again I do not want anything written to Disk and don't want to ship a DB with my app if it can be avoided.
I have to use an INI file as it the file when un-encrypted will be processed by a 3rd party.
Any suggestions welcomed.
Thanks..
I have an IniFile C++ class which allows you to work with Ini files in memory:
http://www.lemonteam.com/downloads/inifile.h
It's a short, well documented single .h file. Sample usage:
IniFile if ( "myinifile.ini" );
if.SetString( "mykey", "myvalue" );
// Nothing gets actually written to disk until you call Flush(), Close() or the object is deleted
if.Flush();
if.Close();
You should be able to modify the Flush() method so that it applies some kind of encryption to the saved data.
Sounds like a good application for a memory-mapped file, since you can control when your in-memory view gets flushed back to the file on disk.
Why would you need to have it in an ini file format if it is never stored to disk?
Why not just keep it in memory as a data structure and use your normal ini file methods to write it to disk when you want to.
If you don't want to save into file, what is the point of using INI file then?
INI API is bascially a property bag or key value pair based on disk file.
If you don't want to use file, I suggest you use your own hash or dictionary data structure to store the key value parirs
We take text/csv like data over long periods (~days) from costly experiments and so file corruption is to be avoided at all costs.
Recently, a file was copied from the Explorer in XP whilst the experiment was in progress and the data was partially lost, presumably due to multiple access conflict.
What are some good techniques to avoid such loss? - We are using Delphi on Windows XP systems.
Some ideas we came up with are listed below - we'd welcome comments as well as your own input.
Use a database as a secondary data storage mechanism and take advantage of the atomic transaction mechanisms
How about splitting the large file into separate files, one for each day.
If these machines are on a network: send a HTTP post with the logging data to a webserver.
(sending UDP packets would be even simpler).
Make sure you only copy old data. If you have a timestamp on the filename with a 1 hour resolution, you can safely copy the data older than 1 hour.
If a write fails, cache the result for a later write - so if a file is opened externally the data is still stored internally, or could even be stored to a disk
I think what you're looking for is the Win32 CreateFile API, with these flags:
FILE_FLAG_WRITE_THROUGH : Write operations will not go through any intermediate cache, they will go directly to disk.
FILE_FLAG_NO_BUFFERING : The file or device is being opened with no system caching for data reads and writes. This flag does not affect hard disk caching or memory mapped files.
There are strict requirements for successfully working with files opened with CreateFile using the FILE_FLAG_NO_BUFFERING flag, for details see File Buffering.
Each experiment much use a 'work' file and a 'done' file. Work file is opened exclusively and done file copied to a place on the network. A application on the receiving machine would feed that files into a database. If explorer try to move or copy the work file, it will receive a 'Access denied' error.
'Work' file would become 'done' after a certain period (say, 6/12/24 hours or what ever period). So it create another work file (the name must contain the timestamp) and send the 'done' through the network ( or a human can do that, what is you are doing actually if I understand your text correctly).
Copying a file while in use is asking for it being corrupted.
Write data to a buffer file in an obscure directory and copy the data to the 'public' data file periodically (every 10 points for instance), thereby reducing writes and also providing a backup
Write data points discretely, i.e. open and close the filehandle for every data point write - this reduces the amount of time the file is being accessed provided the time between data points is low