Me and a team built a small "meet people" app last semester that used Spring linked to a MySQL database as the backend. I am working on my own app now and I'm worried about security because all of our user information was sent over HTTPS GET requests to the server. It seems weird to me that we were able to hop on google chrome, type in xxx.xxxxx.xx:xxx/user/2 and get back a JSON with all of a specific users information. If anyone knew our url/port, they would be able to access this information themselves.
I'm sure this is a basic question, but what steps do I need to take to create a Spring backend that isn't as easy to access? I'm basically a total beginner in this, but I did write the service in Spring last semester so I know the basics.
You can use Spring Security which is a very good project and easy to integrate.
There are many types of security features it provides :
Basic Spring Security
Role Based Spring Security
baeldung.com and howtodoinjava has a very good series on it.
You can also use jwt-authentication-on-spring-boot which is also a good way to secure the APIs.
Related
I've read a lot of articles on this subject and they all suggest completely different things that I can't yet structure in my head.
I have one backend app (spring-boot + kotlin). I have nginx and one android (kotlin) mobile app uses backend api and of course Postgres. By the way backend app and postgres are packages in docker containers via docker-compose.
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
For example:
Spring-security: a huge thing that you don't know what to do with, most likely you can use it to solve your problems, but it's overkill. But if you decide to use spring-security, this will help you {...}
...
By the way, I'm not against spring-security, I just really think it's too much for my task. But I'd be happy to hear your opinion.
Your Problem
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
You have in hands a very hard task to complete. While not impossible it's very hard to accomplish with code written on your own or by trying to leverage security features on your framework of choice.
To understand why it's so hard you first need to understand the difference between who is in the request versus what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
After you understand this idea and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
Possible Solution
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
The best approach to solve your problem is to go with a Mobile App Attestation solution suggested in the answer I linked. A Mobile App Attestation needs to be able to work in tandem with your mobile app and backend in order for the backend to have a very high degree of confidence that what is making the request is indeed a genuine version of your mobile app, that hasn't been tampered with statically or at runtime, and it's not under a
MitM Attack
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Be aware that solutions to solve your problem that are specific to the backend or to the mobile app will not be able to achieve a very high degree of confidence in securing your API backend from serving requests not originated from your genuine mobile app, but it's better to have them then nothing.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
The easiest way probably is to define a shared secret on the phone and the backend service.
On the mobile phone, with each request, you send the secret, e.g., as an HTTP header.
On the backend, you need to implement a Filter (e.g., OncePerRequestFilter) that checks the request for the secret and compares it to the value stored in the backend.
I want to develop a (REST API) web app using Spring, and for the authentication/authorization I am thinking about using OAuth 2.0, but I am not sure whether OAuth is a good option or not.
some information about my app:
1 - completely RESTful API.
2 - microservice Architecture.
3 - using the API for both web pages (maybe SPA) and mobile apps(android and ios).
4 - the API will be used only by our developers (web site developers and mobile app developers), and never by other third-party developers (as far as I know the main purpose of OAuth is for third-party applications).
based on the given information, is it a good idea using OAuth instead of a custom Spring authentication/authorization server with JWT? if yes, what are the benefits?
some disadvantages and advantages from my past experience:
Disadvantages :
OAUTH authentication payload will contain : username, password, grant_type, client_secret and client_id.
The last two ones are specific for third-party login, do they make sense for your application and clients?
Spring OAUTH is a powerful library and will do a lot behind scenes. If you will need custom behavior, it will a little bit trickier to find the right hooks.
Development time took longer (both client and server) in comparison with simple username/password login.
Advantages :
The protocol is well documented, so you will have less overhead when documenting your application.
It will be easier to integrate with third parties (if ever is required).
P.S In your initial iteration you can start with simple login and add later third party integration(both can work together)
I have several Spring web apps, each with its own database.
Now I have to create a web app, that works as enter point for all the other apps..
So if I want to use the web app B I have to pass through the enter point web app. I have to do the login inside this app. To do that I have to sign in against Active Directory.
After that the users can access only to the apps where they have permission, and inside each app they have also some different roles.
what kin of solution can I adopt?
I read about SSO but I'm not sure it is correct.. So, do you have any idea?
EDIT
What do you think about microservice? Is it good for my scenario?
It seems to me you are describing microservice architecture and it is a good way to go. You are likely to need OAuth2 for your authentication. I used this tutorial from Baeldung as a good starting point, although I personally changed the front end from Angular to React but that is down to you.
Your architecture must be micro-service and you might use a API Gateway at front of your interfaces, I suggest you to use Kong - Open-Source API Management and Microservice Management, that have many features like OAuth2
and many other.
Then you can have one or more client-sides that calls one entry point to your services.
i'm designing a security module for a web application using spring security . There are 3 separate wars(3 Apps)using separate login, deployed in a JBOSS Server.
The requirement is , If the user is authenticated in one app then he should be able to access other applications without login . Is it possible to share the security context between the web application( different wars not in a single EAR ).
We discussed about the SSO , but we are trying to achieve this with spring security and with support of the App server . Is there any way ? Please provide your valuable suggestions and inputs.
If you need more information, please let me know.
The easiest way is to employ usual Spring Security authentication (e.g. form-based with username/password) and enable the remember-me feature.
As long as all three applications are deployed on the same domain (and can therefore share their cookies), the remember-me feature will work seamlessly for all of them, i.e. once user authenticates at any of the applications she will be able to access the others without need for re-authentication.
This of course doesn't address issues like single logout, but that doesn't seem to be your aim anyway.
You can set this up in a short time and don't need and third party SSO components. Although relaying on standard SSO protocols and dedicated technologies tends to be a more secure option.
I've done this recently with SSO and Spring Security however I wrote our own security filter to be used which grabs the HttpServletRequest.getRemoteUser() value provided by the SPNEGO filter. One thing with SSO: most mechanisms use Kerberos which only really works in local desktop environments. It is possible to write a fallback mechanism which will redirect the user to a login page but then you still have your issue at hand.
Another option would be to repackage your applications as an EAR (see here).
I have a pretty simple question (for once :D) :
Do you know if a talendconnector to google-contacts exists ?
I can't find one into http://www.talendforge.org/components/, neither on the 4 first pages of Google itself.
As a fallback, do you think it would be possible to wrap a Talend component around google-contacts ... I guess yes, and so I would be surprised that no one had already developped it !
I've not seen a Google Contacts connector in Talend but there's a problem in the fact that to access the API you will need to auth via OAuth2. There's currently nothing standard in Talend to help with this (although it would be pretty useful) but Gabriele Baldassarre who semi regularly answers questions under the Talend tag has built a series of components to access Twitter data which has a similar OAuth requirement.
His website might be a useful reference to building this should you want to do so.
Edit
As of 5.4 Talend's RESTful components such as tRestClient now support OAuth2 so it is possible to provide OAuth2 tokens in your RESTful connection to help you connect to web services secure by OAuth2. There's not (as of yet) a Google Contacts connector available but you could replicate it now.