|
COMMAND Authorize.net SYSTEMS AFFECTED Those using Authorize.net PROBLEM 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. 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.