PHP и AJAX безопасность

[CoderX]

)

 

[HEm]

ЛЮБОЙ запрос к скрипту, выполняемый из браузера можно сымитировать и выполнить например от скрипта на сайте хакера. Подставить те же самые заголовки. Безопасность должна строиться на понимании этого факта. Любые данные приходящие извне считаются подверженными фальсификации. Вот и все.

 

[AmdY]

if ($_SERVER['HTTP_REFERER'] != 'http://адрес_сраницы_реферера_с_аяксом') {
die ("суда низза просто так э");
}

Забыли только объяснить что этот код может не работать во вполне безобидных ситуациях. например, фаервол режет реферер. Можешь погуглить, вполне встречаемая проблема. Не говоря уже о бредовости подобной верификации.
Вторая проблема в том, что последний ответ в данной теме был больше года назад и автор вопроса уже давно забыл о нём. Пока не появился д'Артаньян CoderX

Однако обратите внимание, что Вы лично слишком категоричны в своем отношении к другим.

Я думаю, Фанат был слишком мягок, раз сразу не дошло и вместо того чтобы погуглить варианты проблемы в ответе, здесь демагогию. Вот примеры запросов http://bit.ly/rPnv1r http://bit.ly/tMfmPi

 

[aaachilov]

Приветствую!
Присоеденюсь к этой давней теме.

Я сделал проверку на стороне обработчика - соответствует ли группа пользователя в сессии требуемой для выполнения скрипта.
Этого достаточно для безопасности?
Или ещё например добавить в запрос дополнительную переменную с занесением её значения в сессию и в обработчике проверить ещё и её - таким образом проверить с того ли файла пришел запрос или это уже лишнее?
Заранее благодарю за дополнение и так длинной дисскусии.

 

[HEm]

Я сделал проверку на стороне обработчика - соответствует ли группа пользователя в сессии требуемой для выполнения скрипта.
Этого достаточно для безопасности?

Безопасность имеет много аспектов. В такой постановке вопроса ответ - нет, недостаточно.

 

[aaachilov]

HEm

Спасибо за ответ - но если не доверять сессии... тогда я вообще ничего не понимаю. В любом случае стащив сессию админа любого ресурса можно по моему представлению сделать все что угодно или мои знания в программировании ничтожно малы))) А не могли бы Вы намекнуть направление по которому можно улучшить безопасноть с такой постановкой впроса?

 

[HEm]

ну да, если подсмотреть из-за плеча вводимый пароль, то тоже можно все стащить

я не специалист в области безопасности, поэтому лучше почитать, благо статей про это достаточно много

http://phpfaq.ru/all#safety

http://www.securityscripts.ru/articles/PHP/session-security.html про безопасность сессий например

а насчет соответствия группы пользователя его правам - имеет смысл ознакомиться например с этим http://php.russofile.ru/ru/translate/rights/phpgacl/

 

[lockon]

Вот рабочиe пример 1

if (!isset($_SERVER['HTTP_REFERER'])){
die ( "Попытка взлома!" );
}

Пример 2

В скрипте index.php

Вставляем константу

define ( 'IMYA_KONSTANTI', true );

Потом во всех остальных скриптах делаем проверку существует ли константа

if( ! defined( 'IMYA_KONSTANTI' ) ) {
	die( "Попытка взлома!" );
}

 

[Ragazzo]

f( ! defined( 'IMYA_KONSTANTI' ) )

это конечно жестко

 

[lockon]

это конечно жестко

Чем тебе не нравится примеры?

 

[Ragazzo]

 

[zerkms]

Чем тебе не нравится примеры?

Ну, к примеру тем, что

if (!isset($_SERVER['HTTP_REFERER'])){
die ( "Попытка взлома!" );
}

отсутствие заголовка с реферером вообще ни о чём не говорит. Более того - не нужно никаких "попыток взлома" пользователю выводить.

 

[FRIE]

Я эту тему создавал тучу времени назад когда вообще не особо понимал что такое аякс. Ничем он от обычных запросов не отличается )) Обработка данных для безопасности производится в бэкэнде

 

[FRIE]

Спасибо за ответ - но если не доверять сессии... тогда я вообще ничего не понимаю. В любом случае стащив сессию админа любого ресурса можно по моему представлению сделать все что угодно или мои знания в программировании ничтожно малы))) А не могли бы Вы намекнуть направление по которому можно улучшить безопасноть с такой постановкой впроса?

Делай работу через ssl шифрование, тогда сессию не перехватят. Так же время жизни сессии сделай небольшое. Думаю что этого вполне достаточно

 

[zerkms]

Делай работу через ssl шифрование, тогда сессию не перехватят. Так же время жизни сессии сделай небольшое. Думаю что этого вполне достаточно

Этого недостаточно и это не защита. Идентификаторы в 99% случаев воруют не между клиентом и сервером, а на клиенте (xss, трояны).

Про "доверие к сессиям": фраза поставлена не совсем корректно. Корректнее: сессии можно доверять настолько, насколько можно доверять данным, которые мы сами туда и положили.

 

[FRIE]

Этого недостаточно и это не защита. Идентификаторы в 99% случаев воруют не между клиентом и сервером, а на клиенте (xss, трояны).

Про "доверие к сессиям": фраза поставлена не совсем корректно. Корректнее: сессии можно доверять настолько, насколько можно доверять данным, которые мы сами туда и положили.

чтобы не было xss то htmlentities а от sql иньекций mysql_real_escape_string.

Вот так достаточно? (не считая троянов)

 

[zerkms]

чтобы не было xss то htmlentities а от sql иньекций mysql_real_escape_string.

Вот так достаточно? (не считая троянов)

Ну не то чтобы достаточно, но этот ответ намного лучше, потому как прошлый создаёт иллюзию того, что после переезда с http на https всё автоматически сразу станет безопасно и достоверно.

 

[FRIE]

Ну не то чтобы достаточно, но этот ответ намного лучше, потому как прошлый создаёт иллюзию того, что после переезда с http на https всё автоматически сразу станет безопасно и достоверно.

ssl+htmlentities+mysql_real_escape_string

Что еще можно добавить в этот рецепт безопасности?

 

[zerkms]

ssl+htmlentities+mysql_real_escape_string

Что еще можно добавить в этот рецепт безопасности?

htmlentities не всегда панацея, потому как часть контента может использоваться, к примеру, в js, а с ним придётся повоевать Этот вопрос, afaik, очень любит Дима, и если о нём сильно-сильно подумать, то он придёт сюда и позлорадствует на эту тему ))

 

[zerkms]

Ах, ещё - чтобы попытаться защитить постфактум сессии - можно (нужно) проверять, что клиент тот же самый (ip + юзерагент), это же спасёт и от session fixation