I have a website that reads an xml file, caches the file's object model, and i have web pages that read from the cache. I now want to make that xml file writable by the application pool account that runs the website so it can be managed by the website.
I've heard from peers that making that file writable is a security risk because if a hacker were to hack the website, he could potentially use the app pool account to overwrite that xml file and put whatever he/she wants into that file. However, since that file is read by directly hitting the web cache (and not the xml file) and the application pool account has write access to it, doesn't that mean a hacker can modify the object model that represent the xml file, regardless if the xml file is writable? By modifying the web cache, the hacker could inflict the same damage as if he had access to the web cache. I don't see how making the xml file read-only makes the website safer from hackers.
If I understand correctly, your xml file is read, turned into an object or a collection or some .NET data structure. And presumably only xml files of a certain schema can be successfully read this way.
I guess this depends on if there is something interesting in the xml file. If the xml file is the list of administrators, then as a hypothetical hacker I'd like to modify that file and add my name to the administrators list, which will result in an xml file that still serializes and deserializes to the data structure previous defined in code.
Another way to use write ability, would be to update a price list so that the prices are all free or heavily discounted.
If the XML file is a list of US states, then even if I could modify the list, I'm not sure what I could do with it outside of mischief, which is a larger concern for internet apps than for intranet apps.
I would put the file in the App_Data folder so that it can't be downloaded directly, which will make it harder for a hacker to make correct modifications to it... but security through obscurity is not really a good plan on it's own.
If the hacker were to hack the website, then security is compromised anyway. Allowing write access to the XML on it's own shouldn't be an issue, but I wouldn't give this access to any other files within your website.
Related
I've had this question for many years, and did research every time that this issue arose, but could never find a definite answer. Somehow the mighty Internet, MSDN, community forums, are either silent or vague on this. Out of thousands of development-related uncertainties, this is the only one that remained elusive.
To the point: in order to enable users to upload and manage images (and other files) used in their blog posts, in a shared hosting environment, I can either consider SQL Server binary data types (performance implications), or the file system. To use the latter, the necessary permissions need to be set for the IIS_IUSRS role on the storage directory : create/write, read and delete. My question - if I do this, what are the security implications? Could someone somehow take advantage of this, bypass the ASP.NET request pipeline and manipulate the files inside the folder without making a request to the corresponding ASP.NET handler (which checks rights, validates uploads, etc.)?
I've developed several systems that allowed file uploads and this has always bothered me. Now, hopefully, someone will be able to put my mind at ease and, ideally, explain the mechanics behind the process.
UPDATE
After viewing the latest answers (many thanks), another formulation of the question:
Is it in any way possible for a client to somehow bypass the request pipeline and create/delete files inside a directory that allows it (assuming the person knows the directory structure)? Or only the code that handles the request can do it? Any potential exploits?
The main problem is to been able to upload a script, an aspx page, in this directory with the photo files, and runs it.
Here is one case: I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼
The solution to that is to add this extra web.config file on the directories that allow to upload files and not permit to run any aspx page. Also double check to allow only extensions that you permit and not allow to change that on the file name, if they have the opportunity to make rename.
<configuration>
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</configuration>
Also on the directories that you allow to upload files, do not permit to run any other script like simple asp, or php or exe, or anything.
general speaking
All your pages have permissions to run and manipulate many things on the server. What you give now is the ability of write on some directories, also by using some aspx page. The asp.net now have one more extra permission to write files there, on the photo folder. Also note here, that you asp.net page have this control, not the user. What you do there with your code can write on this directories, so must be carefuller there to double check where you write and not allow any other directories, not allow the user to manipulate the directory that can be written to.
So this is the weak link. To been able to upload more script that can take control of the server, at least the part that can be access by the asp.net user of this pool.
Having done this before, I'd make two recommendations:
First, do not store the uploaded files in the same directory structure as your application code (if possible). Make it a well-defined external location, and locked down explicitly to only the user the application is running as. This makes it harder for a malicious upload to be injected into your application as nothing in the web server, or ASP.NET itself, knows how to access the file (only your application).
If that is absolutely not possible to do so, be sure to make sure no external user can access the storage folder using standard ASP.NET authorization and only allow writes by your application user to this folder, nothing else.
Second, do not store the uploaded files with their original names and file extensions; Keep that meta-data separate. Just consider the file a raw binary blob of data. This is good for a couple reasons. First, it prevents inadvertent execution of the file on the server, be it by someone accessing the file system directly, the web server, or ASP.NET. Second, it makes it much more difficult for an attacker to exploit a malicious upload as they should never be able to guess the name, or path, of the file on the server.
I have a scenario where a user will have access to a one-time-url.
When the user clicks on the URL, specific files will be available to that user.
I have many files on the site but would only like certain files to be accessible by that user.
I have though about generating an authenticated cookie and using forms based auth and applying permissions to a certain folder, but I need authorization on indiviual files. and the files will constintly be changing.
What would be the best way to give a user only access to specific files? (I won't display the other files, but I still do not want other files available if they are typed in the URL)
I would create an .ashx (handler file) and have that serve the files to the user (load into memory and then write the contents out by pushing the file to the content stream). That way the end user never has permissions to the actual files on the system but can still access them. Your code can then control when and how long each file is available to a user.
I would provide an abstraction around the actual file retrieval. That way the user never sees file name. Something like www.example.com/File.aspx?id=SOMERANDOMGUID
That RANDOMGUID could reference a file in the back end.
If you have lots of disk space, one way to accomplish this is to copy the files to a randomly-generated folder, so that the URL to a user's files is unique for each user.
I think it would be easier if your files are associated with an ID and the path is kept in the database. This way you can pull the files using the ID.
What would be the best method to implement the following scenario:
The web site calls for a image gallery that has both private and public images to be stored. I've heard that you can either store them in a file hierarchy or a database. In a file hierarchy setup how would prevent direct access to the image. In a database setup access to the images would only be possible via the web page view. What would be a effective solution to pursue?
[Edit] Thanks all for the responses. I decided that the database route is the best option for this application since I do not have direct access to the server. Confined to a webroot folder. All the responses were most appreciated.
Having used both methods I'd say go with the database. If you store them on the filestore and they need protecting then you'd have to store them outside the web-root and then use a handler (like John mentions) to retrieve them, anyway. It's as easy to write a handler to stream them direct from database and you get a few advantages:
With database you don't need to worry about filestore permissions or generating unique filenames or folder hierarchies etc.
With database you can easily apply permissions and protection directly - no trying to work out who can view what based on paths etc.
With a database you can store the image and metadata all together - when you delete the metadata you delete the image - no possibility of orphaned records where you delete from database but not from filestore
Easier to back-up database and images and then restore
The disadvantage is that of performance, but you can use caching etc. to help with that. You can also use FILESTREAM storeage in SQL Server 2008 (and 05?) which means you get filesystem performance but via the DB:
"FILESTREAM integrates the SQL Server
Database Engine with an NTFS file
system by storing varbinary(max)
binary large object (BLOB) data as
files on the file system. Transact-SQL
statements can insert, update, query,
search, and back up FILESTREAM data.
Win32 file system interfaces provide
streaming access to the data.
FILESTREAM uses the NT system cache
for caching file data. This helps
reduce any effect that FILESTREAM data
might have on Database Engine
performance. The SQL Server buffer
pool is not used; therefore, this
memory is available for query
processing."
Using file hierarchy, you can put the files out of the website file folder, for example, suppose the web folder is c:/inetpub/wwwroot/somesite, put the file under c:/images/, so that the web users won't be able to access the image files. but you cannot use the direct link in your website neither, you need to create some procedure to read the file, return the stream.
personally I think it's better to put the file in the database, still create some procedure to retrieve the binary image data and return to wherever it needed.
In reality both scenarios are very similar, so it's up to you... Databases weren't designed to serve files, but if the size isn't really a concern for you, I don't see a problem with doing it.
To answer your question about direct access, you'd setup the file images the same way you would for the database: You'd use some sort of page (probably a .ashx handler) that serves the images, allowing you a layer of logic between the user and image to determine whether or not they should have access to it. The actual directory the images are located in would then need to either a) not be part of the directory structure in IIS or b) if it is part of IIS, only allow windows authenticated access, and only allow the account the application process is running under access to the directory.
If you're using IIS7, since .net jumps in the pipeline early I believe you can protect jpg files as well, just by using a role manager and applying roles to file system folders. If you're using IIS6, I've done something similar to the answer by John, where I store the actual file outside of the wwwroot, and use a handler to decide if the user has the correct credentials to view the image.
I would avoid the database unless you have a strong reason to do this - and I don't think a photo gallery is one of them.
Neither. Amazon S3 offers a very simple API for accepting uploads. You can use SimpleDB or your SQL database to track the URLs and permissions. Set the entire S3 bucket to private, and authenticate to it using your AWS key on the ASP.NET server.
Very little code is required to upload to S3, and very little more would be required to perform bookeeping in SQL.
Once they're in S3, grab the image resizer library and the S3 Reader plugin and you can have your entire system running in under an hour. And - it will scale properly. No disk or database space limits. Ever.
You can implement authorization using the AuthorizeImage event of the Image Resizer library. Just throw an AccessDeniedException if access isn't allowed for the current user.
If you want to tune performance a bit mare, add both the DiskCache and CloudFront plugins. CloudFront can edge-cache the public images (inexpensively), and DiskCache will handle the private images, serving them at static-file speeds.
I have an ASP.NET page that will run on a shared hosting service (e.i. I'm leasing space on a single server that also serves content for other people) and I need a way to find a directory that I can save files in and that will not get hosted as web content. The file will be long lived and should be the same across sessions, visits, etc. I think App_data might work.
Is there a method or property that will give me an absolute path to such a directory?
Kinda like this question that doesn't have a useful answerer.
App_Data is safe because by default you can't download file from there by typing in a URL to your browser.
IsolatedStorage is good if you need to isolate users from each other. IsolatedStorage requires less collaboration with your IIS admin when it comes to granting NTFS rights to folders outside of your virtual directory. Blobs in the database are possibilities, too but the extra effort involved with blobs in databases makes it a last resort choice.
in /App_Data/ ?
Get a fileserver going.
Or a shared directory that all the web servers can access.
Due to permissions that must be established on the directory housing these files it is usually for the best that it not be in your application's path. Other than that it really just comes down to what you have available, and how you want to manage it.
If data is static - you can store it in resources too.
At least - i haven't heard any arguments why that is bad.
The server is IIS7.
Is there a way to disable web.config files in subfolders?
I am asking because, I have a folder on the web server that is for uploads. When someone uploads files, a new folder is created for the user's session and the files they upload go in the folder.
So the path to uploads would be like this:
~/uploads/3F2504E0-4F89-11D3-9A0C-0305E82C3301/somefile.txt
In the ~/uploads/ directory there is a web.config file that removes all http handlers except the static file handler and adds a wildcard mime type. So every file that a user uploads will only ever be served statically.
If a user uploads a web.config file, I want to disallow any of the settings in that file from being applied.
How can I do this?
EDIT
Could I just make the upload folder an application that is a member of an application pool configured to run in Classic mode instead of Integrated Pipeline mode? That way it wouldn't even care about a web.config file.
EDIT 2
Is there another type of webserver I could install for serving all files statically? I could just access the files through a different port. Is there some software that I can be sure wont run any scripts and is safe.
I simply wouldn't allow them to upload a file with that name. In fact, I normally wouldn't trust any filename that the user gave me... makes a great candidate for an injection-style attack.
Ok I have a different angle on this...
What if your uploads folder was not part of the website and instead part of the file system? This way ASP.NET is not processing requests to the folder and thus web.config wouldn't be loaded by the ASP.NET runtime.
You'd have to give your app pool's account read/write access to the file system where these files are stored, but I think it better fits what you're trying to accomplish.
Obviously it could be done in code.
If the folders always exist, you could pre-populate with a web.config with no (significant) content and an ACL to ensure it cannot be overwritten, but looking at the path it I suspect you create the upload folders dynamically which means this would not work.
I don't believe there is a way to tell IIS not to use a web.config (but I could be wrong). Personally, I would add a check to my save code and rename the file.
Why not just check the filename first to prevent the user from uploading a file named web.config? You're probably going to want to check for other things too before allowing the upload - files that are too big, etc.