I have noticed a number of installations of a particular forum management software product that does not secure the user registration or login.
User beware! NEVER, EVER, EVER reuse an important user name or password.
This is the HTML of the registration page that submits the user credentials to the server.
<form action="http://www.XXXXX.net/XXXXXX/index.php" method="post" name="REG" onsubmit="return Validate()" ID="Form1">
<input type="hidden" name="act" value="Reg" ID="Hidden1"/>
<input type="hidden" name="termsread" value="1" ID="Hidden2"/>
Truncated for brevity
On the front page of the forum there are two methods to log in.
- The Welcome Guest banner
- The Welcome back banner
#1 Clicking ‘Log In’ brings up an insecure form...
<form action="http://www.XXXX.net/XXXXXX/index.php?act=Login&CODE=01" method="post" name="LOGIN" onsubmit="return ValidateForm()" ID="Form1">
<input type="hidden" name="referer" value="http://XXXX.net/XXXXX/index.php" ID="Hidden1"/>
Truncated for brevity
#2 This is the HTML of the banner login (next to the ‘Go’ button):
<form action="http://www.XXXXX.net/XXXXX/index.php?s=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&act=Login&CODE=01&CookieDate=1" method="post" ID="Form2">
<input type="text" size="20" name="UserName" onfocus="this.value=''" value="User Name" ID="Text2"/>
<input type="password" size="20" name="PassWord" onfocus="this.value=''" value="ibfrules" ID="Password2"/>
<input class="button" type="image" src="style_images/ipb_skin/login-button.gif" ID="Image1" NAME="Image1"/>
Notice that in all three cases the action= of the form is to post to an http:// protocol URL. This causes the contents of the input controls to be sent as clear text across the web to the runehq.net server-side validation process.
This must be changed to prevent man-in-the-middle attacks, credential snooping, and runehq falling prey to an impersonation attack.
This software needs to post user credentials across an https:// protocol (so the data is contained in an SSL encrypted stream).
While it is possible to change the action= of the form to point to an https:// URL to secure the posting, there are security risks associated with including a secure form on an non-secured (http://) page.
To be completely secure, a login web page must be delivered to the browser over an https:// protocol.
Because the SSL overhead is significant, login web pages should be as light-weight as possible (no sense encryption huge bitmaps, etc) to keep the performance impact to a minimum.
I don't want to rehash the argument, but I would give my $495 MS Tshirt if IE7 would provide visual cues when a form is secure/insecure (I propose a mod to the chrome or submit button).
Yes, yes, it should be conservative and never have a false-positive (indicating a form is secure when it is not).