I'm working an app with Angular.I want to get the data to be listed from rest api. However, I don't want users to access the resource. Which language, library or framework can I secure it with? And users are using the app without membership.
I tried jwt but I didn't get the result I wanted. Maybe I couldn't.
Here is express.js
const app = require('express')()
const express = require('express')
const fs = require('fs')
const cors = require('cors')
const bodyParser = require('body-parser');
app.use(cors())
app.use(bodyParser.json())
app.get('/', (req, res) => {
res.json({message: 'Rest API Work'})
})
app.get('/list', (req, res) => {
fs.readFile('data1.json','utf-8',(err,data)=>{
res.setHeader("Content-Type", "application/json; charset=utf-8")
data = JSON.parse(data)
console.log(data)
res.end(JSON.stringify(data,null,4))
})
})
app.listen(3002, function(){
console.log('Server OK')
})
I want a simple security method where I can connect with Angular.
Best way to secure your API is start using a reverse proxy like Nginx. Javascript frameworks are all basically the same in terms of security. They all have a basic router handler, dispatcher (based of native Node.js HTTP library) and some basic helper methods, they give it a nice catchy name and that's it. I've checked the source code of almost all major frameworks.
Now, some basic configuration params of Nginx are: client_body_buffer_size proxy_buffers etc. All your directives should regex input data too. Generally anything that could "filter" the malicious code is useful. Cloudflare can somehow help and some other companies that could secure your app but they're expensive.
Another good example is containerizing your app using Docker.
If you have a basic piece of code in Node.js, the most easy way to hack it is through your app's logic. You should use anti-XSS modules like xss or express-sanitizer. If you're using SQL database you should always escape the query values.
ASSUMPTIONS
I'm working an app with Angular.
I am assuming that you are doing a Web App, and not a mobile app with something like NativeScript.
I want to get the data to be listed from rest api. However, I don't want users to access the resource
I assume here that you want that only the web app to have access to the API, and not anyone else.
LETS TACKLE YOUR QUESTIONS
Which language, library or framework can I secure it with?
The problem is not the programming language or framework, but what you are trying to achieve, and I honestly have to tell you a cruel truth... In the context of the web is not possible to lock down an API to a Web app, and this is just because of the way the web was built, you know you hit F12 and you can see all the code running in the browser, therefore any secret you put there to identify your web app in each request it does to the API, will be up for grabs and reuse by anyone who wants to replicate your web app, and your API will not be able to distinguish the WHO is doing the request from WHAT is doing the request.
And users are using the app without membership.
Contrary to what many developers may think, authenticated users don't lock-down a web app or mobile app to the API server, because the user is only one part of the equation, he represents the WHO is accessing the API, but you still need to address WHAT is accessing it.
Wait, wait a second... You keep referring to the WHO and the WHAT, do you care to explain it in more detail?
Glad you asked ;)
The Difference Between WHO and WHAT is Accessing the API Server
So let's clear a common misconception, among developers, about WHO and WHAT is accessing an API server.
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
So replace the mobile app by web app, and keep following my analogy around this picture.
The Intended Communication Channel represents the web app being used as you expected, by a legit user without any malicious intentions, communicating with the API server from the browser, not using Postman or using any other tool to perform a man in the middle(MitM) attack.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using Curl or a tool like Postman to perform the requests, a hacker using a MitM attack tool, like MitmProxy, to understand how the communication between the web app and the API server is being done in order to be able to replay the requests or even automate attacks against the API server. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the web app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the browser were your web app should be running from, with a real user.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the web app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise, you may end up discovering that It can be one of the legit users manipulating manually the requests or an automated script that is trying to gamify and take advantage of the service provided by the web app.
Well, to identify the WHAT, developers tend to resort to an API key that usually is sent in the headers of the web app. Some developers go the extra mile and compute the key at run-time in the web app, inside obfuscated javascript, thus it becomes a runtime secret, that can be reverse engineered by deobusfaction tools, and by inspecting the traffic between the web app and API server with the F12 or MitM tools.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?. While in the context of a Mobile App, the overall idea is still valid in the context of a web app. You wish you can read the article in full here, that is the first article in a series of articles about API keys.
Now you may ask... If I can not lock down the API server to my web app only, how can I defend it?
Defending an API Server
To start with a web app or even a mobile should only communicate with an API server that is under your control and any access to third part APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
So anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about Mobile API Security Techniques. While this articles are in the context of an API serving a mobile app, some of the content are applicable for an API serving a web app to, and will help you to understand how fragile an API is when it comes to distinguish from WHO and WHAT is accessing it. So this series of articles will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.
Now that you are more aware of the pains of defending an API server, let's see what can be done to mitigate the security risks is facing in the context of a web app. For an API serving a web app, you can employ several layers of dense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about the detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All these solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that these solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at the same time they are properly keeping at bay the unauthorized ones.
CONCLUSION
I want a simple security method where I can connect with Angular.
So as may have realized already, you are not able to achieve a simple security method to lock down your Angular app with the API server. That's it, a simple security method does not do the trick, and instead you need to resort to several solutions, that will reduce the attack surface, but will not eliminate it.
So In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
I'm considering using Firebase with my Electron App. Specifically I'd like to begin by using Firebase Authentication to sign users in to my app. I've done tons of research regarding the subject thus far, and my biggest concern remains that the domain I'd require for an authorized redirect would need to be localhost (Please correct me if I'm wrong). The Firebase interface sets localhost as an allowed domain by default, I assume just for developer testing, not for a live production environment (Again, please correct me if I'm wrong). The image below is the section of the Firebase Authentication interface that I'm referring to, for setting up authorized domains.
My question is this, in order to distribute an Electron application with access to Firebase, do I have to have the localhost domain authorized? As well, if I do have the localhost domain authorized, is this secure, in the context of couldn't malicious users set up their own localhost and redirect to an unintended page, giving them the ability to freely add data to Firebase databases?
If there's an alternate, more secure option than authorizing the localhost, what are my options?
I've read in plenty of places that the bulk of Firebase security comes in the form of setting applicable rules on who can read and write to the database. Namely this post gives some good oversight on the topic. But I'm a firm believer that if there are extra security measures that can be taken, then always take them, so long as they don't diminish the quality of the application.
Am I being too paranoid, or is this the right approach? Thanks in advance! Any advice or guidance is appreciated.
I see many questions in your post, but I'll answer these two:
My question is this, in order to distribute an Electron application
with access to Firebase, do I have to have the localhost domain
authorized?
That's not something implied by Firebase. Having the localhost
domain authorized is just for testing purposes when you're running
your app locally before deploying to another domain.
If I do have the localhost domain authorized, is this secure, in the
context of couldn't malicious users set up their own localhost and
redirect to an unintended page, giving them the ability to freely add
data to Firebase databases?
Yes, it is secure. You said you haven't started with Firebase yet,
but when you do, you'll find out that you need to download the service credentials
to be able to use the SDK in your app. Only you have access to these credentials. That's why other users can't setup their own localhost and access your authentication system.
This question has come up at my job a few times, and I was hoping to get some community backing.
We are working on a Single Page WebApp, but require that the data coming from our services API be secure to prevent snooping of the data. We are also trying to iron out the prod environment details for where our SPA will be hosted. One of the options is using something like Amazon's S3, which doesn't support SSL (to my knowledge).
There's a group that believes the whole site needs to be hosted over SSL. However, it's my understanding that SSL will only protect the transmission of the data. So the point I'm trying to make is that hosting the services from an HTTPS site and the client code from non-SSL based URLs will be just as secure as hosting everything from an SSL site.
Could anyone clarify this for me?
Thanks in advance.
Yes, SSL just encrypts the transmission of the data, and does not offer any type of protection of the runtime environment on any client-side code.
Now, it is generally considered a best practice to host everything over SSL, for these reasons:
Users can get warnings that a site is transmitting data with an untrusted source if parts are from SSL and parts are not.
Any cookies, will be sent in the clear when requesting the non-SSL files and may contain information that should be kept private.
Is it possible to use SSL one one of the servlet-mappings in web.xml?
I have a site using GWT for browser access and mobile phones accessing the gae via simple HttpServletRequest in servlets.
The setup:
Browser GWT Access
For the site, the user log in via Google Account or Facebook. Then the user interacts with the site - no SSL setup here as I am using Google App Domain.
I guess the communication regarding user and password is safe in this senario with tokens etc. right?
Mobile Access
The user interacts with the Google App Engine(Java) from Mobile phones - the user and password is passed along each call. This I need to be SSL and safe.
I have seen thinks like this: using https sparingly in my GAEJ app
But I am not using RPC from the mobile access.
Any thoughts on this - Thanks in advance
Regards
Therefore I am thinking SSL on the Google Ap Engine, but is it posible in my scenario
Yes, it is possible to use ssl with appengine but you have to use the *.appspot.com domain, not your own domain name.
See the following link for information about securing specific urls in appengine in web.xml
http://code.google.com/appengine/docs/java/config/webxml.html#Secure_URLs
hth
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.