wicket:for does not work if used after the referenced component
Hi, in Wicket 6.18 this code works as expected ("for" attribute of is set to id of and id of input is written to HTML): Label wicket:id="cb"/> However if reversed, the id of the is not written to the HTML and therefore the does not work properly: Label My guess is that the AutoLabelResolver calls the getMarkupId method of the referenced FormComponent too late. A workaround is to call setOutputMarkupId explictily on the FormComponent. I can create a JIRA issue and quickstart (should be easily reproducible) if needed. Thanks! Best Regards, Andreas
CSRF protection by randomizing the page ID
Hi, I am working on securing a Wicket application against CSRF attacks, which are possible because Wicket URLs can be easily guessed by an attacker and requests contain no challenge token. I did my research and found https://issues.apache.org/jira/browse/WICKET-1782 and https://issues.apache.org/jira/browse/WICKET-5326 , pointing to using CryptMapper to encrypt the request URLs. However, wouldn't a simpler approach be to randomize the page ID that gets inserted into each URL? This way, an attacker can no longer issue requests as he cannot guess the URL of the page instance. The following basic session override does the trick: public class MySession extends WebSession { private final int sessionToken; public MySession(Request request) { super(request); sessionToken = RandomUtils.nextInt(); } @Override public synchronized int nextPageId() { int num = super.nextPageId(); return (num + sessionToken) % Integer.MAX_VALUE; } } However, this seems a little too simple for nobody to have thought of that. Do you see any problems with this code, or should this successfully protect against CSRF, without causing other issues? Best regards, Andreas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CSRF protection and mounting pages
Hi Jesse, thanks, this looks like a promising solution! However I have two problems with it: 1) Some ajax requests (not all requests, but e.g. expanding an item in a TreeTable) result in a ajax redirect to the actual ajax response, which is then displayed in the browser. I have not investigated this any further yet. 2) It seems to me that the ListenerInterfaceCryptoMapper allows unencrypted query strings? This would effectively surpress the CSRF protection. Best Regards, Andreas Am 18.09.2013 15:14, schrieb Jesse Long: Hi Andreas, Try using this, in addition to normal CryptoMapper. usage: protected void init() { setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), .)); mountPage(); mountPage(); mountPage(); mountPage(); mountPage(); setRootRequestMapper(new ListenerInterfaceCryptoMapper(getRootRequestMapper(), )); } Let me know if it works for you? Cheers, Jesse import java.util.List; import org.apache.wicket.Application; import org.apache.wicket.core.request.handler.BookmarkableListenerInterfaceRequestHandler; import org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler; import org.apache.wicket.core.request.mapper.CryptoMapper; import org.apache.wicket.request.IRequestHandler; import org.apache.wicket.request.IRequestMapper; import org.apache.wicket.request.Request; import org.apache.wicket.request.Url; import org.apache.wicket.util.IProvider; import org.apache.wicket.util.crypt.ICrypt; import org.apache.wicket.util.string.Strings; public class ListenerInterfaceCryptoMapper extends CryptoMapper { private final String parameterName; public ListenerInterfaceCryptoMapperCryptoMapper(String parameterName, IRequestMapper wrappedMapper, Application application) { super(wrappedMapper, application); this.parameterName = parameterName; } public ListenerInterfaceCryptoMapper(String parameterName, IRequestMapper wrappedMapper, IProvider cryptProvider) { super(wrappedMapper, cryptProvider); this.parameterName = parameterName; } @Override protected Url decryptUrl(Request request, Url encryptedUrl) { List queryParameters = encryptedUrl.getQueryParameters(); if (queryParameters.size() == 1){ Url.QueryParameter param = queryParameters.get(0); if (param.getName().equals(parameterName) && Strings.isEmpty(param.getValue()) == false){ String decodedQueryString = getCrypt().decryptUrlSafe(param.getValue()); return new Url(encryptedUrl.getSegments(), Url.parse(decodedQueryString, encryptedUrl.getCharset()).getQueryParameters(), encryptedUrl.getCharset()); } } return encryptedUrl; } @Override protected Url encryptUrl(Url url) { // no encrypting of segments return url; } @Override public Url mapHandler(IRequestHandler requestHandler) { Url url = super.mapHandler(requestHandler); if (url.getQueryParameters().isEmpty()){ return url; } if ((requestHandler instanceof ListenerInterfaceRequestHandler) || (requestHandler instanceof BookmarkableListenerInterfaceRequestHandler)){ Url encryptedUrl = new Url(url.getSegments(), url.getCharset()); encryptedUrl.addQueryParameter(parameterName, getCrypt().encryptUrlSafe(url.getQueryString())); return encryptedUrl; }else{ return url; } } } On 18/09/2013 14:48, Andreas Kappler wrote: Thanks for pointing out that ticket. So as I see it, there is currently no easy way to secure pages from CSRF attacks if they are mounted. To be honest I find it a bit surprising that no one contributed a solution for this common problem. I will probably go for the solution with redirects instead of mounting pages, it seems to me to be the safest way. Am 18.09.2013 14:08, schrieb Martin Grigorov: Check https://issues.apache.org/jira/browse/WICKET-5326 It talks about similar things On Wed, Sep 18, 2013 at 3:03 PM, Andreas Kappler < andreas.kapp...@jato-consulting.de> wrote: Hi Martin, thanks for your answer. I tried that and I am not sure if I did something wrong, but still the URLs generated for posting forms are not encrypted. For example I have a page that contains a form to change the user's password and I want the page to be available as /changePassword. Now if the user submits the form, the form's action points to /changePassword?xyz, which makes it open to CSRF. Best Regards, Andreas Am 18.09.2013 13:09, schrieb Martin Grigorov: Hi, You can extend CryptoMapper and setup it as root mapper. In your custom CryptoMapper you can override "Url mapHandler(final IRequestHandler requestHandler)". If the passed requestHandler is IPageClassRequestHandler then you can call #getPageClass() on it and decide whet
Re: CSRF protection and mounting pages
Thanks for pointing out that ticket. So as I see it, there is currently no easy way to secure pages from CSRF attacks if they are mounted. To be honest I find it a bit surprising that no one contributed a solution for this common problem. I will probably go for the solution with redirects instead of mounting pages, it seems to me to be the safest way. Am 18.09.2013 14:08, schrieb Martin Grigorov: Check https://issues.apache.org/jira/browse/WICKET-5326 It talks about similar things On Wed, Sep 18, 2013 at 3:03 PM, Andreas Kappler < andreas.kapp...@jato-consulting.de> wrote: Hi Martin, thanks for your answer. I tried that and I am not sure if I did something wrong, but still the URLs generated for posting forms are not encrypted. For example I have a page that contains a form to change the user's password and I want the page to be available as /changePassword. Now if the user submits the form, the form's action points to /changePassword?xyz, which makes it open to CSRF. Best Regards, Andreas Am 18.09.2013 13:09, schrieb Martin Grigorov: Hi, You can extend CryptoMapper and setup it as root mapper. In your custom CryptoMapper you can override "Url mapHandler(final IRequestHandler requestHandler)". If the passed requestHandler is IPageClassRequestHandler then you can call #getPageClass() on it and decide whether to encrypt the Url or not. For all other IRequestHandlers - always encrypt. On Wed, Sep 18, 2013 at 11:43 AM, Andreas Kappler < andreas.kappler@jato-**consulting.de > wrote: Hi! I am currently looking into making our Wicket applications CSRF safe. From my understanding the CryptoMapper is the way to go, and I was able to set it up working successfully. There are however several mounted pages in the applications (with WebApplication.mountPage), where the URLs should not be encrypted. This also works fine, the CryptoMapper does not encrypt the URLs to these pages, but that also removes the CSRF protection. E.g. if one of these mounted pages contains a form, the URL to post back the form data is unencrypted and vulnerable to CSRF. My idea was to not mount pages directly, but instead mount a Page that redirects to the actual page. That way the page is still reachable with a static URL, but all consequent requests are properly encrypted. So instead of: webApplication.mountPage("login", LoginPage.class); Something like this: public class LoginPageRedirect extends WebPage { protected void onInitialize() { throw new RestartResponseException(LoginPage.class); } } webApplication.mountPage("login", LoginPageRedirect.class); I did however not find anything in the wicket API that supports this concept and now I am wondering if there is a better way to do this, e.g. with a server side redirect. I would be grateful for any ideas! Best Regards, Andreas --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.org<http://apache.org> For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CSRF protection and mounting pages
Hi Martin, thanks for your answer. I tried that and I am not sure if I did something wrong, but still the URLs generated for posting forms are not encrypted. For example I have a page that contains a form to change the user's password and I want the page to be available as /changePassword. Now if the user submits the form, the form's action points to /changePassword?xyz, which makes it open to CSRF. Best Regards, Andreas Am 18.09.2013 13:09, schrieb Martin Grigorov: Hi, You can extend CryptoMapper and setup it as root mapper. In your custom CryptoMapper you can override "Url mapHandler(final IRequestHandler requestHandler)". If the passed requestHandler is IPageClassRequestHandler then you can call #getPageClass() on it and decide whether to encrypt the Url or not. For all other IRequestHandlers - always encrypt. On Wed, Sep 18, 2013 at 11:43 AM, Andreas Kappler < andreas.kapp...@jato-consulting.de> wrote: Hi! I am currently looking into making our Wicket applications CSRF safe. From my understanding the CryptoMapper is the way to go, and I was able to set it up working successfully. There are however several mounted pages in the applications (with WebApplication.mountPage), where the URLs should not be encrypted. This also works fine, the CryptoMapper does not encrypt the URLs to these pages, but that also removes the CSRF protection. E.g. if one of these mounted pages contains a form, the URL to post back the form data is unencrypted and vulnerable to CSRF. My idea was to not mount pages directly, but instead mount a Page that redirects to the actual page. That way the page is still reachable with a static URL, but all consequent requests are properly encrypted. So instead of: webApplication.mountPage("**login", LoginPage.class); Something like this: public class LoginPageRedirect extends WebPage { protected void onInitialize() { throw new RestartResponseException(**LoginPage.class); } } webApplication.mountPage("**login", LoginPageRedirect.class); I did however not find anything in the wicket API that supports this concept and now I am wondering if there is a better way to do this, e.g. with a server side redirect. I would be grateful for any ideas! Best Regards, Andreas --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
CSRF protection and mounting pages
Hi! I am currently looking into making our Wicket applications CSRF safe. From my understanding the CryptoMapper is the way to go, and I was able to set it up working successfully. There are however several mounted pages in the applications (with WebApplication.mountPage), where the URLs should not be encrypted. This also works fine, the CryptoMapper does not encrypt the URLs to these pages, but that also removes the CSRF protection. E.g. if one of these mounted pages contains a form, the URL to post back the form data is unencrypted and vulnerable to CSRF. My idea was to not mount pages directly, but instead mount a Page that redirects to the actual page. That way the page is still reachable with a static URL, but all consequent requests are properly encrypted. So instead of: webApplication.mountPage("login", LoginPage.class); Something like this: public class LoginPageRedirect extends WebPage { protected void onInitialize() { throw new RestartResponseException(LoginPage.class); } } webApplication.mountPage("login", LoginPageRedirect.class); I did however not find anything in the wicket API that supports this concept and now I am wondering if there is a better way to do this, e.g. with a server side redirect. I would be grateful for any ideas! Best Regards, Andreas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UrlResourceReference escapes too much?
I created an issue for this: WICKET-4907 <https://issues.apache.org/jira/browse/WICKET-4907> Best Regards, Andreas Am 03.12.2012 16:21, schrieb Martin Grigorov: I'm not sure. I have to debug it to be able to say what happens. On Mon, Dec 3, 2012 at 4:16 PM, Andreas Kappler < andreas.kapp...@jato-consulting.de> wrote: Hi Martin, thanks for your quick reply, it does indeed work with forUrl but what I didn't mention before is that I am using a ResourceReference because I want to declare a dependency using ResourceReference#**getDependencies. Is there a way to do this? Best Regards, Andreas Am 03.12.2012 16:10, schrieb Martin Grigorov: Hi, Try with org.apache.wicket.markup.head.**JavaScriptHeaderItem#forUrl() This method cares about context relative urls. On Mon, Dec 3, 2012 at 4:06 PM, Andreas Kappler < andreas.kappler@jato-**consulting.de > wrote: Hi, I am trying to render a reference to a Javascript library which is stored somewhere in my webapp directory using UrlResourceReference: public void renderHead(IHeaderResponse response) { super.renderHead(response); response.render(JavaScriptHeaderItem.forReference(new UrlResourceReference(Url.parse("public/scripts/jquery-*** *ui-1.8.6.custom.min.js")) .setContextRelative(true))); } This does not work, because our wicket servlet is using a prefix ("nui"), and thus the URL to the resource (corrently) contains ".." but this is escaped for some reason to "::". So the URL generated by the ResourceReference is e.g. " http://localhost:8080/app/nui/::/public/scripts/jquery-<http://localhost:8080/app/**nui/::/public/scripts/jquery-**> ui-1.8.6.custom.min.js<http://**localhost:8080/app/nui/::/** public/scripts/jquery-ui-1.8.**6.custom.min.js<http://localhost:8080/app/nui/::/public/scripts/jquery-ui-1.8.6.custom.min.js> " leading to a 404. The correct URL would be "http://localhost:8080/app/** nui/../public/scripts/jquery-ui-1.8.6.custom.min.jshttp://localhost:8080/app/nui/../public/scripts/jquery-ui-1.8.6.custom.min.js> " As far as I can see, ParentPathReferenceRewriter does the escaping. Am I using the API not correctly? Thanks for your help! Best Regards, Andreas --** --**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.org<http://apache.org> For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UrlResourceReference escapes too much?
Hi Martin, thanks for your quick reply, it does indeed work with forUrl but what I didn't mention before is that I am using a ResourceReference because I want to declare a dependency using ResourceReference#getDependencies. Is there a way to do this? Best Regards, Andreas Am 03.12.2012 16:10, schrieb Martin Grigorov: Hi, Try with org.apache.wicket.markup.head.JavaScriptHeaderItem#forUrl() This method cares about context relative urls. On Mon, Dec 3, 2012 at 4:06 PM, Andreas Kappler < andreas.kapp...@jato-consulting.de> wrote: Hi, I am trying to render a reference to a Javascript library which is stored somewhere in my webapp directory using UrlResourceReference: public void renderHead(IHeaderResponse response) { super.renderHead(response); response.render(**JavaScriptHeaderItem.**forReference(new UrlResourceReference(Url.**parse("public/scripts/jquery-**ui-1.8.6.custom.min.js")) .setContextRelative(true))); } This does not work, because our wicket servlet is using a prefix ("nui"), and thus the URL to the resource (corrently) contains ".." but this is escaped for some reason to "::". So the URL generated by the ResourceReference is e.g. " http://localhost:8080/app/**nui/::/public/scripts/jquery-** ui-1.8.6.custom.min.js<http://localhost:8080/app/nui/::/public/scripts/jquery-ui-1.8.6.custom.min.js>" leading to a 404. The correct URL would be "http://localhost:8080/app/** nui/../public/scripts/jquery-**ui-1.8.6.custom.min.js<http://localhost:8080/app/nui/../public/scripts/jquery-ui-1.8.6.custom.min.js>" As far as I can see, ParentPathReferenceRewriter does the escaping. Am I using the API not correctly? Thanks for your help! Best Regards, Andreas --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
UrlResourceReference escapes too much?
Hi, I am trying to render a reference to a Javascript library which is stored somewhere in my webapp directory using UrlResourceReference: public void renderHead(IHeaderResponse response) { super.renderHead(response); response.render(JavaScriptHeaderItem.forReference(new UrlResourceReference(Url.parse("public/scripts/jquery-ui-1.8.6.custom.min.js")) .setContextRelative(true))); } This does not work, because our wicket servlet is using a prefix ("nui"), and thus the URL to the resource (corrently) contains ".." but this is escaped for some reason to "::". So the URL generated by the ResourceReference is e.g. "http://localhost:8080/app/nui/::/public/scripts/jquery-ui-1.8.6.custom.min.js"; leading to a 404. The correct URL would be "http://localhost:8080/app/nui/../public/scripts/jquery-ui-1.8.6.custom.min.js"; As far as I can see, ParentPathReferenceRewriter does the escaping. Am I using the API not correctly? Thanks for your help! Best Regards, Andreas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org