There's a case that the user change the parameters send to servlet through URL,
is there's any way to restrict user not to change paramters,
if not, how can I manage all parameters send to servlets? in a case they are many, is it reasonable to check each one in turn??
You can't restrict the user from sending you anything.
It is the server-side where you can add restrictions.
Usually you get only the parameters you need, so additional parameters should not bother you.
You definitely should check parameters send to your servlet. Thats basically what you do anyways since thats the way clients (such as webpages) communicate with your application.
The simplest way is to hash the parameters with some hidden secret, and pass that back with the URL, then compare the hash to the URL parameters to make sure they match.
Another way is to not use individual parameters, but encrypt them in to a encoded bunch of characters and the whole thing is decrypted on return.
The hash is easier to implement if you don't care that the user sees the actual parameters.
You cannot avoid someone from typing in the URL, but what you do in your servlet is filter the input recieved from the URL, with some java code.
Example:
Just found an interesting link where a Servlet Filter is used to filter out XSS attacks(As you see, there is no such code that avoids someone to type certain characters in the URL, or similar): Link
Simply put, you cannot stop the users from changing the parameters.
You must do input validation on all parameter values. If you have a variable that contains sensitive information, you do not put that on the URL. A really bad example: http://mydomain.com/myservlet?isAdmin=1. Information such as that needs to go into a session since that is stored on the server and out of the user's reach.
Related
I have a list of users across various companies who are using one of the functionality that our website provides. Whenever they contact our business group , we need to send a url via email to the requestor in order for them to upload some data. All these external users do not have any dedicated account. However we do not want a static link to be provided to them as this can be accessed by anyone over the internet. We want dynamic links to be generated. Is this something that is usually done? Is there an industry accepted way of doing this? Should we ensure that the dynamic link expires after a certain amount of time - if so , are there any design options?
Thanks a lot!
Usually, parameters to urls and not the actual urls are what's dynamic. Basically you generate params that are stored somewhere, typically on the database, and send email with the url and the parameter(s). This url is valid for only a limited period of time and possibly only for one request.
Answers to questions:
yes, this is something that is quite commonly used in, for example, unsubscribing from a mailing list or validating an account with a working email address
I'm not aware of any single way that is "industry accepted", there are many ways of doing it, but the idea is not that complex - you just need to decide on a suitable token format
normally you should ensure that the link expires after a certain amount of time. Depending on the use case that can be some days, a week or something else. In practice, you'd remove or disable the generated parameters in your database. However, if this data is something that might be needed for extended periods of time, you might want to think up a functionality so that it can be retrieved later on.
You may have a static URL taking a token as parameter. Eg. http://www.mycompany.com/exchange/<UUID> or http://www.mycompany.com/exchange?token=<UUID>.
The UUID could have a validity in a time range or be limited to a single use (one access or one upload).
Other variant is to use exists cookies on that site in web browser (of course, if they are).
But there are some drawbacks in this solution:
User can open link in different machine, different browser. User can clean all cookies or they can expire after it was visited your site last time when user try to go on granted URL. In these cases user won't access your page.
I have GET Method. I want to pass something like Student_id in request but without showing it in URL. I know for that we use POST Method. But I dont want to use POST since I am getting someother issues.
If Student_id is something you don't want the user to have, then don't send it. Ever. There's no way to make it safe once it's in a user's hands.
Perhaps you can use a frame as a mask so the domain doesn't change whilst the form submits. You can sneak a REFRESH header in there for 0 seconds with the _top addition, making it nearly impossible for someone to follow your form's weaknesses.
You can't eat the cake and leave it whole.
Your best option is to encrypt the Student_id somehow, you can have your own simple method if it's not very sensitive data, and you can use more complicated algorithms but it can never be 100% safe.
Another option is to not submit the form at all, but AJAX instead to pass the values to server.
You can not do it.
First learn the difference between get and post method.
Get is used to query something with some parameter and post is used to create or update content in the server via http.
It is better using ajax get if you want to hide the parameters form the user.
Look at these link:
http://api.jquery.com/jQuery.get/
http://api.jquery.com/jQuery.ajax/
Cant help to wonder, what does this have anything to do with java.. However, to understand your problem. I would suggest that you use $_SESSSION or setcookie(); So before sending the user to another page, you would first save the user_id in some form.
I want to pass an email address as a parameter in a URL string but hide it. The URL string is constructed in a Java routine and the jsp page receiving the request will pass the string to a server side java routine to decode it. Someone must have already written this code but I cannot find it - probably not asking the right question. Thanks. Fred
If you're including the email in the URL you cannot hide it, but you can encrypt it.
If encryption doesn't rock your world, and you simply want to obscure the email address, you could obfuscate it.
The other way to submit it with out it being so obvious would be to use POST to send the data to the jsp page rather than using Querystring.
Typically, users have a session with data stored on the server. The e-mail address would be stored in the session object, on the server. The client supplies its session ID in a cookie or in the URL. This way, you can pass information to the next page without putting it in the URL.
If you don't want to deal with this via a session, or you're passing this string between servers, you have two options. Either Hash the email, or Base64 encode it. If you're worried about anyone other than you ever (or the user) finding the actual email, don't use Base64. However, if that's not a concern, then base64 is the easiest and fastest way to include an email address the doesn't look like an email address.
If, however, you're worried about the information leaking in any way, use MD5 or SHA hashes of the email. To speed the lookup in the DB, you may want to pre-compute the hashed version of the email and store it in an additional column in the table.
I'd recommend SHA over MD5, though for this lightweight usage, I doubt the flaws in MD5 will affect you.
Use hiddden form fields.
<input type="hidden" ...>
Hidden form fields come into handy when you dont want them to be exposed when transferring from jsp page to servlet and then to a java bean.
I want to write a code in java that takes a url identify whether it is tiny url or not. if yes then it will identify the url is malicious or not. if not malicious print the url...
Please can any body help me....
You can use HttpClient to detect whether the URL is redirected to another location. After that it's a simple case of:
if (!isMalicious(redirectTargetURL))
{
System.out.println(redirectTargetURL);
}
The isMalicious(...) implementation is left as an excercise for the reader.
If you trust google to implement isMalicious(...) then they have done so with their Safe Browsing API.
So 2 main things you want:
Identify if it's a tinyurl
Identify if the URL is malicious
The answer to part 1 is easy. Just check if the URL belongs to the domain 'tinyurl.com'. Should be straightforward to either test raw URL string, or the host part returned by the getHost() method of a java.net.URL object.
Part 2 is more difficult to code up from scratch...
First you will need your code to figure out where the tinyurl redirects to.
The next bit really depends on how you want to define 'malicious'. Detecting deceptive URLs will require a bit of work (e.g. finding the difference between something like www.stackoverflow.com and www.stack0verf10w.com), or comparing the target URL with a malicous URL list (there's sites that publish them). There's also checking for multiple redirects, popups, and the list of criteria could go on and on.
I got the answer for If I disabled the cookies then using URL ReDirect I can pass the JSESSIONID but my URL is already very long as I use the GET method it has constraint. Then how
should I use my sessions.I want my application to be very security intensive.
This is one of the question asked to my friend in GOOGLE interview.
Apart from using one-letter parameter names (e.g. ?a=value1&b=value2&c=value3 or using RESTFul-like URL's (i.e. just the pathinfo, no query parameters, e.g. /value1/value2/value3, which is accessible by HttpServletRequest#getPathInfo() in the servlet) instead of ?name1=value1&name2=value2&name3=value3, you can also consider to Gzip and Base64-encode the query string so that it becomes shorter. Both JavaScript and Java are capable of (de)compressing and (d)e(n)coding it. You can eventually format the query string in JSON before compressing/encoding, it will be shorter in case of arrays/collections/maps.
That said, are you sure that the request URL's are often that unfriendly long (assuming that it's over 255 characters)? Why would you need to pass that much information in? Are they supposed to maintain the client state? If so, you shouldn't use the URL for this, but the HttpSession instance in the server side which is already associated with the jsessionid cooke. Use HttpSession#setAttribute() to store some information in session and use HttpSession#getAttribute() to retrieve it.
As far as I understand, your main problem with JSESSIONID in the URL is the total length.
Perhaps you should have a closer look at why the length of the URLs are too long in the first place. Since you allready have a session, it is not unlikely you can move some GET parameters to the session. There are also lots of different way to make shorter URLs for pages (a la mod_rewrite).
With regards to security, JSESSIONID is just as vunerable with HTTP GET as HTTP POST. The base64 encoding HTTP POST does is not a security measure at all. The best way to gain a bit more security is to encrypt the transport channel through TLS/SSL, in effect enable HTTPS. This will make sure that eavesdropping (or man in the middle attacks) will not have access to the plain text.
If you want your application to be security intensive why are you using GET. Use POST. This will also reduce the URL length.
As such, as per the HTTP protocol there is no max length limit to URL length. Most of the time its the browser that puts in the max length limit. Try different browsers
You should put forward the above points to the interviewer. They might be more interested in your ability to assess the system as a whole and identify any fundamental flaws.
If the URL is too long then you have to store that data somewhere else. Most sites would put the session ID in a cookie.