Безопасность web-сайта

Будем рассматривать какой-либо web-ресурс, к интерфейсу которого имеет доступ, в принципе, каждый. Естественно, рождается мысль, не давать пользователю делать нежелательные действия, а только запланированные. Слово «запрограммированы» тут не подходит, так как можно наряду с программированием желательного действия косвенно запрограммировать нежелательное. Вы понимаете о чем я?

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

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

2. особо критические участки безопасной работы сайта авторизируются или закрываются паролем. Причем система сайта может иметь достаточно мощную систему прав пользователей, позволяющая распределить роли в системе, а также обеспечить СЛОЖНОСТЬ, а в идеале НЕВОЗМОЖНОСТЬ кражи пароля или сессии.

Вы еще с нами? В частности использованием SSL можно безопасно передать пароль пользователя на сторону сайта. В принципе, с использованием пар ключей возможно зашифровать любой траффик, защитив его от перехвата (т.н. снифф), который весьма вероятен в наше время, когда потоки могут проходить через несколько «роутеров». Поэтому важно, как минимум передавать пароль пользователя в видоизмененном, зашифрованном виде или по шифрованному каналу https.

Можно упомянуть опасность «иньекции» в веб-сайт. В принципе, данная опасность и не возникает при соблюдении пп.1. Есть три вида «утечки»: в БД, в HTML, в файлы на хосте! (совсем надо обмороженным быть). «Утечка» в БД называется sql-иньекцией, позволяющая выполнять sql запросы злоумышленника. «Утечка» в HTML, и как следствие выводится вредоносный JavaScript, называется что-то типа «атакой через удаленный хост». А «утечка» в файлы вообще называется «кривые руки» и начальству следует рассмотреть вопрос на профпригодность для программиста. В целом, не пренебрегать ЛЮБОЙ проверкой переменных, прямо или косвенно
зависящих от пользователя.

В принципе тема исчерпана, можно конечно привести тучу примеров исходниках на разных языках. Хотя было бы познавательно посмотреть как безопасность организована на каких-либо известных системах веб-решений. Судя по результатам поиска exploit по www.google.com ошибок более чем достаточно и в них.