Аутентификация и безопасность на моем сайте - нужен совет, пожалуйста - PullRequest
Новая
       15

Аутентификация и безопасность на моем сайте - нужен совет, пожалуйста

2 голосов
/ 27 мая 2010

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

Когда они отправляют страницу, я просто делаю проверку хранимой процедуры для проверки подлинности. Если они авторизованы, то их пользовательские данные (например, имя пользователя, имя пользователя, адрес, адрес компании, другая важная информация) сохраняются в пользовательском объекте пользователя, а затем в сеансе. Этот пользовательский объект User, который я создал, используется во всем веб-приложении, а также на дочернем сайте (совместное использование сеанса).

Мой вопрос / проблемы:

  1. Является ли мой метод аутентификации правильным способом?

  2. Я нахожу пользователей, жалующихся на то, что срок их сеанса истек, хотя они "не простаивают", возможно, из-за повторного использования пула приложений? Они набирают большие объемы текста и считают, что срок их сеанса истек, и, таким образом, теряют весь набранный текст. Я не уверен, действительно ли сеанс действительно сбрасывается спорадически, но решит ли это проблему с помощью проверки подлинности с помощью файлов cookie / cookiless?

  3. В качестве альтернативы я должен создать и сохранить объект пользователя в сеансе, файле cookie или в чем-то еще вместо этого, чтобы быть более «правильным» и избегать случаев, подобных пункту № 2.

  4. Если я пойду по маршруту проверки подлинности с помощью форм, я считаю, что не могу сохранить свой пользовательский объект User в файле cookie проверки подлинности с помощью форм, поэтому означает ли это, что я сохраню идентификатор пользователя и затем воссоздаю объект пользователя на каждой странице? Не будет ли это значительным увеличением нагрузки на сервер?

Советы и ответы очень ценятся.

L

Ответы [ 5 ]

1 голос
/ 30 сентября 2016

Вот некоторые общие меры безопасности, которые должен соблюдать начинающий и Advance Web Developer. 

       #15 Steps To Secure Your Website

1: предотвращение хотлинкинга изображений (IMP)

Горячая ссылка на изображение - это процесс использования чужого URL-адреса изображения на нашем веб-сайте и использования его пропускной способности. Чтобы предотвратить эту загадку, мы можем запретить доступ к внешнему серверу, добавив следующую строку в коде. 

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

2: предотвращение атак CSRF (подделка межсайтовых запросов)

Чтобы предотвратить атаки CSRF на ваши запросы GET и POST для отправки формы, вы можете использовать следующие 2 метода.
Первое, что включает случайный токен с каждым запросом, это уникальная строка, которая генерируется для каждого сеанса.
Второй метод заключается в использовании случайного имени для каждого поля формы.

3: запретить доступ к каталогам / отключить индексирование

Добавьте следующую строку в ваш файл .htaccess. 

Options -Indexes

4: Защита вашего личного доступа и входа в CMS с ограничениями IP

IP-ограничение - это немного более продвинутый, но эффективный метод, позволяющий неавторизованному персоналу получить доступ к определенной области вашего сайта. Вот пример кода htaccess для IP, ограничивающего доступ к определенному местоположению. 

ALLOW USER BY IP
<Limit GET POST>
order deny,allow
deny from all
allow from 1.2.3.4
</Limit>

5: защита вашего файла .htaccess

Вы можете написать приведенный ниже фрагмент кода в файле htaccess, который не позволяет другим доступам к вашему файлу htaccess. 

<Files ~ “^.*.([Hh][Tt][Aa])”>
order allow,deny
deny from all
satisfy all
</Files>

6: правило доступа к функции

Добавляя «_» в качестве префикса для имени функции, мы можем запретить публичный вызов функции из Интернета. Это лучший метод, когда нам нужна определенная функция, доступ к которой возможен только через AJAX.

7: заблокируйте ваш каталог и права доступа к файлам

Права доступа к файлу определяют, кто может что делать с файлом.
«Read» = 4: просмотреть содержимое файла.
«Запись» = 2: изменить содержимое файла.
«Execute» = 1: запустить файл программы или сценарий.

8: Запретить запуск задания Cron из веб-браузера

Добавив следующую строку кода на своей странице, вы можете защитить свою страницу для доступа через веб-браузер. 

if( ! $this->input->is_cli_request() ) {
            die("Only CLI Requests Allowed");
}

9: Скрыть страницы администратора, которые будут сканироваться Google

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

10: отключить щелчок правой кнопкой мыши на странице, если не требуется

Отключение «щелчка правой кнопкой мыши» как способа просмотра исходного кода вашего веб-сайта с помощью элемента inspect для защиты содержимого веб-сайта для обычных пользователей.

11: используйте надежный пароль для CMS

Соблюдайте практику установки случайного пароля только с помощью специального символа.

12: сделать административный каталог сложным для угадывания Может случиться, что хакеры могут использовать сценарии, которые сканируют все каталоги на вашем веб-сервере на предмет бесплатных имен, таких как «admin» или «login» и т. Д., И ваши важные данные могут быть утечками. 13: изменить префикс таблицы базы данных

Добавьте префикс (смесь названия проекта и года), который трудно предположить для защищенной стороны.
Для иллюстрации
А) Верховный BPM => bpm14_download
B) Glickin => gk15_admin
C) TravelWorthy => tw16_user

14: Запретите пароль пользователя, это так же важно, как ваш

Относительно алгоритма шифрования паролей, используйте алгоритм sha1 вместо традиционного алгоритма Md5, который является очень старым способом и становится менее безопасным в настоящее время по источникам.
Справка: http://php.net/manual/en/function.sha1.php

15: скрыть журнал ошибок

В режиме разработки сохраняйте сообщение об ошибке «ВСЕ», и, как только мы перейдем в прямом эфире, измените его на «0», не забывая. Здесь
Справка: http://php.net/manual/en/function.error-reporting.php

1 голос
/ 28 мая 2010

Просто коснемся пункта № 4 - было бы эффективнее использовать память, чтобы не хранить каждый «пользовательский» объект в памяти и заново создавать объект каждый HTTP-запрос.Таким образом, вы также повторно проверяете данные для входа - что, если чья-то учетная запись будет взломана, а фактический пользователь изменит свой пароль, чтобы попытаться защитить свою учетную запись, но «плохой пользователь» уже вошел в систему?В соответствии с вашим механизмом безопасности «плохой пользователь» может продолжать просмотр, поскольку пользовательские данные кэшируются и не проверяются при каждой обратной передаче.

1 голос
/ 27 мая 2010

Вы можете использовать Членство в ASP.NET, роли, проверку подлинности с помощью форм и ресурсы безопасности Я приведу пример с использованием c #

Для справки Аутентификация с помощью форм в ASP.NET 2.0 

 //code for checking user name & password 
protected void btnlogin_Click(object sender, EventArgs e)
{
    try
    {
        if (txtUserName.Text.Trim() != "" && txtPassword.Text.Trim() != "")
        {
            User obj = objUser.UserAuthenticate(txtUserName.Text.Trim(), txtPassword.Text.Trim());
            if (obj != null)
            {
                //To set AuthenticationCookie of usertype "User"
                SetAuthenticationCookie("User", obj.UserID.ToString(), obj.DisplayName);

                HttpCookie usercookie = new HttpCookie("LoginTime");
                usercookie.Value = DateTime.Now.ToString();
                Response.Cookies.Add(usercookie);
                HttpCookie namecookie = new HttpCookie("LoginName");
                namecookie.Value = obj.DisplayName;
                Response.Cookies.Add(namecookie);



            }
            else
            {
                lblMsg.Text = "Invalid Username or Password.";
            }
        }
        else
        {
            //lblMsg.Visible = true;
        }
    }
    catch (Exception ex)
    {
        //lblMsg.Visible = true;
        throw ex;
    }
}

private void SetAuthenticationCookie(string role, string userid, string name)
{

string userdata = "logintype=user|role=" + role + "|email=" + txtUserName.Text.Trim() + "|name=" + name;

    FormsAuthenticationTicket faTicket = new FormsAuthenticationTicket(1, userid,
       DateTime.Now, DateTime.Now.AddHours(+1),
                                           false, userdata);

    HttpCookie authCookie = new HttpCookie( FormsAuthentication.FormsCookieName,//"martinfernandez@ispg.in",
                                            FormsAuthentication.Encrypt(faTicket));

    authCookie.Expires = faTicket.Expiration;
    Response.Cookies.Add(authCookie);


}

    //code inside global.asax.cs
    protected void Application_AuthenticateRequest(object sender, EventArgs e)
    {
        if (Context.User != null && Context.User.Identity is FormsIdentity && Context.User.Identity.IsAuthenticated)
        {
            FormsAuthenticationTicket faTicket = FormsAuthentication.Decrypt(Request.Cookies[FormsAuthentication.FormsCookieName].Value);

            string[] userdata = faTicket.UserData.Split("|".ToCharArray());
            string logintype = "";
            string email = "";
            string uname = "";
            string roleString = "";
            foreach (string s in userdata)
            {
                string keyname = s.Split("=".ToCharArray())[0];
                if (keyname == "logintype")
                {
                    logintype = s.Split("=".ToCharArray())[1];
                }
                else if (keyname == "role")
                {
                    roleString = s.Split("=".ToCharArray())[1];
                }
            }
            string[] rolesArray = roleString.Split(";".ToCharArray());
            Context.User = new System.Security.Principal.GenericPrincipal(new FormsIdentity(faTicket), rolesArray);
        }
    }
1 голос
/ 27 мая 2010
  1. На самом деле все равно, используете ли вы свою собственную систему аутентификации или поставщиков услуг по умолчанию при использовании такого простого сценария.
  2. Следует избегать использования состояния сеанса InProc, когда приложение может перезагружаться несколько раз в день. Скорее сохраните ваш сеанс в базе данных (SqlSessionState) или используйте StateServer. Тогда пул приложений может перерабатывать весь день, не мешая вашим сеансам. Установка тайм-аута сессии на 60 минут или около того, решит оставшиеся проблемы. Никогда не используйте сеансы без файлов cookie (если вы не знаете, что делаете), , поскольку они слишком легко украдут сеанс .
  3. Просто сохраните его в сеансе (или в профиле, если вы используете поставщик членства по умолчанию). Файл cookie не только легко читается, но и ограничен 4 КБ.
  4. Нет, у вас будет профиль, где хранится вся пользовательская информация. На самом деле не имеет значения, используете ли вы проверку подлинности с помощью форм или пользовательскую систему, которая сохраняет эти данные в SqlSessionState. Поставщик членства сохранит идентификатор профиля в файле cookie, так же как состояние сеанса сохранит идентификатор сеанса в файле cookie.
0 голосов
/ 27 мая 2010

Мой совет - использовать членство и роли asp.net (Microsoft). Это очень хорошее решение для обеспечения безопасности - безопасность входа в систему, роли (разрешения) и хранится в базе данных SQLServer (не уверен, что его можно хранить в другом месте).

Я использую его на своем сайте, и вы можете использовать элементы управления членством прямо из коробки (формы входа, изменить пароль и т. Д.), Или вы можете использовать свой собственный.

Единственный хитрый момент, который я обнаружил, - это настройка таблиц членства, представлений и хранимых процедур в моем дБ (вы загружаете скрипт дБ), но на самом деле это было довольно просто реализовать.

Вот ссылка на членство в asp.net и роли

...