Преподаватель который помогает студентам и школьникам в учёбе.

Особенности алгоритмизации при разработке WEB-приложений (Общие подходы программирования)

Содержание:

Введение

На заре появления Всемирной паутины (WWW - World Wide Web) сайты были статичными, без какой либо интерактивности, взаимодействии с пользователем. Для создания сайта достаточно было использовать язык разметки гипертекста HTML. С развитием интернета сайты стали усложняться, языка разметки уже не хватало для реализации сайтов с такими возможностями, как поисковые системы, форумы и т. п.

Для разработки сайтов стали использовать языки программирования. Одним из первых был Perl, в дальнейшем создавались языки специально для Веб-разработки, либо разработанные с учетом Веб-программирования, такие как PHP, Ruby, Python. Данные языки используются для выполнения каких либо действий (формирования контента, работы с Базой Данных) на серверной стороне.

Для выполнения сценариев на стороне клиента (в браузере) был разработан язык JavaScript, который на данный момент является стандартом во всех современных браузерах. Следует отметить, что теперь JavaScript может использоваться и на серверной стороне, благодаря программной платформе NodeJs.

Особенностью разработки Web-приложений, в отличии от прикладных программ, является использование Клиент-серверной архитектуры. В роли клиента выступает браузер пользователя, в котором происходит отображение содержимого сайта. В роли сервера выступает Web-сервер (Apache, Nginx, IIS) с настроенным на нем интерпретатором языком программирование (PHP, Perl), либо уже откомпилированным приложением. Соответственно Веб-приложение работает не постоянно, а выполняется только в момент запроса клиентом, формируя ответ для клиента (содержимое сайта). Всё это, а так же некоторые другие моменты, накладывает свои особенности при разработке Веб-приложений.

Все примеры и листинги в данной курсовой приведены с использованием языка PHP, JavaScript и СУБД MySQL.

Глава 1. Общие подходы программирования

Совокупность подходов, идей и понятий называется «Парадигмой программирования». Несмотря на свои особенности, в Веб-программировании используются те же подходы, что и в других областях разработки ПО. Далее будут кратко рассмотрены несколько Парадигм программирования.

Процедурное программирование — при данном подходе выполнение программы сводится к последовательном выполнению операторов, функций, условий, циклов. Полученные данные в ходе выполнения записываются в переменные. Функции могут выдавать различный результат в зависимости от состояния переменных. Особенностью такого подхода является, что программа разбивается на этапы, и выполняется этап за этапом.

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

Объектно-ориентированное программирование ООП — использует в качестве основных логических элементов объекты, а не алгоритмы. Каждый объект является экземпляром одного определенного класса. В ООП выделяют несколько основных понятий.

Абстрагирование — Выделение значимой информации и исключение незначимой. Программист работает с определенным набором свойств и методов.

Инкапсуляция — Сокрытие, разграничение доступа различных частей программы.

Наследование — Возможность системы, позволяющая создать новый класс на основе существующего, наследовав функциональность родительского класса, частично дополнив и/или расширив существующий функционал родительского класса.

Полиморфизм — Возможность, позволяющая использовать объекты с одинаковым интерфейсом, без информации о внутреннем устройстве объекта. Внутреннее устройство при этом может быть совершенно разным, при условии одинакового интерфейса у объектов.

В Веб-программирование чаще всего используется Процедурный подход, либо ООП. При разработке сложных и больших (сложнее, чем сайт из нескольких страничек и формы обратной связи) Веб-приложений чаще всего используют Объектно-ориентированный подход. Это позволяет разделить приложение на несколько независимых частей, которые можно изменять, без опасности повредить работу других частей приложения. Например выделить работу с базой данных в отдельный класс, снабдить его методами для чтения, изменения, удаления данных. Тогда при смене СУБД, можно изменить только класс для работы с базой данных, снабдив его такими же методам, не изменяя всю остальную логику и структуру Веб-приложения. Также такой способ позволяет разделить труд программистов в команде. Одна часть команды занимается разработкой логики работы приложения, другая занимается формированием страниц на стороне пользователя (версткой HTML кода).

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

Глава 2. Вкрапления в код. Код в шаблоне

При появлении первых интерактивных (с иcпользованием языков программирования) сайтов непосредственно кода было очень мало. В этом случае вполне можно было писать программу вперемешку с HTML версткой. Пример с вкраплением HTML-верстки в PHP скрипт показан на Листинге 1:

<?php // Листинг 1

$heading = 'Последние новости';

echo '<html><head><title>'.$heading.'</title></head><body>';

echo '<h2>'.$heading.'</h2>';

echo '<ul>';

$f = fopen("../last_news.txt", "r");

for ($i=1; !feof($f) && $i <=10; $i++)

{

echo "<li><strong>Новость № $i</strong>". fgets($f, 1024); echo "</li>";

}

echo '</ul>';

echo '</body></html>';

В этом примере сценарий открывает текстовый файл с новостями и выводит первые 10 строк на странице. Здесь в одном файле выполняется PHP сценарий и формируется HTML код. Даже в таком небольшом примере видно, что код плохо читается. При желании переделать отображение новостей из списка в таблицу, необходимо четкое понимание на какой строчке что делает код, иначе можно испортить всю программу. Такой вариант с вкраплением подходит разве что только для какой либо микро задачи. Например: чтение лога, отображение нескольких параметров. При таком подходе изменение программы, в случае необходимости добавить дополнительный вывод информации из базы данных, либо добавления в верстку сценария на JavaScript, становится практически нереальным, чтобы при этом ничего не испортить в уже работающем коде.

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

Пример разделения шаблона и кода показан в Листинге 2:

<?php // Листинг 2

$f = fopen("../last_news.txt", "r");

$news_storage = array();

for ($i=1; !feof($f) && $i <=10; $i++)

{

$news_storage[] = ['number' => $i, 'text'=>fgets($f, 1024)];

}

$heading = 'Последние новости';

<html>

<body>

<ul>

<?php foreach ($news_storage as $news) { ?>

<li><strong>Новость № <?=$news['number']?></strong>

<?=$news['text']?>

</li>

<?php } ?>

</ul>

</body>

</html>

В данном примере PHP код и HTML верстка разделены. При желании можно нижнюю часть с версткой выделить в отдельный файл HTML шаблона, и отдать верстальщику для внесения желаемых изменений в шаблон. Небольшие участки PHP кода не осложняют чтение, и при минимальных знаниях языка программирования не вызовут трудности при работе с шаблоном. Соответственно верхнюю часть кода программист может переделывать не опасаясь повредить верстку, так как здесь не используется ни единого тэга. Данные из файла записываются в массив, из которого в последующем выводятся данные в соответствии с HTML версткой в нужном месте на странице. При желании можно даже изменить получение данных, например получать их из другого файла, получать не по 10 записей, а по 15. Или даже изменить хранилище данных с файла на Базу Данных (БД). Главное записать эти данные в ассоциативный массив с такими же ключами. Получение данных можно обернуть в функцию, добавить условия проверки существования файла.

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

Например вывод новостей необходим на «Главной» странице в ограниченном количестве и на странице «Новости» в полном объеме, так же у каждой страницы есть свой «Заголовок» который хранится в переменной heading. В этом случае нельзя один и тот же участок кода использовать на разных страницах, хотя он и отличается незначительно. Так же при изменении хранилища с файла на БД придется изменять код во всех участках. А при выводе данных из разных источников и взаимодействии с пользователем такой код становится очень трудно поддерживать. Отсюда следует вывод что такой способ подходит только для реализации очень простых сайтов, на которых практически нет никакого взаимодействия с пользователем, очень простая структура и иерархия разделов.

Глава 3. ООП MVC

Наиболее популярный подход на данный момент при разработке сайтов от довольно простых до вполне серьезных Веб-приложений является MVC.

Аббревиатура MVC расшифровывается как Model View Controller и переводится как Модель Представление Контроллер. Это шаблон проектирования, в котором разделены данные приложения, пользовательского интерфейса и управляющей логики, таким образом что изменение любого из этих компонентов может осуществляться независимо. Данный шаблон проектирования появился еще до появления WWW. Со временем его переняли Веб-разработчики, и вкупе с ООП подходом MVC стал удобным и мощным способом для разработки приложений в Веб. Этот шаблон проектирования используется в большинстве фреймворков для разработки Веб приложений, например: Yii2, Laravel, Ruby on Rails и другие.

Model (Модель) — это объект приложения, содержит в себе бизнес-логику приложения. Модель полностью независима от остальных частей приложения. Она ничего не знает об элементах дизайна, о том каким образом он будет отображаться. Также ничего не знает о контроллере, где и как будут вызываться методы модели. Таким образом достигается результат, позволяющий изменять представление данных, их отображение, не трогая саму Модель. Она обладает знаниями только о себе, и не знает о контроллерах и представлениях. Модель может быть слоем данных (База данных, XML-файл), а так же содержать логику для работы с этими данными.

View (Представление) — отображает данные полученные от модели, но никак не может влиять на модель. В Веб-приложениях содержит HTML код для отображения в браузере. Грубо говоря представление может только «читать» данные из модели. Представление вызывается контроллером, который ей передает данные из модели, а так же данные полученные в ходе работы самого контроллера.

Controller (Контроллер) — Получает запрос, и на основе данных из модели формирует представление. В Веб приложении получает запрос от браузера клиента (POST, GET и другие). На основе полученных сведений вызывает необходимые методы модели и на основе данных полученных от модели формирует представление, либо совершает какие либо другие действия. Например перенаправление на другие страницы сайта, формирование данных в специальных форматах при AJAX запросах и прочее.

Проще говоря браузер клиента обращается всегда к контроллеру, который производит некоторые действия и возвращает клиенту результат выполнения этих действий в браузер в виде сформированного представления: HTML страницы, XML данных.

Без-имени-1.png Стандартная последовательность действий в Веб приложении при использовании паттерна MVC представлена на рисунке 1.

На этом рисунке схематично изображена работа паттерна MVC. На основе этой схемы можно расписать шаги которые выполняются при посещении пользователем сайта.

1. При заходе пользователя на сайт, Веб-приложение запускает скрипт инициализации, который на основе параметров конфигурации (данные для доступа к БД, часовой пояс, базовый домен и прочих) создает экземпляр приложения и запускает его на исполнение.

2. Приложение на основе данных полученных от пользователя (маршрута, GET, POST запросов) определяет контроллер и действие. Например по маршруту http://domen.local/about приложение на основе правил маршрутизации определяет, что надо вызвать метод actionAbout() в контроллере.

3. Приложение создает экземпляр контроллера и запускает метод действия actionAbout() .

4. В методе контроллера создается экземпляр Модели AboutModel и вызывается метод getData(), полученные данные из модели передаются контроллером в представление. Так же могут происходить различные действия как с моделью, так и без нее, в зависимости от полученных данных контроллером.

5. На последнем этапе контроллер формирует представление с полученными данными из модели и отправляет обратно пользователю в браузер сформированную HTML страницу. Вместо страницы HTML могут быть данные в любом другом формате, включая изображения, документы в форматах PDF doc и т.д.

Ниже приведен упрощенный пример контроллера, модели и представления на базе фреймворка 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>

</head>

<body>

<ul>

<?php foreach ($data as $news) { ?>

<li>

<strong>Новость № <?=$news['number']?> -

<?=$news['heading']?></strong>

<?=$news['text']?>

</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

Так как чаще всего администратор зарегистрирован одним из первых, даже если с идентификатором 1 результат не будет получен, перебрав еще несколько значений можно будет получить данные доступа администратора сайта. Даже если злоумышленник не узнает данные доступа администратора, он сможет получить личные данные пользователей, что тоже является серьезной проблемой в безопасности. Особенно если среди личных данных есть данные документов, информация о счетах и т.п. В больших проектах такая ошибка может закрасться в неочевидных местах. И найти место в приложение подверженном SQL-инъекции бывает достаточно трудно. Избежать таких ошибок можно при правильном планировании архитектуры приложения. При использовании шаблона MVC, все данные возвращает только Модель. Соответственно проверив только Модели на наличие фильтрации данных при SQL запросах, можно не опасаться эксплуатации этой уязвимости.

3. XSS атака

Атака Cross-Site Scripting – межсайтовый скрптинг. Тип атаки при котором на сайт через различные уязвимости внедряется JavaScript код, который производит вредоносные действия. Например может прочитать Cookies файл который необходим для "узнавания" сервером пользователя на сайте и отправить его с помощью AJAX запроса злоумышленнику. Далее злоумышленник подставив значения Cookies у себя в браузере получит доступ к сайту с правами атакуемого пользователя. Если атаке был подвержен администратор, то соответственно получит доступ администратора.

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

Он получает из запроса переменную var и выводит ее на экране. В штатном режиме адресная строка выглядит примерно так

http://some.local/page.php?var=About

PHP скрипт отработает и выведет

<h2>About</h2>

Изменив в адресной строке значение переменной var можно эксплуатировать XSS уязвимость

http://some.local/page.php?var=<script>alert(‘xss’)</script>

PHP скрипт отработает и выведет

<h2><script>alert(‘xss’)</script></h2>

А в браузере у пользователя подверженного атаке выведется так называемое alert сообщение. Изображение 2.

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

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

Более опасной является активная уязвимость. Для ее эксплуатации, злоумышленнику необходимо найти форму на сайте, которая недостаточно хорошо фильтрует входные данные и записывает их в базу данных, после чего выводит на какой то странице. К примеру" форма комментария", если злоумышленник отправит через такую форму зловредный код, то он будет срабатывать у всех посетителей сайт, которые будут просматривать страницу с этим комментарием, в котором находится зловредный код.

Еще более опасная разновидность XSS это атака CSRF/XSRF – Межсайтовая подделка запросов. Такая атака позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы средства защиты от CSRF

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

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

В реальности часто эти уязвимости эксплуатируются совместно. Например через SQL инъекцию можно получить данные доступа администратор, и тогда через форму редактирования контента загрузить вредоносный PHP скрипт. Либо так же через SQL инъекцию, произвести запись вредоносного JavaScript кода, который будет выполняться на страницах посетителей.

При эксплуатации SQL инъекции уже не важно, что на сайте везде происходит проверка входных данных на наличие тэга <script>, так как злоумышленник запишет свой код напрямую в базу данных, через SQL запрос.

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

Для того чтобы уменьшить риск атак необходимо производить комплекс мер. Например установить на сайт SSL сертификат, для передачи данных через шифрованное соединение HTTPS. Правильно настроить Веб-сервер, СУБД, следить за обновлениями безопасности программ работающих на сервере. Скрыть доступ от внешнего мира всех серверных приложений (например СУБД), кроме Веб-сервера. В своих проектах использовать библиотеки, компоненты из надежных источников. При использовании CMS (систем управлением контентом) и фреймворков следить за актуальностью их версий, вовремя обновлять при обнаружение в них уязвимостей. Правильно и грамотно разрабатывать архитектуру своего приложения.

Не хранить в передаваемых Cookies файлах никаких личных данных, даже идентификатора пользователя. Лучше всего хранить идентификатор сессии с проверкой IP адреса. В таком случае даже если злоумышленник украдет Cookies файл, он не сможет ничего узнать о пользователе и воспользоваться открытой сессией.

Правильная настройка прав и разрешенных команд в СУБД позволит если не избежать, то хотя бы минимизировать опасность при эксплуатации SQL инъекции.

Кроме всех этих мер, необходимо проследить, чтобы пользователь использовал безопасные пароли. Пароль не должен совпадать с логином, минимальная длина должна быть 6, а лучше 8 символов. Использовать подтверждение email адреса или номера телефона при регистрации, чтобы в случае восстановления пароля, код восстановление приходил на правильный адрес или телефон.

Глава 5. Приложение на стороне клиента. JavaScript. AJAX

С развитием Веба, возникла необходимость поддержки языка, который мог бы выполняться на стороне клиента, в браузере. Со временем таким языком стал JavaScript (JS), который на данный момент является общепринятым стандартом. На начальном этапе JS использовался для каких-то небольших действий на стороне клиента (проверка заполнения формы, всплывающие подсказки), и в основном не воспринимался как серьезный инструмент для создания приложений. Но тенденции последнего времени привели к тому что JavaScript стал довольно мощным языком разработки. С языка который исполняется только в браузере (фронтенда) он так же переместился и на серверную часть (бэкенд), яркий пример платформа Node.JS. Для него разработано много библиотек и фреймворков. Наиболее известная библиотека JQuery. Наиболее известные фреймворки Angular.JS React.Js.

Развитие языка позволило ему реализовывать сложные алгоритмы на стороне клиента, тем самым разгружая Веб-сервер. И даже какое то время работать странице браузера в автономном режиме, при недоступности Веб-сервера. Некоторые фреймвокрки позволяют вообще всю генерацию HTML кода производить на стороне клиента, а к серверу обращаться только для получения данных из базы данных и служебной информации. Всё это привело к тому, что сейчас многие Веб сайты состоят из двух приложений. Одна часть, называемая бэкенд, работает на сервере, она уже не занимается форматированием HTML контента, либо занимается в меньшей мере, основная задача такого приложения отдавать результирующие данные на поступившие запросы от клиентского приложения. Другая часть, называемая фронтенд, исполняется на языке JS на стороне клиента в браузере. Страница уже не перезагружается при каждом запросе. Запросы от клиента к серверу работают через AJAX и становятся незаметными для пользователя. Такой подход приводит к усложнению сценариев, и как следствие созданию полноценных программ со своими алгоритмами, паттернами.

С развитием Веба и языка JavaScript появилась необходимость в механизме для обращения к серверу без перезагрузки страницы, незаметным для пользователя. Таким механизмом стала технология AJAX.

AJAX ( Asynchronous JavaScript and XML) – способ построения интерактивных пользовательских web-приложений посредством фонового обмена информацией браузера с сервером. Термин AJAX обозначил Джесси Джеймс Гаррет в 2005 году. Первыми приложениями, использующими данную технологию, стал сервис карт Google Maps и почтовый клиент Gmail.

Использование AJAX для сайта позволяет улучшить его внешний вид и удобство (приложения становятся более удобными и быстрыми для посетителей).

Принцип работы

AJAX базируется на технологии обращения к серверу без перезагрузки страницы (XTMLHttpRequest, создание дочерних фреймов или тега <script>) или использовании DHTML, позволяющего динамически изменять содержимое. Формат передачи данных – XML или JSON. AJAX можно реализовать в разных языках программирования: PHP, Ruby on Rails, ASP.NET и других. В коде web-страниц широко используется JavaScript для прозрачного обмена данными клиента с сервером. Пользователи взаимодействуют со стандартными HTML элементами, динамическое поведение которых описывается на JavaScript.

Ниже рассмотрим примеры использования этой технологии.

Пример реализации AJAX технологии на стороне клиента, на языке JavaScript представлен на Листинге 6

// Листинг 6

function sendAjax(host, data)

{

var xhr = new XMLHttpRequest();

xhr.open('POST', host, true);

xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");

xhr.send(data);

}

sendAjax("http://some.local/ajax/get", "?data=Some Data");

В данном примере функция использует объект XMLHttpRequest, который позволяет создавать HTTP запросы к серверу. Далее создается сам запрос, в данном случае POST. Передаются HTTP заголовки. Первый указывает какой тип данных передается. Второй заголовок указывает что запрос является AJAX запросом. Вызывая функцию необходимо указать хост куда будут передаваться данные и сами данные. На стороне сервера мы можем принять эти данные.

Пример принятия данных на стороне сервера на языке PHP. Листинг 7

// Листинг 7

function is_post() {

if($_SERVER["REQUEST_METHOD"] == "POST") {

return true;

}

return false;

}

function is_ajax() {

if(isset($_SERVER["HTTP_X_REQUESTED_WITH"]) &&

!empty($_SERVER["HTTP_X_REQUESTED_WITH"]) &&

strtolower($_SERVER["HTTP_X_REQUESTED_WITH"]) == "xmlhttprequest")

{

return true;

} else {

return false;

}

if(is_ajax() && is_post()){

$data = $_POST["data"];

return $data;

}

В данном листинге можно получить данные от браузера. Функцией is_post() проверяем что запрос является POST запросом. Функцией is_ajax() проверяем пришедшие заголовки, убеждаемся что запрос является AJAX запросом. После этого мы можем получить данные обратившись по ключу data к глобальной переменной $_POST, которая содержит в себе все переданные данные методом POST.

Таким образом происходит фоновая (незаметная) передача данных от браузера к серверу. Если на сервере вернуть данные в формате JSON или XML на стороне клиента их также можно будет принять в фоновом режиме.

Для сайта применением AJAX имеет ряд преимуществ:

1.экономия трафика пользователя (вместо обновления всей страницы, загружается ее небольшая изменившаяся часть);

2.снижение нагрузки на сервер. К примеру, на странице личных сообщений форума при выделении пользователем прочитанных писем сервер вносит изменения в БД и отправляет скрипту клиента ответ о выполнении операции без повторного создания страницы и ее передачи;

3.ускорение реагирования интерфейса на команды пользователя.

Так же есть и недостатки, связанные в основном с поисковой оптимизацией сайтов

1. Не всегда возможна интеграция со стандартным набором инструментов браузера. Так как интернет-обозреватели не регистрируют в истории переходы по страницам, нельзя воспользоваться кнопкой «Назад». В некоторых случаях нет возможности добавить в закладки нужный материал;

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

3. Неправильный учет статистики перемещения пользователя по сайту;

4. Усложнение контроля целостности типов и форматов, так как процессы форматирования данных частично переносятся на сторону клиента;

5. В браузере пользователя должен быть включен JavaScript.

Альтернативой AJAX выступают Java-аплеты, JavaFX, технологии ActionScript, Flash Remoting, Adobe Flex, составляющие технологическую основу Rich Internet Applications от Macromedia, и Silverlight от корпорации Microsoft.

Заключение

В этой курсовой работе я попробовал охватить самые основные на данный момент технологии, парадигмы, принципы разработки ПО. За небольшой срок, около 20 лет, Веб-сайты прошли большой путь от статичных страничек, до серьезных Веб-приложений, которые практически вытеснили некоторые "настольные" программы, например почтовые клиенты. Первые Веб-сайты, с использованием языков программирования, практически не содержали сложных алгоритмов. Использовались небольшие вкрапления кода, для автоматической генерации контента. С развитием Интернета, увеличением пропускной способности каналов связи, Веб-сайты становились все сложнее. Так же развивались языки программирования для разработки сайтов. Это можно увидеть на примере языка PHP. До пятой версии в нем не было нормальной поддержки парадигмы ООП (сокрытия данных, поддержки интерфейсов и много другого), но постепенно перенимая лучшее из таких языков как Java, C++ он стал пригодным для разработки сложных систем. Благодаря этому стало возможно использовать многие паттерны программирования, например MVC. Всё это позволяет на данный момент создавать сложные, масштабируемые приложения, сервисы для Веба. Похожий путь, хотя и со своими особенностями прошел язык JavaScript, который на первоначальном этапе не воспринимали как полноценный язык программирования. Но развитие Интернета привело к тому, что уже сейчас на нем создаются сложные приложения, которые работают в браузере, и даже могут работать какое то время независимо от сервера. Одним из первых таких приложений была почта Gmail от компании Google. На данный момент также идет бурное развитие языка разметки HTML и каскадных таблиц стилей CSS. Уже в них начинаются появляются возможности, присущие языкам программирования (например функция calc в CSS).

С развитием языка JavaScript появилась библиотека WebGL, которая позволяет работать с 3D графикой прямо в браузерах.

Исходя из этого можно смело заявить, что сейчас в Веб-программировании используются самые передовые решения, подходы, алгоритмы. Каким путем пойдет процесс развития дальше, трудно предположить, ясно лишь одно, что Веб-приложения будут всё больше вытеснять “настольное” ПО и захватывать всё новые ниши.

Список использованных источников

1. Приемы объектно-ориентированного проектирования. Паттерны проектирования/ Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес и др.; - СПб:. Питер, 2012

2. PHP5 / Д. Котеров, А. Костарев; СПб.: БХВ-Петербург, 2005

3. Yii. Сборник рецептов/ А. Макаров; М.: ДМК-Пресс, 2013

4. Язык программирования С++/ Бьерн Страуструп; М.: Бином, 2006