I have a security issue. I have a menu, which allows or disallows user to go to a certain page. It is simple, if user is disallowed to reach page, link to it is being hidden in the menu.
But, user still can enter direct URL in browser, and can reach page.
For example, I have CardPage, per link I can reach it using
setResponsePage(new CardPage());
or
setResponsePage(CardPage.class);
but still I can reach this page entering such URL:
http://127.0.0.1:8080/my-application-war/?wicket:bookmarkablePage=:com.my.application.CardPage
Is there is any way to forbid user to access this page per URL?
I can give you additional info on that question if there is something you need.
UPDATE
Had to do it manually, check on every page if it is allowed to be seen, and redirect to NotAllowedPage.
There are several ways to do this, like using Spring Security or Apache Shiro. But if you don't need anything fancy, I would just go with the functionality that is provided by Wicket itself. Just read Security with Wicket in the Wicket guide (which is by the way an excellence reference).
Related
Currently my java code uses
response.sendRedirect(request.getRequestUrl().toString());
Which is an open redirect.
I have to fix this but I can not white list it since there are too many URL's are associated with it.
I have tried the following solution with ESAPI but it wont work for me.
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
I am new to ESAPI.
[Disclaimer]
I'm project co-lead on ESAPI.
I have to fix this but I can not white list it since there are too
many URL's are associated with it.
Essentially, "I have to fix the problem, but I am restricting myself from the easiest solution."
Here are the best practices enumerated by #jww:
Simply avoid using redirects and forwards.
If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
Sanitize input by creating a list of trusted URL's (lists of hosts or a regex).
Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.
These are literally all the solutions available to you. Some web frameworks make this easy for you, like Spring MVC with Spring Security.
These lines:
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
Don't work because you have to inspect the user input before performing the redirect.
You definitely are going to want to white-list this, at least at a minimum, based on domain names. Restrict it as much as possible. E.g., if your app is hosted at https://myApp.example.com/ redirecting to anywhere on your site is probably okay. (I write probably, because if it can be used as a way to bypass authorization checks, say on a multi-sequence page series, then it might not be okay. But as long as your regular authorization checks pick up and validate the redirect, you generally will be okay.) But what about redirects to https://anotherApp.example.com/? Would those be okay? What about anything in the "example.com" domain? Are their other 3rd party domains that you need to white-list? If so, be sure to list those URLs as well. But the one thing that you want to avoid are completely open redirects and for that you need some type of white-listing. You could build some custom validators using ESAPI to do this, but it's probably just easier to write it without ESAPI. If you have a bunch of URLs that you have to white-list, keep them in a configuration file that's not part of your .war / .ear file so you can easily update it without redeploying your application and just (re)read the config file when it gets updated.
Hope this helps.
-kevin
Thanks for all your suggestions and comments.
I found that the lines
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
Is now working fine for me, after a long struggle I found that my code is using latest version of commons-configuration.jar but when I added Esapi as a dependency the Esapi used an old version of the same and that was not compatible with my code so I just excluded the this from Esapi dependency using the exclusion in pom and it worked for me.
My GWT app URL when a page is access looks like this:
http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997#ViewPage;hash=6a
or
http://127.0.0.1:8888/index.html#ViewPage;hash=6a
However, this does not look good, is there a way for the GWT client side code to make it look like this, to "mask" it somehow to:
http://127.0.0.1:8888/6a
Where I have a servlet configured to forward this "shortened" URL to the long URL above so its very safe to make the URL "masked"? Without losing state and history.
The shortest possibility I know would be an URL like:
http://127.0.0.1:8888/#6a
Therefore you must configure index.html as default page. (It must be configured as default response).
You also have to rewrite the history-management. You have to remove the Place-Token from the URL.
I don't see any way to do this directly with GWT, since GWT needs access to the code fragment in the URL to manage browsing history and state.
One indirect way to do it would be to embed your GWT module inside an iframe that occupies the whole page area. The drawback is that the user would loose the ability to bookmark pages inside the GWT application.
By the way, I don't share your view that it "does not look good". Many popular Web applications use the URL like this, including Gmail. Most users don't care about what's in the URL.
I have nearly 20+ pages from different Web application that a user can access once he login. I have this 'Recent Activity' section on my Home page where I have to show the last 10 visited pages by the user ( if possible along with date and time of visiting). The pages are jsp pages. I dont know how I can acheive this basically I am more a frontend developer so can I do this with jquery, jsp, js etc.. or anyother technoloiges. We use Java technology also. Please let me know any sample code or way of approach to do it.
Thanks
I am a php developer, not too familiar with jsp, but i am sure it would be the same logic.
You have 2 option here:
Option 1:
Create a database table and record all the user flow whenever the user access an application.
Option 2:
Save all the flow in a cookie variable so whenever the user logs in you can pull out all his info from the cookie variable.
Personally i rather use the option 1, because if the use clears out the cookie/session variable you will lose lo all the information.
Since i am not a jsp i can't providew with a sample code. Hope this get your started at least.
This information may be stored on Cookies or User Session.
If it's available on cookies, you can access and manipulate it using JavaScript or any other server-side languages.
Do you want some example on how to use it using JSP&Servlets?
There's pros and cons for each approach.
Cookies: User can cleanup private browser data, and cookies go away with it.
Sessions: You can store it in some database or log file, for future load or/and analysis.
Cons is the management of this data in any layer. But it's not a big problem.
I use Wicket's AjaxFallbackLink in a number of places. This works fine for users, but it's giving us some SEO headaches.
When Google crawls one of our pages, it might be hours or days before they return and try crawling the AjaxFallbackLinks on that page. Of course since the links look like this:
http://example.com/?wicket:interface=:1869:mediaPanel:permissionsLink::IBehaviorListener:0:2
... the session is no longer valid by the time the crawler returns. This results in a ton of 404 errors on our site, which presumably harms our SEO.
My question: how can I make the Ajax links "stable" (like a BookmarkablePageLink) for search engines, but still retain the Ajax behavior for interactive users?
You can tell Google to ignore certain URL parameters by using the URL Parameter options in Google Webmaster Tools. As of July 2011, you can even tell Google what to do in the case where changing the URL parameters has an effect on the page content (e.g. paging or sorting).
To access the feature, log into your Google webmaster tools account,
click on the site you want to configure, and then choose Site
configuration > URL parameters. You’ll see a list of parameters Google
has found on the site, along with the number of URLs Google is
“monitoring” that contain this parameter.
The default behavior is “Let Googlebot decide”. This results in Google
figuring out duplicates and clustering them.
http://searchengineland.com/google-adds-url-parameter-options-to-google-webmaster-tools-86769
The question for you is whether the content of the page does change when you ignore the wicket:interface params. If it does, maybe you need to explore moving to a stateless Ajax fallback, such as the one described here:
https://github.com/jolira/wicket-stateless
Ever visit a website such as myspace where they leverage CAPTCHA to prevent spam? The typical pattern is to present a challenge to each URL that is opened, yet the challenge doesn't actually belong to the page itself which causes additional bandwidth usage.
So, if I open up six pages at the same time and want to present a challenge on each page. I want the challenge to be tied to the page and not to the session. How can I make this work with Spring and/or Struts.
This depends largely on what you are using for rendering the pages. Spring MVC? Struts? You can tie components to pages in most of these frameworks.
You can also maybe think of a workaround where each page registers his captcha in the session in a seperate key, and have the page check against it's own value.