You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Tino Kissig (JIRA)" <ji...@apache.org> on 2010/06/01 09:16:37 UTC

[jira] Created: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
------------------------------------------------------------------

                 Key: WICKET-2903
                 URL: https://issues.apache.org/jira/browse/WICKET-2903
             Project: Wicket
          Issue Type: Bug
    Affects Versions: 1.4.4
            Reporter: Tino Kissig
            Assignee: Igor Vaynberg
             Fix For: 1.4.6


The HttpsRequestCycleProcessor has the following code:

	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
	{
		// we need to persist the session before a redirect to https so the session lasts across
		// both http and https calls.
		Session.get().bind();

		IRequestTarget target = super.resolve(rc, rp);
		return checkSecure(target);
	}

The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.

I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-2903.
-----------------------------------

    Fix Version/s: 1.4.11
                       (was: 1.4.9)
       Resolution: Fixed

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.11
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903079#action_12903079 ] 

Igor Vaynberg commented on WICKET-2903:
---------------------------------------

the scenario why this code was added:

* the user is browsing your application which is all stateless until login
* then they go to your login page which redirects to https
* they login and you create a session with id 550 for them and stuff their user id into the session, which is how your app tracks whether they are logged in or not
* user is redirected to their landing page which is not secure
* user is all of a sudden logged out - wtf?

the answer is that the session that was created during login with id 550 was created during an https request and tomcat will markup it as "secure". only requests on the https protocol will see this session. requests coming on http will create a new session - which will not have the user id stored - so the user will be effectively logged out as soon as going to any http page.

now if the session was created before the https request it will be preserved and https requests will use it - so everything works transparently.

a large class of applications, perhaps the largest, does not sandbox the user into https pages after login. usually, only the login page and a key few others are server over https. so the default is set up to make the code work for these applications.

i will apply martin's patch which will allow the creation of session to be toggled, but youve been warned.

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.9
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907734#action_12907734 ] 

Hudson commented on WICKET-2903:
--------------------------------

Integrated in Apache Wicket 1.5.x #316 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/316/])
    WICKET-2903 CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
WICKET-3016 Port to 1.5

Port to 1.5 the https config flag whether to bind the Session before going https or not.


> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.11
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903108#action_12903108 ] 

Hudson commented on WICKET-2903:
--------------------------------

Integrated in Apache Wicket 1.4.x #125 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/125/])
    Issue: WICKET-2903


> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.11
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov updated WICKET-2903:
------------------------------------

    Attachment: WICKET-2903.patch

Attach a possible patch.
Added a flag in the HttpsConfig with which the user can configure whether she wants to bind the session or not before going secure (https).

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.9
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Tino Kissig (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873906#action_12873906 ] 

Tino Kissig commented on WICKET-2903:
-------------------------------------

Since we try to do without a HttpSession as long as possible we would like to have the possibility to change this default behavior.
Overwriting of the "resolve"-method isn't the solution since "super.resolve(...)" will create the session as well.

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.4
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.6
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Tino Kissig (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tino Kissig updated WICKET-2903:
--------------------------------

        Fix Version/s: 1.4.9
                           (was: 1.4.6)
    Affects Version/s: 1.4.8
                           (was: 1.4.4)

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.9
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2903) CLONE -HttpsRequestCycleProcessor causes HttpSession to be created

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895010#action_12895010 ] 

Martin Grigorov commented on WICKET-2903:
-----------------------------------------

There is a high risk with that patch.
If the session is not bound before redirecting to https then the jsessionid for the https request will be completely new and from there on back button support will be broken.
In completely stateless application (like described here) this probably is not a problem. But it is high risk for any other application.

> CLONE -HttpsRequestCycleProcessor causes HttpSession to be created
> ------------------------------------------------------------------
>
>                 Key: WICKET-2903
>                 URL: https://issues.apache.org/jira/browse/WICKET-2903
>             Project: Wicket
>          Issue Type: Bug
>    Affects Versions: 1.4.8
>            Reporter: Tino Kissig
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.9
>
>         Attachments: WICKET-2903.patch
>
>
> The HttpsRequestCycleProcessor has the following code:
> 	public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> 	{
> 		// we need to persist the session before a redirect to https so the session lasts across
> 		// both http and https calls.
> 		Session.get().bind();
> 		IRequestTarget target = super.resolve(rc, rp);
> 		return checkSecure(target);
> 	}
> The Session.get().bind() causes an HttpSession to be created even if the target page is stateless.  In our application all our pages are https and our login page is stateless.  Because the session is created anyway, we are now exposed to a DoS attack.
> I don't really see why a HttpSession needs to be forced here.  If the page is stateful, then a session will be created anyway.  If the current page is stateless but the user had already navigated stateful pages, then a session will be present again.  Is there a scenario where it is important to for the session creation?   Can a mechanism be provided that will disable this behaviour?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.