Jump to content

sourcy

Members
  • Posts

    12
  • Joined

  • Last visited

sourcy's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. public function checkUser($username, $email, $emailConfirm) { if (!$this->_dataCheck->checkEmail($email, $emailConfirm)) { return "Emails do not match, or the email is invalid"; } if (!ctype_alnum($username)) { return "Username must only contain numbers and letters"; } $this->_db->query("SELECT username, email FROM users WHERE username='$username' OR email='$email'"); if ($this->_db->numRows() != 0) { return "Username or email is already in use, please try again"; } return "success"; //this is where i will add them to the table "users" if they do not already exist and passed all my other checks } And here is my check email function public function checkEmail($email1, $email2) { if ($email1 == $email2 && filter_var($email1, FILTER_VALIDATE_EMAIL)) { return TRUE; } else { return FALSE; } } Basically my question is simple, is there any risk to checking for the input to be alpha numeric and a valid email using PHP's built in functions? so as to avoid sql injections and XSS? Never done it like this before, but I'm re-coding a site from scratch and I feel like this would work better. Anyone see any problems?
  2. I just started using OOP a week ago after not using it for several years. Don't want to go back. Pretty easy to learn, I would suggest phpacademy on youtube.
  3. ten newest records would look like: SELECT * FROM 'account' ORDER BY 'timestamp' LIMIT 10
  4. I don't feel that it's invalid, in fact, I'm not really sure what's a good idea and what's not. However, that said, I do have some background in security with regards to the web, securing sites, and how to break them. I'm implying that since attackers have access to all of the same information re: how to secure a system, they also know common tricks that are used such as use a time-stamp. Therefore, they can still likely guess that their salt may be a timestamp, or something similar. However, realistically, an attacker would create an account on the site, register, and then when they've compromised the DB, find their own hash and work out how it could possibly be encrypted. (works unless the password is salted within the actual encryption function). Somethings an attacker theoretically might think of using are username, timestamp or even a column field named "salt" lol.
  5. I feel that this is such a widely used suggestion that it's almost pointless to use it. My new solution is this: md5 their password and then take the first 16 characters (50%) of the returned string and use that as the other part of the salt.... (so it'd still use their username, but also now this two, so no two hashes are the same regardless of matching passwords) I'm not sure how smart this is either.
  6. I also think you need to change this to if (!isset($_SESSION['login_user'])) { $_SESSION['login_user'] = $myusername; Because I don't see $_SESSION[$myusername] being set anywhere. This will check if they are already logged in, and if they aren't it will set them a session and then send them to welcome.php. But if they are, i will do nothing.
  7. Well for starters: You login.php page is missing {}'s I re-wrote it for you to include them if($_SERVER["REQUEST_METHOD"] == "POST") { // username and password sent from form $myusername=addslashes($_POST['username']); $mypassword=addslashes($_POST['password']); $error="<h3><strong>Your Login Name or Password is invalid</h3></strong>"; $result=mysql_query("SELECT uid FROM users WHERE username='$myusername' and password='$mypassword'"); $row=mysql_fetch_array($result); $active=$row['active']; // If result matched $myusername and $mypassword, table row must be 1 row if(mysql_num_rows($result)==1) { if( isset($_SESSION[$myusername]) ) { //session_register("myusername"); //$_SESSION['login_user']=$myusername; $_SESSION['login_user']= $_POST['username']; header("location: welcome.php"); } } } Second on login.php you're adding slashes to the username that they are entering, but setting the raw $_POST as the $_SESSION['login_user'] and then running that on a SQL query meaning it's vulnerable to SQL injection. Third: You should encrypt passwords in your DB.
  8. I have been reading about salts and password encryption, and as such, I wrote this code: Is this safe? The reason I am asking is I read that using a user's username is a bad idea since, it's easily guessable as being a hash. However, I feel with adding it in twice in random spots, along with server side random salts is enough to prevent it being easily cracked? Thoughts? And obviously not my real salts.
  9. Well if anyone cares to look, using both suggestions I now have this code: http://pastie.org/5618835 (yes I realize username, pass and DB were all left in, they've all been edited and changed) I think that's what was intended by your suggestions, and as such, I have altered my code. (which seems to work) Thanks, I just figured that out as you posted!
  10. Ahh makes sense. I'm a noob at this OOP stuff as you can tell. So basically I would have to get rid of the "extends database" Then on login.php I would have to make it " $db = new Database('mysitedb', 'root', 'password', 'mydb'); $user = new User($_POST['user'], $_POST['pass'], $db); " ? But then how in the user class could I call the function "query" from the database class? Ahh yeah, makes sense as well. I'm glad I posted this, instead of writing a bunch of code just to re-write this.
  11. I see that if I change the user construct to: " public function __construct($user, $pass) { $this->_user = $user; $this->_pass = $pass; Database::__construct('mysitedb', 'root', 'password', 'mydb'); }" it get's ride of the error then I just can use Database::query(); Is this how it's done?
  12. Okay, please don't tell me I can do this with regular PHP and I'm making things more complicated on myself for doing it with OOP etc.. I know. I'm just doing this to learn OOP (and it could be used for more than just a login, I still would have a problem doing it) First I have this login page, Where I am creating a connection to the DB and then creating a new user. Then I call the function $user->login(); http://pastie.org/5618540 Database parent class http://pastie.org/5618537 User Child class http://pastie.org/5618533 When I have it written like that I get: "Fatal error: Call to a member function query() on a non-object in /home/sourcy/thesourcy.com/classes/User.php on line 15" So I changed $db-query("SELECT FROM") to Database::query() in the user child class. That got rid of that error, but then it will throw me this error: "Warning: mysql_query() expects parameter 2 to be resource, null given in /home/user/site.com/classes/Database.php on line 19 Warning: mysql_num_rows() expects parameter 1 to be resource, null given in /home/user/site.com/classes/Database.php on line 20" Which essentially means that $this->$_link isn't getting set (since it's null). What am I missing? / Doing wrong? I'm new to OOP. And no, this code will not be going live. I understand the security vulnerability, I'm just doing it for practice/learning Also: If I use $db->query() on "login.php" it will work, but when I move it to the User class and try to use it, it doesn't work
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.