Как заставить программистов перестать писать код, уязвимый для SQL-инъекций?

Иногда вы заняты и поручаете небольшие задачи младшим программистам. Но если вы не уделите достаточно пристального внимания, вы окажетесь с таким кодом в производстве:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

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

Вы можете научить их. Каждый делает это в начале, даже вы. Если этот тип кода делает его в производство, это вина старших людей; не младший.

Редактировать:

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

Взломайте их код перед их глазами, затем покажите им, как это исправить. Снова и снова, пока они не поймут.

Вы можете поручить им принять класс, как только они присоединятся к вашей компании, прежде чем они получат доступ к системе контроля версий, который знакомит их с инъекциями SQL, межсайтовым скриптингом, подделкой межсайтовых запросов и другими распространенными уязвимостями. Обсуждайте примеры лицом к лицу, разбивайте плохой код перед ними, заставляйте их взламывать плохой код и направляйте их на сайт OWASP для получения дополнительной информации, как только они «закончат обучение».

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

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

Знание - сила!

Предполагая, что это небезопасность, на которую ссылались другие, как на разработчика любого уровня, легко забыть, что getPost () не защищает данные в первую очередь.

Один из способов обойти это:

1. Напишите класс, который получает все данные POST / GET и записывает их как есть в класс Singleton, называемый «insecure_data». Затем очистите массивы POST / GET.
2. Разработчикам, которые должны извлекать данные POST / GET из массива 'insecure_data', а не из массивов POST / GET.

Любой разработчик, который извлекает что-то из массива с именем «insecure_data» и не заботится о его защите, либо неосведомлен, либо ленив. Если это первое, проведите обучение, после чего оно должно быть последним, и тогда у вас возникнет дисциплинарная проблема, а не проблема программирования.

Одним из лучших руководств, которые я прочитал по веб-безопасности, является это руководство по безопасности Ruby on Rails . Хотя это Ruby on Rails, многие концепции применимы к любой веб-разработке. Я бы посоветовал любому новичку прочитать это руководство.

Код, который вы связали выше, подвержен атаке SQL-инъекцией, потому что входы HTTP, которые вы используете в запросе, не были очищены mysql_real_escape_stringкаким-либо другим способом.

С точки зрения вашего (предположительно переопределенного) вопроса «как я могу заставить программистов прекратить делать это», я бы сказал, что наставляю их на регулярной основе, тщательно объясняя рассматриваемый вопрос (и возможные последствия, и т. Д.) И подчеркивая Важность уязвимостей кода (как с точки зрения внедрения SQL, так и межсайтового скриптинга и т. д.), вероятно, является наиболее разумным решением.

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