Будем рассматривать какой-либо web-ресурс, к интерфейсу которого имеет доступ в принципе каждый. Естественно рождается мысль, НЕДАВАТЬ пользователю делать нежелательные действия, а только запланированные. Слово «запрограммированы» тут не подходит, так как можно наряду с программированием желательного действия косвенно запрограммировать Нежелательное. Вы понимаете о чем я?
Такие действия могут включать в себя как действия с банальными ошибками ввода, так и злонамеренные попытки повлиять на ход исполнения действия.
1. данные, передаваемые системе сайта должны обрабатыватся системой и иметь механизм сообщения результата обработки. По тем или иным признакам. Любой потенциально уязвимый параметр должен быть обработан на предмет кавычек, спец. символов, каких-либо других символов.
2. особо критические участки безопасной работы сайта авторизируются, или закрываются паролем. Причем система сайта может иметь достаточно мощную систему прав пользователей, позволяющая распределить роли в системе, а также обеспечить СЛОЖНОСТЬ, а в идеале НЕВОЗМОЖНОСТЬ кражи пароля или сессии.
Вы еще с нами? В частности использованием SSL можно безопасно передать пароль пользователя на сторону сайта. В принципе, с использованием пар ключей возможно зашифровать любой траффик, защитив его от перехвата (т.н. снифф), который весьма вероятен в наше время, когда потоки могут проходить через несколько «роутеров». Поэтому важно, как минимум передавать пароль пользователя в видоизмененном, зашифрованном виде или по шифрованному каналу https.
Можно упомянуть опасность «иньекции» в веб-сайт. В принципе, данная опасность и не возникает при соблюдении пп.1. Есть три вида «утечки»: в БД, в HTML, в файлы на хосте! (совсем надо обмороженным быть). «Утечка» в БД называется sql-иньекцией, позволяющая выполнять sql запросы злоумышленника. «Утечка» в HTML, и как следствие выводится вредоносный JavaScript, называется что-то типа «атакой через удаленный хост». А «утечка» в файлы вообще называется «кривые руки» и начальству следует рассмотреть вопрос на профпригодность для программиста. В целом, не пренебрегать ЛЮБОЙ проверкой переменных, прямо или косвенно зависящих от пользователя.
В принципе тема исчерпана, можно конечно привести тучу примеров исходниках на разных языках. Хотя было бы познавательно посмотреть как безопасность организована на каких-либо известных системах веб-решений. Судя по результатам поиска exploit по www.google.com ошибок более чем достаточно и в них.