Система входа в систему (PHP) Cookie и Сессии

Это - то, что зафиксировало его для меня.

Открытый терминал

sudo gedit /etc/modprobe.d/modprobe.conf

новый файл будет открыт, записать, что строка ниже затем сохраняет.

options snd_hda_intel model=mb5

Близкий файл Перезагружают компьютер.

Благодаря Никакой звук на iMac

7
задан stukelly 30 August 2009 в 23:17
поделиться

6 ответов

If you set a session variable, the user can't directly change it unless they hijack another session cookie.

What you mainly have to watch out for is on shared hosting, your session data isn't secure (typically other sites can see it).

It's also worth noting that cookie data isn't secure either. It shouldn't be relied upon in the same way that form data shouldn't be relied upon (no matter what client validation tells you).

Your best practices with passwords are:

  1. Store the password in the database in a hashed form, preferably SHA1 (first choice) or MD5 (second choice);
  2. When you receive the user's password, encrypt it and check it against what's stored in the database;
  3. Set the logged in username in the user session;
  4. Expire the cookie after some period (even if its days) rather than having it last forever; and
  5. Use a secure connection (HTTPS not HTTP) where possible. SSL certificates are cheap.
7
ответ дан 6 December 2019 в 11:50
поделиться

As several people here have stated, do not trust user input - ever. By sanitizing your input, especially username & password fields you help to ward off SQL Injection attacks.

For all that is good & holy don't store usernames or passwords in cookies, they're sent back & forth to the server on every request and anyone watching the stream can snatch that data...then you're in big trouble.

Here's a couple articles you should read on sessions, security and hashing - just hashing your passwords to SHA1 or MD5 isn't enough, salt them so they're even more robust. There's no such thing as impenetrable security - even if you do EVERYTHING right someone can break it - it's inevitable. Your job is to make things as hard to break/exploit as possible.

The more work involved in breaking into your site, the more valuable your content has to be to be worth the effort. Your job is to discourage malicious users.

This article has some nice info on creating unique fingerprints for your visitors, helps to make session hijacking more difficult - PHP Security Guide: Sessions

This article deals with basic password hashing & salting techniques - Password Hashing

This is by no means an end all & be all - you can make a career doing security and the like, but they're a good starting point. Someone here can probably point to better / more advanced articles, but I've personally found these helpful in shoring up my code.

5
ответ дан 6 December 2019 в 11:50
поделиться

Rule of thumb: do not trust user input. Cookies are user input, session ids that are stored in cookies are user input, http headers are user input -- these things must be triple checked for every possible thing. Session data, on the other hand, is stored on your server, so it is more or less secure if not stored in /tmp.

One of the most popular setups for session authorization is this: session id is stored in cookie, and everything else including password is stored in session. After starting a session based on id from a cookie, you should get user id from session data and then check if password stored there is still valid.

3
ответ дан 6 December 2019 в 11:50
поделиться

Any and all user input needs to be scrutinized and sanitized religiously, be it GET and POST data, cookie data..

To answer your question if storing the login state in a session var is safe, the answer is yes. Just remember to sanitize everything the user sends you, no matter how safe it is supposed to be.

0
ответ дан 6 December 2019 в 11:50
поделиться

This login system is a great one to learn from.

0
ответ дан 6 December 2019 в 11:50
поделиться

Хорошая практика для использования - это сохранено 3 переменных. Один для того, чтобы они вошли в систему, один для их имени пользователя и один для случайным образом генерируемых хэш (который генерируется при входе в систему и сохраняется в базе данных вместе с другой информацией пользователя). Таким образом, если они изменит свое имя пользователя, которое может быть сохранено в их файла cookie, он не будет соответствовать тому, которое было сгенерировано для этого пользователя, когда они вошли в систему.

Пример: данные Cookie могут быть: logged_in = true; user = 'admin'; SESSICID = [Случайно генерируемый ID (я обычно просто MD5 случайно сгенерированное слово, которое я создаю)]

Каждый раз, когда они вход в систему, новый SESSIDID генерируется и сохраняется в базе данных в собственном поле. Теперь, если я должен был изменить информацию о файле cookie, и изменить переменную пользователей, чтобы сказать «Пользователь» (что было бы другому пользователю, которую они могут пытаться Hi-jack). SessionId больше не будет соответствовать одному для второго пользователя, и вход будет отклонен.

Вот быстрый пример, который я украл из проекта CI, я работал через пару недель назад:

    function logged(){
$logged_in = $this->session->userdata('logged_in');
if($logged_in){
  $userid = $this->session->userdata('userid');
  $sessionhash = $this->session->userdata('hash');

  $this->db->where('id', $userid);
  $this->db->where('hash', $sessionhash);
  $query = $this->db->get('members');

  if($query->num_rows == 1){
    return TRUE;
  }else{
    return FALSE;
  }
}
}
2
ответ дан 6 December 2019 в 11:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: