ARP - Another Radio Panel (Alpha)

[Beau]

Code is incredibly insecure...

if($username == "+"){
echo("Hacking attempt.");
exit();
} 

That isn't a hacking attempt. A hacking attempt is where a query sent to the database would look like:

SELECT * FROM users WHERE username='admin' AND password='' OR 1=1

As 1=1 is always going to return as true, it'll think the user is logged in.

When you declare your username and password variables, use this:

$username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']); 

It'll filter out nasty queries like the one above.

Also, how are you encrypting your passwords when you store them in the database. From the login script, it looks like they're stored as plaintext, which is incredibly insecure. You should be storing them hashed with either md5 or sha1 (hopefully, with salts as well).

[lolwut]

The passwords are MD5'd. Just after the bit that checks for the + in the password.

$password = md5($password); 

And I'm about to change that thing you told me, I don't actaully know how to hack, so I'm not really any good at filtering out attacks.

[Beau]

Oh, escaped my eyes Sorry sorry.

Can I suggest you salt your password hashes as well? Example:

$salt = "iohIY&8yweoi8h";
$encrypted_password = md5($_POST['password'] . $salt); 

It's basically an extra precaution, and means that unless you use a simple salt like 'cat' or 'dog', your passwords won't be found out. MD5 rainbow table sites are becoming more common these days. They basically hold hashes for many words, so if anyone runs an md5 hash through one of them, and their password is something simple, like a dictionary word for instance, it'll most likely be in their database of hashes, and the plaintext password will be displayed.

[Tomm]

Why would you want to check if the password has a plus in it? If the password is hashed before placing it in the database it becomes impossible to use SQL injection unless you store it in a cookie (This was a exploit used in IPB as they did not clean the password cookie before using it in a SQL query and since the user can mess around with the cookie it does not necessarily contain the hash you put in it.)

The passwords are MD5'd. Just after the bit that checks for the + in the password.

$password = md5($password); 

And I'm about to change that thing you told me, I don't actaully know how to hack, so I'm not really any good at filtering out attacks.

[lolwut]

Tomm; I have no idea how to hack, like I said earlier. And I thought that + was somehow used in SQL Injections. Anyway, I've changed it to mysql_real_escape_string(); like benzo said. Sorry.

Benzo; I will probably, but right now I'm trying to focus on this stupid login error, I think it's possibly got something to do with the cookies. Any ideas?

[Tomm]

Okay lets take an example of Habbox Forum

Date: Mon, 29 Oct 2007 10:01:21 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.3 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a
X-Powered-By: PHP/5.2.3
Set-Cookie: bbsessionhash=-Snip-; path=/; HttpOnly
Set-Cookie: bblastvisit=1193652081; expires=Tue, 28-Oct-2008 10:01:21 GMT; path=/
Set-Cookie: bblastactivity=0; expires=Tue, 28-Oct-2008 10:01:21 GMT; path=/
Cache-Control: private
Pragma: private
Content-Encoding: gzip
Content-Length: 18892
Connection: close
Content-Type: text/html; charset=ISO-8859-1

This is followed by all the HTML data for the habbox forum homepage.

Your site sends these headers as well. But if you use the header function after sending HTML then you will get that error since you can't send headers after you sent HTML.

e.g
<?php
//This is okay
header("X-Tester: Tom");
echo "<p>Hiya</p>";
?>

<?php
//This is not okay
echo "<p>Hiya</p>";
header("X-Tester: Tom");
?>

[Beau]

Normal characters that are used in SQL injections are ' and --. ' will cut off the quote of the query that should be processed, allowing an attacker to launch another. -- is an SQL comment, it'll block any code after it from processing correctly.

Unsure whether this will work, considering your database dump didn't include the user's table, but try adding this to the line straight after the <?PHP tag:

ob_start(); 

And this after line 32 (setcookie commands):

ob_end_flush(); 

EDIT: Tomm, from the source I'm looking at, I can't see a header() command anywhere. He's using a meta refresh.

[lolwut]

benz; Thanks for that thing about the SQL, I think it's abit securer now thanks to the mysql_real_escape_string() though?
I tryed that output buffering thing out, and it WORKS! +Rep. Ily.

Tomm; I didn't even use header(); on the index.php page, and I do already understand headers, thanks anyway.

EDIT: Soz cant repz u but i owe u rep.

[lolwut]

UPDATED LINK.
WORKS FINE NOW.