I am coding a webapp (E-commerce) for learning purpose using AngularJS + BootStrap and REST.
I have used Apache Wink for REST WS and and application is deployed on JBoss EAP 6.4. My application is working fine.
I can access the back end data using AJAX and webpages are getting populated properly. The issue is security of REST WAS. If I use REST URL directly on browser, without going through front end, JSON data gets populated and my data is exposed. What design changes should i do ?
Please note that initial operation on the website for e.g. browsing the products, adding them to cart etc are stateless. No user's identity is needed for these operations. I still need to secure my data for these interactions. Please suggest, how can I do it.
Sunil
If you want to lock down the services, you may require some type of authentication (for example user/pass) that returns a security token (over https). Then all subsequent function calls may require the security token to be passed in as a parameter (if the operation is sensitive). The token will require a session timeout.
However, if the data is also publically shown on the site, then there's not really a security risk in itself. IOW, how is this any different than them using the public website to get/update data? The rest services usually shouldn't require any additional level of security beyond what is already used on the website to protect the data.
Related
I’m currently working on a PoC with multiple Quarkus services and Keycloak RBAC. Works like a charm, easily to bootstrap and start implementing features.
But I encountered an issue that I could not solve in my mind. Imagine:
User accesses a protected service
quarkus-oidc extension does fancy token obtaining by HTTP redirecting, JWT in cookie lasts 30 minutes
User is authenticated and gets returned to the web application
User works in application, fills in forms and data
Data is being stored by JWT-enriched REST calls (we do validation by hibernate-validator)
User works again, taking longer than 30 min
Wants to store another entry, but token from step 3 is now expired and API call fails
User won’t be happy, so me neither
Possible ways to solve:
Make the JWT last longer than the current 30 minutes, but that just postpones the issue and opens some security doors
Storing users’ input in local storage to restore it later after a token refresh (we also would do that to not loose users’ work)
Refresh the token „silently“ in JS without user knowing. Is there a best practice for that?
I missed something important and the internet now tells me a better architecture for my application.
Thank you internet!
Re the step 3. In Quarkus 1.5.0 adding quarkus.oidc.token.refresh-expired=true will get the ID token refreshed and the user session extended if the refresh grant has succeeded
For such use cases, I tend to prefer the reverse of JWT. I keep the user data in a shared data service (a data grid like Infinispan or Redis). So that this data is keyed by the user and available. I do control the TTL of that data in the shared data service.
It can either be specific to an app, or shared between a small number of apps. It does bring some coupling but so does the JWT property structure.
For Quarkus, there is an Infinispan client integration, a Hazelcast one, mongodb and AWS dynamoDB. And you can bring other libraries.
I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.
Say you're developing an application which consists of a backend HTTP API, which serves a frontend UI. The UI, upon being rendered on the client's browser, will need to make certain calls to the backend (e.g., fetch data for views). However, all these calls are can be checked on Chrome's developer console, for example. This exposes my application's overall logic and internal API endpoints.
Is this a concern for a web application? I looked around some other websites (e.g., Reddit) and I was indeed able to check an API call was being made and I even managed to reproduce it via cURL, getting the same response back.
My first idea to solve this would be to encrypt all data and have it decrypted internally in the frontend app. However, I don't think this would provide much security since the private key would have to be hardcoded in the app's source code, which can also be checked by modern browsers. Besides, this could greatly impact the application's performance.
The best I could think of was to somehow assign a token (JSON Web Tokens, maybe?) to the session (which in turn is assigned to a user). This token would be needed to make the API calls, and maybe it could have a short expiration time. However, the token can still be seen in the HTTP request.
Any ideas?
I am using bcrypts => https://www.npmjs.com/package/bcryptjs + jsonwebtokens in my MEAN app for the same. Bcryptjs creates a salt at the server side and send an encrypted token to the client. The same token is used for API calls. This makes decoding a bit harder for any phishing attempt.
Use HTTPS instead. => Are querystring parameters secure in HTTPS (HTTP + SSL)?
I'm new to Shiro. We are attempting to use Shiro with Stormpath. I've been trying to dissect the examples to come up with a solution to what I want to do, but I'm unsuccessful so far.
For now, I'm simply trying to create REST services to do what I want, and I'll tie a real client in later. This is what I'm trying to achieve as my first step:
I want to have a client hit a REST endpoint (login) on my server. My server would authenticate, and return a JWT to the client. This JWT would then be used to access secured endpoints on my server. (I have written Java code that can successfully authenticate against Stormpath).
My problem is the JWT. I expected that a JWT would be created for me, or at least easily accessible. I can't find a way to get one. I have seen sample code on how to build one, but that doesn't seem like the way I would expect to acquire one.
I have run through several examples, but most seem to deal with JSP interfaces, and I can't seem to make the leap to what I'm trying to do.
Is this approach reasonable? Any guidance is appreciated.
Edit 1
I now have a Java client that can authenticate using the Shiro servlet and retrieve a JWT. I have this running as a deployed application (war) in GlassFish. My next step is to use that JWT to authenticate against a different application that has my REST endpoints. This REST application doesn't need to know anything about how to authenticate - I just want to pass the JWT along in the call to a given REST endpoint and use Shiro (via annotations) to control access to the endpoint (if that is indeed possible). All of the examples I can find seem to be "all-in-one" examples (bundling JSP with Shiro/Stormpath configurations, etc). I'm trying to determine the minimum working configuration for securing REST endpoints and I'm having difficulty determining which pieces of the configuration I need.
Edit 2
I am using the Stormpath-Shiro-Servlet (as stolen from the Shiro Servlet example) as my authentication back-end. Using my Java client, I am sending a login request to the servlet, and I am indeed getting back a JWT. However, I am not able to successfully use the JWT to access my other rest resources. My rest calls result in this error:
org.apache.shiro.authz.UnauthenticatedException: This subject is anonymous - it does not have any identifying principals and authorization operations require an identity to check against. A Subject instance will acquire these identifying principals automatically after a successful login is performed be executing org.apache.shiro.subject.Subject.login(AuthenticationToken) or when 'Remember Me' functionality is enabled by the SecurityManager. This exception can also occur when a previously logged-in Subject has logged out which makes it anonymous again. Because an identity is currently not known due to any of these conditions, authorization is denied.
First, I don't understand why the servlet 'login' doesn't actually log me in and give me non-anonymous principle? Second, I am attempting to do everything on a separate client, so I don't have access to Subject.login (is this a correct assumption?).
Take a look at this example from github/stormpath-shiro
The JWT creation is managed for you by the Stormpath API. If you start up one of the examples, (the servlet one above, or the spring-boot-web example), after login, you will have a JWT cookie. There is background info in this blog post.
I'm working on releasing strompath-shiro now, but figured I'd include these link here so you can start looking.
I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)