I've got SL application where i should implement file managment subsystem. I've got hierarchical structure of files\folders(just description). Also each file\folder has its own permissions to users\groups. I would like implement that one user who has permission to download file couldn't give it to another user, who hasn't this permission. So if user has download permission he get link www.site.com/file.rar and download it. But he could give this link to another person without permission. What alogorithm is more appropriate in this case? Any help would be appreciated.
The web server needs to be in charge and provide authentication and authorization for any file requests. It's not specific to Silverlight as this is a general problem.
Your web server must validate each file download request against the currently logged in user (which, if you were using ASP.NET, could be using one of the authentication methods such as Forms Auth, or Windows Auth for example). You might have an HTTP Handler for example that does this validation and allows the download (and provides the download file's bytes). Here's an older example, but looks like it's still applicable for ASP.NET for example.
Or, you could provide a securely generated, expiring (maybe one time use?), token in place of a file name, which maps to a preauthorized file request, and again serves up the file on demand. This one is more difficult to manage in many respects and could lead to a less pleasant user experience if not done carefully (especially if the download may be interrupted and needs to be restarted, then the old token may not be valid, etc.).
I'd go with the first suggestion as it's more reliable and easier to control and manage (ignoring technology specifics as that pattern is available in all web platforms).
You could store permission information in a database. Then each user will have their own account and permission set. Then you can set user group permissions to file groups or individual files.
This could probably also be achieved using the file permission information stored at the operating system level.
You can then have a dynamic page which takes a filename as a request and verifies a user name and password combination and checks whether that file is allowed for that person.
So when someone goes to that file link, they first have to provide the correct credentials to download, otherwise they are denied access.
I hope this helps, it wasn't a directly SilverLight answer but more language agnostic
Related
We have a requirement to enable drag and drop of content from Alfresco to a PLM application. Now we have created a new custom view with the PLM product and have incorporated an SWT browser in that view. The idea is that the user would enter the alfresco url and he would be able to drag and drop contents from Alfresco to PLM product using this new view.
The trouble here is that we are being asked to develop it as a single sign on application. The moment the URL is entered by the user, alfresco would ask the user his login credentials.
The user authenticates himself and would be able to view different documents.
But in order to actually download them, we need to set the user info. specifically the user name and password in the request to Alfresco. This is where we got stuck.
Is it possible to get a session or an equivalent identifier codefully [ Note that user visited alfresco url and has authenticated himself. So, we dont have any hold of his information there. ].
Requesting you to share any ideas...
Thanks,
Pavan.
Note: A new UI that would prompt the user to enter user name and password might be possible. But we do not want to resort to that approach.
First, some background.
Most web SSO systems work by authenticating the user themselves, and then setting a custom HTTP header containing the user identify (normally a plain username) which is sent to your web applications by a proxy. I'm not sure if that would work for you, but you may wish to investigate integrating CAS with Alfresco, assuming that both your applications are webapps.
Other options for SSO with Alfresco which might work for non-webapps are NTLM (old and insecure) and Kerberos (much more secure; recommended). These normally integrate with your operating system login session but must be configured in the user's web browser as well as in all the applications that you wish to SSO enable.
In summary, there are a few options that may be available but it depends on the nature of the second application that you want to integrate Alfresco with. I would suggest that you do some further technical investigation based on these areas and any others which others might suggest, and then come back with any specific questions that you have.
My team have been asked to 'enhance' a web app to permit the following. Is this considered a security risk in a web app? I'm not sure about this.
"Be able to access directories, for exporting and importing [data into the database] , outside of the virtual directory"
In other words the requester wishes to be able to navigate to a data file anywhere outside the application's IIS virtual directory, presumably when importing (or exporting) data.
I think this means on the web server, but it may mean local files on the client machine (to be clarified). But either way the question stands.
If you are talking about going outside the boundaries of the web application, that means a risk. Once you allow a particular user to go beyond your web application, then there is no more control in what that user could do with the webserver.
Have a look at path traversal attacks:
https://www.owasp.org/index.php/Path_Traversal
Also, here is a list of things to consider in order to avoid this:
https://www.owasp.org/index.php/File_System#Path_traversal
Any questions, just let me know.
Regards,
Fabio
#fcerullo
The question does not stand 'either way'. They are different questions. If it is about being able to select a file from the local computer to send to the remote server then that is pretty routine. e.g. one does it all the time while attaching a file to an email. The user is the one who initiates the file choice AND it is their file to send to the web app. No security hole here.
IF you have a need to allow clients to be able to browse the server computer for all sorts of files, then that itself is NOT a security hole. That is what you wanted, you got it. It is a security hole ONLY when you did not mean that the client should be able to grab hold of files off any whichever directory on the server. This whole scenario is classified as security issue because more often than not you do NOT want clients to have access to all inclusive files on the server. Typically the client needs to be able to access only certain files. Restricting you to virtual directory is one way of doing it. e.g. would you want your clients to be able to grab hold of the actual DB files with records of all users of your web site and then load that DB file in their own DB?
If you need to go beyond that, you need to implement mechanisms in place that allow access to only certain files. Remember your web server is running in the context of some user on the server OS. When the client request comes to the server, it that that web server user under which the command executes. So you cannot achieve security by simply putting in permissions for that web server user.
Big picture: I have been asked to create a search engine for our company's intranet. Such a search engine will crawl pages supplied to it by XML files for each independent application on the intranet. Problem is, the entire intranet is using Forms Authentication, and so the crawler will have to have access to each application without actually having user credentials (e.g. username and password).
Each application within the intranet has its access controlled by a permission manager, which is essentially a wrapper on the default Role Manager ASP.NET comes with. Each application can define its own roles and assign people who have those roles.
Please note that there are potentially hundreds of applications.
The crawler has access to the permission manager's database, so it knows what all the roles are. Therefore my idea was to have the crawler create a cookie that identifies it as having all roles for each application.
The problem I'm running into is this: how do I create a forms authentication cookie which already has the roles assigned in it without creating a corresponding user (IPrincipal).
It is entirely possible that I've failed to completely understand how Forms Authentication works, and if so, please tell me what I can do differently.
This is probably not what you want to hear, but...
I would just have the crawler authenticate like anyone else.
Given that this is a crawler you control, why fight Forms Authentication? Seems logical to create a user with all required roles in each application (hopefully you have a central administration point for the hundreds of apps, else I would not want to be an administrator there ;-)
If you do anything that allows "just the crawler" special access (bypass user-based authentication based on... what? The crawler's user agent? A specific origin IP?), you create a security hole that a hacker can leverage to gain access to all of the intranet applications that have otherwise been diligently secured with user IDs, passwords and roles (in fact, the security hole is particularly wide because you propose granting access to EVERY role in the system).
It sounds like what you want is an appropriately encrypted System.Web.Security.FormsAuthenticationTicket (which then gets attached to HTTP requests as a cookie).
The encryption logic is located in System.Web.Security.FormsAuthentication.Encrypt(), which I think uses the MachineKey as the encryption key. Also have a look at the GetAuthCookie() logic (using Reflector).
You might have to write your own version of the encryption method, but what you want to do should be possible, provided you have a copy of the remote site's encryption keys. You don't need the user's passwords -- only the user name is encoded into the Ticket.
It seems to me that the problem is not yet well defined, (at least to me!).
Why do you need to crawl the pages and index them if there are fine grained permissions on them?! How do you show search results without violating the permissions? Why not index the back end by passing the pages altogether (I mean index the database records not the pages)....
I allow the user to upload an xml file. From security perspective, what should I do? I want to prevent the user from uploading more than three times per day. I am looking for any suggestions about the security issues.
Basic sanity check on file size
Avoid validating using DTD or XSD. If you must, be sure to read about "XML bombs". Also, XSDs may be downloaded from the internet. An attacker may input a XSD url that takes forever to load, leading to a DOS
Verify the XML based on your business rules, and DELETE it from the hard disk if it doesn't pass you verifications.
If you save the files on your server, make sure the directory doesn't have execute permissions
Its a good idea to rename the file to a random name, so even if the file is "abc.xml", it will be saved as abc-433fdsadf3234234.xml on the hard-disk.
Do NOT allow the user to download the file that he uploaded via an anonymous URL. If you can, prevent downloads of uploaded files. If you cannot, use a throw-away domain or serve the file using ip address. This is to prevent content sniffing errors. Even if you set the content-type, some browsers can be fooled into thinking the document is HTML. This then allows the attacker to insert javascript code that can be executed by the browser.
EDIT :
Some more information on content-type sniffing
Lets say an attacker uploads an XML file that contains HTML in the first few lines. When a user downloads this XML, it is possible to trick the browser into thinking this XML is HTML.
Once you have fooled the browser, an attacker can execute javascript on the users browser. A simple example can be stealing the session cookies.
Putting it together, this is how the attack works -
1. Attacker uploads XML that has javascript code in it
2. Attacker sends the download link to another user who is the victim
3. Attacker can now execute javascript on the victims browser and steal his cookies
To prevent this - a) Validate the XML per your schema, b) Don't allow the user to download files that were uploaded, c) Serve the file from an ip address or a domain different than your regular domain - so that cookies cannot be stolen. You can read similar information over here - https://security.stackexchange.com/questions/8587/how-can-i-be-protected-from-pictures-vulnerabilities
Basic steps:
Require the users to have an account and be logged in before allowing them to upload any files
Count the number of files they upload each day
Don't allow them to upload another file if they have reached the limit.
Other than that, there are TONS of things to think about regarding security of uploading files, but none of the security things has anything to do with uploading only a certain number of files.
Limit the size of the file they can upload (reduces risk of a DDOS on the service)
Run it through a validation routine before consuming it (reduces risk of a DDOS on consumption of an invalid file)
Require authentication on the upload handler (reduces risk of unwanted files thrown your way)
Set a limit on the amount of time an upload can take (this reduces the risk of a DDOS on the service)
Ideally, if you are expecting an xml file of a specific schema, then see if the file presented validates against that schema rather than just as xml, and reject it if it does not.
Just a few to get you started.
You need to identify your users somehow, you generally have two ways:
using session identifier (stored in the cookie by default). This can be easily bypassed if the user deletes his cookies
by authenticating your user.
When your user is identified, you can extend your controller action method by business logic to check how many times that user uploaded file. And the rest can be same as the following article how to upload files in asp.net mvc.
If I give the Asp.Net user account (Network Service for Win 2003) modify rights to the root folder of my public website can a user send a request to the server to somehow modify the .aspx files of my website? What are the risks of doing this?
Short answer: Don't do it
Long answer: Still don't, but here is one scenario followed through that might make you think twice (there are prob many many more):
If you have an file-upload control anywhere on your site, say for image uploads, and an attacker manages to compromise your security (don't forget this does not necessarily mean breaking your site - they might just hijack someone's session or manage to guess/steal password) they can upload a malicious script (.aspx page). The site has "modify" permissions so it can write the file to disk.
I see you tagged the question with .net, so imagine they upload an .aspx page with some <script runat="server">...</script> that reads the contents of the web.config file and displays them.
Did you put any database connection strings with passwords in clear text in your web.config file? Cos' if you did, imagine their next step is to upload a new .aspx file that connects to those databases... they can then read your databases, delete data, change data... They probably don't really need the username/password because they can just use your named connection strings, but that information could be useful for another attack that I haven't thought of here.
I think you see where this scenario goes...
Is it safe to give the Asp.Net user account modify permissions to the root of the website?
100% definitely NOT.
can a user send a request to the server to somehow modify the .aspx files of my website?
Only if you build a page that does this in response to the request. Otherwise, no, not in one request.
What they can do is things like submit forms with way more characters in each field than your page was built to handle and attempt to create a buffer overflow they can exploit. But that happens over multiple requests. Or they can create an interactive http session and look for vulnerabilities to hijack your process that way.
Don't do it, it's dangerous. If you do, and if a malicious user finds a security hole (either in your code or in IIS), they will be able to modify files executed on the server and therefore execute malicious code.
If you need to write/modify files on the web server, you better give the aspnet user permissions to modify a separate folder, which will not have "execute" permissions under IIS (and perhaps even invisible to IIS altogether).
More info (regarding minimal required permissions, and therefore recommended maximal permissions): http://support.microsoft.com/kb/815153