iRecently my app got hacked by using sql map.We added few filters to avoid unwanted requests but how to integrate security to the api calls, in back end my app communicates with spring controllers.
Well are you using any authentication on the requests made from the mobile?
Like JWT or a security token. You can check this ionic or auth.
Also make sure your making the api call your making it you can hide it many ways. Store it in a object and then call that object when your making the http or ng-resource request.
Related
I am planning on hosting my REST API in a VM in a VNET where the only point of entry is via Azure API Management.
I have multiple back ends so the API Management will route to a different backend base url depending on the group the user is in and the backend will also return different data depending on the user making the call.
Since the Azure API Management can handle authorisation, JWT validation and setting headers etc what type of authorisation code should I put in my REST API application?
Should I try to validate the JWT again in my Java code or just parse the headers?
i.e. is it safe to code it as a public API and trust that the headers have been set correctly by API Management?
Or should I make a call to Azure Active Directory from the Spring controller every time to validate that the user does actually exist in the specified group and that the group specified is the one expected for this backend?
If so, how would I do that from Java and how would I inject an offline version when running locally?
Since your API will be inside a VNET it'll be protected as it is. But, there is really no reason to just have it open. The more layers of protection you can add the better your chances to whistand a potential attack.
So see whatever is most convenient to you. You can rely on APIM doing user authentication and authorization and avoid doing that in your backend API. But it would be a good idea to check if call made to your backend API is coming from APIM, and you can do that by sending credentials from APIM. The best option here would be client certificates: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates
But you can also send basic credentials: https://learn.microsoft.com/en-us/azure/api-management/api-management-authentication-policies#Basic
We are designing an application which can be accessible via both mobile app and web app.
Mobile app will get data using exposed REST API (we are using CXF). For web app, we are using Spring MVC, it will also get data from REST API. In both cases, we want to show data for the authenticated users. For authentication, we are using JWT token.
My question here is we are offering two ways of accessing data via REST or web, and both need authentication. How can we reuse our security code in both components.
URL for web component
http://localhost:8080/web/resource/
URL for REST API component
http://localhost:8080/rest/resource/
URL for authentication
http://localhost:8080/auth/
Initially, we thought of having two different filters for each component, i.e. web and REST. From each of them we'll make a REST call to authentication API for validating the token. One doubt with this approach is if user going through web, then with this design we are validating token twice. So the better would be calling to the authentication API from REST API, avoiding it in web because rest api will always going to make authentication call.
Is there any other better way to do the same?
I am using some angular ui routing in some places, and I wanted the java server to not control some of the urls.
Perhaps it makes more sense to run the java app elsewhere? The reason I have the angularJS in the same url is because there are some authentication checks for my springboot app. So I want most URLs controlled.
But there's a few where I may want to control the authentication----but not the templating.
I think my problem is my Spring Boot code is trying to use velocity, when some of those URLs should just forward to AngularJS routing.
So a URL=/myreport/
--> goes to Java 404 error, instead of just forwarding to Angular UI Routing
--> But in some cases, Java should return 404/500/403 et al
Is there a way to do like a RestController that just forwards to AngularJS after authenticating? or to disable velocity??
This would probably be more straightforward if you limit your Spring Boot code to just doing authentication and providing an API, and implement all of your UI in the Angular app.
You can then still use Spring Security to control access to the API.
On the Angular side, you can use AuthGuards in your routes to control access to parts of your UI based on the user's role.
To get a nice, clean separation, it is helpful to use token-based authentication instead of, say, Form-Based or Basic authentication. That way, the Angular app can present the login UI, and make a REST call to the Spring Boot app to log in, and get a token back, which is used on subsequent calls.
If you use JWT, you can have the back-end produce a token that includes the users' role, and then read that in the Angular app.
I recently wrote a 2-part blog post showing how to create an Angular 2 app with a Spring Boot back-end using JWT.
See http://chariotsolutions.com/blog/post/angular-2-spring-boot-jwt-cors_part1 and http://chariotsolutions.com/blog/post/angular-2-spring-boot-jwt-cors_part2
We are planning on developing a layer of REST services to expose services hosted on a legacy system. These services will be used by a classic web application and native mobile phone applications.
This legacy system is secured in such a way that an initial username + password authentication is required (a process that can take 5 to 10 seconds). After the initial authentication, a time-constrained token is returned. This token must then be included in all further requests or else requests will be rejected.
Due to a security requirement, the legacy security token cannot be returned outside of the REST service layer. This means that the REST service layer needs to keep this token in some form of user session, or else the expensive username + password authentication process would need to be repeated for every call to the legacy system.
The REST service layer will be implemented using a Java 6 + Spring 3 + Spring Security 3 stack. At first sight, it looks like this setup will run fine: Spring-based REST services will be secured using a rather standard Spring Security configuration, the legacy security token will be stored in the user's HTTP session and every call will retrieve this token using the user's session and send it to the legacy system.
But there lies the question: how will REST clients send the necessary data so that the user's HTTP session is retrieved properly? This is normally done transparently by the web browser using the JSESSIONID cookie, but no browser is involved in this process. Sure, REST clients could add cookie management to their code, but is this an easy task for all Spring RestTemplate, iPhone, BlackBerry and Android clients?
The alternative would be to bypass the HTTP session at the REST service layer and use some other form of user session, maybe using a database, that would be identified using some key that would be sent by REST clients through a HTTP header or simple request query. The question then becomes, how can Spring Security be configured to use this alternative session mechanism instead of the standard Servlet HttpSession?
Surely I am not the first dealing with this situation. What am I missing?
Thanks!
There's nothing magical about cookies. They're just strings in HTTP headers. Any decent client API can handle them, although many require explicit configuration to enable cookie processing.
An alternative to using cookies is to put the JSESSIONID into the URL. I don't know anything about spring-security, but it seems that that's actually the default for at least some types of URL requests, unless disable-url-rewriting is explicitly set to true . This can be considered a security weakness, though.
Unfortunately authentication is highly problematic -- a bit of a blind spot in terms of web standards and browser implementations. You are right that cookies are not considered "RESTful" but purists, but even on fully-featured browsers avoiding takes quite a bit of hackery, as described in this article: Rest based authentication.
Unfortunately I haven't done any mobile development, so I can't suggest what the best compromise is. You might want to start by checking what authentication models each of your targetted platforms does support. In particular, two main options are:
HTTP authentication (ideally "digest", not "basic")
Cookies
One possibility would be to provide both options. Obviously not ideal from a technical or security point of view, but could have merits in terms of usability.
I'm hosting a REST web service in a Grails application, using Spring Security, i.e.:
#Secured(['IS_AUTHENTICATED_REMEMBERED'])
def save = {
println "Save Ride REST WebMethod called"
}
I'm calling it from an Android app. (Calling the unsecured service works just fine.)
To call the service, I'm manually building up a request (HttpUriRequest) and executing it with an HttpClient.
I'm wondering what the best practices are, and how to implement them... Specifically, should I:
Perform a login once, to retrieve a JSESSION_ID, then add a header containing it into the HttpUriRequest for each subsequent request?
Or (not sure how I would even do this) include the login and password directly on each request, foregoing the cookie/server-side session
I think I can get option 1 working, but am not sure if Spring Security permits (2), if that's the way to go... Thanks!
--also, there isn't any library I'm missing that would do all this for me is there? :)
Spring security does support both basic authentication and form based authentication (embedding the username/password in the URL).
A REST service is generally authenticated on each and every request, not normally by a session. The default spring security authentication (assuming you're on 3.x) should look for basic authentication parameters or form parameters (j_username and j_password) (in the form http://you.com/rest_service?j_username=xyz&j_password=abc).
Manually tacking the j_username/j_password onto the URL, adding them as post parameters (I believe), or setting the basic authentication username/password should all work to authenticate a REST service against the default Spring Security interceptors, right out of the box.
I will admit that I haven't tried this on REST services, though I do clearly recall reading exactly this in the docs as I did the same for basic page logins on spring security recently. Disclaimer over.
I think you can use a login-once-and-get-a-token method that's similar to how oauth works.
sending username and password across the network outside of secured channel(https/ssl) is a terrible idea. anyone on the network can sniff your request package and see the clear text password.
on the other hand, if you use a token method, since the token string is randomly generated, even the token is compromised, the worst case is someone can use the token accessing your REST API.
another solution is going through ssl tunnel(HTTPS). i have actually done a comparison and result shows: 80 requests/min(https) vs 300 requests/min(http)