Файл: Web'cepbep.docx

Помимо того, что этот вид аутентификации неудобен в поддержке, у него еще и серьезный недостаток безопасности, потому что имя и пароль передаются с каж­дым запросом и их легко декодировать. Если хакер перехватит хотя бы один из за­просов, он получит доступ к паролю, поэтому убедитесь, что вы используете про­токол с шифрованием HTTPS, который зашифрует все данные и не позволит пере­хватить имя и пароль.

2. 
   Аутентификации на основе cookie
   

Очень часто используются самостоятельно написанные системы аутентификации, которые могут быть реализованы с нуля или использовать какие-то библиотеки/ API. Чаще всего они основаны на cookie-значении, которое сохраняется в браузе­

ре пользователя. Именно это значение будет отправляться на сервер с каждым запросом.

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

В cookie не должно быть никаких персональных данных, вместо этого должно быть какое-то уникальное значение, которое на сервере будет привязано к имени теку­щего пользователя. Например, когда мы входим на сайте и успешно вводим имя и пароль, сервер может сгенерировать уникальное значение 3e2c676e-09fb-41d8-a847- de65ff0e3fe1 и поместить его в cookie с именем Auth. Для нас это совершенно странное и непонятное значение, но в реальности это глобальный идентификатор, которые часто использует Microsoft. Эти значения уникальны (рис. 9.3).

в • Щ Г лммда Перс о»	лпыщЛса* х +
-> С 1 ftenov.info
Appi Я Work Ш Do»		Я Other Bookmerkt

Ш

---

Блог Ш Статьи Ш Книги ► Видео Л Подкасты > Плюс

' i .i*.		^ ^ ® # л
План О&ученияД \ Программиста]®^ f ттяШ		_ 4I y> ®		fiFfcy'rT v f г и.

Мистер Фикс, у вас есть План обучения?


Наконец-то я стал миллионером


По дороге из Ванкувера в Банфф




Рис. 9.3. Cookie, который хранит уникальный идентификатор сессии

Теперь это значение в cookie будет передаваться на сервер с каждым запросом и сервер будет знать, что это я, потому что он создал это уникальное значение для меня и сохранил где-то в базе данных или в другом хранилище для сессий, что 3e2c676e-09fb-41d8-a847-de65ff0e3fe1 соответствует пользователю MikhailFlenov.

А что, если хакер увидит один из запросов и украдет это cookie-значение? Он мо­жет создать у себя в браузере такое же значение с таким же именем и при отсутст­

---

вии дополнительной защиты украдет мою сессию: теперь сервер будет думать, что хакер тоже авторизован как MikhailFlenov, потому что он у него такой же ID.

Да, хакер все еще может украсть сессию, если увидит запрос, но по крайней мере он не увидит пароль, и это уже хорошо. А для защиты сессии мы можем добавить дополнительные меры защиты, которые позволят остаться в безопасности даже ес­ли хакер украдет сессию.

Давайте на практике посмотрим, как можно украсть сессию. На своем сайте flenov.info я не стал делать сложной защиты, потому что это не тот сайт, который может подвергнуться атаке хакеров, поэтому здесь можно украсть сессию, если очень сильно постараться.

Загрузите мой сайт flenov.mfo и зарегистрируйтесь. Если у вас уже есть аккаунт, то авторизуйтесь на сайте. Теперь откройте утилиты разработчика и на вкладке Appli­cation, найдите cookie для URL flenov.info, а затем элемент с именем PHPSESSID. Это имя по умолчанию для идентификатора сессии в PHP.

Теперь можно открыть другой браузер, я буду использовать Safari (рис. 9.4), в ко­тором тоже есть утилиты разработчика. Здесь переходим на вкладку Storage и вы­бираем слева Cookies и имя моего сайта. Теперь можно добавить новый элемент или изменить существующий. Можете взять любой существующий элемент cookie и изменить его имя на PHPSESSID и значение на то, что вы видите в своем случае. Мое значение, скорее всего, использовать у вас не получится, потому что к выходу книги оно точно уже не будет корректным.




Рис. 9.4. Работа с cookie в Safari




Изменив существующий или добавив новый cookie, перезагрузите страницу. Те­перь вы должны быть авторизованы с тем же аккаунтом, что и в первом браузере. Таким образом мне удалось украсть свою же сессию на своем же сайте.

Как защититься от подобных вещей? Можно привязывать ID сессии к определен­ному IP-адресу. Если пользователь зашел на сайт с IP-адреса 10.10.10.10, и вдруг по какой-то причине эта же сессия используется с другим IP, то это может быть хакер, и сессию можно закрыть, чтобы хакер не украл информацию.

В принципе, это очень хороший вариант защиты для финансовых сайтов, банков. Но если вы работаете с социальной сетью, то тут такой вариант защиты создаст пользователю неудобства. IP-адреса могут меняться даже на стационарных компь­ютерах. Пользователи могут использовать для доступа к сайту мобильные телефо­ны и ноутбуки, где адреса меняются достаточно часто: подключился через одну сеть WiFi — получил один адрес, подключился через сотовую сеть — другой адрес. Завершать при каждом переключении сессию и заставлять пользователя снова вво­дить данные будет не очень эффективно.

---

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

Так как же поступать социальным сетям? Закрывать сессии, подобно банкам, они не будут, так неужели все социальные сети небезопасны?

У хакера есть два основных метода перехватить cookie — незашифрованный тра­фик или с помощью JavaScript при наличии XSS-уязвимости. Чтобы хакер не смог увидеть трафик, просто шифруем его, используя HTTPS. А вот чтобы хакер не ук­рал cookie с помощью XSS, нужно просто писать код так, чтобы не было XSS, но об этом мы поговорим в главе 10.

Но даже если есть уязвимость XSS, мы можем защитить cookie от хакеров.

Откройте утилиты разработчика и перейдите на вкладку Console (рис. 9.5). Здесь можно выполнять JavaScript-команды. Чтобы прочитать cookie, выполните сле­дующую команду:

document.cookie

В моем случае я получил в результате строку со всеми доступными cookies:

fid=db2333d3-48ee-473d-948c-07ceab707857;

utmc=18411502;

gads=undefined;

utma=18411502.50099190.1570832327.1615397634.1615411123.1765;

utmt=1;

utmb=18411502.1.10.1615411123;

gads=ID=1202c48cafd95d86-

2210f15bd2c6008b:T=1615411123:RT=1615411123:S=ALNI_MZhzK_9ES8dvhJ3Sj7iZc2










9 9 9 p| Главная Персональный cat- X <- -> 0 • flenov.info

---

Hi Apps t3 Work t3 Dev

★ О # *

Я Other Book та

Програмысли

Найдется почти все

Memory Apptcabon Security

document.cookie.

id-db23Up*Ree-473d-948c-«7ceat>787857; _utec>18411582; _gads*undefloed: _ute*-184U582.58899198.1578832327.16 15411123.1765: utar*18411582.1615411123.1765.1 .utecs redirect)|uteccna(direct)|uteceda(nonc); _utet«l;

0-1282c48cafd95d86-2218fl!

(8b :T=161S411123 :RT= 1615411123 :S»ALNI_(*ZhrK
zzGLHxw

Рис. 9.5. Выполнение команд в консоли

Я разбил большую строку, которую отобразила команда по точке с запятой, и те­перь слева от знака равенства это имя параметра, а после равенства — его значения. Обратите внимание, что phpsessid среди параметров нет, хотя на вкладке Cookies мы его видели. Дело в том, что JavaScript не имеет доступа к защищенным cookie, они просто передаются от сервера браузеру и обратно, но в JavaScript-коде их уви­деть не получится, а значит, хакер не сможет их украсть, даже если будет XSS- уязвимость.

Если посмотреть на рис 9.3, то напротив cookie с именем PHPSESSID в колонке Secure вы увидите галочку. Она свидетельствует о том, что это значение использу­ется только для коммуникации с сервером и не будет доступно для JavaScript-кода. Галочка напротив Secure говорит еще и о том, что значение будет передаваться только по защищенному HTTPS-протоколу.

В PHP за создание защищенных cookie отвечает метод setcookie, у которого по­следние два параметра как раз и позволяют указать, что нужен защищенный и httponly параметр и по умолчанию оба значения равны false: setcookie ( string $name, string $value = "", int $expires = 0, string $path = "" ,

string $domain ="", bool $secure = false, bool $httponly = false

)

Если оставить $secure и $httponly по умолчанию, то значение cookie будет дос­тупно коду JavaScript и будет передаваться по незащищенному HTTP-протоколу, который теоретически можно перехватить и увидеть значение. Это самый небезо­пасный способ.

---