My protection from multi submits and brute force attacks

[notset]

Hello,

Here is my protection from multi submits, brute force attacks and any similar hackers actions.

functions.php

function form($name) {
	$id = md5(uniqid(mt_rand(), true));
	$_SESSION['fid.'.$name] = $id;
	return $id;
}

function check_form($name, $id) {
	if (isset($_SESSION['fid.'.$name]) && $_SESSION['fid.'.$name] === $id) {
		unset($_SESSION['fid.'.$name]);
		return true;
	}
	return false;
}

form.html

<form method="post" action="login.php?fid=<?=form('login')?>">
</form>

login.php

if (isset($_GET['fid']) && check_form('login', $_GET['fid'])) {
  echo 'ok';
} else {
  echo 'invalid request';
}

What is your opinion about it?

It's enough secure or not?
It's useful or not?
Maybe there is a beter variant of this function?

Thank's for comments.

[c1a1o1]

good!

But it is too terrible for all the form

[MarkR]

Totally hopeless, as it relies exclusively on the session. Someone who's going to create automated form submissions can simply avoid providing a session ID cookie, thus creating a new session each time.

Although your protecting against CSRF might be quite adequate by the above*, an attacker can create as many sessions as they like.

Mark

• I'm not claiming it's 100% effective against CSRF, but it looks like it may make it a lot harder at least.

[notset]

Thank's for comment, Mark.

MarkR wrote:

Totally hopeless, as it relies exclusively on the session.

So, what do you suggest to you instead of sessions?

MarkR wrote:

Someone who's going to create automated form submissions can simply avoid providing a session ID cookie, thus creating a new session each time.

And where is a problem? I check if $SESSION['fid.'.$name] is set. If it is not, submit is denied. If attacker creates a new session each time, $SESSION['fid.'.$name] wont't be set, or i don't understand something?

[Weedpacket]

What MarkR is getting at is this:

1. Attacking program visits your site

2. Your site provides a session ID

3. Attacking program submits to your form, passing the session ID

4. Your site checks the session ID, verifies it's there, and proceeds to process the form.

5. Attacking program destroys its session ID.

6. Go to step 1.

How do you distinguish between a client that is visiting for the first time, and one that is visiting for the second time in three seconds but destroyed its session ID?

[notset]

Ok, i understood.

So, the best way to deny from site access is to track and block the IP address?

But my script doesn't allow hacker to do such thinks like multi login attack (automatic form submission using different passwords until login succeed), yes? I think it's the most important.

[Shrike]

That's exactly what your script doesn't protect against.

I think what your trying to achieve is data tainting, distinguishing your data from other, unknown data. Quite a hard thing to achieve (Javascript employs a data tainting security model, I think). Restricting access by IP address will add some further difficulties but again an IP address can be spoofed.

To prevent brute force attacks I would only allow a few consecutive failed logins before locking that particular record in some way.

How does your code prevent multiple submits? I take it you mean POST data getting resubmitted when the browser refresh button is pressed. To get around this I usually do a header redirect after receiving the POST.

[notset]

Ok, here is my IP blocking system.

if (in_array($page, explode(', ', $settings['block_pages']))) {
	$sql = "SELECT `blc_id`,`blc_status` FROM `blocks` WHERE `blc_ip` = ".qs($_SERVER['REMOTE_ADDR'])." AND `blc_page` = ".qs($page)." AND `blc_time` > UNIX_TIMESTAMP()";
	$result = mysql_query($sql) OR exit(mysql_error());
	$ipblock = mysql_fetch_assoc($result);
	if ($ipblock != NULL) {
		if ($ipblock['blc_status'] >= $settings['block_count']) {
			header('Location: http://site.com/?error');
			exit;
		} else {
			$sql = "UPDATE `blocks` SET `blc_status` = `blc_status`+1, `blc_time` = UNIX_TIMESTAMP()+".intval($settings['block_time'])." WHERE `blc_id` = ".intval($ipblock['blc_id']);
			$result = mysql_query($sql) OR exit(mysql_error());
		}
	} else {
		$sql = "INSERT INTO `blocks` SET `blc_ip` = ".qs($_SERVER['REMOTE_ADDR']).", `blc_page` = ".qs($page).", `blc_time` = UNIX_TIMESTAMP()+".intval($settings['block_time']);
		$result = mysql_query($sql) OR exit(mysql_error());	
	}
}

P.S. function qs() works with mysql_real_escape_string().

$settings['block_pages'] - pages, in which blocking is enabled, for example login and admin/login.
$settings['block_count'] = amount of times after which the access to page is blocked.
$settings['block_time'] = time period (in seconds) in which block is activated.

I allow 5 attempts in 300 seconds and then block visitor for the same time. Is it ok or better to use different settings?

[buraks78]

Here is how i prevent brute force attacks. If the form is submitted and all checks are passed, I call sleep() otherwise display errors (no need to sleep)

// create form object
$login_form = new Form($form_template,$form_type);
// if form is submitted and it is a valid submission
if($login_form->isValid()){
    // sleep to prevent brute force
    sleep(3);
    // do database stuff
    // ....
}
// generate form html
echo $login_form->getForm();

[buraks78]

One more comment. I dont think IP blocking is a good idea. Try blocking usernames.

From owasp.org

There have been suggestions that associating web application sessions with IP addresses would increase security. Request handlers could be added to applications that would check the IP address of incoming requests and either invalidate the session or at least log the anomaly if the IP address associated with the session changes. This would increase security for a number of applications, but it should be noted that depending on the network infrastructure between the web application client and server this may not be an acceptable solution. Some Internet service providers route traffic on their network such that the apparent client IP address might change during the course of a valid session. In addition, NAT firewalls and other technologies might mask when a host performing attacks has attempted to hijack a session. These concerns limit the utility and applicability of IP to session binding for Internet-accessible web applications.