История изменений

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.

-----------

А у китайцев с их бытовым хламом вот как: допустим, надо произвести вилку (столовый прибор). Что такое вилка? Штука с ручкой чтобы держать с одной стороны и 4 зубцами, чтобы втыкать в еду, с другой. Ещё надо сэкономить: ищем материал подешевле. Пробуем картон. Выглядит - удовлетворительно (ручка на месте, зубцы тоже), втыкание в еду - не получается. Ищем другой, заодно вспоминаем что обычно они металлические, иначе никто не купит. Берём силумин, массой (толщиной материала) поменьше чтобы сэкономить, да и кажется она так острее. Тест на втыкание к еду пройден, пускаем в производство. Итог: вилка выглядит как настоящая, её покупают, она ломается через неделю (или день). А что вы хотели? Держать в руке - можно, втыкать в еду - можно. Всё, задача выполнена. Про остальное китайца не спросили, он и не делал.

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.

-----------

А у китайцев с их бытовым хламом вот как: допустим, надо произвести вилку (столовый прибор). Что такое вилка? Штука с ручкой чтобы держать с одной стороны и 4 зубцами, чтобы втыкать в еду, с другой. Ещё надо сэкономить: ищем материал подешевле. Пробуем картон. Выглядит - удовлетворительно (ручка на месте, зубцы тоже), втыкание в еду - не получается. Ищем другой, заодно вспоминаем что обычно они металлические, иначе никто не купит. Берём силумин, массой (толщиной материала) поменьше чтобы сэкономить, да и кажется она так острее. Тест на втыкание к еду пройден, пускаем в производство. Итог: вика выглядит как настоящая, её покупают, она ломается через неделю (или день). А что вы хотели? Держать в руке - можно, втыкать в еду - можно. Всё, задача выполнена. Про остальное китайца не спросили, он и не делал.

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.

-----------

А у китайцев с их бытовым хламом вот как: допустим, надо произвести вилку (столовый прибор). Что такое вилка? Штука с ручкой чтобы держать с одной стороны и 4 зубцами, чтобы втыкать в еду, с другой. Ещё надо сэкономить: ищем материал подешевле. Пробуем картон. Выглядит - удовлетворительно, втыкание в еду - не получается. Ищем другой, заодно вспоминаем что обычно они металлические, иначе никто не купит. Берём силумин, массой (толщиной материала) поменьше чтобы сэкономить, да и кажется она так острее. Тест на втыкание к еду пройден, пускаем в производство. Итог: вика выглядит как настоящая, её покупают, она ломается через неделю (или день). А что вы хотели? Держать в руке - можно, втыкать в еду - можно. Всё, задача выполнена. Про остальное китайца не спросили, он и не делал.

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.

-----------

А у китайцев с их бытовым хламом вот как: допустим, надо произвести вилку (столовый прибор). Что такое вилка? Штука с ручкой чтобы держать с одной стороны и 4 зубцами, чтобы втыкать в еду, с другой. Ещё надо сэкономить: ищем материал подешевле. Пробуем картон. Выглядит - удовлетворительно, втыкание в еу - не получается. Ищем другой, заодно вспоминаем что обычно они металлические, иначе никто не купит. Берём силумин, массой (толщиной материала) поменьше чтобы сэкономить, да и кажется она так острее. Тест на втыкание к еду пройден, пускаем в производство. Итог: вика выглядит как настоящая, её покупают, она ломается через неделю (или день). А что вы хотели? Держать в руке - можно, втыкать в еду - можно. Всё, задача выполнена. Про остальное китайца не спросили, он и не делал.

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.

А у китайцев с их бытовым хламом вот как: допустим, надо произвести вилку (столовый прибор). Что такое вилка? Штука с ручкой чтобы держать с одной стороны и 4 зубцами, чтобы втыкать в еду, с другой. Ещё надо сэкономить: ищем материал подешевле. Пробуем картон. Выглядит - удовлетворительно, втыкание в еу - не получается. Ищем другой, заодно вспоминаем что обычно они металлические, иначе никто не купит. Берём силумин, массой (толщиной материала) поменьше чтобы сэкономить, да и кажется она так острее. Тест на втыкание к еду пройден, пускаем в производство. Итог: вика выглядит как настоящая, её покупают, она ломается через неделю (или день). А что вы хотели? Держать в руке - можно, втыкать в еду - можно. Всё, задача выполнена. Про остальное китайца не спросили, он и не делал.

Мда, защитник вредителей.

Ещё раз: речь НЕ про исправление допущеных ошибок. Речь про культуру разработки. Вот чтобы не вдаваться в детали, возьмём на примере любимого быдлокодерами php.

Допустим, у нас есть веб-просмотрщик книги, показывающий её по одной странице. На сервере страницы хранятся в формате txt в отдельных файлах, например 123-я страница тут: /home/mysite/book_name/123. Веб-просмотрщик должен добавить вокруг собственно текста какое-то html-оформление и выдать результат. Веб-просмотрщику передаётся аргумент: название книги $name и номер страницы $page. Как рассуждает профнепригодный производитель мусора:

Нам на вход дают название книги и номер страницы, мы знаем как из них составить путь к файлу:

"/home/mysite/".$name."/".$page

Итог - через этот скрипт можно читать любой файл на сервере, подставляя в $name и $page всякие "../../etc" и «passwd». В чём проблема? Задача же выполнена? При предполагаемых входных данных действительно получается предполагаемый результат - выводится страница. Только вот этого на самом деле недостаточно, в любую задачу по написанию публичного сервиса неявно входит «не выполнять никаких непредусмотренных действий ни при каких обстоятельствах». Действия «прочитать /etc/passwd» определённо не было предусмотрено. И узнать об этом надо было не по факту взлома (ну ладно, чтением не /etc/passwd а чего-нить другого, например лежащего рядом скрипта с паролями к базе) сайта, а с самого начала при проектировании продукта. Если нам надо прочитать файл с номером страницы из директории с названием книги, лежащей в /home/mysite/, то надо проверить, что мы подставляем туда

а) действительно название книги

б) действительно номер страницы

а не что угодно, что нам прислали. Нужно так же заранее понять, что если в названии книги будет / или книга называется "." или ".." то это к проблемам и такие ситуации тоже не допускать.

Если вышеописанная проблема дошла до «исправления ошибок» (пусть даже по результатам внутренних тестов в компании-разработчике), то разработчика (если это был не ученик) уже следует увольнять. Потому что этой проблемы изначально быть не должно.