We are trying to make sure that our users can't under any circumstances alter the files in any way.
Is there a way to prevent normal non-admin users from interacting with files that my application need to interact with?
Say there are N amount of files that my application interact with. Once the application get a reference for these files then users should not be able to interact with them. Right now I am making a copy of the files and hide them under appdata in my applications folder.
This works for the normal Joe, who is just doing his job and working hard as he will never try to look for trouble down there, but the bored Adam will probably go and play hacker when nothing special happens.
The files are storred on the local computer until they are sent, with another application, to a remote database. The time between the files first interaction with my application and the event of being transferred to the database can range from seconds to weeks.
I have a local database on the computer, but I can not store the files there because there can be N amount files that needs to be transferred and some other data needs to be stored in the database as well. I believe the max capacity of the database is 4 GB, which would make it impossible to store the data.
The computer is also not under my supervision, so I am not allowed to change OS settings, and I can't store the data remotely either, because if I could then it would be sent to the remote server.
My current solution hack solution would be to hold the file in memory (so it can't be changed durring the process) create a hash of it, which I will store in the database, and then make X amount of copies that I will spread out in different parts of the computer. This way Adam needs to touch more than one file, which are all in a non-disclossed location, to be able to sabotage everything. This would also require him to search in a couple of folders to find the files, which would require work and which Adam will probably try to avoid.
The problem here is that I don't really know what kind of sociopathic maniac Adam is, so even by going this far would still be throwing die with god.
That's why I am wondering if there are places where Adam can't touch or ways to hide/lock the files in a way so that Adam can't alter och destroy them?
Is there a way to prevent normal non-admin users from interacting with files that my application need to interact with?
Programs run in the context of the user that starts them. If your user is not able to edit a file, your program won't be able to edit it, either. If your program is able to edit the file, your users WILL ultimately have that ability. There is no separating the two.
As an example, zip files also support password protection. So you could put everything in a password-protected zip file, where the password is embedded/obfuscated in your application and not known to the user. In this case, it will be extremely difficult for the user to open the zip file in the normal way. But even then, the user will still able to tamper with the file via a text editor. They may not come out with anything useful, but they did still modify the file.
The one thing you can do is detect the tampering. You can compute and save a hash value for your files, and check the contents of the file match the saved hash.
One other thing option you may have is using multiple databases. I don't know what kind of database you have that's giving you a 4 GB limit, but if it's something file-based like sqlite there's no reason not to have multiple files. Keep in mind, though, the user still has the ability to tamper with these files in a text editor. If it's SQL Server Express, the version with the 4 GB limit has been end-of-life and fully-unsupported for several years and should not be used! Newer releases of Express are still free and now offer a 10 GB limit, and also allow you to have multiple databases with a 10 GB limit each.
Related
I have a program I use on multiple computers, that I would like to keep in sync to each other.
The files shared are .json and .txt files. Am I just able to serialize back to the file every so often without cause for concern? The software is used to make transactions on an inventory, it is only used on 1 computer, and then I use the software to make purchases or restock the items after purchased. I just want to be able to access it from my computer without having to walk to the other computer, close it, and open it on my computer make my changes and close it, walk back and open it back up.
I haven't dug into this at all, as I'm not sure what exactly it is called that I am looking for.
I would think if I can just serialize back to the file it would be ok, but maybe there is an easy way to check if the file has been saved over since I have had it open on my computer?
If you want to check whether or not the file was altered since some defined point in time look at the FileInfo. If you have several computers running put the file on a shared folder and use a FileSystemWatcher. In general I think there is nothing principally not working with serializing/deserializing data to disc.
Nevertheless I would suggest backing up data and considering concurrency.
I'm trying to create software that will add a computer to an Active Directory domain. One criteria I need to meet is the machine must be added to the proper OU. In order to do this I have a set list of site locations with addresses (this is how we determine OU). This list is currently in the form of an ACCDB file, and I want to include this within the application as the Access list will not be changed.
Everything I see wants the DB file to be connected to in a different location such as server or on the local machine. My preference is to use the DB file as a reference or something inside the program's .exe file itself. I may be missing something horribly obvious, but it's been messing with me for a couple days so I'm reaching out for help.
To clarify, this software MUST be self contained (no installer). It must also be able to determine the proper OU to join to the domain (no access to shares until the PC joins the domain). It must also be user-friendly enough to avoid mistakes, meaning I want to avoid copying distributing multiple files that must go to a correct location. This is why I want to embed the ACCDB file into the application for on the fly use.
Things get much easier because this is static data. You don't have to worry about persisting this data, reclaiming changes into your program, or users accidentally deleting something, etc. You will be able to just use an embedded resource in your application. In the link, follow the examples using the image file. Text file examples will corrupt your database.
However, there is still a trick to doing this. The problem is the Access engine included with Windows will not be able to open the database as a resource, and so you will need to save this file to the local hard drive. The good news is its not as bad as it seems, because your program can do this as needed, and make sure it's right, rather than asking the user to put a file in a specific place.
As for where to put the file when you extract it... the safest and best place is the Application Data folder. You can easily get the path for this folder by checking the results of this call:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This will give you a path where standard privilege users do have write access, no matter which user.
In summary:
Embed the ACCDB as a resource.
When your program runs, get the Application Data path using the Environment object.
Open a FileStream for writing to a file based on the path from #2
Open the embedded resource as a Stream object in C#
Copy the stream from #4 to the stream from #3. Make sure to use a mechanism intended for binary data, rather than text.
Close/Dispose your streams, so no locks remain on the file. This is as simple as putting using blocks in the right places.
Open a normal Access connection to the file you just made, using any of the thousands of tutorials or examples available on the web as a guide.
In this way, you only need to distribute the final .exe file, and users won't need any special permissions to use the database. You don't have to worry if a user deletes your file; it's still embedded in the application, which will recreate it if needed every time it starts up.
The downside is a clever user may be able to manipulate the database to end up in an undesirable OU. If you need to worry about this, you should consider having the program check a web service, rather than using embedded data. Anything you embed can ultimately be altered by an end user. A web service is also nice because you can update your mapping data as your organization evolves, without needing to rebuild or redistribute the program.
I am having one situation related to security and need your valuable suggestions or solutions.
So the story goes like this:
There is a Windows (consider Win 7 and above. This is an end user machine and not any server) machine and it is having 2 desktop applications. One is written in C++ and the other is written in C#.
One application emits some data as configurations which I need to save on this machine (on disk), later when another application wakes up, it will pick the configuration file and do whatever it is supposed to do.
Both the applications are 2 different application. There is no relationship between them except that they are installed on the same machine.
Now, from the security and consistency point of view, I do not want that user access this file and play with this/update it or delete it.
So my question here is what is the best way (or safest place) to secure the file on the Windows machine so that user will not be able to temper it? The amount of config data is very small - consider 3 string fields like first name, last name and age in json format.
Thanks.
So far in development, my application has been storing its databases in the app base directory. When it is deployed this will be in program files so I cant keep them there!
The obvoius places are:
Environment.SpecialFolder.LocalApplicationData
Environment.SpecialFolder.ApplicationData
One problem is that data downloads can be run from sceduled tasks so I would have to ensure tasks were run under the same user.
The major issue is that after a couple of years, these database files could total 5 to 10GB, so I feel like I should give the user an option after install to choose the database location. I'd have to ensure that it was writable and not a network location.
What solutions have others come up with?
About checking the write access to a directory: So far I have found no better way than to create a file in the directory and immediately delete it. If you encounter an error during these steps, you have insufficient privilegs. (Just remember to first check if there is enough free space on the drive).
I once tried to solve this programmatically by going through the access control lists, but then i encountered a dir where I had write priviliges, but not the right to list the ACLs...
You can check if a given drive is a network share by using the DriveType property of the System.IO.DriveInfo object. As for handling UNC pathes, I have yet to find a better way than (myPath.Substring(0,2) == #"\\")
My company created an application that can send large attachements from one mail recipient to another (because most mailboxes are very limited).
But we were wondering how we can prevent the uploading of warez?
For now all extentions are allowed, but we could restrict the extentions to zip and images.
But if you zip warez you can still upload these.
Are there any tools, methods or something like it to prevent the uploading of warez through our system?
Some more info:
This project is semi-public. It will mostly be used for the communication between customer and company. Therefore an email address of our company is always required (either within the receivers as that of the senders, but you all know how easy it is to manipulate this).
Define what "warez" is first.
I'm pretty sure you're going to have problems with that.
You can probably implement heuristics that figure out that you're sending applications and just ban that, but there's no way you're going to figure out that one application is a pirated copy and another isn't and allow the legal one while ban the pirated one.
If you control the server, and is afraid that people will upload pirated copies of applications onto your server and use it to spread it with, then I'm pretty sure your only option is to check with a lawyer what you're obligated to do.
I think it boils down to that you need a system where copyright owners can inform you of pirated copies being present and that you have a system to remove said content within a time frame. I think that's all that is required.
EDIT
If as you said in your edit, that this is for customers to send stuff to you, then I'd be very careful about the allowed email addresses. Is there anything to stop somebody putting in Distribution Email addresses. e.g. If some naughty person sent a large file to All#YourCompany.com, will it be distributed or will it be blocked
ORIGINAL
If this is an open/public system, then its going to be abused. There are ways to unpack zip files on the fly to check their contents, and even to check the file mimetype headers to perform more restrictions, but it doesn't change the fact that someone might want to legitimately send an AVI file of a presentation, while someone else whats to upload a pirated movie.
If this is for internal use in your company, I'd suggest restricting access in someway (tie the system into your Company LDAP/ADSI system and make users login to the system.
Also putting some file size restrictions in place might be necessary as theres nothing to stop some script kiddie just sending 1Gb Junk Text files around, just to be a nuisance and eating up your bandwidth
You can always just rename, for example, a .rar extension to .jpg and let the downloader know to rename the file to open the "Warez".
There is no way to block it other than to take random samplings, test it your self, and then manually delete whatever it is you don't want.
Short answer: No, you can't.
You could look for filenames from a list, but that will fail (e.g. you might ban "MS Word", but then if someone uplads an innocent "MS Word.doc" you fail. Or if the bad guy renames his exe to "MS W0rd" you fail.
You could look for recognised sequences in the file - that fails as soon as they apply even simple encryption or compression.
You can create user accounts and ban users who misbehave, but this fails because you have to spend a lot of effort policing it and in any case users can just creat multiple accounts using web mail addresses.
My suggestion would be to make this someone else's problem. Get users to upload files to someone elses system (Microsoft SkyDrive, Amazon S3 etc) and then they can worry about the legal side.
What if someone sends a password-protected RAR archive to ensure security of some documents? You can't possibly look inside of it - and you shouldn't - not your business.
For example, we had a couple of times some access right issues with our network. And I needed to install some third-party components on my developer machine. As I was unable to access our repository at the time, I just got the installation package sent to me per email. Now, how can an outsider possibly decide whether a file "SomeCoolComponent.msi" is a warez copy downloaded from the intenet or a 100% legal copy which I have the rights to use?
We once had at university our email account suddenly block all password-protected archives as attachments. You guess what? I didn't stop encrypting them. I stopped using that account.
No - you cannot prevent this with a tool or framework.
You can prevent this by banning / blacklisting users who violate the policy.
Trying to do everything in code isn't always the best idea - sometime a simple "break the rules and you get banned" policy is best.
Assuming you can build decompression support in, you could use this heuristic method to determine whether a given uploaded archive is warez (derived from real world warez distribution methods):
get the filenames contained in the archive
if the archive contains (an .nfo OR a .diz file) and (an exe OR an msi or an archive containing one of the above) block the upload
if the archive contains a series of zip/rars/00X files block the upload
if the file is an exe, check whether it's a SFX and if it's a zip, rar or 7z SFX check the embedded archive
Otherwise just accept the upload, making sure you clearly state in your TOS that the company is not responsible for user uploads.