[JBoss JIRA] Created: (JBCLUSTER-269) AbstractJBossCacheService getSessionIds() misses dead backup regions
by Brian Stansberry (JIRA)
AbstractJBossCacheService getSessionIds() misses dead backup regions
--------------------------------------------------------------------
Key: JBCLUSTER-269
URL: https://jira.jboss.org/jira/browse/JBCLUSTER-269
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: HA-Server-Cache-JBC
Affects Versions: HA-Server-Cache-JBC 2.1.2.GA, HA-Server-Cache-JBC 2.0.1.GA , HA-Server-Cache-JBC 2.2.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The algorithm for searching for session ids does not take into account that the Fqn for buddies whose name ends with :DEAD (i.e. buddies that JBC knows are no longer in the group) include an extra element. Effect is getSessionIds() does not return ids for sessions stored under such trees.
Effect of this is when a session manager starts, it gets an incomplete listing of session ids. Affects of this are:
1) Some incorrect session count statistics through the JMX interface.
2) The sessions that are missed will not be passivated or expired by the background cleanup task.
Such sessions will still be available if accessed by a user request.
Fix is to properly search the dead buddy backup trees.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Resolved: (JBWEB-141) Servlet Filter against CSRF
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-141?page=com.atlassian.jira.plug... ]
Remy Maucherat resolved JBWEB-141.
----------------------------------
Fix Version/s: JBossWeb-3.0.0.Beta6
Resolution: Done
For XSS, if you are talking about a well defined set of patterns, you might be able to create a set of mod_rewrite rules. They should then work just fine with the rewrite valve. If that's not enough, then create a new JIRA on XSS.
> Servlet Filter against CSRF
> ---------------------------
>
> Key: JBWEB-141
> URL: https://jira.jboss.org/jira/browse/JBWEB-141
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Marc Schoenefeld
> Assignee: Remy Maucherat
> Priority: Minor
> Fix For: JBossWeb-3.0.0.Beta6
>
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application.
> So a common solution offered by the http server is helpful to raise the default protection level.
> A servlet filter will help to
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Updated: (JBWEB-141) Servlet Filter against CSRF
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-141?page=com.atlassian.jira.plug... ]
Remy Maucherat updated JBWEB-141:
---------------------------------
Summary: Servlet Filter against CSRF (was: Servlet Filter against XSS)
> Servlet Filter against CSRF
> ---------------------------
>
> Key: JBWEB-141
> URL: https://jira.jboss.org/jira/browse/JBWEB-141
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Marc Schoenefeld
> Assignee: Remy Maucherat
> Priority: Minor
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application.
> So a common solution offered by the http server is helpful to raise the default protection level.
> A servlet filter will help to
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months