Name:    Problem with customized login pages for Oracle SSO
Id:    MG-2004-01
Issued:    2004-03-30
Authors:  Guido van Rooij (Madison Gurkha)
    Arjan de Vet (Madison Gurkha)
Application:  All known versions
Platforms:  All supported platforms
Reference:  http://www.madison-gurkha.com/advisories/MG-2004-01.txt
CVE:     ---


Description:

  Oracle has a Single Sign-on application called OSSO.

  Among others, it has a web based login form. This form can be
  customized as explained in "Oracle 9iAS Single Sign-on
  Administrators Guide, Release 2(9.0.2), Part No. A96115-01".  In
  this document, a sample login form is published (section 8).

  The problem with this login form is that it can be abused by
  unauthorized persons to gain access to the supplied usercode and
  password. This can be done by tricking a valid user to open a
  URL that is the real URL of the customized SSO login page but
  with a modified URL parameter.

  The problem is that the attack makes use of the real login page.
  Thus, if users check host certificates only, they will not be
  able to detect that they are being tricked. Also, after logging
  in, they can be redirected to the proper application on the
  intended system to hide the fact that usercode and password have
  been stolen.

  Note that the problem is a design problem in the way custom
  login pages must be implemented, not a problem with a sample
  script.

Impact:

  Users can accidentally reveal their SSO usercode/password
  combination to unauthorized persons.

Vendor response:

  Oracle came with the following solution:

    The p_submit_url value in the customized login page can be
    hard-coded.  This will mitigate this issue since it will not be
    an input value to the page anymore. The p_submit_url URL value
    in the 902 SSO server is in the following format:

    http(s)://sso_host:port/pls/orasso/orasso.wwsso_app_admin.ls_login

Recommendation:

  We recommend implementing the proposed solution.

  Of course, we hope that Oracle will update its documentation as
  well such that the p_submit_url parameter will be removed from
  all example code.

History:

  2003-12: discovered
  2004-01-12: vendor informed
  2004-02-18: vendor came with solution
  2004-03-10: communicated solution
  2004-03-30: publication