We are using Web API 2.0 to serve clients in a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate). To secure content moving between the client and server, we'd like to be able to encrypt it. We're OK with un-encrypted HTTP headers (only need to encrypt payload). The question is: is there a way to insert a custom handler into both the request and response message pipelines so that we can apply a decryption as a request pre-processing step and an encryption as a response post-processing step?
We are using the built-in features of Web API to serialize/de-serialize between JSON and model classes, and don't want to have to refactor any of that existing code. So an encryption handler would have to be inserted at the very start/end of the request/response pipeline. Is this possible, and if so, what is the technique to insert custom request/response content pre/post processing?
The network is "public" in that users bring their own devices, but the network is isolated from the public internet. Clients will only use a custom application we are developing to consume our Web API service, so we can address implementation issues of a custom encryption scheme on both client and server side.
If you control the client application, you can hard-code the SSL certificate that the server is expected to return, which means that it doesn't have to validate through the normal PKI means (sometimes called certificate pinning). Most other approach will result in you attempting to re-invent SSL, but with some fatal flaw.
To be explicit, I think you are seeing a conflict between "a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate)" and "Clients will only use a custom application we are developing" where one doesn't necessarily exist. The user doesn't have to know that the certificate is self-signed, and self-signed does not always imply untrusted.
Related
I've created an API and deployed to Azure (be patient I'm new to all this). The API will be used by a single daemon app in another organisation. I'm planning to secure this by:
IP White List - this seems to work an to my mind makes the API pretty damn secure.
Client secret create by AAD - is this sufficient?
HTTPs - I've turned this on (Azure APP service TLS blade). However it just seems to work which always makes me suspicious, do I need to link a certificate? Is the encryption being handled behind the scenes?
If it's sufficient or not depends on your scenario. (e.g. is it hipaa / pci compliance?)
I would also add a Azure Key Vault for storing the secrets; WAF (Web Application Firewall) in front of the API + API Gateway (using API Management).
Your point #2 looks useless to me, you'd better request your client to authenticate against your azure Ad and pass the acquired token to your API. this way you'll know who / when called your service.
#3- Azure gives you a SSL certificate, but if you plain to use your custom domain (recommended), you could either generate a certificate using Let's Encrypt or buy from another trusted authority. The encryption happens at rest and in transit, but you could also use your encryption keys for the encryption at rest part.
Identity Server 4 exposes OpenID Connect Discovery via .well-known/openid-configuration url. Now I'm not fully clear why this is here or who should have access to it. The way I understand this, all this page does is gives out information about the endpoints.
The applications that will have access to my IS4 server will have the endpoints pre-configured as they are all internal so I see no reason to have this page exposed, I see it more secure not to give out this information out.
As such, My question is should I restrict access to this page and if so how? And if not, why?
The main benefit for keeping that endpoint is automatic client configuration. From the MVC sample on the AspNet.Security.OpenIdConnect.Samples GitHub page:
// Note: setting the Authority allows the OIDC client middleware to automatically
// retrieve the identity provider's configuration and spare you from setting
// the different endpoints URIs or the token validation parameters explicitly.
Authority = "http://localhost:54540/"
The server library has the ability to change any of the endpoint paths during startup, like the endpoint for obtaining a token. By using automatic configuration, your applications can automatically pick up on that change without you needing to update all your client applications manually.
This functionality is only offered as a convenience, should you want to use it.
If this application is only exposed to your internal network (or just within your own computer or Docker network), there is absolutely no harm in leaving this be.
If this application is exposed to the public network, then you need to start asking yourself if you want an attacker to know the information that the configuration endpoint provides.
All an attacker would know is the application is an Auth server, the paths to your various endpoints, what types of OAuth2 flows you support, and maybe a few other small details. If you have publicly facing documentation, this would just be a machine-readable version of that.
Rather than focusing on preventing access to the configuration endpoint, make sure that your Auth server endpoints are authenticated. You should be checking that the Client Id and Client Secret are present and correct before giving out tokens.
From oauth.com (this is about the introspection endpoint but really the principle applies to all endpoints):
If the introspection endpoint is left open and un-throttled, it presents a means for an attacker to poll the endpoint fishing for a valid token. To prevent this, the server must either require authentication of the clients using the endpoint, or only make the endpoint available to internal servers through other means such as a firewall.
I want to send data from my C# Windows 8 App to a PHP Script on my webserver to save Highscores etc.
But to avoid Manual insertions of fictional highscore values, I think I have to en- and decrypt it.
In which way can I encrypt data in C# which I can decrypt in PHP and maybe in the other way?
Or are there other Solutions to realize it?
Standard way to encrypt/decrypt data web-transmitted data is using the HTTPS protocol. All encryption/decryption happens automatically once the client and server authenticate and trust each other after exchanging certificates.
To avoid fake data talk only to authenticated clients that are authorized to insert the scores.
So you'd have a list of trusted clients, talk to them over HTTPS and each session would start by authentication (client would prove its identity to your server).
In my opinion the key terms you should definitely take into consideration are HTTPS (SSL Certificate), REST, OAuth
You may want to start by reading the
Open Web Application Security Project (OWASP) - Authentication Cheat Sheet
After that you may find useful some followup technical questions like:
https://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication
How to build a secure and RESTful service in PHP?
Simple PHP REST server with secure user authentication and registered third party applications
...?
I am new to web services so I created a web service to replace my current in-app DB transactions. I wanted things to be safer so that is why I went this way.
When using a free packet sniffer, it instantly grabs my web service ASMX call. The problem with this is that using a program such as fiddler they can easily see the data going back and forth and even worse set up a auto responder.
Is there a way to hide the calls being sent to the web service to hide from packet sniffers? Or at least make it more difficult to see the calls?
Expose it over a secured channel (such as SSL) only for transport level security.
Alternatively, you may choose to implement WS-Security to validate the identity of the callers, sign the payload or encrypt the payload (partially or fully); or any combination of the above.
Here is an article that talks about this in the context of ASP.NET: http://msdn.microsoft.com/en-us/magazine/cc188947.aspx
This the situation: I have one webservice without SSL, which provides two pages for the other web application. When the user submits these pages, an XML file with private information is sent to the webservice.
How can I provide the necessary privacy protection on the XML file? Is the one certificate good enough to give the appropriate security?
I'm not sure about this one, and am in the preparation phase of a project... So need to know the involved work on this part...
As an alternative to SSL you could encrypt the file yourself using any of the algorithms available in using System.Security.Cryptography but then you have to work out a mechanism to exchange your key(s).
However by far the easiest way will be to have both web services using SSL endpoints. That will take care of all your confidentiality, integrity and identity considerations in one fell swoop.
Certificates are tied to the hostname of the server (or, with wildcard certificates, all the hosts in a domain). So if the two services are on the same host, then both can use the same certificate.
If they are not on the same host there will be no transport security on the non-SSL service unless this is added separately. WCF has support for message (or part of message) encryption.
The simplest solution is certainly to use TLS, ex-SSL (widely supported in every programming language).
There is no need to buy a certificate (and it brings no extra security, it is mostly there to make PHBs feel better): either create self-signed certificates or set up your own CA.