You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by sthomps <st...@gmail.com> on 2013/02/05 19:43:29 UTC
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 message in context: http://apache-wicket.1842946.n4.nabble.com/HP-Fortify-Critical-Security-Issues-tp4656091.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HP Fortify & Critical Security Issues
Posted by "Richard W. Adams" <RW...@UP.COM>.
From: sthomps <st...@gmail.com>
To: users@wicket.apache.org
Date: 02/05/2013 12:44 PM
Subject: HP Fortify & Critical Security Issues
We use Fortify at our company. I'm please to note that it found no
vulnerability in my Wicket app, though it did numerous issues with
ColdFusion apps (no surprise). I'm not in our security department, so am
by no means an expert, but at least some Fortune 500 companies use it.
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 message in context:
http://apache-wicket.1842946.n4.nabble.com/HP-Fortify-Critical-Security-Issues-tp4656091.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: HP Fortify & Critical Security Issues
Posted by sthomps <st...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HP Fortify & Critical Security Issues
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Feb 5, 2013 at 10:43 AM, sthomps <st...@gmail.com> wrote:
> 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.
invalid. the javascript code referenced here is only invoked as a
callback to an ajax request object. the url passed in is generating on
the server. in order to take advantage of this vulnerability the
attacker would need to gain javascript execution via a GET url at
which point they may easily execute window.location=foo themselves
rather then utilizing our javascript.
>
>
> *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.
>
invalid. the prefix part of the file name is fixed to be the user's
session id and request timestamp - so the user cannot access other
user's temp files by manipulating the file name.
> *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.
invalid. this field is meant to be shared.
-igor
>
> *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 message in context: http://apache-wicket.1842946.n4.nabble.com/HP-Fortify-Critical-Security-Issues-tp4656091.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org