Petr
Not sure if this helps you out, it is the specific report from the IBM Rational Appscan. I realise now that if I had not allowed guest access this probably would have stopped this? Thanks again.
...............................
[1 of 3] Session Identifier Not Updated
Severity: High
Test Type: Application
Vulnerable
URL: /moodle/calendar/export_execute.php
Remediation Tasks: Do not accept externally created session identifiers
Variant 1 of 1 [ID=14709]
The following may require user attention:
GET /moodle/calendar/export_execute.php?
preset_what=all&preset_time=recentupcoming&username=guest&authtoken=4bd60ee266e
f7fffe88ad5c519424fc708e7afbd HTTP/1.0
Cookie: MOODLEID_=%25ED%25C3%251CC%25B7d;
MoodleSessionTest=UpdK1fYAAa; MoodleSession=d2ac24dad34277fec2250f41f150b746
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Referer: /moodle/calendar/view.php?
view=month&course=1&cal_d=1&cal_m=6&cal_y=2009
HTTP/1.1 200 OK
Content-Length: 111
Date: Sun, 26 Jul 2009 22:39:57 GMT
Server:
Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.8
X-Powered-By: PHP/5.2.8
Expires: Thu, 01 Jan 1970 00:00:00GMT
Cache-Control: private, must-revalidate, pre-check=0, post-check=0, max-age=0
Pragma: no-cache
Last-Modified: Sun, 26 Jul 2009 22:39:58 GMT
Accept-Ranges: none
27/07/2009 1:34:56 PM 141/2327
Content-disposition: attachment; filename=icalexport.ics
Content-Type: text/calendar
Connection: close
BEGIN:VCALENDAR
METHOD:PUBLISH
VERSION:2.0
END:VCALENDAR
Validation In Response:
N/A
Reasoning:
One or more session identifiers were not updated in the response.
Session Identifier Not Updated
Application
WASC Threat Classification
Authorization: Session Fixation
http://www.webappsec.org/projects/threat/classes/session_fixation.shtmlCVE Reference(s)
N/A
Security Risks
It is possible to steal or manipulate customer session and cookies, which might be used to
impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform
transactions as that user
Possible Causes
Insecure web application programming or configuration
Technical Description
According to WASC:
"Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending
on the functionality of the target web site, a number of techniques can be utilized to "fix" the session
ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with
previously made HTTP requests. After a user's session ID has been fixed, the attacker waits for the
user to login, and then uses the predefined session ID value to assume the user's online identity.
In general, there are two types of session management systems for ID values. The first type is
"permissive" systems, that allow web browsers to specify any ID. The second type is "strict" systems,
that only accept server-side generated values. With permissive systems, arbitrary session IDs are
maintained without contact with the web site. Strict systems require that the attacker maintain the "trap
-session", with periodic web site contact, preventing inactivity timeouts.
Without active protection against session fixation, the attack can be mounted against any web site
using sessions to identify authenticated users. Web sites using session IDs are normally cookie-
based, but URLs and hidden form-fields are used as well. Unfortunately, cookie-based sessions are
the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of
cookies.
In contrast to stealing a user's session ID after they have logged into a web site, session fixation
provides a much wider window of opportunity. The active part of the attack takes place before the user
logs in.
The session fixation attack is normally a three step process:
1) Session Set-Up
The attacker sets up a "trap-session" for the target web site and obtains that session's ID, or the
attacker may select an arbitrary session ID used in the attack. In some cases, the established trap
session value must be maintained with repeated web site contact.
2) Session Fixation
The attacker introduces the trap session value into the user's browser and fixes the user's session ID.
3) Session Entrance
The attacker waits until the user logs into the target web svalue is used, the attacker may take over."
----------------------------------------------
If a session management system accepts session IDs in the form of a URL parameter, the following
request may force the session ID to the value of the URL parameter.
Code Snippet:
http://example/login.php?PHPSESSID=1234
According to WASC:
"Issuing a new session ID cookie value using a client-side script
-------------------------------------------------------------------------------------------
A Cross-Site Scripting vulnerability on any web site in the
domain can be used to modify the current
cookie value.
Code Snippet:
http://example/<script>document.cookie="sessionid=1234;%20domain=.example.dom";</script>
Another similar example (using
META tag injection):
http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%
20domain=.example.dom">
Issuing a cookie using an HTTP response header
-----------------------------------------------------------------------
The attacker forces the target web site, or any other site in the domain, to issue a session ID cookie.
This can be achieved in many ways:
- Breaking into a web server in the domain (e.g., a poorly maintained WAP server)
- Poisoning a user's DNS server, effectively adding the attacker's web server to the domain
- Setting up a malicious web server in the domain (e.g., on a workstation in Windows 2000 domain, all
workstations are also in the DNS domain)
- Exploiting an HTTP response splitting attack"
----------------------------------------------
Comparison of the session identifiers before and after the login process revealed they were not
updated, which means that user impersonation may be possible. Preliminary knowledge of the
session identifier value may enable a remote attacker to pose as a logged-in legitimate user.
The session identifier value can be obtained by utilizing a Cross-Site Scripting vulnerability, causing
the victim's browser to use a predefined session identifier when contacting the vulnerable site, or by
launching a Session Fixation attack that will cause the site to present a predefined session identifier to
the victim's browser.
General Fix Recommendations
Always generate a new session to which the user will log in if successfully authenticated.
Prevent user ability to manipulate session ID.
Do not accept session IDs provided by the user's browser at login
References and Relevant Links
"Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security
PHP Manual, Session Handling Functions, Sessions and security
............................................
). Sadly we can't trust all the users we have in our University 
