HP Fortify Critical Security Issues
Hello, As part of an evaluation of web frameworks, one of the checkboxes to tick is security vulnerabilities. In this case the tool being used to scan for those vulnerabilities is HP Fortify http://www8.hp.com/us/en/software-solutions/software.html?compURI=1349399#.URFMM6WbR2o I wanted to get the communities feedback on critical security issues that were presented based on this tool (I'll leave my opinion out of it for now) and if other teams are using are using this software - what is their process for evaluating/fixing/etc these kinds of issues in open-source software. Appreciate your input. Issue 1 - wicket-ajax-jquery.js:651 (Open Redirect) *Abstract:* The file wicket-ajax-jquery.js passes unvalidated data to an HTTP redirect function on line 651. Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks. *Explanation*: Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker. Attackers can utilize open redirects to trick users into visiting a URL to a trusted site and redirecting them to a malicious site. By encoding the URL, an attacker can make it more difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data. *Recommendations*: Unvalidated user input should not be allowed to control the destination URL in a redirect. Instead, a level of indirection should be introduced: create a list of legitimate URLs that users are allowed to specify, and only allow users to select from the list. With this approach, input provided by users is never used directly to specify a URL for redirects. Issue 2 - FileUpload:253 (Path Manipulation) *Abstract:* Attackers can control the filesystem path argument to createTempFile() at FileUpload.java line 253, which allows them to access or modify otherwise protected files. *Explanation*: Path manipulation errors occur when the following two conditions are met: 1. An attacker can specify a path used in an operation on the filesystem. 2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker. In this case, the attacker can specify the value that enters the program at getId() in FileUpload.java at line 251, and this value is used to access a filesystem resource at createTempFile() in FileUpload.java at line 253. *Recommendations:* The best way to prevent path manipulation is with a level of indirection: create a list of legitimate resource names that a user is allowed to specify, and only allow the user to select from the list. With this approach the input provided by the user is never used directly to specify the resource name. In some situations this approach is impractical because the set of legitimate resource names is too large or too hard to keep track of. Programmers often resort to blacklisting in these situations. Blacklisting selectively rejects or escapes potentially dangerous characters before using the input. However, any such list of unsafe characters is likely to be incomplete and will almost certainly become out of date. A better approach is to create a white list of characters that are allowed to appear in the resource name and accept input composed exclusively of characters in the approved set. Issue 3 - WicketServlet:327 (Race Condition: Singleton Member Field) *Abstract:* The class WicketServlet is a singleton, so the member field wicketFilter is shared between users. The result is that one user could see another user's data. *Explanation:* Many Servlet developers do not understand that a Servlet is a singleton. There is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result of this misunderstanding is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition. *Recommendations:* Do not use Servlet member fields for anything but constants. (i.e. make all member fields static final). Developers are often tempted to use Servlet member fields for user data when they need to transport data from one region of code to another. If this is your aim, consider declaring a separate class and using the Servlet only to wrap this new class. -- View this
Re: HP Fortify Critical Security Issues
Thanks Igor for the quick response. The bottom two are pretty self explanatory as to why they shouldn't be issues when you look into the codebase. The first one, I had the same response for but it's good to hear a similar echo from a wicket maintainer. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/HP-Fortify-Critical-Security-Issues-tp4656091p4656102.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Session Expiration - Ajax interactions
Just reading through the description - the components only included StatelessLink and a StatelessAjaxFallbackLink Browsing through the source code, it appears that there are stateless behaviors that can be added to other Ajax components. Best thing to do is to test it out :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-Expiration-Ajax-interactions-tp4655591p4655638.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Session Expiration - Ajax interactions
I'm currently in the process of evaluating frameworks. We are currently using Wicket 1.4. The ones I've looked at so far have been Vaadin, Tapestry 5.4, and Wicket 6.0. Vaadin I ruled out for various reasons. One of the problems that our users have complained quite a bit about is the dreaded PageExpiration problem. In Wicket 6.0 the issue is resolved somewhat by the framework recreating the page and then issuing a redirect. While understand why it does this // If the page is stateful then we cannot assume that the listener interface is // invoked on its initial state (right after page initialization) and that its // component and/or behavior will be available. That's why the listener interface // should be ignored and the best we can do is to re-paint the newly constructed // page. it's still not the solution we want. The Ajax interaction should continue on as normal. Due to how Tapestry is architected, this is not an isssue. In Wicket 1.4, I got around this somewhat by extending the WebRequestCycleProcessor and recreating the request when a PageExpiration was encountered. It doesn't appear that I can carry this forward in Wicket 6.0. I just want to make sure that I'm not missing anything. Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-Expiration-Ajax-interactions-tp4655591.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Session Expiration - Ajax interactions
It's just not efficient. We have users that will let their pages sit for hours before they come back to them. I would rather have these sessions/memory be reclaimed, and if a user has a stale page, the Ajax action continues on as normal. We also have a sudo portal that contains applications contained in iframes - most of them are wicket applications. Depending on the # of iframes opened, ajax timers, this can cause issues with the # of concurrent connections opened in the browser. When I went through this in 1.4 to recreate the request, a lot of the issues were related to the use of back button support and PageMaps, which most of our applications have no use for. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-Expiration-Ajax-interactions-tp4655591p4655594.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Session Expiration - Ajax interactions
You can read the Tapestry response a href=http://tapestry.1045711.n5.nabble.com/Session-Expiration-Ajax-td5719213.html;here. Essentially there are no PageMaps/versions per users session. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-Expiration-Ajax-interactions-tp4655591p4655604.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
Again address the content and not the speaker. I prompted him to post this to get some good feedback on why Wicket is a better alternative than the UI frameworks than we have come across. Frameworks in the ui space are numerous and all serve a different need or perspective. If all you have to say is essentially you suck, you haven't done anything to promote the virtues of wicket and it's ideals. I like wicket and I've seen It put to good use based on the ideals it try's to follow by. If all you have to say is you suck you're stupid etc don't fucking post. He's obviously done some research and has as an informed opinion - give him the respect by offering a intelligent counter argument to his points or dont post at all. You really just come off as a jerkoff zealot. Sent from my iPhone On Nov 19, 2011, at 5:29 PM, Eelco Hillenius [via Apache Wicket]ml-node+s1842946n408747...@n4.nabble.com wrote: Really, is this what you do, go around posting to user lists of frameworks you don't like? I imagine one can have a full time job doing that. Eelco On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki [hidden email] wrote: Violates Dry: You must repeat the component hierarchy of your widgets that are in HTML in Java Code for no good reason. If you move your widget around in the html it will break the Java and you get a stack trace if you change the nesting. You have to keep these two files synched. A JSP file is more maintainable. At least the view code is in one place. Not previewable: One of the supposed benefits of Wicket is a clean template that could make pages previewable for designers. First, we don't have seperate designers at my company. Second, it is better if the samer person does development and design. Third, if you use extends your page will not be priviewable outside an application server running Wicket. This supposed benefit does not exist. Violates MVC: It smashes view and controller code into the same Java file. You have code that regulates page flow and code that changes css attributes in the same file. Even Spring MVC had better separation of concerns. JSP/Servlets with Spring MVC is better. Excessively verbose and complicated: What is a LoadableDetachableModel? The learning curve for Wicket is immense. Breaks POJOS: A real POJO does not need to implement an interface or extend a class. Wicket forces your beans to be Serializable. This is like using EJBs in how it forced you to implement interfaces. Terrible AJAX: Compared to a few lines of jQuery AJAX is excessively complicated and verbose in Wicket. A lot of things like “AJAX” links should not be done via “AJAX” at all. Hiding a div on the client would simply be done with JavaScript on the client. Wicket better not require a server request for that. You also have no JSON support and good luck debugging any JavaScript or AJAX in Firefox. Instead you have to use the subpar Wicket debugging. HTML5: No support for HTML 5 form elements unless you upgrade to Wicket 1.5. You will get a stack trace. The upgrade to Wicket 1.5 is painful and will break your code. Good luck getting this to work with jQuery mobile. Bad Defaults: Most pages are stateless. The default for Wicket is stateful. So if I want a decent URL and a bookmarkable page I have to mount the page and use a bookmarkable page link with page parameters. Using page parameters is worse than how Spring MVC does binding. I have to keep doing this over and over for each page. There is too much work involved to get a decent stateless page with a nice URL. This should be the default. Interferes with other libraries: It screws up your jQuery code. It forces you into a restrictive way of doing web-development: the Wicket Way. Causes a redeploy whenever you add anything: Maybe Java developers are used to this, but in any other web development environment I do not need to redeploy after adding a text box to the page. It is completely absurd. Only with JRebel is this alleviated. No, embedded Jetty in debug mode still slow. Even a simple JSP file has hot reloading on Tomcat and if I make a change to my view code the changes are immediately viewable in the browser when I refresh. This is WITHOUT JRebel. HTTPSession Objects are not hard: Most pages do not need state. If you do use HTTPSession it is simple. Can you use a map? Then you can use HTTPSession. This is less comlicated than most Wicket code. Stateful Component based framework are a terrible idea: Even at the theoretical level this is a bad idea. It is a leaky abstraction over a simple request/response cycle. It made something simple and made it overly complicated. This remind me of Hibernate and ORMS. I disagree that we should abstract things to this level and do
Re: Apache Wicket is a Flawed Framework
As gerald mentioned address the content - not the speaker, much more effective. i'll address a few of your points and bring up a few of my own. I'm sure the others can be addressed with thoughtful/intelligent responses. *Violates DRY*: There is a reason that HTML is separated from your corresponding Java component (not every html snippet has to have a component btw). Behavior is not allowed in your HTML and that makes me happy. I can have a Human Factors/Web designer do what they do best. Design a beautiful, high fidelity prototype that has taken actual user need in mind with plain ol HTML/JS/CSS. I've seen data driven UI's done by backend programmers - not so nice. I know because I've done them myself. Not having behavior embedded in your view like a JSP/Facelet means that when something goes wrong with a page, I have one place to look - in the corresponding Java component. No hidden loops tucked away in that page, no calls to a Java API embedded within a mess of HTML code - clean separation. *Breaks POJOS*: The data being stored in your model doesn't have to implement an interface. See this response http://apache-wicket.1842946.n4.nabble.com/confusion-about-Wicket-models-and-serialization-td1933714.html A couple of things I think Wicket could improve upon is when you *don't* want back button support and having to worry about PageMaps being stored in the users session disk. As this is a corner case for the most part in the web app world, I can live with what I have. In that same vein, having to deal with PageExpiration exceptions when back button support is not needed and I don't want my users to encounter this when an Ajax action takes place. Again this is not the norm and there's a workaround but it's hacky. As mentioned no UI framework is perfect. All have their strengths and weaknesses and usually those depend on your point of view, coding style, time of day... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082041.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
PageExpiredException - ajax request
I'm running into an issue with PageExpiredExceptions and ajax responses.
Here's what I would like to do.
1. Have sessions timeout at 20 minutes.
2. Once a session has timed out and the user clicks an ajax link on the
expired page - the link should process as normal and do whatever was tied to
that link - such as show a modal window.
Here's what I have so far. The ajax link works but the returned response is
the entire page + whatever component was added to the AjaxRequestTarget -
because of the Page.render() I would assume. It's starting to feel like
more of a hack and I'm pretty sure there's a better way to do this.
public class MyWebRequestCycleProcessor extends WebRequestCycleProcessor
{
protected IRequestTarget resolveRenderedPage(RequestCycle requestCycle,
RequestParameters requestParameters)
{
String componentPath = requestParameters.getComponentPath();
Session session = requestCycle.getSession();
Page page = session.getPage(requestParameters.getPageMapName(),
componentPath, requestParameters.getVersionNumber());
if (page != null)
{
return resolveRenderedPage(requestCycle,
requestParameters, page, false);
}
else
{
// Try to resolve the page instead of throwing an
expired page exception
try
{
page = newPage(requestCycle, requestParameters);
if (page != null)
{
IPageMap pageMap =
PageMap.forName(requestParameters.getPageMapName());
pageMap.put(page);
return
resolveRenderedPage(requestCycle, requestParameters, page,
true);
}
}
catch (Exception e)
{
LOG.error(e.getMessage(), e);
}
}
return null;
}
protected Page newPage(RequestCycle requestCycle, RequestParameters
requestParameters) throws Exception
{
PageParameters params = new
PageParameters(requestParameters.getParameters());
IPageFactory pageFactory =
requestCycle.getApplication().getSessionSettings().getPageFactory();
if ((params == null) || (params.size() == 0))
{
return
pageFactory.newPage(Class.forName(requestParameters.getPageMapName()));
}
else
{
requestCycle.getRequest().getParameterMap().putAll(((params)));
return
pageFactory.newPage(Class.forName(requestParameters.getPageMapName()),
params);
}
}
private IRequestTarget resolveRenderedPage(RequestCycle requestCycle,
RequestParameters requestParameters, Page page, boolean newRequest)
{
IRequestTarget target = null;
requestCycle.getRequest().setPage(page);
String interfaceName = requestParameters.getInterfaceName();
String componentPath = requestParameters.getComponentPath();
MyAjaxMarkupContainer container = null;
if (newRequest)
{
if (componentPath.indexOf(ajax_link) != -1)
{
container = ((MyPage)
page).getMyAjaxMarkupContainer();
}
// needed for wicket to find the ajax link to make the
request
container.beforeRender();
// Render the page so wicket finds the markup for the
ajax link making
the request
page.render();
page.afterRender();
}
if (interfaceName != null)
{
target = resolveListenerInterfaceTarget(requestCycle,
page,
componentPath, interfaceName, requestParameters);
}
else
{
target = ((new PageRequestTarget(page)));
}
return target;
}
}
--
View this message in context:
http://www.nabble.com/PageExpiredException---ajax-request-tp21840751p21840751.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageExpiredException - ajax request
Thanks - that's the path I went down after i posted. Didn't know if there
was a cleaner way or not.
igor.vaynberg wrote:
requestcycle rc=getrequestcycle();
response orig=rc.getresponse();
rc.setresponse(new noopresponse());
page.render();
rc.setresponse(orig);
-igor
On Wed, Feb 4, 2009 at 2:10 PM, sthomps stho...@gmail.com wrote:
I'm running into an issue with PageExpiredExceptions and ajax responses.
Here's what I would like to do.
1. Have sessions timeout at 20 minutes.
2. Once a session has timed out and the user clicks an ajax link on the
expired page - the link should process as normal and do whatever was tied
to
that link - such as show a modal window.
Here's what I have so far. The ajax link works but the returned response
is
the entire page + whatever component was added to the AjaxRequestTarget -
because of the Page.render() I would assume. It's starting to feel like
more of a hack and I'm pretty sure there's a better way to do this.
public class MyWebRequestCycleProcessor extends WebRequestCycleProcessor
{
protected IRequestTarget resolveRenderedPage(RequestCycle
requestCycle,
RequestParameters requestParameters)
{
String componentPath =
requestParameters.getComponentPath();
Session session = requestCycle.getSession();
Page page =
session.getPage(requestParameters.getPageMapName(),
componentPath, requestParameters.getVersionNumber());
if (page != null)
{
return resolveRenderedPage(requestCycle,
requestParameters, page, false);
}
else
{
// Try to resolve the page instead of throwing an
expired page exception
try
{
page = newPage(requestCycle,
requestParameters);
if (page != null)
{
IPageMap pageMap =
PageMap.forName(requestParameters.getPageMapName());
pageMap.put(page);
return
resolveRenderedPage(requestCycle, requestParameters, page,
true);
}
}
catch (Exception e)
{
LOG.error(e.getMessage(), e);
}
}
return null;
}
protected Page newPage(RequestCycle requestCycle,
RequestParameters
requestParameters) throws Exception
{
PageParameters params = new
PageParameters(requestParameters.getParameters());
IPageFactory pageFactory =
requestCycle.getApplication().getSessionSettings().getPageFactory();
if ((params == null) || (params.size() == 0))
{
return
pageFactory.newPage(Class.forName(requestParameters.getPageMapName()));
}
else
{
requestCycle.getRequest().getParameterMap().putAll(((params)));
return
pageFactory.newPage(Class.forName(requestParameters.getPageMapName()),
params);
}
}
private IRequestTarget resolveRenderedPage(RequestCycle
requestCycle,
RequestParameters requestParameters, Page page, boolean newRequest)
{
IRequestTarget target = null;
requestCycle.getRequest().setPage(page);
String interfaceName =
requestParameters.getInterfaceName();
String componentPath =
requestParameters.getComponentPath();
MyAjaxMarkupContainer container = null;
if (newRequest)
{
if (componentPath.indexOf(ajax_link) != -1)
{
container = ((MyPage)
page).getMyAjaxMarkupContainer();
}
// needed for wicket to find the ajax link to make
the request
container.beforeRender();
// Render the page so wicket finds the markup for
the ajax link making
the request
page.render();
page.afterRender();
}
if (interfaceName != null)
{
target =
resolveListenerInterfaceTarget(requestCycle, page,
componentPath, interfaceName, requestParameters);
}
else
{
target = ((new PageRequestTarget(page)));
}
return target;
}
}
--
View this message in context:
http://www.nabble.com/PageExpiredException---ajax-request-tp21840751p21840751.html
Sent from the Wicket - User mailing list
Re: Wicket Modal Window - IFrame
Matej,
Just to be clear - it's not that a modal window in Wicket App A is sourcing
content from Wicket App B. It's that in this scenario Wicket App A has an
generic iframe - not wicket produced - who's src is Wicket App B.
The code here when run from B on modal creation pulls the Wicket.Window from
A which I don't want. I want all modal content to be created in the iframe
document that Wicket App B is sourced in.
Wicket.Window.create = function(settings) {
var win;
if (typeof(settings.src) != undefined Wicket.Browser.isKHTML() ==
false) {
try {
win = window.parent.Wicket.Window;
} catch (ignore) {
}
}
Matej Knopp-2 wrote:
On Wed, Sep 3, 2008 at 10:13 PM, Shaun Thompson [EMAIL PROTECTED] wrote:
I'm currently running into an issue with the wicket modal window.
My situation is this.
Wicket App A contains an IFrame sourcing Wicket App B.
B has an Wicket IFrame modal window on one of it's pages.
When Wicket.Window.create in modal.js is called from B, the
Wicket.Window is pulled from window.parent.Wicket.Window which has
been created in A.
Now the remaining functions called on Wicket.Window are referencing
functions from A modal.js
This becomes a problem when the createDOM in modal.js is called. The
div tag containing the modal html from B is created in A's document.
The iframes src is relative so the content for the modal is not found.
One solution is to have Wicket App B use WebRequestCodingStrategy and
encode all it's url's from relative to absolute. This is not an
optimal solution as I have no control over the multiple wicket apps
that will be sourced in Wicket App A's iframe.
Is there anyway to essentially namespace the Wicket.Window so B does
not pick up A's objects?
I don't think so. And the modal window wasn't really meant to be able
to contain different/multiple applications.
-Matej
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Wicket-Modal-Window---IFrame-tp19297181p19301522.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
