There are several risks:
- obtaining the ST and using it before the user and at the same time
redirect the user again to the cas to get a new one for himself. You
have 2 session in the app. One hacker, one user. Not quite sure if the
second ticket for a service would trigger a single logout event. But i
think it does not.
- A kind of firesheep attack where you gain access to app by stealing
the local session cookie and do some dual usage of one session. Could be
prevented (or at least made more difficult) by some firesheep antimeasures.
- Recreating session info (cookie?) from the ST (if session cookie is
derived from the ST)
- Genereating a single logout requests for a user.
Maybe some more :D
Regards,
Joachim
Am 29.09.2011 20:06, schrieb [email protected]:
I want to check the risk scenario for authorizing CAS services that
are not behind SSL, e.g. http://example.com/casapp
Is the scenario that someone might intercept the ticket from the
redirect to the users browser? That is, they would get the ticket sent
in the clear to the user via the redirect then quickly before the user
could use it (or by blocking the user's communication with the target
host) use the ticket on the target host and gain access as the user?
As I understand it, once the ticket is validated, it can't be validated
again.
Is there another scenario?
Best,
Kim
Kim Cary
Chief Information Security Officer
Pepperdine University
<html><head></head><body style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I
want to check the risk scenario for authorizing CAS services that are
not behind SSL, e.g. <a
href="http://example.com/casapp";>http://example.com/casapp</a><div><br></div><div>Is
<http://example.com/casapp";>http://example.com/casapp</a><div><br></div><div>Is>
the scenario that someone might intercept the ticket from the redirect
to the users browser? That is, they would get the ticket sent in the
clear to the user via the redirect then quickly before the user could
use it (or by blocking the user's communication with the target host)
use the ticket on the target host and gain access as the
user?</div><div><br></div><div>As I understand it, once the ticket is
validated, it can't be validated again.</div><div><br></div><div>Is
there another scenario?<br><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust:
auto; -webkit-text-stroke-width: 0px; font-size: medium;
"><div>Best,</div><div>Kim</div><div><br></div><div><br></div><div>Kim
Cary</div><div>Chief Information Security Officer</div><div>Pepperdine
University</div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
