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?
Related
I am new to tableau. I have this complicated problem in our system, where I am trying to use trusted authentication to by-pass tableau login. We have installed Tableau server (ex: 1.2.3.4) and have added the webserver (ex:1.3.3.4) to its trusted hosts list. In order to connect to the servers, we use Cisco VPN our IP is dynamic.
The tableau reports are to be integrated to a asp.net web application hosted in the webserver (1.3.3.4), which has an existing login mechanism. So, I would like to avoid/by-pass the tableau login. To achieve this, I am trying to use trusted authentication. When I tested this in the webserver (1.3.3.4) as mentioned in the link : http://kb.tableau.com/articles/knowledgebase/testing-trusted-authentication, it returns ticket value only when I send the client IP. But when I try to access the embedded tableau reports, I am unable to get the reports. Instead, I get "Could not locate unexpired trusted ticket" error. Also, I am unable to find ways to retrieve VPN IPs of the clients from my webserver. My requirement is to find a proper way to avoid tableau login (using trusted authentication) while embedding the reports in our asp.net web application.
Is there any other possible way of implementing the same or am I missing something? Since I can't find any proper examples for the same, I am posting this question. Kindly provide me your valuable inputs in finding a suitable solution.
Thanks in advance.
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.
hey guys i have written a small webservice which allows users of a company (lets call it xyz) to login to xyz's website remotely via my iphone app (without ever going on xyz's official website to login)
after logging these users programatically to xyz's website, i can allow my users to do many authenticated tasks xyz offers
since xyz does not offer apis for this i was forced to hijack xyz's login cookies from my webservice to allow users to use all the authenticated features
at no point of time am i saving xyz users username or password and use https for my webservice to ensure safety n security of users
however i have got an email from xyz asking me to shut down my webservice otherwise face legal action. if i do that my users would be very unhappy to loose so many cool features of my iphone app
i wanted to know the best way to host my webservice on some offshore server which has elastic / dynamic ip addresses with completely different patters (so xyz cant block a particular range of ips or even domain names)
i have heard amazon provides elastic ips - can they be used for such scenario
or can someone help me come out with a better solution
webservice is asp.net 3.5 based
You should negotiate with them and find out what they don't like about your service.
You can then modify it to be friendlier to them.
Alternatively, you can get rid of your webservice and connect to their control panel directly from the iPhone.
Looks like you are asking for help on doing illegal things. Not a smart thing to do on something as public as this.
Best advice I can give is bite the bullet and take your service down.
I've built an ASP.NET application that's using Forms Authentication. In our hosting account control panel, I set up an automated task that requests a web page once per week. When the page loads, a number of emails are sent out.
I'd just like to know if there's any way to determine in the code-behind if the request is coming from the local machine (as with Windows authentication). Using a separate web.config file in the page sub-directory with Windows authentication mode doesn't work.
The application will work fine either way. I'm requiring that a specific Guid value be present in the query string, so it's very unlikely that the task will be executed by mistake. I'd just like to learn something new while I'm working on this, and I'd like to see if I can add this little bit of extra verification.
Thanks very much for any advice.
Request.IsLocal
The IsLocal property returns true if
the IP address of the request
originator is 127.0.0.1 or if the IP
address of the request is the same as
the server's IP address.
Request.Url.IsLoopback
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.