I'm have implemented a module for Java web application that users will need to request for them to access the secured data. It works like this: when users that does not yet have access clicks on a certain link, a request is made and is received on the server side. It now generates an email and sends to people who are "approvers". The email contain links on approving or denying the access of that user.
Approved Link:http://hostname/App_name?action=actionClass&approved=true
Denied Link:http://hostname/App_name?action=actionClass&approved=false
Now the question is, is there a better way to do this which also takes into consideration the security?
I did try to look for other posts that are related to this but the results don't seem to be touching on this regard. If there are any that I have missed, I would appreciate if you can also point them so I can revise the question.
Thanks in advance
I'll assume that you are authenticating the users when they click on the given link, because otherwise it's just bad mojo.
You can have some privileges assigned to that user and check that to see if you are going to allow the approve or not.
That depends on how you are sending out the email. Assuming you are doing it client-side, then a user could intercept their own approval link, which clearly you don't want.
A better way (assuming you aren't doing this already) would be to send the user information (via HTTPS of course) to your server and then have the server generate and send the email. This way no one has access to the approval link except those emailed by the server and those in control of the server (you hopefully).
Related
I have a website and my own server and database, I also have an native Android app. I need to allow users to be able to sign-in with their account from the website inside the app in order to sync information and other things they need to use. I've been stuck for a couple of days trying to figure out how to do that. I've found a lot of content regarding OAuth and AppAuth but they are focused on using an OAuth API to the job. Back on my server, I use Hybridauth for social login, but users can also register directly on the site. How would be the proper way to allow my users to sign-in to their website account through the Android app?
You're overthinking it. OAuth isn't meant for users to log in, it's meant to enable external services to access data on behalf of a user.
To make a user log in? Create a POST endpoint on your webservice named login. It should take two parameters- username and password. The body of the login service should salt and hash the password, then check if the hash equals the hash stored in the db for the same user. If so, you're logged in and you return a success packet with a unique token to authenticate you for later requests. If not, you return a failure. The Android app would ask the user for their data, then send a request to the endpoint. On success it saves the token and sends it in all future requests to authenticate yourself, either as a parameter or as a header.
This is of course the simplest possible version. More advanced features would include expiring of login tokens, refresh tokens, possible lockout if you have too many bad requests, etc. But the above is the basic idea. Although really I'd look for an open source solution you can take, as there's quite a lot of complexity when you get into all the stuff mentioned above, and its a place where a mistake that leads to a vulnerability is probably the most dangerous.
I have a problem with the Docusign embedded Edit View.
My application connects to Docusign via JWT. Using the API, I'm allowing users to edit existing envelopes (when in draft) through my own application. The redirection to docusign works fine and the users are able to edit an envelope, adding/removing recipients, setting the signature blocks, etc. All good there. My problem is with the callback.
Using the ReturnUrlRequest, my callbacks are successful and after editing an envelope, users are redirected back to my application. The problem is that before this happens, for a few seconds they are looking at the Docusign inbox for the account. This is a security issue and could allow users to see privileged information, as if they send an envelope after editing it, they'll be looking at the sent folder and can see all other recent envelopes. I presume they could also stay in the inbox and do whatever they wanted if they click on an entry quick enough, but I haven't confirmed this yet.
I need the callback to go directly from the envelope edit to my application, and prevent anything else from docusign from appearing. Is there a way I can lock this down?
And yes, I know that this is something I shouldn't be doing in any event, and that my basic problem is that I'm using the edit view in the first place. I don't have much of a choice. I originally implemented things using the API and my own application provided all of the configuration options on their own. The client, however, didn't like this and essentially demanded that their users be allowed to use the Docusign system's own editing suite, as that is what they are familiar with. I'm trying to square the circle as best as I possibly can.
As per the Information Security Notice on the linked page, the Create Edit View provides fully authenticated access to the sending user's account. Even if you were able to prevent the brief view of the inbox, a savvy user could 'break out' of the edit view by navigating directly to app.docusign.com (or appdemo.docusign.com in the sandbox) because their DocuSign session is still valid.
The only way to 'secure' this is to provision each sending user their own membership on the DocuSign account so that users cannot see each other's envelopes (unless explicitly allowed to do so via Document Sharing).
In addition to Drew's answer: please ask your DocuSign account rep or customer service contact to add your customer information to internal ticket EC-1009. That will help raise prioritization of providing a secure edit screen for applications to use.
i am working on a java/j2ee based web application where i have one module called leave management in which when the employee request for the leave the manager approves or reject leave by log in to the application,Here log in into the application creates an extra overhead for the user , so i am trying to implement a feature where the manager can approve or reject the from his/her mail itself as mail is sent to the manager every time the employee request for leave based on the parameters in the url in the link like this
without log in to the application
https://my.xyz.com//LEAVE#LeaveReq#123#1545#State
So my question is
Is it possible to achieve this without log in to the application and saving values to the database and without breaching the security.
2.If yes, how can i implement this?
Yes you could. Just pass in some other parameters like say we call it token which would contain a "random" string which is currently in your database.
Each request that doesn't require authentication should also pass in this token. You check the token in your database if it is there then do the request, if not, you know what to do. If a token is consumed, you could either delete it from your DB (meaning each token is one-time use only).
EDIT: Regarding whether the correct manager approves/reject, well that's difficult without something like authentication to identity the manager.
We just rely on the fact that that URL can only be used once, and that it can only be seen on the email of the appropriate person.
is it possible? Certainly.
Is it desirable? Maybe not. What prevents someone else from sending that confirmation email? You need to find a way to secure it all.
How to do it? A REST webservice comes to mind, with the manager just clicking a link in that automatically generated email which launches a webservice request.
Or you set up a system where the server can receive emails, and the manager can then just forward the leave request to either of 2 email addresses.
There should be at least single authentication like a pin code or password before manager approve or disapprove the leave. Don't think about overhead, for such circumstances security is equally important.
Is it possible to achieve this without log in to the application and
saving values to the database and without breaching the security.
When the manager gets an email & he clicks on the approve. Ideally a request is fired from manager's system carrying an authentication token or something like a remember me token. In this case the application won't prompt the manager to login. It will tally the request token with token stored in the db & would let manager in.
Check how remember me works in web applications. You can create a remember me token for manager for an indefinite amount of time. This way the app will never prompt the manager for a login. But there is a caveat, this approach is a little vulnerable for attack. If there is a man in middle attack the hacker will get hold of the manager's client side cookies & would always login with ease. The auth token should be changed periodically. You can always implement remember me, it just depends on what level of security you require.
Bottom line: Yes it is possible, generate a remember me token which will always be included in the manager's email request for approving employee's leave request. Just follow the best practices to implement a remember me token.
Another way is
If your application is implementing security using filters. You can bypass the request for leave approval. Just put a secure none attribute for that particular request in ant style say "yourapp/approval" resource. Now the server side code would let all the requests in this pattern pass without security check. But this approach is a strict No No. If this happens a hacker which intercepts the leave request from the employee's browser can approve his leave by himself. No need of manager's authentication.
If yes, how can i implement this?
Implementing remember-me for a website
You can also integrate Spring Security with your code. It's hell of a framework, one stop solution for all the security related features which your app would require. You don't have to write the login for implementing auth token & stuff from scratch.
Is it possible? Certainly.
Is it desirable? Yes
Use a one time hash(sha1 hash may be) in the link to approve and after approving the email, send an email to the person who approved the email saying that "He/She has approved a leave for this particular person"
So the manager/authorizer is aware about it.
How password rest with an email link works could be a good analogy.
I think login is not critical for this scenario assuming that cancelling a approved leave is not that critical.(It happens usually in many companies)
I am getting confused.
I have to write an Java Serverapplication for an mobile application. We have our own user management in that application, meaning the user can register and login on our servers without using an OAuth-Provider at all.
Now I want the user to be able to alternativly register via an OAuth Provider.
These are the options I see:
Let the user register local only.
Advantage:
The mobile applications can use the frameworks which are able to login and retrieve an access token for our application
Everything is prestyled by the platform itself, so no GUI work on that
Disadvantage:
How does the server know if the user is logged in or not? One way to figure that out could be to send the access token to the server and let the server start a request to the provider to check if the token is valid or not.
For the registration I have to send all user information which the client got from the provider to our servers.
I dont like this option, cause I would send Userdata and Accesstoken arround. Yes, it would be crypted via https of course, but it just feels wrong.
Let the user register via our servers
The user requests the OAuth provider itself to retreive the code with which you could request the access token.
Send this code to the server and let the server retreive the acess token.
Advantage:
The Server can be sure now, that the user is logged in
The server can retreive all user specific information about the user (such as username etc) from the OAuth provider itself, without sending the arround.
On a login you can repeat this, to make sure that the user is logged in correctly
Disadvantage:
I have to write the OAuth connectors (or using some library for that)
We are not able to use the sdk's, cause they're just returning the actual access token.
We still prefer the first option (register local only)
Because
they WANT to use the sdks. "'cause everyone does it."
If the user would start the application the first time and he was logged in already (with i.e. the FB client), he just has to accept the scopes, we setted up for our application.
Easier to handle the actual login, cause the sdk's where made for it
Does anyone know how to do something like that correctly? Both solutions seem a bit wrong to me.
The idea is the following.
The user sends credentials to the server (username,password).
Server tries to login to the website and parses useful data. Some
data remains to server in order to provide notifications if
something changes in the next parse.
Server sends data to the user application.
User interacts with data and makes requests to server to receive
data
loop between 3,4
logout
The problem is security and privacy. How to exchange this kind of information between server and the application securely? Also i don't like the idea of people sending me their credentials.
How to implement such a thing knowing that the site i am screen scraping does not provide an API to do this job?
Instead of storing their login details you could store the session cookie and reuse it until expires. Hopefully it would last step 5 but if not you could ask for their login details again.
The only specific problem here is the screen-scraping, the other tasks are too vague to answer.
I can recommend screen-scraper.com (I am not affiliated in any way).