Good morning Dale,
By examining the /WEB-INF/login-webflow chain of events, it appears that
it has been designed to check for the existence of a TGT and not the
validity of the user's TGT cookie.
Excerpt:
------------------------------------------------------------------------
----------------------------------------------------
<action-state id="initialFlowSetup">
<action bean="initialFlowSetupAction" />
<transition on="success" to="ticketGrantingTicketExistsCheck" />
</action-state>
<decision-state id="ticketGrantingTicketExistsCheck">
<if test="${flowScope.ticketGrantingTicketId != null}"
then="hasServiceCheck"
else="gatewayRequestCheck" />
</decision-state>
<decision-state id="gatewayRequestCheck">
<if test="${externalContext.requestParameterMap['gateway'] != ''
&&
externalContext.requestParameterMap['gateway'] != null
&&
flowScope.service != null}"
then="redirect"
else="viewLoginForm" />
</decision-state>
<decision-state id="hasServiceCheck">
<if test="${flowScope.service != null}" then="renewRequestCheck"
else="viewGenericLoginSuccess" />
</decision-state>
------------------------------------------------------------------------
----------------------------------------------------
The code behind the org.jasig.cas.web.flow.GenerateServiceTicketAction
web flow action uses the value in the user's TGT cookie in the
generation of service ticket's, so IF a user is able to get another
user's TGT by guessing (tickets are opaque, random, case-sensitive 40+
alphanumeric strings so guessing is nontrivial) or capturing network
traffic (CAS is configured to require SSL so capturing is non-trivial),
then s/he would be able to masquerade as someone else.
FYI: Pertinent source files to review are:
cas-server-core/src/java/main/org/jasig/cas/web/flow/GenerateServiceTick
etAction.java (Spring Web Flow action that generates STes against TGTes)
cas-server-core/src/java/main/org/jasig/cas/web/ServiceValidateControlle
r.java (controller that validates STes and responds to clients with
principals)
cas-server-webapp/src/main/webapp/WEB-INF/view/jsp/default/protocol/2.0/
casServiceValidationSuccess.jsp (xml response to clients when STes have
been validated by ServiceValidateController)
Hope this helps,
Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
[EMAIL PROTECTED]
(office) 225.578.3737
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Dale Ogilvie
Sent: Wednesday, September 26, 2007 12:07 AM
To: [email protected]
Subject: Modifying CASTGC
Hi there,
A colleague tried an experiment with our CAS that returned a surprizing
result.
1. Browse to CAS https://cas.trimble.com/cas/login
The CAS login page is displayed and the response included:
Set-Cookie: JSESSIONID=C3DE37759B69F4A018F7EC79DAB2ABC7; Path=/cas;
Secure
2. Login (using the out-of-the-box password equals username auth
backend)
A pleasant green "Login Successful" is displayed and we get a CASTGC:
Set-Cookie: CASTGC=TGT-13-dACeQGE4BV4ObzNmRGfHwSizSAcgTANJVR5-50;
Path=/cas; Secure
3. My colleague with the devious mind used the cookie editing facility
of the firefox Web Developer extension
(http://chrispederick.com/work/web-developer/) to change the value of
CASTGC to "dodgy"
4. We browsed to https://cas.trimble.com/cas/login again, expecting to
be presented with the login page due to our "dodgy" CASTGC.
But no, we get "login successful" again!!
GET /cas/login HTTP/1.1
Host: cas.trimble.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7)
Gecko/20070914 Firefox/2.0.0.7
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
n;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: JSESSIONID=C3DE37759B69F4A018F7EC79DAB2ABC7; CASTGC=dodgy
HTTP/1.x 200 OK
Date: Wed, 26 Sep 2007 05:00:16 GMT
Pragma: No-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 788
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Why are we still (seemingly) logged in to CAS after we munged the
CASTGC!?!
This is with the 3.1 CAS server by the way.
--
Dale Ogilvie
Senior Software Engineer
Trimble Navigation NZ Ltd
P O Box 8729
Riccarton
Christchurch
Ph: +64 3 9635344
Fax: +64 3 9635317
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
