Здраствуйте! Хотелось бы узнать как лучше обезопасить себя от хакеров при написании своей cms, а именно  php иньекций и sql иньекций. 

Делать проверку...


Вот тут нефиг передавать имена подключаемых файлов в параметрах...

Если это int, то достаточно преобразовать к инту

Если это строковый параметр, то 

Спасет от всех недугов....

Объясните мне чайнику, что такое CMS ?

Content Managed System (Система управления контентом)
Кароче, движок грубо говоря

а если там JS код (допустим)... он не выведет его, даже ввиде текста.... тогда надо будет использовать htmlspecialchars

для работы  с БД используйте PDO и биндинг параметров....Для очистки нежелательного js-кода можно написать функцию или взять ее из какого-нибудь фреймворка....пример вот тут http://andrey.opeykin.ru/yii-xss-filter/

если там код javascript, то это никак не повредит базе данных

htmlspecialchars нужна именно там, где js имеет силу - для вывода в браузер

короче,

1. при работе с БД нужно все данные пришедшие от пользователя пропускать через mysql_real_escape_string()
и это панацея, больше ничего не требуется, а даже вредно

2. при выводе данных в браузер, тех что были когда-то введены пользователем, то надо использовать htmlspecialchars()
и это панацея, уничтожит все тэги и кавычки, преобразует их в html-сущности

3. ни в коем разе не давать пользователю узнать структуру сайта и оградить его от возможности влиять на работу системы
простой пример - передача имени подключаемого файла через get-параметры в ссылке. кто-то умудряется так делать. ни в коем случае. даже часть физического пути передавать нельзя. заведите дополнительную таблицу в БД, где перечислите имена и пути ко всем вашим модулям, а передавайте в ссылке только его идентификатор: id=5, или что более красиво в случае ЧПУ адресов /mypage/, где mypage - уникальное имя по которому можно найти путь к модулю в базе


конечно, если встанет задача изменения содержимого сайта пользователем, то здесь придётся выкручиваться. к примеру, пользователь может вставлять целый куски html-кода, тогда htmlspecialchars здесь не покатит, тут уже либо вырезать крамольные тэги <script> и ряд других, придумать какую-то обработку, но это уже будет зависеть от конкретной задачи

bars80080
А как на счёт XSS в загружаемых фото! Здесь уже пробой получится!


Это сообщение отредактировал(а) Sentox - 10.5.2009, 00:10

А че?

Ну обычному пользователю думаю давать такую возможность не стоит. При обработке велика вероятность пропустить xss.

В фото? А фото скрипт? Фото можно заставить передать куку? Фото - это фото! Если фото берется с постороннего сайта, то его можно заставить собирать информацию (типа IP), но кукис ты никак не получишь...

 Выучить PHP.

После нескольких дней обучения ты уже не допустишь PHP-inj. От SQL-inj избавишься через пару сесяцев, а при альтернативных инструментах(ORM) ты их не сможешь допустить впринципе.
XSS - самые "безопасные" ошибки. Но множество гемора будет с ними.

Но самые опасные ошибки - ошибки в логике, в разделении прав и т.д., но на мелких проектах < 200кб собственного кода их не будет, они для сложных проектов.

 Иногда это надо. Например RICH-редакторы. Надо просто юзать соответствующие библиотеки для преобразования.

 Бред. Не нужно проверять содержимое графики и т.д. - не надо бояться локальных инклюдов, правильная архитектура их исключает.


 Лучше вообще не юзать устарешую либу для работы с СУБД ;) Это совет не топикстартеру, а тебе.

 Зачастую надо сохранить форматирование, так что не панацея.

 ИМХО самая большая глупость. Это как старые шифры, которые считались надежными только из-за того, что никто не знал их алгоритма.
Например я знаю архитектуру этого форума, но не могу его поломать, потому что он надежен(уже как полтора года не знаю открытых багов в 1ой ветке IPB, даже приватных XSS не нашли за это время).

мине? а что есть устаревшая либа для СУБД?



о чём я и написал далее



ага, но это не предохранило его от покусительства. ИМХО, самая большая глупость - это позиционировать себя в духе: смотрите какую я замечательную систему изобрёл. меньше знают - крепче спишь. тише воды, ниже травы - в итоге стрелы мимо будут пролетать, а не царапать броню