When a user signs up in our Struts application, we want to send them an email that includes a link to a different page. The link needs to include a unique identifier in its query string so the destination page can identify the user and react accordingly.
To improve the security of this system, I'd like to first encrypt the query string containing the identifier and second set the link to expire--after it's been used and/or after a few days.
What Java technologies/methods would you suggest I use to do this?
I'm going to make some assumptions about your concerns:
A user should not be able to guess another user's URL.
Once used, a URL should not be reusable (avoiding session replay attacks.)
Whether used or not, a URL shouldn't live forever, thus avoiding brute-force probing.
Here's how I'd do it.
Keep the user's ID and the expiration timestamp in a table.
Concatenate these into a string, then make an SHA-1 hash out of it.
Generate a URL using the SHA-1 hash value. Map all such URLs to a servlet that will do the validation.
When someone sends you a request for a page with the hash, use it to look up the user and expiration.
After the user has done whatever the landing page is supposed to do, mark the row in the database as "used".
Run a job every day to purge rows that are either used or past their expiration date.
For the first part have a look at Generating Private, Unique, Secure URLs. For the expiration, you simply need to store the unique key creation timestamp in the database and only allow your action to execute when for example now-keyCreatedAt<3 days. Another way is to have a cron or Quartz job periodically delete those rows which evaluate true for "now-keyCreatedAt<3 days".
I think you can do this in a stateless way, ie without the database table others are suggesting.
As mtnygard suggests, make a SHA-1 hash of the URL parameters AND a secret salt string.
Add the hash value as a required parameter on the URL.
Send the URL in the email.
When the user click on the URL:
Verify the integrity of the URL by calculating the hash again, and comparing the calculated value to the one on the URL.
As long as you never divulge your secrete salt string, no one will be able to forge requests to the system. However, unlike the other proposals, this one does not prevent replaying an old URL. That may or may not be desirable, depending on your situation.
Related
In our project we have the following:
A list of Notes documents with fields:
Our System's user ID (our name)
System B's Auth Object (their name)
System B's token
I decided to write a Java method for updating the token (every 30 minutes). Basically, it'll iterate through the list, execute a REST method to their system and finally we'll get a new token and write it to the document. There are not so many documents (in fact, always fewer than 10, but the request can take a lot of time)
However, I stumbled upon a problem. What if a user's request will be executed simultaneously with token refreshing? How should we treat such a case? Should I have something like a lock for eliminating such a possibility? And in the code of each user's request we should send a request only if the document is unlocked? How can we "wait" for that unlock?
Thanks in advance.
Just use the default Locking mechanism in Notes: document locking needs to be enabled in Database Properties. Then you can do the following:
If doc.lock( timestamp ) then
'Document has not been locked previously
'Your code comes here
'Don‘t forget to unlock at the end
End if
Parameter usually is a username, so why use a timestamp as a „pseudouser“? The „locking“ user is always the signer of the code, you need to differentiate between the different calls, so use a timestamp to identify the session uniquely.
I want to make a javaEE application when users can register and confirm their email when receiving a email with a link after inserting their data in registration form (name, mail...)
To do that I am going to generate a long and unique key with java.util.UUID, store in a database and then send an email to the user with that key being part of the URL (Example: www.mysite.com/account.xhtml?id=KEY). Then the user will click the link, I extract the key from the URL and check if that key is stored in the DB. If it is, the user registration will be completed.
My question is, when creating that key with java.util.UUID, how can I know that it is a unique key? Should I check if there is another equal key in the DB and if so create a new one until the created key is unique?
What's the chance that a randomly-generated 128-bit integer will be equal to another randomly-generated integer?
If you just need peace of mind, use a primary key and if the insert fails due to a key collision, re-create a new UUID and retry the insert.
There are couple of ways you can do UUID in Java.
Java 5 onwards better practice is using java.util.UUID It is size of the string 36 characters. This link gives you simple example.
This discussion will give you answer to your question. It is very strong. I have never came across someone is complaining about its uniqueness.
But if you adding into DB or using in storage or using through network, size may be matters. So converting to other formats - Bases is good solution (Base64, Base85 etc). Please check this discussion here. You can use apache library org.apache.commons.codec.binary.Base64. Base85 is not safe for URLs.
My recommendation is, if you have may application/session beans/web services (many interconnections other applications and data transfers etc) are creating UUIDs, I prefer to do unique application name padding too. Like APP1, APP2 etc and then decode to other bases. If UUID is 6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8, then APP1-6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8 like that...
Though it is off the topic here, BUT When you use a URL like this www.mysite.com/account.xhtml?id=KEY, beware about SQL injection hacking attacks.
I'm generating a unique id(generated by the frame work used are, so I should use only this ID and there is no API in the framework to check if this generated by the framework. Thanks RichieHH for pointing this) for each request in the web application and this can be presented back as a part of another request to the system. Now, I am storing these unique ID's generated in the database, and for every request the DB query is issued to check if this ID already exists(this is how the validation is done currently for the unique ID's). Now, if I have to validate the ID sent in the request has been generated by the application with out using the persistent storage, which approach should I be following?
My initial approacht is to generate the ID which adds to particular sum after hashing, but this can be identified after going through the patterns.
It will be great if some one can help me with an approach to solve this problem in a way it can validate the uniqueID generated with in the application. Thanks.
Use UUID, which is pretty standard solution for this task. You don't need to validate UUID, you can assume that it is unique always.
You can use ServerName+Timestamp+some extra. It can be more advantageous for debug but less secure.
I want to implement double submission prevention in an existing java web application (struts actually). Architecture wise we are talking about 2 to N possible application servers (tomcat) and one single database server (mysql). The individual servers do not know each other and are not able to exchange messages. In front of the application servers there is a single load balancer which has the ability to do sticky sessions.
So basically there are two kinds of double submission prevention client side and server side. If possible I want to go server-side because all client side techniques seem to fail if people disable cookies and/or javascript in their browsers.
This leaves me with the idea of doing some kind of mutex-like synchronisation via database locks. I think it may be possible to calculate a checksum of the user entered data and persisting it to a dedicated database table. On each submit the application would have to check for presence of an equal checksum which would indicate that the given submission is a duplicate. Of course the checksums in this table have to be cleared periodically. The problem is the whole process of checking whether there is a duplicate checksum already in the database and inserting the checksum if there is none is pretty much a critical section. Therefore the checksum table has to be locked beforehand and unlocked again after the section.
My deadlock and bottle neck alarm bells start to ring when I think about table locks. So my question is: Are there saner ways to prevent double submissions in stateless web applications?
Please note that the struts TokenInterceptor can not be applied here because it fails miserably when cookies are disabled (it relies on the HTTP session which simply isn't present without session cookies).
A simpler DB based solution would be something like this. This can be made generic across multiple forms as well.
Have a database table that can be used to store tokens.
When an new form is displayed - insert a new row into the token table
and add the token as a hidden field in the form.
When you get a form submit do a select for update on the row
corresponding to the token you received as a part of the form.
If the row still exists then this is the first submit. Process the
submit and delete the row.
If the row doesn't exist then the form has already been processed -
you can return an error.
The classic technique to prevent double submissions is to assign two IDs (both as "hidden" field in HTML Form tag) - one "session-ID" which stays the same from login to logout...
The second ID changes with every submission... server-side you only need to keep track of the "current valid ID" (session-specific)... if you get a "re-submission" (by click-happy-user or a "refresh-button" or a "back-button" or...) then that wouldn't match the current ID... this way you know: this submission should be discarded and a new ID is generated and sent back with the answer.
Some implementations use an ID that is inremented on every submission which eases a bit the check/kepp track part but that could be vulnerable to "guessing" (security concern)...
I like to generate cryptographically strong IDs for this kind of protection...
IF you have a load-balanced environment with sticky session then you only need to keep track of the ID on the server itself (in-memory)... but you can certainly store the ID in the DB... since you store it together with the session ID the lock would be on "row level" (not table level) which should be ok.
The way you described goes one step further by examining the content... BUT I see the content part more on the "application logic" level than on the "re-submission prevention level" since it depends on the app logic whether it wants to accepts the same data again...
What if you work with sticky sessions then you would be fine with some TokenManagement. There exist a DoubleClickFilter which you can add to your web.xml.
Since you have sticky sessions there is no need for a Cross-Tomcat-Solution.
I want to resemble the typical "confirmation of account" procedure seen in multiple websites. When a user registers an email is sent to him with a confirmation link. Once the user goes to that confirmation link its account gets confirmed. Don't worry about the email sending process. The thing is that I need to generate a URL to which the user can then enter to get his new account confirmed. This page will need to receive some parameters but I don't want the url to be something like .../confirmation?userId=1 . I want it to be an ecrypted url to avoid abuses, is this possible? So far, I have something like this:
public class CancelReservationPage extends WebPage{
public CancelReservationPage(PageParameters pageParameters){
// get parameters
// confirm account
// etc..
}
}
What's next?
Thanks!
You don't need encryption, better making your parameter totally agnostic. Just generate a random string, for example 12 char long, that you store in DB in the user table.
Aside from the solutions with storing unique key in the DB, there is a more convenient but perhaps less secure method (vulnerable to disclosure of the secret key and breaking of the hash).
Generate a URL containing userId and hash(userId + secretKey), where secretKey is an unique key of your application and hash is something like SHA-1. So, malicious person can't compute the hash unless he knows the secret key, and you can validate the confirmation request by comparing incoming hash with the newly computed one.
SHA-1 can be computed using java.security.MessageDigest or Apache Commons Codec's DigestUtls.shaHex().
You may also include an expiration date to make your confirmation link valid for the limited time.
Pretty simple:
before sending the email, generate a
unique key (a series of characters,
the easiest would be a GUID)
store this unique key in the database and link it to the
associated user account
include this key as a parameter in the account confirmation URL sent in the email
in the account confirmation page code, check the database to see if
the received code is genuinely
generated by your code
if the key is in your database then activate the account