Речь о правилах разработки, а не фильтрации, если что :)
SQL: данные в запрос передавать только через плейсхолдеры. Идентификаторы и ключевые слова — только фильтруя по белому списку, своему для каждого запроса.
CSRF: привязанные к сессии токен в каждой POST форме.
Чтение файлов: при передаче через пользователя имени файла, всегда передавать только его имя, без пути, и соответствующим образом валидировать. (basename в простейшем варианте). Путь же строить всегда самому, внутри приложения.
XSS — htmlspecialchars принудительно внутри шаблонизатора для всех переменных, кроме, опять же, специально помеченных в белом списке.
Такие очевидные правила, как «ни одна переменная не выводится мимо шаблонизатора» или «никакое действие, меняющее состояние сервера, не выполняется методом GET » я не выделяю отдельно, хотя, возможно, стоило бы.
Ой, вот уж чему-чему, а «коллективному разуму» я безопасность своего сайта тем более не доверю. У семи нянек — дитя без глазу.
А честные посетители получают Forbidden за смайлик и пример SQL запроса в комментарии.
Ну, здесь, мне кажется, мы говорим о гипотетических сайтах с «ужасным» legacy code.
Если говорить о новых разработках, то уж читатели-то хабра должны бы уже забыть о таких простых атаках, как
— SQL-инъекция (2 простых правила для написания безопасного кода)
— CSRF (1 правило)
— LFI/RFI/TRAVERSAL (два)
с XSS сложнее, но уж на уровне-то этого модуля тоже решение элементарное. Которое, к тому же, не будет за смайлики 403 показывать.
Можно.
Но решение ведь явно из разряда «поставил и забыл».
А при наличии таких ресурсов, как время и опыт, я бы всё-таки потратил их на написание безопасной версии сайта, а не на паллиатив.
Так что модуль явно для «ситуации, когда требуется хостить подозрительные сайты» которые не жалко, а времени заниматься ими нету.
$SQL и $XSS — для магазина по продаже подгузников это сработает. Для сайта типа Хабра — по очевидным причинам — нет.
$RFI — ну, тут, скорее всего, можно сделать достаточно надёжный набор правил.
$TRAVERSAL — здесь тоже 100% попадание — модуль идеально подходит для этой задачи. Главное поисковики не забанить
CSRF — проверка реферера, с теми же дырами, что и обычно.
Так что я бы всё-таки подчеркнул разницу между «поможет защитить» от «защищает». Особенно на «важном для бизнеса участке».
1. К безопасности собственно сайта безопасность хранения паролей имеет весьма опосредованное отношение. И выстрелит раззве что в случае, если злоумышленнику удалось получить дамп БД. Разумеется, это не повод не хэшировать пароли, но просто почему-то всегда в разговоре о паролях подразумевается безопасность сайта, а не сохранность собственно паролей.
2. Множество «короткие и простые пароли» НЕ тождественно множеству «8-символьный пароль, который будут ломать 7 лет». Пароль «12345» будут ломать пару секунд. Так что все эти «тыщу раз захешируем» НЕ являются альтернативой запрету простых паролей.
На основе чего статистика?
По логам моего сайта, без реферера или с кривым реферером (типа «Field blocked by Outpost Firewall») довольно много пользователей.
А я недавно попробовал Таинственный остров — такая беспомощная книга.
В детстве катит хорошо, но с возрастом начинаешь видеть нестыковки, шаблонность, слабость сюжета…
Даже не знаю, что забавнее — то ли сам опрос (вида «я моюсь раз в день, раз в месяц, вообще не моюсь»), то ли каменты, с восхитительным делением всей литературы на «художественную» и «о программировании».
Да при чем здесь мой ЖЖ.
Речь о ситуации в целом.
У меня есть релевантный пример, avva.livejournal.com/2328256.html
Авва имел возможность сравнивать на практике. И это очень важный опыт. Практический.
А не теоретические рассуждения, как в нашем с вами случае.
ЖЖ — это именно что автобус.
ЖЖ — это сеть.
И без перенесения всей сетевой инфраструктуры попытка уйти на отдельно стоящие блоги просто убьёт эту сеть.
Мы просто говорим о разном.
Вы говорите о переносе блога, а я говорю о переносе уникальной среды общения, переводе её с централизованного на распределённый принцип работы.
Это совсем разные вещи.
не, не.
Это получится кадавр, сшитый из кусков, а не живой организм.
Тут много тонкостей.
Ещё нужны
Нотификация на почту.
Какой-то аналог сообществ
Более гибкое управление комментариями.
Обеспечение подзамков
Группы
И ещё тыща нюансов.
Сделать просто «шоб було» — действительно, легко.
Сделать так, чтобы с этим можно было жить, чтобы твой стандалон комментировали живые люди чаще, чем раз в неделю — гораздо сложнее.
До чего же смешное представление у молодёжи о жж :)
Живой журнал — это не симбиоз десятка записных болтунов с офисным планктоном.
Если все это говно сольётся в гп — воздух только чище станет.
Настоящий ЖЖ — это несколько десятков тысяч перелинкованных дневников, в которых люди читают других людей, а не «блогеров».
И эту сесть так легко не перенести, увы.
Надо делать новую, распределённую архитектуру, и перелезать на неё.
Но кто ж этим будет заниматься…
Это единственная придирка к букве текста, которую можно найти, да.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
SQL: данные в запрос передавать только через плейсхолдеры. Идентификаторы и ключевые слова — только фильтруя по белому списку, своему для каждого запроса.
CSRF: привязанные к сессии токен в каждой POST форме.
Чтение файлов: при передаче через пользователя имени файла, всегда передавать только его имя, без пути, и соответствующим образом валидировать. (basename в простейшем варианте). Путь же строить всегда самому, внутри приложения.
XSS — htmlspecialchars принудительно внутри шаблонизатора для всех переменных, кроме, опять же, специально помеченных в белом списке.
Такие очевидные правила, как «ни одна переменная не выводится мимо шаблонизатора» или «никакое действие, меняющее состояние сервера, не выполняется методом GET » я не выделяю отдельно, хотя, возможно, стоило бы.
А честные посетители получают Forbidden за смайлик и пример SQL запроса в комментарии.
Если говорить о новых разработках, то уж читатели-то хабра должны бы уже забыть о таких простых атаках, как
— SQL-инъекция (2 простых правила для написания безопасного кода)
— CSRF (1 правило)
— LFI/RFI/TRAVERSAL (два)
с XSS сложнее, но уж на уровне-то этого модуля тоже решение элементарное. Которое, к тому же, не будет за смайлики 403 показывать.
Но решение ведь явно из разряда «поставил и забыл».
А при наличии таких ресурсов, как время и опыт, я бы всё-таки потратил их на написание безопасной версии сайта, а не на паллиатив.
Так что модуль явно для «ситуации, когда требуется хостить подозрительные сайты» которые не жалко, а времени заниматься ими нету.
$RFI — ну, тут, скорее всего, можно сделать достаточно надёжный набор правил.
$TRAVERSAL — здесь тоже 100% попадание — модуль идеально подходит для этой задачи. Главное поисковики не забанить
CSRF — проверка реферера, с теми же дырами, что и обычно.
Так что я бы всё-таки подчеркнул разницу между «поможет защитить» от «защищает». Особенно на «важном для бизнеса участке».
Плохой пароль защитить никаким хэшированием НЕВОЗМОЖНО.
1. К безопасности собственно сайта безопасность хранения паролей имеет весьма опосредованное отношение. И выстрелит раззве что в случае, если злоумышленнику удалось получить дамп БД. Разумеется, это не повод не хэшировать пароли, но просто почему-то всегда в разговоре о паролях подразумевается безопасность сайта, а не сохранность собственно паролей.
2. Множество «короткие и простые пароли» НЕ тождественно множеству «8-символьный пароль, который будут ломать 7 лет». Пароль «12345» будут ломать пару секунд. Так что все эти «тыщу раз захешируем» НЕ являются альтернативой запрету простых паролей.
По логам моего сайта, без реферера или с кривым реферером (типа «Field blocked by Outpost Firewall») довольно много пользователей.
В детстве катит хорошо, но с возрастом начинаешь видеть нестыковки, шаблонность, слабость сюжета…
Речь о ситуации в целом.
У меня есть релевантный пример, avva.livejournal.com/2328256.html
Авва имел возможность сравнивать на практике. И это очень важный опыт. Практический.
А не теоретические рассуждения, как в нашем с вами случае.
ЖЖ — это именно что автобус.
ЖЖ — это сеть.
И без перенесения всей сетевой инфраструктуры попытка уйти на отдельно стоящие блоги просто убьёт эту сеть.
Мы просто говорим о разном.
Вы говорите о переносе блога, а я говорю о переносе уникальной среды общения, переводе её с централизованного на распределённый принцип работы.
Это совсем разные вещи.
Это получится кадавр, сшитый из кусков, а не живой организм.
Тут много тонкостей.
Ещё нужны
Нотификация на почту.
Какой-то аналог сообществ
Более гибкое управление комментариями.
Обеспечение подзамков
Группы
И ещё тыща нюансов.
Сделать просто «шоб було» — действительно, легко.
Сделать так, чтобы с этим можно было жить, чтобы твой стандалон комментировали живые люди чаще, чем раз в неделю — гораздо сложнее.
Нужна система перелинковки.
Независимый блог + агрегатор RSS (с некоторыми доп.фишками) + система авторизации на основе OpenID = вот это будет система, адекватная нынешнему жж.
Живой журнал — это не симбиоз десятка записных болтунов с офисным планктоном.
Если все это говно сольётся в гп — воздух только чище станет.
Настоящий ЖЖ — это несколько десятков тысяч перелинкованных дневников, в которых люди читают других людей, а не «блогеров».
И эту сесть так легко не перенести, увы.
Надо делать новую, распределённую архитектуру, и перелезать на неё.
Но кто ж этим будет заниматься…
В самой ссылке есть важное.
Сама ссылка — это authentication credentials. Аналог логина и пароля.
Которые нельзя передавать ГЕТом.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.