DO NOT REPLY [Bug 45255] New: support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 Summary: support disable jsessionid from url against session fixation attacks Product: Tomcat 6 Version: unspecified Platform: PC URL: http://en.wikipedia.org/wiki/Session_fixation OS/Version: Windows XP Status: NEW Severity: critical Priority: P1 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] please see wikipedia http://en.wikipedia.org/wiki/Session_fixation -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 quaff <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|critical|enhancement --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-23 01:43:25 PST --- Please read SRV.7.1 of the servlet spec. An option could be adding to disable URL-rewriting (noting that this would be non-spec compliant). Requests for enahncements that are accompanied by patches tend to get looked at sooner that those without. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255
--- Comment #2 from Rainer Jung <[EMAIL PROTECTED]> 2008-06-23 01:58:29 PST ---
Hi Mark,
Spec 7.1 seems to say:
- a compliant container may support URL encoded sessions ("may be used")
- if it does support them, it has to use the path parameter "jsessionid"
So if a site decides to only use cookies because of security, it could be an
interesting option to allow not even accepting session IDs which were URL
encoded.
What do you think?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #3 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-23 02:32:36 PST --- SRV.7.1.4 is the important bit for us. If we disable URL-rewriting we break the spec. That said, I am not against it as an option (probably at the context level) providing it defaults to off. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #4 from Rainer Jung <[EMAIL PROTECTED]> 2008-06-23 02:40:39 PST --- Ahh, of course you are right. I'll see how easy an option is (I guess the incoming session path parameter and cookie is handled in the connector, and the context later doesn't know, where the id in the request came from ...). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #5 from Rainer Jung <[EMAIL PROTECTED]> 2008-06-23 02:46:58 PST --- Sorry, again I wrote partial nonsense: there is a request.isRequestedSessionIdFromURL() in the servlet API. So it is easy for us to know, but also for the webapp. One could thus prevent session fixation via the jsessionid path parameter by a simple filter, that invalidates the session, if request.isRequestedSessionIdFromURL() is true. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #6 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-23 02:56:29 PST --- That would work. If we wanted to make this a Tomcat option the code around the context configuration option cookies is where I would start. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "Tomcat/UTF-8" by ChristopherSchultz
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The following page has been changed by ChristopherSchultz:
http://wiki.apache.org/tomcat/Tomcat/UTF-8
The comment on the change is:
Stopped clobbering client-provided character encoding; added notes.
--
3.
For translation of inputs coming back from the browser there must be a
- method that translates from the browser's ISO-8859-1 to UTF-8. It seems to
+ method that translates from the browser's ISO-8859-1 to UTF-8. ISO-8859-1
+ is the default character encoding for servers and browsers according to the
+ [http://www.ietf.org/rfc/rfc2616.txt HTTP specification] section 3.4.1.
- me that -1 is used in all regions as I have had people in countries such as
- Greece & Bulgaria test this and they always send input back in -1 encoding.
- The method which you will use constantly should go something like this:
{{{ /**
- * Convert ISO8859-1 format string (which is the default sent by IE
+ * Convert ISO-8859-1 format string (which is the default sent by IE
* to the UTF-8 format that the database is in.
*/
public String toUTF8(String isoString)
@@ -41, +40 @@
}
catch(UnsupportedEncodingException e)
{
+ // TODO: This should never happen. The UnsupportedEncodingException
+ // should be propagated instead of swallowed. This error would indicate
+ // a severe misconfiguration of the JVM.
+
// As we can't translate just send back the best guess.
System.out.println("UnsupportedEncodingException is: " +
e.getMessage());
@@ -89, +92 @@
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain next)
throws IOException, ServletException
{
+ // Respect the client-specified character encoding
+ // (see HTTP specification section 3.4.1)
+ if(null == request.getCharacterEncoding())
- request.setCharacterEncoding(encoding);
+ request.setCharacterEncoding(encoding);
+
next.doFilter(request, response);
}
@@ -119, +126 @@
The suggested solution originates from
[http://people.comita.spb.ru/users/sergeya/java/ruschars.html Sergey Astakhov
(all texts are in russian)] ([EMAIL PROTECTED])
+ '''Important note''': Note that this filter should be as far towards the
front of your filter chain as possible. If some other code calls
request.getParameter (or a similar method) before this filter is invoked, then
the encoding will not be set properly, and your parameters will still be
decoded improperly.
+
'''- TIP -'''
Update the file $CATALINA_HOME/conf/server.xml for UTF-8 support by
connectors.
@@ -131, +140 @@
disableUploadTimeout="true"
'''URIEncoding="UTF-8'''"/>
+ Note that this changes the behavior of reading GET parameters from the
request URI and will not affect POST parameters at all.
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "Tomcat/UTF-8" by markt
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The following page has been changed by markt:
http://wiki.apache.org/tomcat/Tomcat/UTF-8
The comment on the change is:
Remove inaccurrate statement
--
%> }}}
2.
- In the Catalina.bat (windows) catalina.sh (windows)
- apache$jakarta_config.com (OpenVMS), file there must be a switch added to
- the call to java.exe. In LINUX (FC5), use /etc/tomcat5/tomcat5.conf and
update the JAVA_OPTS switch.
- The switch is:
-
- -Dfile.encoding=UTF-8
-
- I cannot find documentation for this environment variable anywhere or what
- it actually does but it is essential.
-
- 3.
For translation of inputs coming back from the browser there must be a
method that translates from the browser's ISO-8859-1 to UTF-8. ISO-8859-1
is the default character encoding for servers and browsers according to the
@@ -64, +53 @@
'''Alternative solution'''
- The solution suggested above works fine with steps (1) and (2) only, but from
the architecture perspective the correct way is to add a filter to the Tomcat
that will do necessary correction for the application deployed without any
additional changes to the rest of the code.
+ The solution suggested above works, but from the architecture perspective the
correct way is to add a filter to the Tomcat that will do necessary correction
for the application deployed without any additional changes to the rest of the
code.
1. Make sure JSP header is set as suggested:
{{{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "FrontPage" by ole
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by ole: http://wiki.apache.org/tomcat/FrontPage -- * '''["PoweredBy"]''' - A list of sites powered by Tomcat. * '''["Tomcat/Links"]''' - Useful Links. * '''["HowTo"]''' - How to as linked by the FAQ. + * '''["Logging FAQ"]''' - Logging FAQs. + * '''["Logging for Developers"]''' - Best practices, etc. * '''["JNDI HowTo"]''' - How to authenticate to different LDAP servers * '''["Tomcat/Books"]''' - Books about Tomcat. * '''["UsingPhp"]''' - Using PHP with Tomcat 4 or later. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "FrontPage" by ole
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by ole: http://wiki.apache.org/tomcat/FrontPage -- * '''["PoweredBy"]''' - A list of sites powered by Tomcat. * '''["Tomcat/Links"]''' - Useful Links. * '''["HowTo"]''' - How to as linked by the FAQ. - * '''["Logging FAQ"]''' - Logging FAQs. - * '''["Logging for Developers"]''' - Best practices, etc. * '''["JNDI HowTo"]''' - How to authenticate to different LDAP servers * '''["Tomcat/Books"]''' - Books about Tomcat. * '''["UsingPhp"]''' - Using PHP with Tomcat 4 or later. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45261] New: Concurrent node failure leads to inconsistent views.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45261
Summary: Concurrent node failure leads to inconsistent views.
Product: Tomcat 6
Version: 6.0.16
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=22166)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22166)
Demonstrate view inconsistency.
In a four node cluster, using NonBlockingCoordinator, if two nodes fail at the
same time, the remaining two nodes get different views and never converge.
When the other nodes restart, they never install a view at all.
I've attached the relevant demo code. Run it on 4 machines, wait for view
installation, then CTRL-C two of them. The other two will never print the same
UniqueId. Start a new node, view is always null.
Immediately after the two node failure, one of the surviving nodes issues this
stack trace;
WARN - Member send is failing for:tcp://{-64, -88, -91, 34}:4000 ; Setting to
su
spect and retrying.
ERROR - Error processing coordination message. Could be fatal.
org.apache.catalina.tribes.ChannelException: Send failed, attempt:2 max:1;
Fault
y members:tcp://{-64, -88, -91, 34}:4000;
at
org.apache.catalina.tribes.transport.nio.ParallelNioSender.doLoop(Par
allelNioSender.java:172)
at
org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessag
e(ParallelNioSender.java:78)
at
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMes
sage(PooledParallelSender.java:53)
at
org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessa
ge(ReplicationTransmitter.java:80)
at
org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage(Chann
elCoordinator.java:78)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(C
hannelInterceptorBase.java:75)
at
org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.
handleMyToken(NonBlockingCoordina
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
