Предотвращение взлома PHP, это хорошие идеи? - PullRequest
Новая
       10

Предотвращение взлома PHP, это хорошие идеи?

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

Я делаю простую корзину для небольшого сайта.

Я планирую хранить элементы корзины, а также зарегистрированный user_id в переменных сеанса.

чтобы сделать вещи немного более безопасными, я думал, что сделаю это:

  1. sha1 () user_id перед сохранением в сеансе.

  2. Также sha1 () и сохраните http_user_agent var с небольшим количеством соли, и проверьте это вместе с user_id.

Я знаю, что есть еще что-то, что можно сделать, но я подумал, что это, по крайней мере, немного помогает, не так ли? и это легко для меня реализовать.

Ответы [ 3 ]

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

Я думаю, вы неверно истолковали, что означает угон сеанса. Ваша первая идея, похоже, совсем не мешает угону сессии.

Когда вы захватываете сеанс, вы крадете чей-то идентификатор сессии и притворяетесь идентификатором этого сеанса. Пользователь не может изменить какие-либо фактические данные сеанса, поэтому не имеет значения, что вы зашифровываете / хэшируете, так как они не смогут получить к нему доступ.

Что вы можете сделать, это сохранить строку IP и User Agent в сеансе и проверить ее перед объявлением пользователя, вошедшего в систему при каждой загрузке страницы. Если IP-адрес и пользовательский агент не совпадают, скорее всего, вам следует предложить им войти в систему. (Ну, по крайней мере, убедитесь, что пользовательский агент совпадает)

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

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

Например, человек X заполняет форму авторизации на twitter.com. Twitter.com отправляет человеку X печенье. Человек Y отслеживает пакет и вручную вставляет этот файл cookie в свой браузер и заходит на twitter.com, чтобы узнать, что они вошли в систему. Это перехват сеанса.

Затем происходит фиксация сеанса, где я даю вам ссылку http://www.blah.com/?phpsessid=1234, а затем молюсь, чтобы вы пошли туда и авторизовались, не заметив PHPsessid в URL. Если вы это сделаете, и если сайт не будет повторно генерировать идентификатор сеанса (как это всегда должно происходить при изменении состояния разрешений), то хакер теперь может посетить blah.com/?phpsessid=1234, и они будут зарегистрированы как вы. Таким образом, им не нужно было отслеживать идентификатор сеанса, потому что именно они дали его вам.

Вот отличный сайт с информацией о предотвращении перехвата основных сессий PHP, который, как я полагаю, может стать примером для ваших исследований.

http://phpsec.org/projects/guide/4.html

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

Я думал, что это, по крайней мере, немного помогает, верно?

Не совсем. Хэширование user_id ничего не делает, так как user_id уже предположительно является частью вашего сеанса.

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

В любом случае ничего из этого не делает ничего против XSRF-атак, где IP и UA будут полностью совпадать. См. этот вопрос , где можно обсудить стратегии анти-XSRF.

...