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.
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?
First let me explain the problem:
I have a little portal that any user from the internet can access.This portal is responsible only for the user authentication against a DB.If user is validated than the portal shows a list of links where they redirect to multiple web sites(this sites are in various coding languages like PHP,ASP.net and Java). If the user input the url off a web site directly on the browser, the user can access the website.I want the multiple sites can only be viewed if the page request came from the portal and not directly inputed n browser.
I have local server with IIS 6, and the portal and websites are in this server.
Can anyone help?
Thanks in advance.
Gabe
If possible , host those applications as Virtual Directories under your authentication application and restrict access to only authenticated users, this shall solve the problem.
I don't know if you are able to do this, but you could try this with an ISA/Forefront server.
You can configure this to do the redirecting for you if someone enters the website url. This way users will need to authenticate themselves and you can let ISA or FF handle the authentication part.
This is implemented a lot for OWA, but can also be used for other purposes (I've done this for several SharePoint solutions).
Of course you do need an extra server, licences and all that stuff.
Don't know how you can pull something like this with only IIS. Perhaps with some IIS Modules, but I haven't got any experience with that kind of stuff, so don't know for sure.
I have a requirement which is to allow users to buy a domain through my site and then programatically set them up with email accounts at that domain, eg user1#domain.com user2#domain.com, etc.
To integrate the buying of the domain I'm planning on using a domain reseller like this.
The next step - of creating the email accounts - is where I'm floundering currently. I'm assuming I can programatically set the domain name to point where ever I need for the email pointers, but not sure how to programatically setup the email client on the other end. I don't care so much what the email client is - gmail, etc. Ideally I'd be able to brand it a bit, but it's not absolutely required.
Hoping someone has experience with this. Thanks in advance.
first you need to choose a mail server for your system. Then you get the SDK of this server and create with the provided interfaces users from your user interface.
For example, a basic free mail server is MailEnable that plesk also use for the same reason.
on this page you can get the sdk of the MailEnable mail server
http://www.mailenable.com/developers.asp
and there you can find the api to control it from your asp.net pages.
Hope this helps you to start.
We have an application that is for both internal users and external customers. We would like to authenticate against AD for the internal users and against sql membership for the external customers. Has anyone taken a similar approach? Also what is the best way to authenicate against AD when in a DMZ? I would rather have a proxy of some sort that is in the dmz and handles authentication against the AD DCs on our internal network. Any suggestions?
TIA,
Kevin
We have a similar situation. Our Internal users go against AD the external guys against an ADAM store. Different than your database approach, but similar in that they have two user stores. Our authentication against AD occurs in the secure zone, the web servers in the DMZ make a webservice call into the secure zone for authentication. Don't know what you are rally looking for, but your approach sounds ok.
EDIT to answer comments:
The ADAM store is not synced with the database.
Basically there were two providers that the webservice was configured to use, one for each store. I fact, there were three for a period of time when users were migrated from the legacy system. To determine which store a user was in, the application simply asked the most common provider first (ADAM in our case) and if the user did not exist, it would move to the next provider.
The endpoint was the webservice, inside the firewall, running on a the middle tier server. That server did run IIS, so technically it was a webserver, but actually our middle tier server as it did not serve up any pages or host anything other than a few webservices.
So it sounds like you have 2 types of external users. Ones that are really internal users (in AD) and ones that are truely external (in DB). This is not very elegant, but you could ave 2 login screens, one for each. Don't publish the internal users external login screen to anyone but them, and publish the real external login screen to teh world. A little hacky but it would work. Otherwise, you login would process will need to identify the type of user.
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.