Разработка безопасных расширений для Joomla

Среди различных доступных онлайн-платформ управления контентом Joomla предпочитают за свою гибкость и повышенную безопасность. Тем не менее, это не мешает хакерам заглянуть в уязвимости вашего сайта и использовать их. Независимо от типа веб-сайта и уровня безопасности, веб-сайты всегда подвержены взлому. В большинстве случаев это связано с использованием уязвимых сторонних расширений.

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

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

HTML-инъекция/HTML Injection

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

Эта уязвимость возникает, когда пользовательский ввод неправильно очищен, а выход не закодирован.

Решение - использовать фильтр - safehtml, чтобы убрать все теги HTML

Пример

Здесь мы используем фильтр safehtml, чтобы сохранить введенные пользователем данные (Фамилия) без какого-либо HTML-кода. В приведенном ниже примере показано, как использовать фильтр для сохранения фамилии.

<field name="lname" type="text" label="COM_SCHOOL_FORM_LBL_STUDENT_LNAME" description="COM_SCHOOL_FORM_DESC_STUDENT_LNAME" required="true" filter="safehtml"/>

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

Приведенный ниже пример демонстрирует, как мы можем использовать функцию this-> escape () для очистки данных из базы данных и отображения их пользователю таким образом, чтобы в браузере пользователя не выполнялась вредоносная нагрузка HTML или javascript.

<?php echo $this->escape($item->fname . ' ' . $item->lname); ?> 

SQL Injection/SQL-инъекция

SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные операторы SQL. Злоумышленники могут использовать уязвимости SQL Injection, чтобы обойти меры безопасности приложения. Они могут получить содержимое всей базы данных SQL. Они также могут использовать SQL-инъекцию для добавления, изменения и удаления записей в базе данных. Чтобы предотвратить это, любые пользовательские вводы должны быть экранированы перед заменой в запросе.

Решение - используйте функции $db->escape() и $db->quote(), принимая входные данные пользователя.

Пример

Приведенный ниже код написан так, что поисковый запрос выполняется только после того, как все пользовательские данные очищены для любых возможных SQLInjection.

$search = Factory::getApplication()->input->get('search', '', 'STRING');

$search = $db->quote('%' . $db->escape($search) . '%');

Здесь мы используем функцию $db->escape() для очистки всех данных, полученных в поисковом запросе от пользователя. Здесь мы также можем ввести пользовательские данные, чтобы разрешить только целые числа или символы и т.д.

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

XSS (Cross-Site Scripting)/XSS (межсайтовый скриптинг)

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

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

Решение. Должна проводиться проверка пользовательских входных данных на стороне клиента и на сервере, а также перед их сохранением в базе данных.

Для проверки на стороне клиента - мы можем использовать соответствующие классы проверки на стороне клиента, чтобы избежать приема вредоносных нагрузок javascript непосредственно в поле формы. Также можно использовать пользовательский javascript для проверки ввода пользователя на стороне клиента.

Проверка на стороне сервера. Для проверки на стороне сервера мы должны определить надлежащие фильтры в файлах XML для очистки входных данных. Если строки принимаются, они должны быть правильно экранированы перед сохранением в базе данных. (пример - JFactory::getDBO()->escape())

<field name="description" type="text" label="COM_SCHOOL_FORM_LBL_DESC" description="" required="true" filter="RAW"/>

Здесь для описания - мы использовали фильтр WORD, чтобы принимать только буквы алфавита и подчеркивания.

Для проверки на стороне сервера - используйте команду trim, чтобы избавиться от нежелательных пробелов в начале и конце пользовательского ввода. Затем используйте функцию JFactory::getDBO()->escape(), чтобы применить htmlspecialchars() и / или htmlentities(), применимые к пользовательским вводимым данным, чтобы избежать вредоносных нагрузок javascript, а затем сохранить в базе данных.

$data['description'] = JFactory::getDBO()->escape($data['description']);

Но иногда данные, извлеченные из базы данных, декодируются в браузере. С другой стороны, вы можете не захотеть проверять данные перед сохранением в базе данных. В таких случаях вредоносные нагрузки javascript выполняются в браузерах, что ведет к потенциальной уязвимости. Чтобы предотвратить это, данные, извлеченные из базы данных, должны быть экранированы перед отображением.

<?php echo $this->escape($item->description); ?>

Итоги

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

Комментировать статью: