Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.
that kind of code secure?
What data i should store in sessions. LoggedIN or user name and password?
Some people say 1 one is stupid and when you use second one someone will come and say what a idiote storing user data in session's
that kind of code secure?
What data i should store in sessions. LoggedIN or user name and password?
Some people say 1 one is stupid and when you use second one someone will come and say what a idiote storing user data in session's
You're code is secure, as long as you actually define all of the outcomes you accept, and give an error if there happens to be an outcome given that you don't accept.
And for logging in, I typically save entire objects that hold their login information and how it's validation has gone, but when it comes down to it, all you really need is one session variable claiming that they are logged on. However, maybe you could make that variable their user name and, occasionally, address the user by it.
But session hacking isn't easy to do, so you shouldn't be worried about it early on.
If you are using something like that as a basic form of password protection than I am afraid that is not secure. However the conditional check itself isn't ever likely to be comprised.
I think what Ole and Everah are trying to say is that yes, what you have is secure, but we're sure that somewhere along the line, you might make it insecure. That "type" of code could mean almost anything.
Write some more and post it up so we can critique it.
The snippet posted would actually be helpful to an attacker, potentially. The error generated by the index not existing could yield a lot of information that is useful in coordinating an attack.
<?
$password2 = md5($_POST['password']); //Make password md5
include("config.php");
//log onto mysql server
$link = mysql_connect($server, $db_user, $db_pass)
or die ("Error in connecting mysql: ".mysql_error());
// Select database
mysql_select_db($database)
or die ("error in selecting database".mysql_error());
//name lenght check
if (strlen($_POST[username])<4){
header("Location:index.php?id=9");
} else {
//password lenght check
if (strlen($_POST[password])<4){
header("Location:index.php?id=9");
} else {
//E-mail check
if (!strstr($_POST['email'],"@") || !strstr($_POST['email'],".")) {
header("Location:index.php?id=9");
} else {
//htmlspecialchars
$username2 = htmlspecialchars($_POST['username']);
$email2 = htmlspecialchars($_POST['email']);
//username control
$kontroll = "select id from $table where username = '".$username2."';";
$query = mysql_query($kontroll)
or die ('mysql_error()');
$num_rows = mysql_num_rows($query);
if ($num_rows != 0) {
header("Location:index.php?id=9");
exit;
} else {
//addslashes
$username3 = addslashes($username2);
$password3 = addslashes($password2);
$email3 = addslashes($email2);
// Let's add data to mysql database
$insert = mysql_query("insert into $table values ('NULL', '$username3','$password3', '$email3')")
or die("Ei saanud andmeid lisada ,sest ".mysql_error());
$insert2 = mysql_query("insert into $table2 values ('NULL', '2500000','2000', '1', '0', '0', '0', '0')")
or die("Ei saanud andmeid lisada ,sest ".mysql_error());
//Let's send user to index.php?id=10
header("Location:index.php?id=10");
} } } }
?>
1. Use mysql_real_escape_string() (NOT addslashes, and NOT htmlspecialchars) on the variables before constructing a dynamic query. $_POST['username'] in index.php and reg.php allows SQL injection.
2. On a successful login, save the "loggedin" flag in the session, not the cookie. Right now, an attacker can create a cookie and hit indeks.php and he'll be let in.
Mordred 1-4 things fixed.
And i have one question to:
Is my code correct? Will that fix: 1. Use of $_GET/$_POST data blindly. i.e. no existence check done.
Better use is_set(), empty() is correct in your concrete sutiation, but it has different semantics. What you want is is_set().
Let's see your updated code, no offense, but as a general rule security fixes may introduce new holes