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
Related
Is there a way to implement a cross browser single sing on using CAS? I'm aware that this isn't a standard workflow and that SSO workflows work on a single browser using session cookies, but we have a specific need that would require to automatically sign in in another browser (e.g. MS Edge instead of Mozilla) via some kind of URL parameter. We would use a custom protocols on OS level to be able to open a link in a different browser.
One thing that slipped my mind that you could use service token (ST) which you get in CAS callback of app1 and use it to open another application (app2) in a different browser. I guess you would also have to fake a client ID, i.e. use the one that retrieved a ST.
And of course, ST would need to be valid for a long time, i.e. it shouldn't quickly expire.
Is there some kind by-the-book alternative for this in CAS?
Thanks a lot!
Igor
CAS provides support for token-based authentication on top of JWTs, where an authentication request can be granted an SSO session based on a form of credentials that are JWTs. CAS expects a token parameter (or request header) to be passed along to the /login endpoint as the credential. The parameter value must of course be a JWT. You can create this JWT and pass it to any browser, and you'll get a session back. See this for more info.
Our situation: A Firebase web app does authentication via Twitter, also allows for token-authenticated calls to cloud functions that store data for a given user. We need a way to get information in the context of an arbitrary URL in the browser into that app with the currently logged-in user – much like the Read-It-Later/Pocket extension.
The JWT token via currentUser.getIdToken would be everything we need to authenticate calls from the Extension. Also, having users log in again inside the Extension, even if they're already authenticated inside the Web App isn't the best experience. Is there a secure way to communicate that token from our app domain to the Extension? Thank you!
Edit: We explored the possibility to set the JWT as a cookie and then read that cookie from the Extension. This works, extremely practical and simple. However, that cookie is naturally also susceptible to xss attacks.
Edit: Nice! Setting the cookie to "Secure", "HTTP Only" and "Host only" and accessing it via chrome.cookie still works! The cookie should be fairly secure and immune to scripting attacks now. Or are we missing something?
I've created a certificate and a key using openssl, and using node.js to server a simple (hello world) file.
Chrome acts like the request never gets to the server (server logs too confirms).
Firefox warns about the certificate, but lets you access the file.
See attached image.
Any ideas?
OS: mac 10.9.5
Chrome: Version 41.0.2272.118 (64-bit)
The whole purpose of certificates is to be signed by a third entity, called a Certificate Authority (CA). A client will generally not accept a certificate given by a server unless the server produces a certificate signed by a CA specifically known to the client.
The 'identity' of a CA and the process of 'signature' are cryptographic concepts that are very precise and strict in order to avoid bad guys impersonating other people (your bank, Google, etc.).
Browsers usually allow you to accept untrusted certificates on a per-session basis, because bad certificates are everywhere and are not necessarily always a sign of malicious activity going on. However automatic code (Node.js included) will almost universally reject bad cetrtificates, because there's no way to ask a user for an override.
What you need to do is to generate a CA certificate and instruct you node.js client to trust it. I think the following links to a valid sample:
https://github.com/coolaj86/nodejs-ssl-trusted-peer-example. Look specifically at request.js - the relevant line is
fs.readFileSync(path.join(__dirname, 'certs', 'client', 'my-root-ca.crt.pem'))
Try to troubleshoot this further. Try other clients or an http(s) proxy.
Specifically I would try other browsers, https://github.com/iSECPartners/sslyze, Fiddler, curl, and other similar tools.
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.
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.