Vulnerability

    Authorize.net

Affected

    Those using Authorize.net

Description

    John  Hennessy   found  following.    Recently   he  switched   to
    authorize.net for  credit card  processing.   After a  bit of work
    trying to  fix a  processing problem  he was  having.   He noticed
    that his login and password were in clear text as part of the URL.

    Taken from the page right after the login screen:

        <MAP NAME="bottombar">

          <AREA SHAPE="RECT" ALT="Account Info" COORDS="0,0,83,12" HREF="minterface.dll?statement&x_login=mylogin&x_password=mypass" TARGET="main">

          <AREA SHAPE="RECT" ALT="Settings" COORDS="84,0,152,12" HREF="minterface.dll?settingsmenu&x_login=mylogin&x_password=mypass" TARGET="main">

          <AREA SHAPE="RECT" ALT="Stats" COORDS="153,0,202,12" HREF="/common/comingsoon.html" TARGET="main">

          <AREA SHAPE="RECT" ALT="Support" COORDS="203,0,281,12" HREF="minterface.dll?support&x_login=mylogin&x_password=mypass" TARGET="main">

        </MAP>

    After some looking around John found that Netscape's  netscape.hst
    file could be  searched for "minterface.dll"  with a text  editor.
    It also contains the login and password in clear text.

    Example (taken from netscape.hst):

        Batch Reports
        https://secure.authorize.net/Interface/minterface.dll?batchreportmenu&x_login=mylogin&x_password=mypass

    Under Internet  Explorer the  same thing  can be  obtained looking
    through the  history.   This means  anyone with  knowledge of what
    machine is  used to  login to  authorize.net can  obtain the clear
    text username and  password.  Another  example would be  something
    like the I-LOVE-YOU  virus spread via  email.  This  could then be
    used to send back Netscape and Internet Explorer history files  to
    an attacker.

    Here's the article that was in the baltimore sun:

        http://www.sunspot.net/content/news/story?section=news-pluggedin&pagename=story&storyid=1150420204148

Solution

    John  contacted  authorize.net  regarding  my  concerns  and there
    response was  that this  is no  more an  issue than  anything else
    that can be accessed on  someone's machine.  To avoid  having this
    be a  problem, they  must make  sure their  computer is  in a safe
    area that  isn't accessed  by anyone  whom they  wouldn't want  to
    know the password.

    Use  the  POST  method  instead  of  GET  to pass arguments to cgi
    programs.  Or  some form of  encryption on the  password and other
    sensitive data.  Passwords in the  the clear are a bad, bad  idea.
    In a URL is worse.  A  POST instead of a GET would be  okay, given
    that this is  an HTTPS connection.   It would take  it out of  the
    history file.   It would  also avoid  the REFERER  problem  (where
    after going to that  site with the password  in the URL, you  type
    in a new URL and go  there--at times that will result in  entering
    the  login  and  password  into  the  new site's logs as being the
    Referrering site).   And of  course it  would take  care of anyone
    who was packet sniffing.