![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Темой сегодняшней лекции для веб-девелоперов будет одна простая мысль,
а именно: никогда не доверяйте данным, полученным от пользователя. НИКОГДА.
Вот, собственно, и всё.
Удивительно, но этой мыслью настолько часто пренебрегают, что я начал сомневаться в ее очевидности.
Причём синтаксическая проверка джаваскриптом на стороне пользователя - это хорошо, но надеяться на неё нельзя. Не поленитесь проверить данные и на сервере в обработчике формы. Потому что у добросовестного пользователя может быть кривой или отключенный джаваскрипт, а у злого хакера - вообще никакого.
Если в некотором поле должно быть число - проверьте, правда ли там число. Или просто сразу запустите функцию преобразования в число. Если оно должно быть в определенном диапазоне или, например, неотрицательным, проверьте это.
Если в поле должен быть (не дай бог!) номер кредитной карты, убедитесь, что там правильно количество цифр, и ничего кроме них.
Если в поле должна быть фамилия, проверьте, что там встречаются исключительно буквы. Максимум - пробелы. Но не цифры и не вопросительные знаки.
И не надейтесь, что J. Random Hacker впишет в поле nickname именно свой nickname из букв и цифр, а не javascript. Лучше проверьте.
Если в поле должен быть URL, то проверьте его на допустимость значения (абсолютный, относительный, с правильным хостом, расширением и допустимым набором символов). А то будет, как на сайте Интерпола.
Ну и так далее.
Если значением поля является опция из выпадающего списка или радиобаттона, ни в коем случае не надейтесь, что там будет именно одна из опций, указанных в форме. Проверьте. И не забудьте предусмотреть вариант обработки по умолчанию на случай неправильного значения.
Не забывайте о hidden полях. И ни в коем случае не передавайте через них чувствительные данные. Злой хакер может не только посмотреть, чтО там написано, но и (сюрприз!) подделать и значения hidden полей, и куки, и Referer, и User-Agent, и вообще ВСЁ, что передаётся на сервер. Кроме, разве что, IP-адреса.
По возможности не втыкайте данные, полученные непосредственно от пользователя, в SQL-запрос или в генерируемый HTML-код. В крайнем случае - предварительно проверенные на синтаксическую И семантическую правильность. В SQL по возможности используйте байндинг.
Потому что иначе вы легко заработаете если не SQL-, то какой-нибудь javascript-injection.
Наконец, если в форме предумотрена передача данных методом POST, то не надо обрабатывать параметры, переданные методом GET. Потому что это ненормально. И вообще, по возможности не используйте GET, у него и так много недостатков.
Вот, примерно так.
Upd: те же гениталии, вид с другого ракурса, то есть, применительно конкретно к PHP: http://www.citforum.ru/internet/securities/phpsecure.shtml
а именно: никогда не доверяйте данным, полученным от пользователя. НИКОГДА.
Вот, собственно, и всё.
Удивительно, но этой мыслью настолько часто пренебрегают, что я начал сомневаться в ее очевидности.
Причём синтаксическая проверка джаваскриптом на стороне пользователя - это хорошо, но надеяться на неё нельзя. Не поленитесь проверить данные и на сервере в обработчике формы. Потому что у добросовестного пользователя может быть кривой или отключенный джаваскрипт, а у злого хакера - вообще никакого.
Если в некотором поле должно быть число - проверьте, правда ли там число. Или просто сразу запустите функцию преобразования в число. Если оно должно быть в определенном диапазоне или, например, неотрицательным, проверьте это.
Если в поле должен быть (не дай бог!) номер кредитной карты, убедитесь, что там правильно количество цифр, и ничего кроме них.
Если в поле должна быть фамилия, проверьте, что там встречаются исключительно буквы. Максимум - пробелы. Но не цифры и не вопросительные знаки.
И не надейтесь, что J. Random Hacker впишет в поле nickname именно свой nickname из букв и цифр, а не javascript. Лучше проверьте.
Если в поле должен быть URL, то проверьте его на допустимость значения (абсолютный, относительный, с правильным хостом, расширением и допустимым набором символов). А то будет, как на сайте Интерпола.
Ну и так далее.
Если значением поля является опция из выпадающего списка или радиобаттона, ни в коем случае не надейтесь, что там будет именно одна из опций, указанных в форме. Проверьте. И не забудьте предусмотреть вариант обработки по умолчанию на случай неправильного значения.
Не забывайте о hidden полях. И ни в коем случае не передавайте через них чувствительные данные. Злой хакер может не только посмотреть, чтО там написано, но и (сюрприз!) подделать и значения hidden полей, и куки, и Referer, и User-Agent, и вообще ВСЁ, что передаётся на сервер. Кроме, разве что, IP-адреса.
По возможности не втыкайте данные, полученные непосредственно от пользователя, в SQL-запрос или в генерируемый HTML-код. В крайнем случае - предварительно проверенные на синтаксическую И семантическую правильность. В SQL по возможности используйте байндинг.
Потому что иначе вы легко заработаете если не SQL-, то какой-нибудь javascript-injection.
Наконец, если в форме предумотрена передача данных методом POST, то не надо обрабатывать параметры, переданные методом GET. Потому что это ненормально. И вообще, по возможности не используйте GET, у него и так много недостатков.
Вот, примерно так.
Upd: те же гениталии, вид с другого ракурса, то есть, применительно конкретно к PHP: http://www.citforum.ru/internet/securities/phpsecure.shtml
Tags:
no subject
и констрайнты они тоже в схему базы сами автомагически вставляют :)
no subject