I have java web application using struts 1.x. Recently my application has gone through penetration testing and our testers found some security holes. Let me explain. In my application i have 2 users called ‘Admin’ and ‘user’. First our PenTester logged to my application as ‘Admin’ and they use ‘Burp tool’ to intercept the request and copy the whole request content into notepad and then forward the request. Now My application log in as ‘Admin’. They use another browser instance to login as “user” and use burp tool to intercept the request. This time they removed the whole request content and copy back the whole request content of ‘Admin’ and then forward the request. Now my application logged in as ‘Admin’ without asking any user id/password? How to restrict this situation? I already stored userid in my session variable after successful login of each user. The moment they intercept the request and copy the ‘admin’ request content, my session variable userid also changed to ‘admin’. How to validate this situation? Your help is really appreciated.
That is not really that much of an issue since the first part "copy the whole request content" is not easily doable if you have a proper HTTPS / SSL connection. That only works if the PC the user is logged in on as an admin is compromised in which case: nothing you can do about it anyway because they can just sniff the keystrokes and get the plain password.
If on the other hand you communicate without the S, namely just HTTP then the solution is: get a certificate and switch to HTTPS.
Apart from that your application can pin a session to an IP which means if the session id / cookie is stolen and someone else uses it you can detect an IP mismatch and ask for credentials again.
To prevent direct replay attacks like copying the request and sending it again you can introduce a hash that incorporates the timestamp or alternative measures, see. How do I prevent replay attacks? . The problem however is that copying the entire request means copying the cookies as well and if the "admin" cookie is copied this measure will not prevent you from "generating" a new hash based on the now admin user.
Related
I want to know how the token based authentication is done in Java. I want that if I hit my application then the system should redirect it to the login page and once the user enters the credentials, the user shall be validated and authenticated. Once authenticated a token should be generated which shall be handled across client and server. My concern is if the token is generated, how it is being passed to the client and how the client sends it back to the server on every request processing. I know that it has to be set in header. But my question is how exactly. I know we have spring and all but I want to know how it is being done using jsp and servlets.
I went across few websites but unfortunately could not find the expected result. A small demonstration shall be very helpful. Thanks in advance.
There is no such authentication token. There is a session token defined in J2EE Web Application server standard (https://docs.oracle.com/cd/E19644-01/817-5451/dwsessn.html). Once the JSessionId is established between server and client it is used to manage the user.
For example if you build you own authentication system you can bind the jsessionid with user login attempts, and keep a list of jsessionids which has logged in successfully. This is basically what authentication frameworks do.
Also, you can check this Under what conditions is a JSESSIONID created? and this: Spring security FAQ
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.
I have an application(client application) hosted in a Tomcat server and this application has to be integrated as a Tab in another application(parent application). In the Parent application the user authentication is done. in the Parent application Html we are using iframe to integrate the client. Everything is working fine except this. The Problem is, if some one knows the URL they can access the client application. How can we avoid this.? we are using JAVA,SERVLET,HTML,Tomacat as technologies.
Thanks :)
One of possible solution is token based authentication.
The parent application should add special token either as a URL parameter or as HTTP header. The token should contain authentication information in encrypted form. "Client" application should extract the information and decide whether authentication passed or failed. In order to guarantee that no-one can copy this token and then get unauthenticated access to your application you should make the token to be one-time or limited in time range.
You can also use x-frame-options in your header. I found this article with some quick googling: http://www.jtmelton.com/tag/x-frame-options/
This will prevent your app from loading in frames except for the domains which you allow permission. You might check into browser compatibility, I'm not sure when this was implemented in different browsers.
Also, you can check the 'host' and 'referrer' header fields to check that requests are coming from a domain you trust before sending a response.
OAuth is the standard for authorizing third party apps. You should check into that as an authentication approach.
None of these will give you a completely secure app. You should consider consulting with a security expert.
From parent application add cookie and from child application get that cookie and validate user.(if both are running on same domain).
I am using GWT for my client side application. I am not using GWT/Java for the server. However, I am not sure how I can handle session management. The GWT application resides on one page, all server calls are done via AJAX. If a session expires on the server... let's assume the user didn't close the browser, but left the application open, how could my server notify the application that the session has expired and that the client side portion should show the login screen again?
What is meant by client side session management? That seems inherently insecure.
I'm not looking for code. I'm looking for ideas, techniques, potential solutions etc. I've considered Comet http://en.wikipedia.org/wiki/Comet_(programming), but that doesn't seem like that will work very well without using Java on the server side. Maybe, I'm wrong? I don't want to poll the server either.
Any thoughts or insight?
Without knowing how you're doing your RPC is working, its hard to give good advice.
If your AJAX service requires a user to be authenticated (IE have a valid session), it is ok to just send a 401 error saying that the user is invalid. Client-side can interpret the 401 error as a message that it should set the user up for re-authentication.
We handled this in our application, by detecting when the server sent back a redirect to the login screen (it would come through the response to the Ajax call), and popped up a dialog asking the user for their password again, but pre-filled their username. We then posted that to the same place the login page does, as if it was the login page, and so the user was logged into this new session automatically. Finally we just re-submitted the ajax call again, so it was a seamless process to the user (eg: they didn't have to click the action again).
Since we stored all the state on the client, and not in session variables we didn't have any problems trying to persist data across sessions.
What should happen if the session expired on the server-side, then the next time the client sends a request to the server, it will either create a new session, or, more likely, send back a message to the client that it is trying to access a page without a session, and send them to the login screen. However, you will still need to wait until the client sends a message to the server.