Dennis Eric Stout (iptv_tech) wrote in suggestions,
Dennis Eric Stout
iptv_tech
suggestions

I was reading through the core layer and found a variable for determining if a viewer was logged in or not, and the comments suggested we make a link to the login page if they aren't. I took it a step further and made a simple login form, but ran into an interesting security issue.


function print_module_login() {
	if (not viewer_logged_in()) {
		open_module("login","login", "http://www.livejournal.com/login.bml");
		"""<form action='http://www.livejournal.com/login.bml' method='post' class='lj_login_form' class='pkg'>\n""";
		"""Username<input type="text" value="" name="user" size="15" maxlength="17" /><br>\n""";
		"""Password<input type="password" name="password" size="15" maxlength="30" /><br>\n""";
		"""<a href='http://www.livejournal.com/lostinfo.bml'>Forgot password?</a><br>\n""";
		"""<input type='checkbox' name='remember_me' id='remember_me' value='1' tabindex='4' />Remember me<br>\n""";
		"""<input name='action:login' type='submit' value='Log in' /><br>\n""";
		"""<a href='http://www.livejournal.com/openid/'>Login with Open ID</a><br>\n""";
		close_module();
	}
}



When I view the page with a login form on it (which is every page printed with Page::print();, which is every page in my layout), the word 'password' is removed from the type="password" portion of the input tag, leaving it as type="".

One can still enter their username and password to login, but the password is not covered by dots or stars by the client browser because the browser isn't being told it's a password field. The default type for unspecified fields is "text", which shows up in plain text, not masked.

For now, I have commented out the entire form in my S2 layout so the only thing that's rendered is a link to the login page.

open_module() and close_module() do nothing more than setup div containers with defined classes and titles, but if anyone feels the code in them is absolutely necessary, let me know and I'll post it as well.

I have two ideas to solve this problem.

Simple: Stop stripping "password" out as an input type. It has no effect on the server side of things, so it's not fixing any sort of possible security hole by being stripped. It is, however, providing the potential for "over the shoulder" password thefts.

Slightly Less Simple: Provide a builtin function in the core layer for providing a login form, probably via something akin to $p->login_form();.


During form submission, each input field is condensed down to a paired key and value. The key is the input field name (from the name="blah" portion of the input tag), and the value is whatever the user typed into the field (or alternatively, wa pre-entered via a value="whatever" portion of an input tag).

In GET requests, those key and value pairs end up looking like ?key1=value1&key2=value2 at the end of the URL.

In POST requests, those key and vlue pairs end up looking like

key1: value1
key2: value2


in the request header.

At no time during submission is there any mention from the client side to the server side regarding what type="" was in the input field. Having type="password" is no less secure than any other type, because the server has no idea what the type is; "type" is not a part of "key" or "value".
Tags: html cleaner, security, styles, § no status
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 16 comments