[Nark]

Следующий пост навел на размышления...

ivan341:
Nark, я уже нашел уязвимость в трех местах. Причем 2 в конференциях.

Еще возможна в заказе. Но я не стал копать глубже.
Есть еще программка для скана сайта. Которая ищет предпологаймые или возможные уязвимости в ПхП скриптах.

С помощью ее нашел 19 ошибок. И одна из них в проверки полей на символы " / //\ ' и т.д.
...

В следствии чего пришлось уйти в себя на два дня и разобраться в конце концов, как обстоят дела на фронте безопасности скриптов...

Из чего вынес:
Основные уязвимые места:
1. includы, evalы и тому подобные функции позволяющие интерпретировать не статические данные. (включая разновидности preg_replace с разными модификаторами).
2. МySQL запросы.
3. Сторонний софт.
4. Не надежный провайдер.
5. Другие уязвимости.

По первому пункту:
Чего делать не надо: инклюдить файлы передаваемые в качестве параметров; выполнять код передаваемый в качестве параметра.
Все это черевато полной потерей сайта или забросом левого скриптика, дающего полный контроль над сайтом злоумышленнику.

По второму:
Экранировать. Экранировать. И еще раз экранировать. Все что поучаем или берем, все не статические элементы эранировать.
Чем черевато и как используется. Если есть возможность вклиниться в MySQL запрос можно:
1. Если можно переписать целиком запрос, то можно потерять все таблицы и потерять данные. Если установленны сторонние скрипты, свои админские формы и прочее можно лишиться сайта + см. п.1.
2. Если можно дописать (обычно в месте критериев отбора (WHERE)) запрос, и результат запроса выводится в каком-либо виде - возможность слить все данные. Если установленны сторонние скрипты/админские см п.1. (Делается это все через UNION. Изменение даных в этом случае не проходит.)

По третьему:
Зачастую сторонние скрипты сложные, а иногда и вобще закрытые, что приводит к тому, что они вставляются как есть и тут все зависит от разработчика, потенциальной уязвимости и функциональной нагрузке скрипта. Одно можно сказать точно, что поставив такие скрпты нужно очень хорошо следить за обновлениями, патчами и заплатками . Обычно в достаточно сложных скриптах раз в пол-года вылазят какие-нибудь критические баги.

По четвертому:
Выберайте хороший хостинг. .

По пятому:
Сюда отнес кучу других уязвимостей, которые меня не особо касаются. Сакжу только, что многие из них появляются в местах где сторонний пользователь может постить информацию на ваш сайт. Защита сводится все к тому же: экранировать и еще раз экранировать.

Отвечая на пост ivan341:
Спасибо за информацию. Посмотрел на уязвимости которые вы нашли. все они не критические и максимум, что возможно с ними было сделать - это получить информацию с базы данных (которую и так можно получить на сайте) и то это очень мало вероятно. А заказ он вобще практически ничего не делает. Максимум - вы бы заспамили бы мне ящик.

Интерессно также какой программой вы пользовались при поиске уязвимостей.
ЗЫ (Небольшой камень в ваш огород) Я бы не стал использовать CMS у которых раз в два меяца выходят критические апдейты. И закрыл директорию /engine/ от листинга.

[ivan341]

Nark, SQL including (иньекция) очень опасна. Легко можно завладеть сайтом. Поковыряться только надо.

В заказе вы думаете можно только к вам на ящик письмо послать .. =)

Я проще скажу - посмотри форум vingrad и почитай там про безопастность и частые ошибки.

if (isset($bla) && $bla != '2') { ...... ну и т.д. Это не спасет от проникновения.

Почитай посты по безопастности MalHack

[Nark]

ivan341:
Nark, SQL including (иньекция) очень опасна. Легко можно завладеть сайтом. Поковыряться только надо.

Инклюдингом если он не целиковый запрос меняет добьетесь максимум содержания всех таблиц. А если в таблицах нету информации по админским паролям/логинам - хрен чего сделаете.

"В заказе вы думаете можно только к вам на ящик письмо послать .. =)"

Абсолютно. Он больше ничего не делает. Это просто меил форма на статично заданный адрес.

[Alkeeper]

ivan341, вообще-то Injection
прочитав упомянутый выше топик, скажу, что у Нарка Бдящий хостер , если простые потуги типа ...&id=10' OR id = '20 он пропускает,

то на такие вещи:

...&id=10' UNION SELECT `login` as `bla` , `password` as `alb` FROM..

Реагирует довольно жестко, недопуская до клиента

[Nark]

Alkeeper:
то на такие вещи:

...&id=10' UNION SELECT `login` as `bla` , `password` as `alb` FROM..

Реагирует довольно жестко, недопуская до клиента

Да. когда-то это бесило... Но ничего привык .
Хотел использовать в закрытой админсткой формочке...