Мы докажем, что 2+2=5, и 95% из вас даже не поймут, в чем подвох
Над этой математической головоломкой бьются лучшие умы мира. А сегодня и вы можете попробовать решить эту задачку. Если вас не пугают неожиданные логические цепочки, обязательно попробуйте решить этот пример!
HeadInsider
Знаете ли вы, что 2+2 может быть равно 5? Не торопитесь возмущаться, даже если в школе у вас было «отлично» по математике! Мы не разрушаем основные арифметические постулаты, а лишь предлагаем с неожиданной точки зрения рассмотреть этот простейший пример.
Итак, каким образом при сложении двоек может получиться пятерка? За основу возьмем 0, который также равен 0:
А если из 20 вычесть 20, а из 25 – 25, то мы вновь получим два нуля. Таким образом, получим математически и логически правильное равенство:
20 — 20 = 25 — 25
Следом представим число 20 как 4×5, а 25 – как 5×5. Поэтому далее получаем такое равенство:
(4 x 5) — (4 x 5) = (5 x 5) — (5 x 5)
А на следующем математическом действии с одинаковыми множителями просто выносим 4 в первой половине и 5 во второй части равенства за скобки. Получаем:
4 x (5 — 5) = 5 x (5 — 5)
Поскольку и в правой, и в левой части равенства одинаковые множители (5 — 5), то по правилам математики мы можем их не учитывать, то есть просто сократить. И получим следующее:
И наконец-то долгожданный финал, если 4 представить как (2 + 2):
2 + 2 = 5
А удалось ли вам осмыслить этот математический алгоритм? Где же тут подвох? Делитесь в комментариях и отправьте ссылку своим друзьям, чтобы взорвать и их чувствительный мозг!
Когда 2+2=5: чем страшны ошибки бизнес-логики приложений и почему их легко не заметить при разработке
М/Ф «В стране невыученных уроков»
Мы как-то писали про SSRF-атаку, которая входит в список наиболее распространенных уязвимостей OWASP Top 10. Однако мир уязвимостей намного разнообразнее и, конечно же, не ограничивается этим списком. Сегодня мы хотим рассказать про уязвимости, связанные с бизнес-логикой. Что в них необычного? Это как доказать, что 2+2=5. Последовательность действий кажется правильной, все операции разрешенными, а результат совсем не тот, который закладывался при разработке. Но мы же знаем, что в доказательстве есть ошибки! Рассмотрим, как подобные задачки решаются при анализе защищенности и какие неожиданные результаты можно получить, используя обычную функциональность приложений.
Бизнес-логика и какие уязвимости в ней могут быть
Для начала немного теории. Бизнес-логика обеспечивает выполнение задач, которые закладывались при проектировании приложения, то есть определяет его поведение при всех возможных сценариях использования. В свою очередь, уязвимости бизнес-логики связаны с недостатками в архитектуре или ошибками, допущенными при реализации логики приложения. Это может в итоге привести к взаимодействию с приложением по непредусмотренному разработчиками сценарию.
Вот простой пример. Для защиты от атак подбора пароля в приложении реализован механизм CAPTCHA. При работе через веб-интерфейс после трех неудачных попыток ввода требуется решить типичную задачу с картинками. Однако при прямой отправке запросов на сервер никаких ограничений не предусмотрено. То есть фактически CAPTCHA никак не защищает от атак подбора. Как так получилось, нам остается только догадываться. Возможно, разработчики решили, что никто не будет напрямую обращаются к API. А зря!
Уязвимости бизнес-логики отличаются от большинства других уязвимостей:
они разнообразны, можно сказать, уникальны для каждого приложения. Это связано с особенностями работы и направленностью каждого отдельного приложения;
их трудно обнаружить автоматизированными сканерами. Отсутствие общих схем классификации и способов обнаружения, а также необходимость понимания предметной области делает уязвимости бизнес-логики недоступной целью для автоматизированных сканеров. Например, заметив в корзине покупок товар с отрицательной стоимостью, человек понимает: что-то пошло не так. Но для сканера – это просто числа;
они предполагают манипуляции легитимной функциональностью приложений. В примере выше, для обхода CAPTCHA не было использовано никаких дополнительных инструментов и действий, а только запрос, который использует само приложение.
Нет единой причины появления ошибок бизнес-логики, как нет и единого шаблона их обнаружения. Это и делает поиск подобных уязвимостей сложным и интересным одновременно.
При этом последние годы мы видим, что число логических уязвимостей в мобильных и веб-приложениях растет. Причина простая: повышение сложности приложений, внутренних взаимодействий и компонентов.
Теперь, понимая, что это за уязвимости бизнес-логики и в чем их особенности, перейдем к обещанным «задачкам».
Не простой перебор идентификаторов
Обычное веб-приложение, проходим аутентификацию, открываем профиль пользователя: имя, замаскированное поле пароля, изображение, инфо о себе и т.д. С первого взгляда все выглядит неплохо, но… Оказалось, в этом приложении можно собрать пароли всех пользователей, да еще и необязательно аутентификацию проходить!
Посмотрим на запросы, которые отправляются на сервер при обычной работе приложения:
Запрос для получения информации о пользователе
Обратим внимание на параметр id и поле password, которое содержит пароль пользователя(!). Пробуем заменить идентификатор на любое другое число – в ответе получаем данные другого пользователя. Осталось дело за малым, автоматизируем перебор идентификаторов и собираем список пользователей и их паролей.
Представленный пример содержит сразу две уязвимости:
небезопасное управление паролями – их хранение в открытом виде и передача пользователям;
небезопасные прямые ссылки на объекты – обращение к объектам на основе полученного от пользователя идентификатора.
Управление паролями – это отдельная тема, которой мы не будем касаться в рамках текущей статьи. А вот на небезопасных прямых ссылках на объекты остановимся подробно. Безусловно, подобные уязвимости также относятся к недостаткам контроля доступа (OWASP Top 10, A01:2021 – Broken Access Control) и могут быть расценены как пропущенные проверки прав. Однако посмотрим на проблему именно со стороны бизнес-логики.
Эксплуатация уязвимости кажется тривиальной, однако сама она не так проста. Вернемся к истокам. Предположим, нам необходимо реализовать функциональность профиля. Начнем с общего сценария ее использования. Пользователь хочет посмотреть свой профиль и выбирает соответствующий пункт в меню, после чего на экране появляется страница с его данными. При этом если неизвестно, какой пользователь обратился, сначала он перенаправляется на форму аутентификации. Кажется, что все хорошо: пользователю будет доступен только его профиль. Приступаем к реализации.
Сценарий работы приложения при обращении неаутентифицированного пользователя 
Сценарий работы приложения при обращении пользователя с активной сессией
И вот уже появляется ошибка. При запросе данных (/api/person?id=22) не проверяются ни сессия, ни права пользователя. Поэтому представленный в начале запрос на получение паролей успешно реализуется. При этом изначальные требования о том, что неаутентифицированный пользователь не может просмотреть страницу профиля – выполняется.
Как так получилось? При проработке сценариев использования не было учтено возможное прямое обращение к API. Конечно, обычно мы работаем с приложением через браузер и взаимодействуем с визуальными элементами, и одной проверки сессии в этом случае достаточно. И это одна из самых распространенных ошибок бизнес-логики – неверные предположение о действиях пользователей. Чтобы ее исключить, необходимо проверять права при каждом обращении к API. А это, согласитесь, уже не самая простая задача.
Неучтенный сценарий прямого обращения к API
Небезопасные прямые ссылки на объекты одна из наиболее распространенных уязвимостей в веб-приложениях на протяжении последних лет. В проектах по анализу защищенности мы сталкиваемся с разными ее проявлениями: чтение данных, удаление и копирование объектов и многое другое. При этом подобные уязвимости редко встречаются в единичных экземплярах.
Как мы уже говорили выше, такие ошибки сложно обнаружить автоматизированными сканерами. Правда, технологии не стоят на месте, и сканеры уже умеют обнаруживать подобные уязвимости, хоть и с большим уровнем ошибок первого и второго рода. Поэтому пока лучший способ обнаружить небезопасные прямые ссылки на объекты – ручной анализ. При этом стоит помнить, что идентификаторы – это не только инкрементальные числа. Название файлов, методов, уникальные идентификаторы (GUID) – небезопасные прямые ссылки на объекты могут быть везде. Поэтому необходимо анализировать всю функциональность приложения и проверять полученные результаты по установленной матрице доступа.
Доверяй, но проверяй
Неверные предположения о действиях пользователей также часто становятся причиной избыточного доверия клиентской части приложения. Давайте разберем, почему же клиенты не заслуживают слепого доверия.
Возможно, многие знают хрестоматийный пример изменения цены товара в запросе. Это демонстрация подделки параметров (Parameter Tampering) – достаточно простой атаки, которая также направлена на бизнес-логику приложений. Основная ее идея в том, что разработчики используют скрытые поля на странице или другие зафиксированные параметры как данные из достоверных источников. Стоит отметить, что это могут быть также cookie-файлы, значения заголовков и т.д. То есть все, что может быть изменено при отправке запроса.
Атака Parameter Tampering: изменение параметра price в запросе
Но подмена параметров возможна и в ответах сервера. Это кажется уже не таким очевидным и поэтому становится причиной различных ошибок логики. Достаточно распространенный случай – реализация всевозможных проверок на стороне клиента: прав, баланса, роли и т.д.
Рассмотрим мобильное приложение с реализованной бонусной программой. Принцип работы такой: пользователи получают бонусы за заказы. Эти бонусы можно потратить в специальном каталоге, который полностью открыт всем. Если бонусов недостаточно, товары отображаются как недоступные.
Запрос информации о пользователе: недостаточное количество бонусов для покупок
Обычно параметр balance используются только для удобства пользователя, чтобы тот смог увидеть свои бонусы и доступные товары. При этом ничего не мешает изменить значение этого параметра в ответе и посмотреть, что произойдет. Изменить ответ на запрос можно с помощью перехватывающего прокси, например, Burp Suite.
Правило в Burp Suite для автоматической замены значения параметра в ответе 
Запрос информации о пользователе: изменение количества бонусов для покупок
Как и можно было предположить, на экране отображается введенное нами значение бонусов, а товары в каталоге теперь доступны для добавления в корзину. Попытаемся оформить заказ – все проходит успешно. В итоге получается, что товар приобретен даже при недостаточном количестве бонусов.
Все дело в отсутствии проверки баланса бонусов на стороне сервера. Она реализована только на стороне клиента, а на стороне сервера происходило списание, о чем свидетельствовал отрицательный баланс бонусов после покупки.
Описанный выше сценарий покупки товаров за бонусы
Некорректные проверки прав также часто встречаются в одностраничных приложениях (Single Page Application, SPA), в которых в зависимости от уровня привилегий отображается тот или иной интерфейс. В совокупности с ранее описанной уязвимостью (небезопасные прямые ссылки на объекты) это представляет значительную опасность для всего приложения.
Параметр, которому точно нельзя доверять
Что еще не стоит доверять клиентам – это аутентификацию в сторонних сервисах. Все взаимодействие следует организовывать на стороне сервера, ведь иначе учетные данные или токены доступа могут оказаться в руках злоумышленников. А это может привести к различным потерям.
Вот так просто раскрываются токены, ключи и учетные данные в js-сценариях
Вокруг да около
Предыдущие примеры так или иначе были связаны с проверкой прав и возможностей пользователей. Однако ошибки бизнес-логики не только про это. Далее разберем, как отсутствие определенных ограничений может привести к финансовым потерям, иногда даже достаточно крупным.
Как отмечалось выше, логические уязвимости зачастую появляются в сложных приложениях. Например, онлайн-банки, которые сложны и многокомпонентны по своей природе. Интерес у злоумышленников к уязвимостям в таких приложениях подогревается возможностью кражи денег здесь и сейчас. При проведении работ по анализу защищенности мы также ищем ошибки, которые позволяют быстро получить деньги. Одной из наиболее известных уязвимостей подобного типа является ошибка округления сумм денежных средств.
В качестве простого примера рассмотрим перевод денежных средств в другую валюту. Не будем привязываться к какой-либо реальной валюте и сделаем следующее допущение:
Что такое математика и почему 2×2 может быть 5
Может ли 2×2 = 5? Большинство скажут «нет». Более знакомые с математикой скажут что-то в стиле «нет в рамках поля вещественных чисел». И вот именно это уточнение делает ответ полностью верным. Потому что в принципе, если не привязываться к существующим полям и операторам, в математике может быть что угодно.
Все дело в том, что математика — не естественная наука. Ее действие разворачивается не в реальном мире, а в мире абстракций. Число — уже абстракция. Точка, прямая — тоже абстракции. Множество — абстракция.
Некоторые абстракции ложатся на некоторые сущности в реальном мире. Так, натуральными числами можно измерять количество, а вещественными — длину. Положение на карте можно считать точкой, а толпу людей — множеством. Другие абстракции не ложатся вовсе — например, многомерные пространства или комплексная плоскость.
Однако сама математика как наука оперирует именно абстракциями, не связывая их с реальным миром.
Но вернемся в 2х2.
Допустим, мы работаем с натуральными числами. Что такое привычное нам арифметическое умножение? Согласно определению, axb = a + a . + a, и так b раз. Блин, очень неудобно на пикабу писать формулы, но суть, думаю, вы поняли.
Но кто сказал, что такое определение — единственно возможное? Что нам мешает определить операцию умножения иным образом? Например так:
axb = a + (a + 1) + (a + 2) + . + (a + b-1). Т.е. b слагаемых начиная с a и далее увеличивая на единицу.
Если мы исследуем эту операцию, станет понятно что она «не очень». Нет коммутативности, нет ассоциативности. На ней не построить ни поля, ни даже кольца. Да что там говорить, множество с такой операцией не будет даже группой. Однако все равно это возможно. Я даже допускаю, что в некоторой очень специфической области такая абстракция «ляжет» на какой-то процесс в реальном мире.
И да, несложно заметить, что с таким умножением 2×2=5 🙂
Возможно, кто-то скажет что «незаконно» использовать слово «умножение» для операций, отличных от арифметического умножения. Это не так — для множеств с двумя операциями, кольцами и полями, обычно одну называют «сложением», а другую — «умножением». Есть сложение и умножение матриц. В булевой алгебре дизъюнкцию (или) иногда называют сложением, а конъюнкцию (и) — умножением. Хотя очевидно, что они отличаются от арифметических.
Так что нет никакого криминала в том, чтобы назвать удобную вам операцию умножением даже если результат будет отличаться от арифметического.
P.S. Спонсором поста стал мой бомбёж от дискуссии в комментах. Свой пост я почистил от лишних эмоций. Если кому интересно, откуда ноги растут, то вот: #comment_260155780
P.P.S. если тема зайдет, расскажу как делить на 0. Нет, не на бесконечно малое в пределе, это скукота, а именно на 0. Как вы поняли, в математике все возможно, надо только правильно аксиоматику подвести)
UPD: Честно говоря, не думал что подобный, в общем-то, безобидный пост вызовет столько негатива. Понял, больше подобных постов не будет. Большая просьба — если очень хочется написать гадость, просто поставьте минус пройдите мимо. Конструктива ваша ругань не принесет, а читать неприятно. Всем добра и с наступающим.
Математика (любая её ветвь) строится на аксиомах и базовых определениях. Из этих аксиом и определений выводится все остальное.
В данном случае вы использовали общепринятое определение и переопределили его. Именно поэтому считаю данный пост неверным.
Ваш пример для матриц и булевых переменных некорректен — там операция называется так же, но определена она над другим множеством и поэтому задается другим (так же общепринятым) способом.
Почему от меня минус? Потому что, если следовать вышей логике придется на каждое утверждение приводить, предварительно, всю систему аксиом и определений
Нухули. Поскольку тангенс подлежащего обычными средствами определить трудно, пусть в данном случае будет синий. Влияние бурундуков отметаем сразу, они свистят, это не мешает, но усложняет и без того нечеловеческую задачу. Которую придется решать стоя, чтобы исключить влияние жопы на результат. Итак. В том месте, где ускоренная кривая пересекает ось понимания, временно ставим вертикальную точку с таймером на 20 минут, которых хватит, чтобы съебаться, если решение будет ложным. Далее. Снимаем с проходящей старухи шляпу, на карте накрываем ей Индию. Получается 14. Но не те 14, которые 7+7, а те, которые 140:10, где 10 — это размерность пиздюлей, необходимых для того, чтобы стронуть с места среднеленивого ишака. Пиздим его и выводим за скобки. В скобках пишем: два китайца чешут яйца на высоком берегу. Это единственная магическая формула, которую мы здесь применяем. После ее применения остается кучка пепла и обугленные, но годные скобки. В которые вводим ишака. В старушечьей шляпе. Оголенную Индию накрываем своей, получается 11. 14+11=25. Минус 20 минут чтоб съебаться — получается 5. Минус подоходный — 4,35. Что, строго говоря, не является решением, но как некруглая цифра вызывает доверие и вполне может служить доказательством для людей, окончивших заочные и вечерние отделения.
Тогда 3 х 220 = 380
«Но кто сказал, что такое определение — единственно возможное? Что нам мешает определить операцию умножения иным образом?»
Люди уже договорились о том, какой смысл несёт термин «умножение». И к этому термину привыкли и менять не собираются. Это и мешает.
Потому что если каждый начнёт в какой-то набор звуков и символов вкладывать свой смысл, то языком пользоваться не получится.
продолжай. расширение границ сознания очень полезно
чтобы не застревали в колее обыденности
Как устроена музыкальная гармония. Пространство кратностей – математик Роман Олейников | Научпоп
Что общего между фортепианной клавиатурой и построчной развёрткой телевизора? 😉 Сколько измерений можно выделить в музыкальной гармонии и что это за измерения? Что такое пространство кратностей и как оно помогает понимать и создавать новую музыку? Почему для построения музыкальной гармонии важны простые числа и что такое микрохроматика? Рассказывает Роман Олейников, математик, музыкальный теоретик, соавтор канала Пространство музыки (Science 4 Music), сотрудник лаборатории биомеханических систем Института машиноведения РАН.
«Математика» калейдоскопа | Лекции по математике – математик Николай Андреев | Научпоп
Как устроена игрушка-калейдоскоп с математической точки зрения? Как сделать калейдоскоп из двух зеркал? На каких геометрических фигурах можно строить калейдоскопы и что произойдёт, если попробовать использовать что-то другое? В чём заключается свойство калейдоскопичности и какой раздел математики описывает связанные с ним закономерности? Рассказывает Николай Андреев, кандидат физико-математических наук, заведующий лабораторией популяризации и пропаганды математики Математического института им. В. А. Стеклова РАН.
90 лет со дня рождения Игоря Васильевича Поттосина
История компьютерных технологий помнит многих героев, но некоторые из них остаются в тени более громких и известных имен. Один из таких людей — Игорь Васильевич Поттосин, советский и российский ученый, внесший огромный вклад в развитие вычислительной математики и математического программирования. Сегодня ему исполнилось бы 90 лет.
Игорь Васильевич Поттосин родился 21 февраля 1933 года в селе Кинель-Черкассы Куйбышевской (ныне — Самарской) области. Окончив с золотой медалью школу в 1950 году, Игорь Васильевич поступил на специальное отделение механико-математического факультета Томского Государственного Университета, где готовили специалистов по направлению «баллистика» для нужд Министерства обороны СССР.
Окончив институт в 1955 году, молодой специалист попал по распределению в Москву, в созданный буквально за год до этого первый советский вычислительный центр Министерства обороны СССР, ЦНИИ-27. Этот военный научно-исследовательский институт появился на свет благодаря инициативе известного ученого, создателя ВЦ-1 и основоположника советской «военной информатики» Анатолия Ивановича Китова. Именно в ЦНИИ-27 испытывали и осваивали первые образцы советских электронно-вычислительных машин, разрабатывали языки программирования и писали программное обеспечение для советских спутников и межпланетных автоматических космических станций, а также для выполнения первых космических полетов с человеком на борту.
В 1958 году один из первопроходцев советской кибернетики Андрей Петрович Ершов начал формировать в Москве отдел программирования при Институте математики СО АН СССР, куда пригласил работать Игоря Васильевича Поттосина. Тот согласился, однако в тот же период институт переезжал из Москвы в Академгородок Новосибирска, и сам Андрей Петрович в силу обстоятельств не мог приехать туда вместе с другими сотрудниками. Поэтому 1 ноября 1958 года руководителем отдела программирования стал Игорь Васильевич Поттосин.
Одна из важнейших работ, в которых он принимал непосредственное участие — создание системы автоматизации программирования «Альфа», опиравшейся на язык Алгол. Началом разработки «Альфа-транслятора» считается выступление А.П. Ершова на состоявшейся в 1959 году Всесоюзной конференции по вычислительной математике с докладом «Какой должна быть следующая программирующая программа?». Именно в нем была сформулирована идея транслятора, «программирующей программы», способной работать с платформенно-независимым языком высокого уровня. С помощью этого инструмента разработчики планировали создавать универсальное ПО, пригодное для использования на ЭВМ разных типов и разных производителей. В своих дневниках Ершов писал: «было бы очень здорово разработать этот язык совершенно независимым от конкретных машин, давая привязку к той или иной машине в виде некоторых коротких общих указаний, касающихся представления чисел в машине и характера выполнения операций». То, что сейчас кажется нам совершенно естественным — существование языков высокого уровня, на которых можно писать приложения для любого «железа», — в 1959 году еще считалось чем-то фантастическим.
Разрабатываемый в Новосибирском Академгородке «входной язык» высокого уровня, получивший условное наименование «сибирский», создавался в качестве универсального средства программирования для решения научных задач. Когда в 1960 году на свет появился Алгол-60, советские ученые с удивлением обнаружили, что его структура во многом напоминает проектируемый ими «сибирский» язык. Было принято решение унифицировать синтаксис этого языка с Алголом: получившийся «гибрид» получил наименование «язык Альфа», а для его компиляции в машинный код применялся «альфа-транслятор», созданием которого занимался Игорь Поттосин.
Именно в Альфа-языке появилась поддержка операций с комплексными числами, язык позволял создавать многомерные массивы, а также использовать переменные, с помощью которых их можно было описывать. Иными словами, «Альфа» имела целый ряд улучшений по сравнению с «классическим» Алголом-60. В 1969 году Игорь Васильевич Поттосин защитил кандидатскую диссертацию на основе своих разработок, а они, в свою очередь, легли в фундамент дальнейшего развития транслятора.
В начале 70-х Поттосин возглавил лабораторию системного программирования в институте математики СО АН СССР, где создавались многопользовательские «системы коллективного использования ЭВМ», а также «универсальный оптимизатор БЕТА», ставший дальнейшим развитием разработанного в 60-х транслятора. Эту должность он занимал до 1990 года, в котором защитил докторскую диссертацию.
Параллельно с работой в Институте Игорь Васильевич Поттосин преподавал в Новосибирском государственном Университете, вырастив несколько поколений выдающихся советских программистов.
Игорь Васильевич скончался 15 декабря 2001 года. На протяжении своей карьеры Поттосин опубликовал 10 научных трудов и несколько монографий, он был удостоен звания Заслуженный деятель науки РФ и награжден Премией Совета Министров СССР за вклад в развитие советской информатики и вычислительной техники. Выпускники Новосибирского университета до сих пор вспоминают его с теплотой — влияние его научных работ на развитие трансляторов языков высокого уровня, вычислительной математики математического программирования будет ощущаться еще долгие годы.
Подпишись на наш блог, чтобы не пропустить новые интересные посты!
2 на 2 равно 5
Нам как-то учительница математики сказала что 2*2=5 и обещала обяснить это на
факультативе. Мне на него не удалось попасть (из лени:)), да вскоре я забыл об этом.
Вспомнил вчера и залез в интернет.
Любителям математики посвещаеться.
2*2=5
Доказательство:
то есть 4=5
25 — 45 = 16 — 36
Далее прибавим (9/2)^2 ко обеим частям ур-ия:
25 — 45 + (9/2)^2 = 16 — 36 + (9/2)^2
5^2 — (2*5*9)/2 + (9/2)^2 = 4^2 — (2*4*9)/2 + (9/2)^2
(5-9/2)^2 = (4-9/2)^2, обе части положительны, можно извлечь квадратный корень
5 — 9/2 = 4 — 9/2
Далее прибавим 9/2 ко обеим частям ур-ия:
5 = 4 что и требовалось доказать
Следовательно 2*2 = 5
2+2=5
Доказательство:
Пyсть 2+2=5.
2*1 + 2*1 = 5*1
Распишем 1, как частное pавных чисел:
1 = (5-5)/(5-5)
Тогда:
2*(5-5)/(5-5) + 2*(5-5)/(5-5) = 5*(5-5)/(5-5)
Умножим левyю и пpавyю части на (5-5), тогда:
2*(5-5) + 2*(5-5) = 5*(5-5)
Отсюда:
0 + 0 = 0
Портал Проза.ру предоставляет авторам возможность свободной публикации своих литературных произведений в сети Интернет на основании пользовательского договора. Все авторские права на произведения принадлежат авторам и охраняются законом. Перепечатка произведений возможна только с согласия его автора, к которому вы можете обратиться на его авторской странице. Ответственность за тексты произведений авторы несут самостоятельно на основании правил публикации и законодательства Российской Федерации. Данные пользователей обрабатываются на основании Политики обработки персональных данных. Вы также можете посмотреть более подробную информацию о портале и связаться с администрацией.
Ежедневная аудитория портала Проза.ру – порядка 100 тысяч посетителей, которые в общей сумме просматривают более полумиллиона страниц по данным счетчика посещаемости, который расположен справа от этого текста. В каждой графе указано по две цифры: количество просмотров и количество посетителей.
© Все права принадлежат авторам, 2000-2023. Портал работает под эгидой Российского союза писателей. 18+