Очевидные 3 правила безопасности

Я всегда считал это подавлением ошибки. Если я жду номер страницы а мне приходит строка то мне не нужно молча сделать из строки число, я хочу знать откуда лезут эти строки — либо кто то ломает, либо я где то ссылку неправильно разместил и т.д…

Можно просто сделать обертку которая будет делать тривиальные проверки данных типа: знаковое/беззнаковое число, пустая/непустая строка, валидный email, и т.д…

Можно занятся сексом и добавить типизацию в пхп:

try {
    $n = Integer::parse($_GET['n']);
} catch (ParseException $e) {
    // blabla
}

но во первых полноценно на пхп сделать это не получится, а во вторых для этого есть другие языки )

Очевидные 3 правила безопасности

что пользователи могут сами допускать ошибки (принять не тот сертификат, или вообще добавить в браузер не тот CA, и так далее).

Что они как правило и делают ) Вы часто проверяете подлинность ключа когда браузер говорит что сертификат неверный? Если да — то респект вам конечно, но далеко не все такие.

Очевидные 3 правила безопасности

Всё так, пример показывает типичную неправильную проверку на тип. Пишут обычно:

$n = $_GET['n'];
if ($n != (int)$n) {
    trigger_error("Invalid number", E_USER_WARNING);
    return false;
}

И потом удивляются как их сломали.
Или вопрос был почему так? При сравнении числа со строкой происходит преобразование к числу обеих переменных. Т.е. (1 == «1abc»)

Очевидные 3 правила безопасности

ru.wikipedia.org/wiki/Человек_посередине

Очевидные 3 правила безопасности

Мультизапрос для примера, фантазии взломщика можно только позавидовать. Не обязательно цель удалить данные:

' AND BENCHMARK(SIN(1), 100000000000000) --

вот вам и DDOS.

А на счет проверок я лишь написал что НУЖНО проверять, а КАК проверять — это уже отдельная тема для разговора.

Очевидные 3 правила безопасности

Ну и помимо очевидных ещё несколько не очень очевидных:

3а.

Со стороны сервера всегда относитесь к вашему javascript-коду так, как будто он весь, от первой до последней буквы написан вашим самым ненавистным врагом, желающим сломать ваш сайт, нарушить целостность ваших данных и продать в рабство вашу жену. Тем более, что иногда это действительно так.

С любой стороны в любом коде относитесь к нему так. Если в ф-ю или метод должно прийти число — проверьте что это число. Если непустая строка — проверьте что это строка и что она не пустая и т. д…
Причем:

if ($n != (int)$n) {
    // это неправильная проверка, проверьте на "123'; DROP DATABASE users; --"
}

Если что то идет не так — не нужно подавлять ошибки — лучше кричите — trigger_error, user_error,… — отлавливайте их и изучайте.

4. Инициализируйте переменные и работайте с error_reporting(E_ALL)
5. Все переменные которые подставляются в SQL запрос должны быть экранированы с помощью mysql_escape_string либо mysql_real_escape_string либо bind либо плейсхолдеры, свои или готовые. Никогда не доверяйте данным, даже если переменная называется $only_fucking_numbers_can_be_in_this_variable все равно не верьте.
6. Все что выводится в браузер должно пропускаться через htmlspecialchars если только вы намерено не хотите вывести html, но тогда удаляйте там все что не разрешено. Используйте autoescape шаблонизаторов.
7. Все html-формы должны отправлятся вместе с токеном который генерируется и проверяется на сервере. Запросы на изменение данных не должны отправлятся POST'ом.
8. Не давайте пользователю передавать имена файлов которые будут впоследствии подключатся.
9. Не верьте HTTP_REFERER'у, USER_AGENT'у, SCRIPT_NAME, mime-type файлов и т.д… Это все формируется на КЛИЕНТЕ и может быть подделано.
10. Не храните пароли ни в открытом ни в обратимо-зашифрованном виде — только хеш, а лучше хеш с солью. Пароль знает только владелец, администратор может только сбросить его.
11. Не пользуйтесь короткими паролями.
12. Не пользуйтесь FTP, только SFTP.
13. При передаче приватных данных используйте HTTPS с реальным (а не самоподписанным) сертификатом.
14. Правильно выставляйте настройки кеширования приватных данных. (Cache-control: ...)
15. Не ограничивайтесь проверкой данных на клиенской стороне. Всегда проверяйте все данные на сервере.
16. Пользуйтесь различными сканерами уязвимостей.
17. Запрещайте все что не разрешено. Не надейтесь что кто то никогда не узнает о чем то. Обо всем все узнают обязательно.
18. Защищайтесь в первую очередь от себя и от тех кто работает непосредственно с кодом. Самое уязвимое место — человек. 99% самых громких взломов были бы невозможны без социальной инженерии.
19. Используйте мониторинг — взломать не наследив — не просто.
20. Пытайтесь сломать сами чужой (ну свой то конечно не сломать) код.

Очевидные 3 правила безопасности

Для дополнительной защиты следует проверять также referer

Абсолютно бесполезная проверка. Такая же как делать trim(htmlspecialchars(strip_tags($_GET['var']))) для защиты от SQL-инъекций и делать addslashes для защиты от XSS-инъекций. Больше доставит головной боли тому кто будет разбираться в коде. Подделать реферер, а так же все что формируется на клиентской стороне, а реферер отправляет именно браузер — вообще не проблема. token'а более чем достаточно. Причем лучше если это будет не session_id а индивидуальный токен на каждый запрос.

Визуализация каталогов на Python средствами NetworkX

D:/Работа/Документы/Старое/Всякий хлам/Нужно удалить/zzzzz/asfsdsfs/Порно? :)

Windows 8 — версия для разработчиков

а как такое на айпаде сделать?

ALTER очень больших таблиц в MySQL

Я о том и говорю — можно сделать скрипт который перельет так же как и mysqldump

ALTER очень больших таблиц в MySQL

mysqldump по идее делает START TRANSACTION и COMMIT если указать --single-transaction

ALTER очень больших таблиц в MySQL

Ну тогда можно сделать скрипт, START TRANSACTION и пачками…

ALTER очень больших таблиц в MySQL

А, у Вас MS SQL. Ну тогда может быть.

ALTER очень больших таблиц в MySQL

Странно, а какая версия? Я пробовал на 5.3 на таблице в 50 млн — не мгновенно.

ALTER очень больших таблиц в MySQL

Оракл не панацея. Я с ним никогда не работал но разве он горизонтально масштабируется?

ALTER очень больших таблиц в MySQL

Мы используем MySQL по 2-м причинам:
1. Так исторически сложилось и переписать тонны кода под другую БД очень долго и дорого.
2. Оракл и Postgre никто просто не знает так как MySQL. Мы обновляли MySQL с 5.1 до 5.3 и ещё месяц находили косяки. При переходе на тот же Оракл просто будем смотреть на него и не понимать чего оно не работает.

Поэтому имеем то что имеем и выкручиваемся как можем. Вообщем то недостатки MySQL — это последнее на что мы жалуемся.

ALTER очень больших таблиц в MySQL

> Шаг 1. ALTER TABLE users ADD(last_login INT);
попробовал на большой таблице на MySQL 5.3 — мускул ушел думать. Т.е. скорее всего переливка.

Знаю что начиная с 5.1 ENUM мгновенно добавляет новое значение а модификация существующего и удаление так же долго.

ALTER очень больших таблиц в MySQL

Это есть у вас туда только вставки идут, а если выборки старых данных?

ALTER очень больших таблиц в MySQL

Мм, да наверное потому что данные в таблице на которую ссылается изменяемая тоже может меняться. Вообще в таких таблицах лучше внешние ключи особо не использовать.

ALTER очень больших таблиц в MySQL

Да, и фейсбук на неё ссылается — но как говорится пока не сделаешь сам не поймешь как оно работает :)