Файл: Особенности алгоритмизации при разработке WEB-приложений (Общие подходы программирования).pdf
Добавлен: 28.03.2023
Просмотров: 113
Скачиваний: 2
Ниже приведен упрощенный пример контроллера, модели и представления на базе фреймворка Yii2.
Пример Контроллера. Листинг 3:
<?php // Листинг 3
// Контроллер приложения
class SiteController extends Controller
{
public function actionAbout()
{
$model = new AboutModel();
return $this->render('about', [
'data' => $model->getData()
]);
}
}
?>
В данном контроллере он наследуется от базового класса Controller, который присутствует во фреймворке, что по принципам наследования в ООП позволяет нам пользоваться методами родительского класса. В данном случае используется метод render из родительского класса для генерации представления и передачи в него данных из модели с помощью конструкции 'data' => $model->getData().
Пример Модели. Листинг 4:
<?php // Листинг 4
// Модель приложения
class AboutModel {
// Для упрощения примера, данные хранятся в переменной
private static $_data = [
'1' => [
'number' =>'1',
'heading' =>'Первая новость',
'text' =>'Полный текст первой новости',
'created_at' =>'2017-04-24 10:26:02',
],
'2' => [
'number' =>'2',
'heading' =>'Вторая новость',
'text' =>'Полный текст второй новости',
'created_at' =>'2017-04-25 10:26:02',
],
];
// Публичный метод класса для получения данных
public function getData()
{
return self::$_data;
}
}
?>
В данной модели для наглядности данные хранятся в статической приватной переменной. Для того чтобы получить данные из нее, необходимо воспользоваться методом getData(). Такое решение позволяет довольно просто сменить хранилище с переменной на Базу Данных, главное, чтобы метод getData() так же возвращал массив. Также из этого примера видно, что модель не знает ничего, ни о контроллере, ни о представлении.
Пример представления. Листинг 5
<?php // Листинг 5
$title = 'Новости о нас';
?>
<html>
<head>
<title><?=$title?></title>
</head>
<body>
<div class="site-about">
<h1><?=$title?></h1>
<ul>
<?php foreach ($data as $news) { ?>
<li>
<strong>Новость № <?=$news['number']?> -
<?=$news['heading']?></strong>
<?=$news['text']?>
<span><?=$news['created_at']?></span>
</li>
<?php } ?>
</ul>
</div>
</body>
</html>
Представление на данном листинге практически не содержит php кода. Не обращается к каким либо методам. Вся задача Представления получить данные от контроллера, в данном случае $data, и сгенерировать HTML код. Файл с таким содержимым легко читается, его можно отдать верстальщику, дизайнеру для создания необходимого дизайна сайта. При этом сама работа по получению данных, может быть достаточно сложной. Также способ получения этой страницы может содержать различные проверки на права доступа, перенаправления. Всё это остается в Модели и Контроллере, полностью избавляя Представление от лишнего кода.
В данном примере представлен самый простой вариант исполнения приложения. В частных случаях контроллер может вызывать несколько моделей, в зависимости от результата выполнения может производить редирект (перенаправление) на другие страницы сайта. При неправильном полученном маршруте приложение может сгенерировать исключение и выдать пользователю страницу ошибки, например «Ошибка 404. Не найдено».
Контроллер может реализовать в себе управление доступом. Осуществлять проверку прав пользователя (гость, зарегистрированный, администратор) на право выполнения данного действия. В случае отсутствия прав генерировать исключение «Доступ запрещен». Также Контроллер кроме редиректа и формирования HTML может формировать данные в формате JSON при AJAX запросе, генерировать с помощью модели и отдавать изображение, отдавать готовые файлы JavaScript, CSS, документы DOC PDF и тому подобное. Правилом хорошего тона считается создавать "тонкие" Контроллеры, в которых выполняется только необходимый минимум действий в зависимости от полученных данных. Вся обработка, валидация и любые другие действия с полученными данными должны выполняться в Модели.
Например пользователь отправляет комментарий через форму на сайте. Контроллер должен только принять данные, определить действие и вызвать метод Модели для загрузки данных, к примеру метод load(). В Модели производится проверка данных на отсутствие стоп-слов (оскорбительного характера и т. д.), удаляются все тэги кроме разрешенных, проверяется допустимая длина сообщения. В случае если сообщение удовлетворяет всем условиям, модель сохраняет сообщение и вызываемый метод возвращает true . Контроллер определяет, что сообщение успешно сохранилось и перенаправляет пользователя на страницу (на действие контроллера actionSuccess() ) с представлением в котором написано «Ваше сообщение успешно сохранено». В случае если сохранить сообщение не удалось контроллер перенаправляет пользователя на страницу (на действие контроллера actionFail() ) с представлением в котором написано «Ваше сообщение сохранить не удалось».
Данный пример показывает преимущества паттерна MVC. Модель содержит в себе все методы и логику работу с данными. Эту логику можно менять. Например добавить правила проверки входных данных, либо изменить хранилище с одной СУБД на другую. Главное чтобы оставались неизменны публичные методы, с которыми работает контроллер. Представление зависит от данных которые ему передал контроллер (в некоторых случаях возможно получение данных из модели минуя контроллер), не производит никаких действий над данными. Соответственно представление можно сформировать как угодно, совершенно независимо от того как и какие данных приходят.
Глава 4. Особенность работы Веб-приложения. Безопасность
Особенностью работы Веб-приложения является то, что контекст его исполнения отличается от прикладных программ. Если в случае с обычным прикладным приложением контекст его исполнения представлен структурами данных, размещенными в оперативной памяти на клиентской машине, то в работе Веб-приложения все несколько иначе. Ниже сформулированы несколько пунктов, чем отличается Веб-приложение от обычного приложения в плане организации контекста его исполнения.
1. Контекст исполнения поделен на всех участников распределенной системы, и они обязаны его как-то делить и синхронизировать между собой.
2. В случае с Веб-приложением контекст исполнения теоретически существует только в ходе формирования и обработки только одного клиент-серверного запроса. Имеется в виду, что жизненный цикл всех структур данных в оперативной памяти ограничен не всем периодом работы клиента с Веб-приложением, а временем подготовки, отправки и обработки одного HTTP запроса. После перезагрузки интернет страницы все старые структуры контекста теряются и создаются новые.
Разумеется, существуют различные способы сохранять состояние сеанса между запросами (сессии, Cookies), но эти способы не вписываются в канву программирования по принципу «запрос-ответ» и являются искусственными надстройками над инфраструктурой Веб-программирования. Так называемая stateless (без состояния) модель использования сервера, когда система не хранит своего состояния между запросами, а «просыпается» только тогда, когда запрос необходимо обработать, является более надежной в сравнении со stateful (с поддержкой состояния) моделью. Это так, поскольку выход из строя аппаратной или системной программной части сервера может привести к непредсказуемому поведению Веб-приложения только в том случае, если этот сбой произойдет в момент обработки запроса. Также, элементарно может не хватить оперативной памяти для обслуживания большого количества клиентских запросов, при условии, что каждому сеансу необходимо обеспечить возможность сохранять и восстанавливать свое состояние. Тем не менее, совсем без контекста исполнения, разделяемого между запросами в некоторых задачах обойтись довольно сложно, поскольку в ходе вычислений часто приходится работать к ресурсам, обращение к которым может занимать много времени. Для того чтобы минимизировать подобные издержки наиболее критичные ресурсы разработчики предпочитают хранить «в быстром доступе» - в оперативной памяти Веб-сервера. Рассмотрим несколько способов управления Веб-приложением. Поскольку мы имеем дело с общением клиента и сервера, то и контекст делится на клиентский и серверный. Ниже перечислены способы сохранения и восстановления контекста исполнения или по-другому состояния сеанса работы Веб-приложения на стороне клиента и на стороне сервера.
На стороне клиента:
1. В оперативной памяти приложения клиента (интернет браузера). С выходом HTML5 для этих целей в браузерах появилась поддержка LocalStorage. Это очень удобно для хранения данных полученных в результате работы скриптов (JavaScript) на стороне клиента (в браузере). В таком варианте на сервер можно передавать данные только при необходимости, экономя ресурсы сервера. И сокращая время задержек из-за отправки данных.
2. В небольших фрагментах текстовых данных, сохраняемых на стороне клиента – cookies. Cookies сохраняются в текстовых файлах, в разделах, выделенных операционной системой для хранения различной пользовательской информации. Эти данные передаются каждый раз серверу в заголовках HTTP запроса. Благодаря тому что эти данные передаются серверу при каждом запросе, можно реализовывать «узнавание» пользователя сервером. На этом принципе работают практически все системы связанные с авторизацией пользователя.
На стороне сервера:
1. В области оперативной памяти, выделяемой Веб-сервером (Apache, IIS) и называемой состояние приложения. Эти данные доступны со всех страниц Веб-приложения всем его пользователям.
2. В области оперативной памяти, называемой состояние сеанса. В отличие от состояния приложения эта область выделяется отдельно для каждого пользователя и сохраняется в течение сеанса его работы с Веб-приложением (от момента перехода на страницу приложения и до момента закрытия последней его страницы).
3. В структурах базы данных. Это наиболее универсальный и надежный способ хранения контекста приложения. Универсальный потому что не зависит от природы Веб-сервера, а надежный, потому что жизненным циклом состояния приложения и состояния сеанса управляет Веб-сервер, в то время, как информацию в базе данных контролирует Веб-приложение.
Таким образом программист при разработке Веб-приложения должен учитывать все эти факторы. Еще одна важная особенность Веб-разработки в отличии от прикладной программы - это безопасность. Конечно при разработке прикладных программ так же необходимо следить за входными данными от пользователя, но проблема в «настольной» программе не представляет такой большой опасности, так как работает с данными только одного конкретного пользователя. Всё по другому при работе Веб-приложения, в базе данных с которой работает приложение хранятся данные о многих пользователях. Во многих случаях это личные данные, такие как имя, телефон, email, а также среди них могут быть паспортные и другие важные данные. При неправильном построении архитектуры Веб-приложения, в нем могут содержаться ошибки, которые могут привести к утечке данных. Так же при неправильной обработке входных данных злоумышленник может получить доступ к Веб-серверу, в таком случае атаке подвержен не только целевой сайт, но и другие сайты расположенные на сервере, которых может быть очень много на одном Веб-сервере.
В итоге ответственность Веб-разработчика возрастает в разы. Веб-приложение при каждом запросе должно проверять пришедшие данные, определять права пользователя (гость, зарегистрированный, права зарегистрированного), и только после проверки прав производить запрошенные пользователем операции. Так же необходимо проверять данные, которые пользователь передает при заполнение форм на сайте, загрузке изображений, документов на сайт.
Далее будут рассмотрены несколько основных типов атак:
1. Загрузка файлов на сервер
Несмотря на то что, такая уязвимость встречается довольно редко, она несет очень большую опасность. Например при загрузке изображений, если проверять только наличие расширения файла ( jpg, png, gif для изображений) злоумышленник сможет обмануть такую проверке загрузив attack_file.jpg.php на сервер. И зная путь для загрузки изображений сможет запустить свой файл, например по адресу http://some.local/image/attack_file.jpg.php . Веб-сервер интерпретирует с помощью php данный файл, в котором например будет эмулятор консоли. В итоге злоумышленник получит доступ к Операционной Системе с правами Веб-сервера. Далее через проблемы в безопасности других программ, находящихся на сервере, он сможет повысить свои права, и получить полный контроль над сервером. Избежать такой уязвимости можно при более тщательной проверки файлов. К примеру если это изображение, можно попробовать произвести с файлом действия которые возможны только с изображением, попробовать уменьшить его размер. Если функция изменения изображения вернет ошибку, то вероятно файл не является изображением, и его нельзя сохранять на сервере. Так же можно запретить исполнение любых скриптов в папке куда сохраняются изображения.
2 SQL-инъекции.
Довольно распространенная проблема при неправильной архитектуре Веб-приложения. Для эксплуатации этой уязвимости злоумышленнику даже не обязательно передавать какие либо данные через форму. Достаточно подправить URI (унифицированный идентификатор ресурса) запрос в адресной строке. Например скрипт выводит на сайте из Базы Данных одну новость по её идентификатору, адрес будет выглядеть примерно так http://some.local/news.php?id=1 .
В скрипте news.php содержится такой код:
$sql="SELECT * FROM news WHERE id=$_GET[id]"
Использую возможности языка SQL злоумышленник может вывод запроса новости объединить с выводом данных о пользователе. Вот такой запрос выведет вместо новости информацию о пользователе с идентификатором 1. http://some.local/news.php?id=-1 UNION SELECT id,name,pass,email FROM users WHERE id=1