А раскажите как распарсить JSON размером эдак в пару сотен мегабайт.

Похоже просто в песочнице долго лежало. Тоже сначала показалось до боли знакомым. Гугл подсказывает что с лета ждало своего часа:

А что не так с заголовком то?

Действительно фейк какой то. Ввел туда SHA1 своего пароля — написал что нашел. Скачал файл с хешами — там нету.

Ну наверное нужно сначала определится что защищаем? Обычно защищают пароль или данные кредитных карт, cv2 коды и т.д… — т.е. та информация которая не должна никоим образом хранится на сервере, а следовательно и получить её владея сессией нельзя. Защищается только момент передачи этой информации на сервер.
Если вы считаете что данные профиля — (фамилия имя отчество имейл) — это конфиденциальная информация то либо эту информацию не нужно нигде выводить, чтобы владея сессией нельзя было её получить, либо передавать айди сессии всегда по зашифрованному каналу — а значит шифровать весь трафик.

Есть ещё один вариант — когда переходите на секьюрную страницу — запрашивать пароль. Поднимать новую сессию и там уже показывать нужную информацию. Т.е. как бы отдельный сайт с отдельной авторизацией, только с таким же дизайном.

Если пользователь введет .../show.php?page=123blablabal вы можете задать поведение по умолчанию — пусть даже привести к int и показать страницу с id=123 (хотя в данном случае будет корректным показать 404 ошибку). Но если он введет неверные данные — вы как программист должны об этом знать. Ошибки совсем не обязательно, даже вообще не нужно показывать пользователю, но программист должен знать обо всех случаях которые отработали не так как должны были. Все ошибки нужно логировать и анализировать.

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

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

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

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

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

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

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

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

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

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

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

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

вот вам и DDOS.

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

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

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. Пытайтесь сломать сами чужой (ну свой то конечно не сломать) код.

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

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

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

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

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

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

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