I need to create licensing server for my application.
Application should ping licensing server and if license expired stop working.
How should it be done securely? I haven't found any articles about this.
More exactly, what confuses me is how to prevent attacker to do the following
Look where I make requests (using fiddler e.g.)
Create his own server
Point his PC to that server using etc/host file.
Any best practices about this?
You can do this by enabling HTTPS on your server. Your application will need to verify the HTTPS certificate to ensure the remote host is not a fake licensing server.
This article describes the attack you mention, and how is it possible to avoid it using HTTPS.
Here's a useful sample :
Defeating Active Attackers
Verifying the server’s authenticity is key to defeating active attackers. Fortunately, TLS has this covered as well. As you recall, HTTPS is really just HTTP running over TLS. When HTTPS is implemented correctly, here is what happens to active attackers.
Because the legitimate server’s Certificate Authority (CA) verifies
ownership of the domain (yourwebsite.com), an active attacker cannot
fake the certificate. Encryption prevents the attacker from reading or
modifying any intercepted data. In short, the entire CIA triad is
satisfied and both passive and active attackers are defeated.
In your case, the roles are slightly different : the user is your application, while the potential attacker is the application user who doesn't want to pay for a license. ;)
Related
I'm using AWS EC2 to run a database that supports search capabilities - similar to Elasticsearch. The database is only running in a single AWS region due to budgetary constraints.
The database is also running inside of a private subnet in a VPC. Currently there are no inbound or outbound connections that it can make.
I need to allow access to the database so that only my serverless functions can connect to it via HTTP. Users should not be allowed to access it directly from the client-side. Using Lambda is possible but is far from ideal due to long cold start times. Users will expect search results to appear very quickly, especially when the page first loads. So something else is required.
The plan is to replace Lambda with Cloudflare Workers. With faster start times and closer distance to end users all over the world, connecting to the database this way would probably give me the speed I need while still offering all the benefits of a serverless approach. However, I'm not sure how I can configure my VPC security group to allow connections only from a specific worker.
I know that my workers all have unique domains such as https://unique-example.myworkerdomain.com and they remain the same over time. So is there a way I can securly allow inbound connections from this domain while blocking everything else? Can/should this be done through configuring security groups, internet gateway, IAM role, something else entirely?
Thank you for any help and advice
There are a couple of options.
ECS
You can run an ECS cluster in the same VPC as your database, and run Fargate tasks, which have sub-second start times (maybe 100ms or less?). And you can run ECS tasks on hot cluster instances (but you then pay for them all the time), but perhaps a scale to/from zero approach with ECS would allow you to manage cost without compromising on most of user requests (the first request after a scale-to-zero event would get 100ms+ latency, but subsequent requests would get similar). Lambda actually does something similar to this under the hood, but with much more aggressive scale-down timelines. This doesn't restrict from a specific domain, but may solve your issue.
Self-Managed Proxy
Depending on how your database is accessed, you might be able to have a reverse proxy such as Nginx in a public subnet doing request validation to limit access to the database. This could control access by any request headers, but I'd recommend doing TLS client validation to ensure that only your functions can access the database through the proxy, and it might be possible to validate the domain this way (by limiting the trusted CA to an intermediate CA that only signs for that domain, alternatively, I think Nginx can allow a connection depending on traits of the client cert matches regexes such as domain name).
Route Through Your Corporate Network
Using a VPN, you can originate the function from within your network or somehow filter the request, then the database could still be in a private subnet with connectivity allowed from the corporate network through the VPN.
Use AWS WAF
You make a public ALB pointing at your database, and set up AWS WAF to block all requests that don't contain a specific header (such as an API key). Note: you may have to also set up Cloudfront, I forget off the top of my head whether you can apply WAF directly to an ELB or not. Also note: I don't particularly advise this, as I don't think WAF was designed with sensitive strings in the rules, so you may have to think about who has describerule / describewebacl permissions on WAF, also these rules may end up in logs because AWS doesn't expect the rules to be sensitive. But it might be possible for WAF to filter on something you find viable. I'm pretty sure you can filter on HTTP headers, but unless those headers are secret, anyone can connect by submitting a request with those headers. I don't think WAF can do client domain validation.
I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
Is there an elegant way to prevent requests from referrers outside the application? Looking at the app.yaml documentation, it doesn't seem like this is a in-box functionality but it seems like it'd be so preferred/common that it has to be hidden somewhere rather than necessarily having to reimplement it manually for every application.
It is built in.
In app.yaml you can specify login: admin for a handler and it would accept requests just from admin or from AppEngine (e.g. cron, taskqueues, and pribably urlfetch of the app itself - the last one not 100% sure).
See docs: https://cloud.google.com/appengine/docs/python/config/appref#handlers_element
Also you can check HTTP_HEADERS like referer, IP, user agent.
Also you can issue a token and pass/check it with every request.
There are probably a few issues being conflated here.
CORS - a browser enforced security measure to prevent pages maliciously or otherwise sending data to non-origin servers. Servers cannot enforce this, only permit it. Permitting this is an application level concern (i.e. Not built in to GAE)
XSRF - a server enforced security measure to stop authenticated users having their account abused by malicious client code. This is an application level concern (i.e. Not built in to GAE)
Authentication - identifying a user or client by some set of permissions. There is some support for this with GAE (cloud endpoints, provided identity service, requiring admin login), but it typically would also be an application level concern. In the case of authorizing a client (as opposed to a user) there is no built in support.
Authorization - different sets of access based on roles/permissions. Not built in.
Other solutions:
Using Host or Origin header - trivially outfoxed by someone implementing a curl request, or any application more sophisticated
API token - fine for server to server over https but trivially compromised when used on a published client (like a web page)
Your best bet is to leverage your framework and have user accounts.
If you don't want to do this, something like XSRF (token in a header and cookie) would be enough in the general case to ensure that a web client was responding to your 'app'. This only works if the client is a web browser though, same as origin/host.
No. There is no built-in logic in GAE for that. Any support would have to exist at the level of your application-specific request routing.
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.