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.
Related
I’m developing an UWP app for Windows 10 phone. The client request is to be able to get the HttpClient BaseAddress (Services address) from a local file located on the Host File like on desktop apps (C:\Windows\System32\drivers\etc\hosts). This is because they need to use the app on different local networks and they want to be able to change the URL manually from the file.
Any ideas? I didn’t find information about it. Basically what I need is to manually write an address in a file to be read by my app without allowing the user interact with the to file.
I see two conflicting requests in your question - being able to manually write address in a file while at the same time without allowing the user to interact with the file.
If you store such configuration anywhere in the file system, where it can be manually written to, you cannot prevent the user to do the same. You could store the file in the applications ApplicationData.Current.LocalFolder which is more secure (although a crafty user can still find a way to edit the files stored there) but you would lose the ability to make manual edits, so your app would have to contain an area that would allow the user to edit the configuration.
In any case - ability to manually edit means user can interact with the file as well.
My approach would be to ask the administrators to create a HTTP endpoint, that would always return the configuration information you require on any given network, which your app would download on startup to reconfigure itself.
If I pass in some Ids from an Asp.net application to SSRS server to render reports - how do I make sure that Ids are not read/modified by the end user?
One way I guess is to use ReportViewer control in Asp.net app and have SSL implemented, but is that foolproof? or are their better/alternate ways to implement security in such an app.
Three levels you could do for security purposes:
Change the default port on the SSRS server to something other than 80. EG: Change it to 81 and then someone needs to connect via: http:// (servername):81/ReportServer. Using a different port makes traffic not on the common internet port of 80 may be a good way to hide usage. This would also require that on the server hosting this port that you open this port up under Windows Firewall settings for use with this application.
Use the HTTPS with a certificate to determine that connection is valid between a host and target.
Set up only a single user on the SSRS Site aside from a local admin. Give that user read only rights. Set up your application to authenticate to the ReportViewer via remote mode but HARD CODE this value into your method, do not put in an app or web config. This way someone would have to have access to source code to be able to view user, they would not be able to get into the SSRS site to even see the user if they were not a local admin on the server hosting SSRS.
Those are my ideas anyways. Most of the time people have problems with SSRS being too secure to just get in versus yours you want more security. I hope some of this helps as I know that this method I cannot say is 100% foolproof(nothing is IMHO) but it now has added a level of complexity in adding a different port as well as a dedicated user with minimal permission only viewable by one other account but can be hardcoded in front end applications.
You can also add your security to your report level. Use User!UserID to capture who is logging into your report. and check that with a dataset you create from the application database that manages the access rights to the reports. This way, you can filter the data from showing for wrong users.
Note: Please consider this as another layer to your system security and Do not rely only on this. There are ways that a power user can go around this.
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
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
As the title suggests:
What is your opinion on allowing administrators to update the SQL Server Connection string dynamically from the application versus just showing them the connection details in the application?
Because the database connection is so important and on a heavily used system the abrupt change to the connection seems like it could cause problems. However I would think displaying the server and catalog and whether the connection is using SSPI or SQL Auth could be helpful for administrators who don't like playing with .NET config files.
Thoughts?
How are you identifying administrators? Presumably not by looking at the database. Because if you do use the db and then change the database to another server, it's possible they aren't administrators or there's no database, and then bam - they can't get in to fix it.
Typically, I like to do maintenance on this out-of-band (the config file or even in Active Directory, so it's in a centrally administered resource). We also typically have application administrators (roles, maintenance, approvals, workflow-related "administrators") who really are not system administrators in a technical sense. And often, we do not allow system administrators as user, managers or administraors within the application. i.e. I might have a purchase order system administrator who can void a purchase order, but they can't change a database connection and I have a sys admin who can't even create or approve a purchase order, let alone void one, but they can change the database connection in the config or in Active Directory as part of an upgrade or migration.
I agree that a debug page, help page or about page can be useful to show information to both system administrators and application administrators. Whether they should be allowed to change things there really depends.
Sounds like two bad ideas. Allowing changes to connection strings while the app is running is sure to cause disruption (broken connections, data out of sync, and who knows what else). And even displaying connection details to anyone (even admins) seems like a dangerous security hole.
What kind of site do you have where this sort of thing would be necessary?
Requires that your application run in full trust, otherwise it's just using the System.Web.Configuration namespace:
http://www.beansoftware.com/ASP.NET-Tutorials/Modify-Web.Config-Run-Time.aspx
On any change to the web.config the app will recycle, so still isn't something you'd want to in the middle of the day if sales might be in flight.
Also, usually authentication and authorization relies on the database. So if you can't authenticate and authorize, you won't be able to get to the admin page to change the connection string! (Unless your authorization and authentication has nothing in it that touches the database, at least for the admin page your considering)
Personally I don't like letting administrators change ANYTHING on a live site. All configuration changes should go through the same version-controlled, time-stamped, user-attributed, build-system-checked process that source code goes through. Only then can you draw connections "this stopped working at time X because user Y changed configuration A at time B".
An extreme view on the topic I know, but given the huge proportion of downtime that can be traced back to operator error I believe is justified, and I honestly can't understand the fascination people have for being able to edit fragile XML files on live servers where a single extra '>' can bring the entire site down.