If your API and Website making ajax calls to that API are on the same server (even domain), how would you secure that API?
I only want requests from the same server to be allowed! No remote requests from any other domain, I already have SSL installed does this mean I am safe?
I think you have some confusion that I want to help you clear up.
By the very fact that you are talking about "making Ajax calls" you are talking about your application making remote requests to your server. Even if your website is served from the same domain you are making a remote request.
I only want requests from the same server to be allowed!
Therein lies the problem. You are not talking about making a request from server-to-server. You are talking about making a request from client-to-server (Ajax), so you cannot use IP restrictions (unless you know the IP address of every client that will access your site).
Restricting Ajax requests does not need to be any different than restricting other requests. How do you keep unauthorized users from accessing "normal" web pages? Typically you would have the user authenticate, create a user session on the server, pass a session cookie back tot he client that is then submitted on every request, right? All that stuff works for Ajax requests too.
If your API is exposed on the internet there is nothing you can do to stop others from trying to make requests against it (again, unless you know all of the IPs of allowed clients). So you have to have server-side control in place to authorize remote calls from your allowed clients.
Oh, and having TLS in place is a step in the right direction. I am always amazed by the number of developers that think they can do without TLS. But TLS alone is not enough.
Look at request_referer in your HTTP headers. That tell you where the request came from.
It depends what you want to secure it from.
Third parties getting their visitors to request data from your API using the credentials those visitors have on your site
Browsers will protect you automatically unless you take steps to disable that protection.
Third parties getting their visitors to request changes to your site using your API and the visitors' credentials
Nothing Ajax specific about this. Implement the usual defences against CSRF.
Third parties requesting data using their own client
Again, nothing Ajax specific about this. You can't prevent the requests being made. You need authentication/authorisation (e.g. password protection).
I already have SSL installed does this mean I am safe
No. That protects data from being intercepted enroute. It doesn't prevent other people requesting the data, or accessing it from the end points.
you can check ip address, if You want accept request only from same server, place .htaccess in api directory or in virtualhost configuration directive, to allow only 127.0.0.1 or localhost. Configuration is based on what webserver You have.
Related
I know that if presented with an mTLS request an modern browser will request the user select a certificate from a store (OS-based or in Firefox's case NSS-based). I was wondering if there is any other way for the Webpage that is returned after the mTLS handshake to requests actions be performed with the users certificate or private key, such as:
Can the webpage be aware of the selected certificate and read some of the field with a Javascript API? (IE: <h1> Hello {x509CommonName}</h1>)
Can the webpage request that the user sign something with their private key? (little risky but potentially useful)
I am not asking how easy it is to just use the web server to reflect the certificate back to the client.
From the client side, it is not possible to obtain the certificate used in the SSL connection, nor to perform a digital signature. The browser keystore is not accessible via JavaScript. Although there has been some attempt to develop a standard API, it seems that it is not succeeding. See https://www.w3.org/TR/webcrypto-key-discovery/
On the server side you can easily obtain the certificate used. Any web server will provide it to the application layer. The web page could navigate to a zone with ssl two ways authentication, the server would retrieve the certificate and return it in the response
Is it possible to create a single policy that will forward all Options requests to the backend server? The only way I have figured out how to do this is by creating a new Options operation for each endpoint. That seems like a lot of unnecessary work since I want all options requests to be forwarded to the backend.
How can I create a single policy to forward all Options requests to the backend?
I don't think that is currently possible, so your only options are:
Create a separate OPTIONS operation in each endpoint.
Set up CORS (https://msdn.microsoft.com/library/azure/7689d277-8abe-472a-a78c-e6d4bd43455d#CORS) policy on a product or global level, so that OPTIONS requests would be served by APIM and not forwarded to backend at all.
Actually it is, operation template support wildcard /*
I am trying this, but since our API requires an SubscriptionKey, it is still not working. Since ApiMgmt will return 401 for options request, since browsers dont send the SubscriptionKey header.
Would be nice with the possibility to open single operations...
https://feedback.azure.com/forums/248703-api-management/suggestions/19450117-feature-to-ignore-api-management-subscription-key
I have this app that uses EWS to access mail, using the standard /EWS/Exchange.asmx SOAP endpoint.
One my user's mail servers is protected by Microsoft Forefront, and the initial HTTP request to
https://server_name/EWS/Exchange.asmx
is redirected (HTTP 302) to:
https://server_name/
CookieAuth.dll?GetLogon?curl=Z2FEWSZ2FExchange.asmx&reason=0&formdir=3
which is an regular HTML page, the point of which, I guess, is to make the user authenticate "manually".
I've not heard about Forefront until today, not sure how to handle it.
Is this normal behavior for Forefront (i.e. it always redirects the initial HTTP request), or is it triggered by something in my app? For example, user-agent?
If it's normal, how am I supposed to get past this page and access /EWS/Exchange.asmx?
If it's triggered by something my app is doing, how can I find out what it is?
My code runs on Android and forms its own XML requests without using any SOAP library. At the transport level, I use Apache HTTP client components. The code works fine with Office 365/Exchange Online, and, according to user reports, "self-hosted" corporate Exchange servers with NTLM.
However, in this case, I'm not even getting an HTTP 401: the HTTP 302 is returned by the very first HTTP roundtrip.
Trying to preemptively authenticate the initial request using Basic authentication didn't make any difference.
The user who reported this issue also mentioned that another EWS based app works, so there must be a solution to it.
Consider OAuth-2.0 Authorization Code Grant protocol.
As described in standard draft http://tools.ietf.org/html/ietf-oauth-v2-26 on Figure 3 : Authorization Code Flow a Client is getting token on behalf of Authorization Code received from User-Agent. Suppose that User-Agent is intentionally sending wrong codes to the Client. If Authorization Server makes some protection against brute force way of obtaining Access Token by banning Client for some reasonable amount of time (by IP or by Redirection URI host name). If in our case the Client is supposed to process horde of requests from multiple different User-Agent's the Client will stop to serve all its users altogether if there's only one malicious one exists.
So the Client becomes a bottleneck in a situation described above.
==== EDITED ====
Any ideas how to evade the bottleneck problem?
I believe you're asking:
"how to evade this problem and NOT to expose Authorization Code to User-Agent?"
This is not possible. The OAuth request flows through the user's browser so you can't prevent exposing the authorization code to the user.
If you're a victim to an attack like this, I'd suggest putting the same protection into your Client that the OAuth provider is putting into their Authorization Server. Namely, stop allowing new authorization codes to be sent from a User-Agent that's abusing your service. If they send more than, say, 3 invalid tokens per hour, ban them for an hour or two (by IP address). Of course, this could lead to you denying access to your site from proxy servers because of one bad user on the proxy, but that's life.
I have two websites http://www.example.com and https://www.example.com. I am using HTML5 session storage to store user preferences.
A user arrives at http://www.example.com and I load some default settings via ajax.
They browse to a page requiring login and are sent to https://www.example.com/login.html
After they are done logging in they are sent back to http://www.example.com where because they are now logged in I should fetch new settings from the server. The trouble is that http and https are different origins and can't share session storage.
Things I've tried that don't work:
Loading a page http://www.example.com/clearSession.html in an iframe that just runs sessionStorage.removeItem('key') to clear my data, but it seems that this has it's own browsing context so it doesn't work.
Things I've tried that work but I'm not wanting to use:
Using a cookie. This works great because http and https can share cookies but this means all my user settings get sent to the server with every resource request. This is usually about 4k but could be up to 1MB of data. No I can't host my resources on a different domain.
Don't cache the settings and just make the request every time to get the settings. I am doing this on older browsers as they don't support session storage but it slows down the page load and puts extra load on my database.
I can tell you how we have solved this problem, but it doesn't involve local sessionStorage. We use a server-side session to store the user's login data (username, ID, etc.) after they have been to our authentication server and back. Before they are authenticated you could still collect preference data from them by using AJAX to report these preferences back to a web service on the server that can store it in the server's session scope. This would break the RESTful model, however, because it would assume the use of server side sessions. That would depend on your server language and how you have your web services set up.
I think you will always bump into that origin problem because that is a restriction designed into local storage in general.
Switch everything to https, its a standard now.