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.
Related
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I have a system which will update some UI details regarding user notification every X seconds (just like StackOverflow's notification, gmail inbox and so on).
I am planing to have a webservice that will check for new notifications and have it called every X seconds. The fact is: I do not want to make it public for everyone, I want to make it accessible only to my system, so it is the only one able to consume it.
Is there any way to do that? Using a WebService is not required, if you have other approach I would like to hear it.
My system is built using ASP.NET 4.0 and Microsoft's MVC framework. Could I call an action to do that?
My question is similar to this: How do I secure ASP.NET web service to only allow relative path calling?
But as far as I understood the answer, he proposed that the webservice could be turned into an ordinary class method inside the system that is not accessible from outside. This does not work for me because I want to access it from the client side.
Thanks,
Oscar
ps: changing infrastructure configs (ex: hosting it in an internal server) would be hard to do...
EDIT: what I want to achieve with this webservice is to update the notifications number. This should be done without refreshing the page, for this reason I thought about verifying with the server if there are any notifications and, if there are, update the UI.
Edit2: I could transform this webmethod in an ordinary method inside my system, that would be no problem. The question would then change to How do I wire the client to this method? Maybe calling an action using javascript and then inside this action calling the method?
Deploy this WebService on a different web site and then configure this site to be accessible only from IP : 127.0.0.1. Also checkout this blog post - you could install the IP Security and then:
Lastly, to create the restrictions, open up the IIS Manager and select
the website that you want to restrict. Open the IP Address and Domain
Restrictions module, and then in the actions panel (on the right side)
choose Edit Feature Settings.... To only allow local browsing, you
should deny by default. Choose Deny from the dropdown, and hit OK.
Then add your exceptions -- the IP's or ranges that you want to allow
access to. To do that, choose Add Allow Entry... from the action
panel, and add all the exceptions you need.
Now, only applications running on the same web server can access this web service.
We've recently released the latest version of our intranet application, which now uses windows authentication as standard, and needs to be able to connect to a configured SQL server with the end-user's domain credentials.
Lately we've found that on a couple of customer deployments, although IIS can see the user's domain credentials, it will not pass these on to SQL server. Instead, it seems to use the anonymous account. This is in spite of following all the correct steps (changing the directory security to Win Auth, updating Web.Config to use Win Auth and denying anonymous users).
I've been doing a lot of reading that suggests we need to make sure that Kerberos is in place, but I'm not sure (a) how valid this is (i.e. is it really a requirement?) or (b) how to go about investigating if it's set up or how to go about setting it up.
We're in a situation where we need to be able to either configure IIS or the application to work for the customer, or explain to the customer exactly what they need to do to get it working.
We've managed to reproduce this on our internal network with a test SQL server and a developer's IIS box, so we're going to mess around with this set up and see if we can come up with a solution, but if anyone has any bright ideas, I'd be most happy to hear them!
I'd especially like to hear people's thoughts or advice in terms of Kerberos. Is this a requirement, and if it is, how do I outline to customers how it should be configured?
Oh, and I've also seen a couple of people mention the 'classic one-hop rule' for domains and passing windows credentials around, but I don't know how much weight this actually holds?
Thanks!
Matt
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
To run your application under the user's Active Directory or Windows credentials, ensure these:
the IIS application is set to NOT allow anonymous access
the IIS application uses Integrated Windows authentication
your connection string should have Integrated Security=SSPI to ensure the user's Windows/AD credentials are passed to SQL Server.
i.e. Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
You state you're not sure "how to go about investigating if it's set up or how to go about setting it up".
For this I'd heartily recommend a tool called DelegConfig. It's a very handy app that you can tell you if kerberos is setup properly.
Unzip it into a directory, configure a virtual directory in IIS to point to it. Browse to the main page and you tell it which backend server you want to allow access to (e.g. UNC, SQL, HTTP etc..) and it tell you its setup correctly or not and explain why.
It even has the abilty to recongiure the kerberos to fix the issue if you so desire (although I've not used this - I'd rather reconfiguire it myself to understand what I've done in future)
I realise this comes too late for your particular problem but thought it worth sharing for others that follow - especially the tools ability to explain why delegation is or is not working. I've found it invaluble.
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.
I have been tasked with getting a asp.net (vb.net) talking to an analysis services engine on our production servers. The web server is a separate machine from the web server. The web server runs as the IUSR_ user. The application (of course) works on the development machine which has both IIS and Analysis services on it. The problem I see appears to be a permissions error (returned in the browser by the asp.net app):
An existing connection was forcibly closed by the remote host ....
it is described in a similar post here: http://www.mydatabasesupport.com/forums/sqlserver-olap/201903-existing-connection-forcibly-closed-remote-host.html
I am not a system admin, nor am I an expert in analysis services (why have I been tasked with this you ask? because other people haven't been able to get it working and it has fallen on me). Anyway, I could use some help ... I have tried creating and adding the user (IUSR_) to the sql server and added that user to the role. While that worked on my local machine, it did not work in our production environment where the sql and web servers are separate.
tia,
Don
well after some fiddling i came up with something that works. its probably not a huge security concern because this server is not visible to the public internet; it is visible only to a couple iis servers (it is not on our lan) - this is, however, a 'brute-force', non-secure solution (in some environments anyway) ...
ON THE IIS SERVER: added this to the connection string in web config: SSPI=anonymous; this turns on an unauthenticated access request.
ON THE SQL SERVER: in analysis services, right click on the server. under "general" go near the bottom to "Security\RequireClientAuthentication" and change it to False
same page, select "security" on the left (instead of general). Add "ANONYMOUS LOGIN" to the list of users
get out of the server properties. right click on the CubeViewer role in the cube and choose properties. Add ANONYMOUS LOGIN to the list of users.
so, i have unauthenticated access from our iis server to the sql server.
i'd still be interested in seeing a more secure solution - oh, and i forgot to mention, there is no domain ... these are two servers on the same subnet with only regular logins.