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.
Related
I am looking for a few pointers to reaching am adequate solution to a problem/feature I need to implement/rectify in my asp.net mvc application.
My application is a LAN only interface that is run over a webserver. In this application there is a page that displays a bunch of files/folders.
I need to be able to store a set of attributes\properties about these files, and those props\attrs need to be independent of their location on the fileserver. This is my main issue, as I could easily link them to the db with the path as the primary key, but alas then as soon as the file moves their link to the db would be lost.
The types of files that need to be displayed unfortunately could be anything. .txt, .exe, media etc etc. So that provides a limiting option also from using something like the tagsharp lib.
One approach i was considering was simply storing a key somehow in the file itself, or with an ADS ( i have no experience in doing this, but am presently trying to research its potentiality).
Does anybody have any experience with this issue, and can recommend a simple approach. I am hoping i do not need to implement an ADS approach as what ive been reading so far is a little bit over my head and im not sure C# will handle the streams adequately for my needs.
Opinion based. Proposal anyway: what about an additional file which is found by a naming convention?
MyDocument.doxc
MyDomument.docx.properties
MyMovie.mp4
MyMovie.mp4.properties
When moving / renaming files, make sure you move / rename the properties file the same.
First of all thanks for taking a moment to reply.
I had considered the possibility of using a separate file. The problem is that the users of the filesystem ( which may or may not include users of the lan application ) need to be able to move/copy files independent of db application.
Therefore if a user moves a file in windows explorer, I need it to automatically move those additional properties with it. Unfortunately I cant rely on users to move those additional files on their own volition, and I cant ask users to only use the application to move files ( if i were to generate code for the program to do this ).
Okay, so I am creating a c# winforms application.
I want to write/read from binary data file. But, I want to put that file in a folder somewhere and I do not want anyone to be able to delete or edit the file. I only want the program that uses the file to be able to access it.
Is this possible? I looked into MSDN's structure on file security and as I researched it I saw people complain that if you limit the file to a user then that person can just override the privileges and make it editable.
Also, I thought about how this would actually work considering in essence I would like a process to edit the file only and that process could have varying process ID's if it is opened and closed over time, seems tough.
Any thoughts?
Even though this will not satisfy all your requirements you can try IsolatedStorage (System.IO.IsolatedStorage Namespace).
How to write and read file in IsolatedStorage
The System.IO.IsolatedStorage namespace contains types that allow the
creation and use of isolated stores. With these stores, you can read
and write data that less trusted code cannot access and prevent the
exposure of sensitive information that can be saved elsewhere on the
file system. Data is stored in compartments that are isolated by the
current user and by the assembly in which the code exists.
Additionally, data can be isolated by domain. Roaming profiles can be
used in conjunction with isolated storage so isolated stores will
travel with the user's profile. The IsolatedStorageScope enumeration
indicates different types of isolation. For more information about
when to use isolated storage
You can prevent file access while your program is running if you open it exclusively.
However, when the program is not running, the file is no longer protected. So someone would just need to kill the program in order to access the file.
In order to protect the file while your program is not running, you'd need to set up a user account and assign it a password which is only known to the program. Then set the permissions of the file so that only your user can access the file.
However, any administrator can take over the ownership of the file, so even permission protection is useless.
Finally, someone can even take the hard disk out of the PC and read the raw data.
You might also think about whether you want to protect the file or the file content. If the file content is sensitive, think about encryption.
It really depends on your needs, which option to choose.
If you have control over the target filesystem prior to install then setup some file permissions and go from there. The user accessing the folder will need read permissions at minimum.
Run the app under a security group and assign persmissions to the folder and files with that security group. Revoke access for others and make it readonly
Windows 10 version 1709 introduced Controlled Folder Access. This allows you to whitelist applications that can modify certain folders. You cannot restrict Read access.
well, I have the same issue and I did some research on this subject and I found that secure your information in a accesspoint database or any other Microsoft data base with password and only one specific app that have the password will have the permission to do read/write to these information.
I am allowing users to upload files to my server. What possible security threats do I face and how can I eliminate them?
Let's say I am allowing users to upload images to my server either from their system or from net. Now to check even the size of these images I have to store them in my /tmp folder. Isn't it risky? How can I minimize the risk?
Also let's say I am using wget to download the images from the link that the users upload in my form. I first have to save those files in my server to check if they actually are images. Also what if a prankster gives me a URL and I end up downloading an entire website full of malware?
First of all, realize that uploading a file means that the user is giving you a lot of data in various formats, and that the user has full control over that data. That's even a concern for a normal form text field, file uploads are the same and a lot more. The first rule is: Don't trust any of it.
What you get from the user with a file upload:
the file data
a file name
a MIME type
These are the three main components of the file upload, and none of it is trustable.
Do not trust the MIME type in $_FILES['file']['type']. It's an entirely arbitrary, user supplied value.
Don't use the file name for anything important. It's an entirely arbitrary, user supplied value. You cannot trust the file extension or the name in general. Do not save the file to the server's hard disk using something like 'dir/' . $_FILES['file']['name']. If the name is '../../../passwd', you're overwriting files in other directories. Always generate a random name yourself to save the file as. If you want you can store the original file name in a database as meta data.
Never let anybody or anything access the file arbitrarily. For example, if an attacker uploads a malicious.php file to your server and you're storing it in the webroot directory of your site, a user can simply go to example.com/uploads/malicious.php to execute that file and run arbitrary PHP code on your server.
Never store arbitrary uploaded files anywhere publicly, always store them somewhere where only your application has access to them.
Only allow specific processes access to the files. If it's supposed to be an image file, only allow a script that reads images and resizes them to access the file directly. If this script has problems reading the file, it's probably not an image file, flag it and/or discard it. The same goes for other file types. If the file is supposed to be downloadable by other users, create a script that serves the file up for download and does nothing else with it.
If you don't know what file type you're dealing with, detect the MIME type of the file yourself and/or try to let a specific process open the file (e.g. let an image resize process try to resize the supposed image). Be careful here as well, if there's a vulnerability in that process, a maliciously crafted file may exploit it which may lead to security breaches (the most common example of such attacks is Adobe's PDF Reader).
To address your specific questions:
[T]o check even the size of these images I have to store them in my /tmp folder. Isn't it risky?
No. Just storing data in a file in a temp folder is not risky if you're not doing anything with that data. Data is just data, regardless of its contents. It's only risky if you're trying to execute the data or if a program is parsing the data which can be tricked into doing unexpected things by malicious data if the program contains parsing flaws.
Of course, having any sort of malicious data sitting around on the disk is more risky than having no malicious data anywhere. You never know who'll come along and do something with it. So you should validate any uploaded data and discard it as soon as possible if it doesn't pass validation.
What if a prankster gives me a url and I end up downloading an entire website full of malware?
It's up to you what exactly you download. One URL will result at most in one blob of data. If you are parsing that data and are downloading the content of more URLs based on that initial blob that's your problem. Don't do it. But even if you did, well, then you'd have a temp directory full of stuff. Again, this is not dangerous if you're not doing anything dangerous with that stuff.
1 simple scenario will be :
If you use a upload interface where there are no restrictions about the type of files allowed for upload then an attacker can upload a PHP or .NET file with malicious code that can lead to a server compromise.
refer:
http://www.acunetix.com/websitesecurity/upload-forms-threat.htm
Above link discusses the common issues
also refer:
http://php.net/manual/en/features.file-upload.php
Here are some of them:
When a file is uploaded to the server, PHP will set the variable $_FILES[‘uploadedfile’][‘type’] to the mime-type provided by the web browser the client is using. However, a file upload form validation cannot depend on this value only. A malicious user can easily upload files using a script or some other automated application that allows sending of HTTP POST requests, which allow him to send a fake mime-type.
It is almost impossible to compile a list that includes all possible extensions that an attacker can use. E.g. If the code is running in a hosted environment, usually such environments allow a large number of scripting languages, such as Perl, Python, Ruby etc, and the list can be endless.
A malicious user can easily bypass such check by uploading a file called “.htaccess”, which contains a line of code similar to the below: AddType application/x-httpd-php .jpg
There are common rules to avoid general issues with files upload:
Store uploaded files not under your website root folder - so users won't be able to rewrite your application files and directly access uploaded files (for example in /var/uploads while your app is in /var/www).
Store sanitated files names in database and physical files give name of file hash value (this also resolves issue of storing files duplicates - they'll have equal hashes).
To avoid issues with filesystem in case there are too many files in /var/uploads folder, consider to store files in folders tree like that:
file hash = 234wffqwdedqwdcs -> store it in /var/uploads/23/234wffqwdedqwdcs
common rule: /var/uploads/<first 2 hash letters>/<hash>
install nginx if you haven't done its already - it serves static like magic and its 'X-Accel-Redirect' header will allow you to serve files with permissions being checked first by custom script
I have a web form which takes in user information. The value of various text boxes is used to build a html file. I write this html to a file( with specific name) and then prompt user to Save this file.This html is used for creating outlook email signatures. Currently I have this html within the application.This has been deployed to the server. I had to set write permission on this file for all users for it to work.
Are there any security risks? What happens if multiple users access this applications and write to the file at the same time.
When you say the file has "a specific name", do you mean that it is always the same name? If so, then yes, there will be problems if multiple users use this functionality at the same time. They'll be overwriting the one file and downloading each other's data. You would need to generate a unique filename each time the process runs to avoid this.
But do you actually need to save the file?
Or is your goal purely to produce some HTML for the user to download, and the way you are doing this is by writing it to a file, and then prompting them to download that file?
If you don't need to save the file, but rather just need to generate HTML and prompt the user to save, just serve it up as a normal page, and set response headers such that their browser will download it. Something along these lines:
Response.AddHeader("content-disposition", "attachment;filename=my_file.html");
From what I understand, the user fills the web form and submits. Immediately, an html file pops up for download from the server. I think this is very neat implementation of this scenario. You just need to make sure that resources are released properly in order to prevent locking of files.
When multiple users access this application, it should not break since separate files are created with a specific name (as you have mentioned). I don't know what logic has been used to create unique names. At some peculiar situation (this is purely dependent on your name calculation logic) if the calculated specific file name somehow becomes similar to an existing file, you should have code in place to replace or create a different version of the same file name. Locking could occur if you are writing captured data from web form into the same file again and again without disposing your stream/File objects . Make sure you dispose your objects after use in the code.
It would be great if you give access to the application pool of the web application to a user who has write access to that file/folder instead of giving everyone the write access. In this way, your application gets full rights to perform write operations rather than users having rights. If users have write access on the file/folder, it is very easy for anyone to peek in and do something unexpected.
Hope this helps.
I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason
If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.
Do not modify the executable. Adding a single SQLite database is a much better solution.
Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it
SQLite is what your looking for and is compatible with c#
If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.
I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.