||Home : Advisories : Possible session hijacking with website implementations using middleware products|
||Possible session hijacking with website implementations using middleware products
||MIS Corporate Defence Solution
||21st November 2000
MIS Corporate Defence Solutions - NST Advisory (001)
Possible session hijacking with website implementations
using middleware products.
Any web systems / farms utilising middleware software to help run all or
parts of their website using some form of session id tokens that are stored
within the URL.
Users that visit websites that are affected (see above).
N/A - no single vendor.
However, BroadVision was contacted about this issue and they are aware of
this problem. They are currently implementing changes and recommendations to
it's customers as you read.
There are a number of companies that utilise middleware software within
their websites / farms, due to the "all-in-one" nature of the packages on
offer. Some of the features (not naming all of them) allow a company to
track user's browsing and buying habits throughout their site, tailored
content depending on the visitor, and real-time analytic reports.
This issue seems not to be publicised and from conversations we have had
with people at the software houses, they seem to be sweeping this under the
carpet and changing their systems on the quiet.
BroadVision will be used as our example middleware product because it is the
one we have been using for testing. An example site of www.site.com
utilising BroadVision software, passes it's parameters required for
run any back-end commands / applications that may be required. We assume
from here on, that www.site.com is an e-commerce and a service provider of
When a user views a site using BroadVision as well as Session IDs and Engine
IDs to display content, the IDs are present within the URL. From the limited
experience we have had with BroadVision, it seems that the session ID is a
random 20 digit number (xxxxxxxxxx.xxxxxxxxxx) and the Engine ID represents
what server is serving the content. Therefore it can be determined how many
servers are presenting the content. The first part (10 digits) of the
BV_SessionID is a random number. The second part (10 digits) however, seems
to be an incremental counter that could be used as a primary key in a
database or as a reference:
An example where the engine IDs are constant (taken from a sample of 100
An example where the engine IDs are different (sequential hits from a sample
of 100 hits):
For example, visit www.site.com that is running Broadvision software. You
will notice that your address bar will read something like this:
(this will be wrapped :( ) The important part of this URL is:
For other middleware applications, the parameter name might be &IdKey or
It is possible to derive the number of engines or servers that serve pages
for www.site.com. This is derived from the way the engine ids are
The problem exists when a user is viewing www.site.com in normal HTTP mode
and decides to move into the secure area of the site (HTTPS), such as
logging in to check your bill / account details for the service been
provided by www.site.com. The session ID that the user has remains the same,
so in essence, follows him/herself into the secure zone.
Therefore, if you were able to sniff the BV_SessionID and BV_EngineID
parameters whilst the user is still browsing the "unsecure" area of the
site, it is possible to "hijack" or "join" the session by replacing the ID
strings within any of the URLs displayed in the address bar, providing the
session timeout hasn't expired. The "hijack" or "join" is possible from
either the same IP address or from a different IP address.
By registering yourself as a valid customer of www.site.com, it is possible
to determine the full URL for accessing say a user's billing details,
billing address, etc... This will enable a malicious user to insert a stolen
set of ids into the URL to gain unauthorised access to another customers
Please note that retrieving a list of valid BV_EngineIDs is trivial. Just
repeatedly close and open a browser and take a note of the value. Both the
session and engine IDs would be trivial to pick up if you knew users were
visiting www.site.com on a LAN for example. Set up a sniffer, retrieve the
IDs and hey presto! Although this is not as widespread as a number of other
website / middleware vulnerabilities, we still deem this as a large security
issue that is largely undocumented.
In theory, it is possible to brute force the BV_SessionID if there are no
restrictions on the server side, and the client side has enough bandwidth
available. Although this would take some time to brute force a randomly
generated 20 digit number, it may be possible for an evil cracker to get
lucky. If you specify an invalid session id / engine id or your session has
timed out, an error is displayed (applicable to this example, may differ
from implementation to implementation).
Workaround / Fix / Solution:
There is no silver bullet solution, but a number of workarounds can be
applied to prevent this type of session hijacking.
1) Send all HTTP communication containing the session and engine ids over
HTTPS to help prevent them from being "stolen".
2) Utilise a session cookie, i.e. a cookie that is linked to the
middleware's session management system. The cookie will contain the session
ID details. Each time a user visits the page, the middleware application
should check for the existance of this cookie and verify the values held
within the cookie against the ones held within it's own internal system. If
they are the same, it is a valid request. However if they are not the same
or the cookie does not exist, this is not a valid request and should be
declined. Please note that with some middleware software, it may be the
responsibility of the web application running on top of the middleware
software, to utilise a library that enables session cookies to be utilised.
Please check with the vendor regarding this.
3) Utilise URL re-writing to prevent the contents of the query string from
appearing in the URL that is displayed in the address bar of a browser.
4) When a user is directed into the secure area of www.site.com to view
their account details, site.com should generate a new session id within the
HTTPS request and reply. This prevents a user being followed into the secure
5) Request further documentation from the vendor on how to implement a
higher level of security whilst using their middleware products. The
reasoning behind this is because BroadVision have further documentation
available, but we understand clients need to request it.
Nothing is 100% secure, the risk of being hacked / cracked is always
improbable, never impossible.
NST @ MIS.
Eric Golin, Kevin Wharton @ BroadVision
Thanks for taking the time to read this advisory,
Network Security Team.
MIS Corporate Defence Solutions Limited
Tel: +44 (0)1622 723400 (Switchboard)
Fax: +44 (0)1622 728580